Merge the relaxation and restriction paths to both only need to adjust
permissions. This avoids un-map + re-map on the restriction path; and
avoids installing an annotated entry on the relaxation path (which
will cause a translation fault on first access by the host).
Bug: 308373293
Change-Id: I9c7a6ac149aad64b19a5ce7808334188475b27cc
Signed-off-by: Keir Fraser <keirf@google.com>
When splitting a block mapping, we install a table entry pointing to an
empty page and recreate the new entries lazily as we fault them in. For
page-tables with the KVM_PGTABLE_S2_IDMAP flag, this can result in
unnecessary translation faults.
When splitting a block for a page-table with KVM_PGTABLE_S2_IDMAP set,
pre-populate the newly allocate page-table page with contiguous ptes
based on the attributes of the block.
Bug: 308373293
Change-Id: I0c53d048de913e193830caef93d75755270db709
Signed-off-by: Will Deacon <willdeacon@google.com>
Signed-off-by: Keir Fraser <keirf@google.com>
Do not re-use stale state_data on subsequent vcpu runs as the stale data
could be interpreted by Gunyah and rejected.
Bug: 268234781
Change-Id: I3d4bf7a922da1e0e85006ffa58b64a74e320d3c9
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
timerfd doesn't create any wakelocks, but eventpoll can. When it does,
it names them after the underlying file descriptor, and since all
timerfd file descriptors are named "[timerfd]" (which saves memory on
systems like desktops with potentially many timerfd instances), all
wakesources created as a result of using the eventpoll-on-timerfd idiom
are called... "[timerfd]".
However, it becomes impossible to tell which "[timerfd]" wakesource is
affliated with which process and hence troubleshooting is difficult.
Adding vendor hooks to allow vendor to assign appropriate names to
timerfd descriptors and eventoll wakesource.
Bug: 155142106
Signed-off-by: Manish Varma <varmam@google.com>
Change-Id: I330a42ab48bed4b26d5eb2f636925c66061165ec
(cherry picked from commit 0ff110fbb3)
This reverts commit 9f67f4f500.
Vanir complained that this fix was missing, but only from this branch.
Let's bring it back and see how the ABI checker behaves.
Bug: 275041864
Bug: 308350116
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I1fc248582347a295d9168bbd8e55dbd6880e34ed
Upstream commit: 63e44bc520
Check the memory operand of INS/OUTS before emulating the instruction.
The #VC exception can get raised from user-space, but the memory operand
can be manipulated to access kernel memory before the emulation actually
begins and after the exception handler has run.
[ bp: Massage commit message. ]
Bug: 309733863
Fixes: 597cfe4821 ("x86/boot/compressed/64: Setup a GHCB-based VC Exception handler")
Reported-by: Tom Dohrmann <erbse.13@gmx.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 57d0639f60)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Iac1c2f15cc922ab215d57654b004d020a0b65e53
Upstream commit: b9cb9c4558
Check the IO permission bitmap (if present) before emulating IOIO #VC
exceptions for user-space. These permissions are checked by hardware
already before the #VC is raised, but due to the VC-handler decoding
race it needs to be checked again in software.
Bug: 309733863
Fixes: 25189d08e5 ("x86/sev-es: Add support for handling IOIO exceptions")
Reported-by: Tom Dohrmann <erbse.13@gmx.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Tom Dohrmann <erbse.13@gmx.de>
Cc: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit def94eb9a8)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ia520acc67da21353148fd07a3a8e48ee8a97d364
CPU errata 2441007 (Cortex-A55) and 2441009 (Cortex-A510) are categorised
as "rare" by Arm and consequently the workaround is not intended to be
deployed in practice as the issue is not expected to occur in real-world
environments.
Given that the cost of the workaround, which issues additional broadcast
TLB invalidation requests, has been shown to impact kswapd significantly
on Pixel devices, disable the workaround following Arm's recommendation.
Bug: 306231846
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I39b6d9736cfa79827321151b45774f62c8d1a747
(cherry picked from commit 4ba6c3197c)
Adding the following symbol:
- __cma_alloc
Bug: 308881290
Change-Id: I5b3ffb0c804dc636355c1462aaa6e96b1189446b
Signed-off-by: Richard Chang <richardycc@google.com>
In huge uevents generating system, especially for user apps who have
small size of rcvbuf socket, it has been reported that netlink overrun
happens quite frequently.
Moreover, if there's no POLLERR (caused by this netlink overrun) handler
in user apps, the system can almost be stucked by calling 'poll' repeatedly.
Regarding this issue, I have sent a kernel netlink patch to linux
maintainers and got replied that this is absolutely user app's problem,
must not addressing kernel.
Until Android team look into this issue and some modification comes out,
we need kernel patch for temporary. To minimize the effect by this patch
to the others who have never met this issue, I would like to just add
netlink's dedicated poll and its hooks.
Please refer to below v1/v2 patch links for history.
v1: https://lore.kernel.org/netdev/20231110110002.7279f895@kernel.org/T/#t
v2: https://lore.kernel.org/netdev/d599922fd89b3e61c7cf531a03ea8b81cbcb003e.camel@redhat.com/T/#t
Bug: 300009377
Link: https://lore.kernel.org/netdev/d599922fd89b3e61c7cf531a03ea8b81cbcb003e.camel@redhat.com/T/#t
Change-Id: I4f11399d61c10332ba05bac64cfa1e92bb111565
Signed-off-by: Jong eon Park <jongeon.park@samsung.com>
lru_cache_disable is not trivial cost since it should run work
from every cores in the system. Thus, repeated call of the
function whenever alloc_contig_range in the cma's allocation loop
is called is expensive.
This patch makes the lru_cache_disable smarter in that it will
not run __lru_add_drain_all since it knows the cache was already
disabled by someone else.
With that, user of alloc_contig_range can disable the lru cache
in advance in their context so that subsequent alloc_contig_range
for user's operation will avoid the costly function call.
Bug: 313795505
Change-Id: Icbb0e6dbf74644d45f562fd1d845888ca1f1f347
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 816567b17866ca3f9a11e670bd52c82335cbb448)
This patch enhances the CMA API with support for failfast mode,
utilizing the __GFP_NORETRY flag. This mode is specifically designed
for high-order bulk allocation scenarios, enabling the CMA API to
avoid prolonged stalls resulting from blocking pages such as those
undergoing page writeback or page locking. Instead of stalling, the
API will continue searching for readily migratable pages across
different pageblocks.
The original patch link:
Link: https://lore.kernel.org/linux-mm/YAnM5PbNJZlk%2F%2FiX@google.com/T/#m36b144ff81fe0a8f0ecaf6813de4819ecc41f8fe
Bug: 308881290
Change-Id: I1c623f17fb49c26005aaffc17330cf820ce6585c
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 3390547fec36527ed15dd213ee55d397f83ffa46)
INFO: type 'struct fscrypt_info' changed
member 'u8 ci_data_unit_bits' was added
member 'u8 ci_data_units_per_block_bits' was added
type 'struct fscrypt_policy_v2' changed
member '__u8 log2_data_unit_size' was added
member changed from '__u8 __reserved[4]' to '__u8 __reserved[3]'
offset changed from 32 to 40
type changed from '__u8[4]' to '__u8[3]'
number of elements changed from 4 to 3
Bug: 299136786
Bug: 302588300
Change-Id: Idbbc2123961a41d395323c72cef67d94bdd17ab0
Signed-off-by: Eric Biggers <ebiggers@google.com>
Until now, fscrypt has always used the filesystem block size as the
granularity of file contents encryption. Two scenarios have come up
where a sub-block granularity of contents encryption would be useful:
1. Inline crypto hardware that only supports a crypto data unit size
that is less than the filesystem block size.
2. Support for direct I/O at a granularity less than the filesystem
block size, for example at the block device's logical block size in
order to match the traditional direct I/O alignment requirement.
(1) first came up with older eMMC inline crypto hardware that only
supports a crypto data unit size of 512 bytes. That specific case
ultimately went away because all systems with that hardware continued
using out of tree code and never actually upgraded to the upstream
inline crypto framework. But, now it's coming back in a new way: some
current UFS controllers only support a data unit size of 4096 bytes, and
there is a proposal to increase the filesystem block size to 16K.
(2) was discussed as a "nice to have" feature, though not essential,
when support for direct I/O on encrypted files was being upstreamed.
Still, the fact that this feature has come up several times does suggest
it would be wise to have available. Therefore, this patch implements it
by using one of the reserved bytes in fscrypt_policy_v2 to allow users
to select a sub-block data unit size. Supported data unit sizes are
powers of 2 between 512 and the filesystem block size, inclusively.
Support is implemented for both the FS-layer and inline crypto cases.
This patch focuses on the basic support for sub-block data units. Some
things are out of scope for this patch but may be addressed later:
- Supporting sub-block data units in combination with
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64, in most cases. Unfortunately this
combination usually causes data unit indices to exceed 32 bits, and
thus fscrypt_supported_policy() correctly disallows it. The users who
potentially need this combination are using f2fs. To support it, f2fs
would need to provide an option to slightly reduce its max file size.
- Supporting sub-block data units in combination with
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32. This has the same problem
described above, but also it will need special code to make DUN
wraparound still happen on a FS block boundary.
- Supporting use case (2) mentioned above. The encrypted direct I/O
code will need to stop requiring and assuming FS block alignment.
This won't be hard, but it belongs in a separate patch.
- Supporting this feature on filesystems other than ext4 and f2fs.
(Filesystems declare support for it via their fscrypt_operations.)
On UBIFS, sub-block data units don't make sense because UBIFS encrypts
variable-length blocks as a result of compression. CephFS could
support it, but a bit more work would be needed to make the
fscrypt_*_block_inplace functions play nicely with sub-block data
units. I don't think there's a use case for this on CephFS anyway.
Link: https://lore.kernel.org/r/20230925055451.59499-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Bug: 299136786
Bug: 302588300
(cherry picked from commit 5b11888471806edf699316d4dcb9b426caebbef2)
(Reworked this commit to not change struct fscrypt_operations and not
depend on other commits that changed struct fscrypt_operations. Also
resolved conflicts with the HW-wrapped key support.)
Change-Id: Ic3dc56ef3f42d123f812e9037e2cc6f0b24bacc1
Signed-off-by: Eric Biggers <ebiggers@google.com>
[ Upstream commit 93995bf4af2c5a99e2a87f0cd5ce547d31eb7630 ]
The expired catchall element is not deactivated and removed from GC sync
path. This path holds mutex so just call nft_setelem_data_deactivate()
and nft_setelem_catchall_remove() before queueing the GC work.
Bug: 310691882
Fixes: 4a9e12ea7e ("netfilter: nft_set_pipapo: call nft_trans_gc_queue_sync() in catchall GC")
Reported-by: lonial con <kongln9170@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 13e2d49647)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ic5d1d98fe5a749e759869f0789cbb77c4ab5e6c2
export tracepoint symbol trace_mm_vmscan_kswapd_wake so we can hook it in our ko
to capture some kswapd running info.
Bug: 309352303
Change-Id: Ieb37f544502f33e708dacda6cbb552792dfbbc6b
Signed-off-by: liwei <liwei1234@oppo.com>
HID descriptors with Battery System (0x85) Charging (0x44) usage are
ignored and POWER_SUPPLY_STATUS_DISCHARGING is always reported to user
space, even when the device is charging.
Map this usage and when it is reported set the right charging status.
In addition, add KUnit tests to make sure that the charging status is
correctly set and reported. They can be run with the usual command:
$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/hid
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Bug: 305125317
Change-Id: Iad6a8177ad6954ad8ac2b714cc35acffcf2f226f
(cherry picked from commit a608dc1c06)
Signed-off-by: luguohong <luguohong@xiaomi.corp-partner.google.com>
readpages will be triggered on the fuse fs in passthrough mode though
system calls like fadvise. If the daemon isn't aware of the file, this
will likely cause a hang.
For the moment, simply ignore fadvise in this situation
Bug: 301201239
Test: fuse_test, atest ScopedStorageDeviceTest both pass
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I524a84aeeb1b1593e51264fcc37f7cfa66757168
When recovering zoned UFS, sometimes we add the same zone to discard multiple
times. Simple workaround is to bypass adding it.
Reviewed-by: Chao Yu <chao@kernel.org>
Change-Id: Ic1501caa02aea8bdc9d7f00a8bd0d35be2ef4ba1
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit bbd3efed3383e332191c665786c61653826d2ac3
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
We can't trust write pointers when the previous mount was not
successfully unmounted.
Change-Id: If67696db9ab820a805711b43cabb50c796c9f75f
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 9f792ab8e33de727993bbd84ece892e72de18c85)
Use the finish zone command first when a zone should be closed.
Change-Id: Ie38800c2787392980f7914ad10b5f92f6d59e99b
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 3b71661214)
We don't need to report an issue, when the zone write pointer already
points to the end of the zone, since the zone mismatch is already taken
care.
Change-Id: Ifc967abe44521cd239ebac509353c25e36cc7a18
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit c9667b19e2)
Zoned UFS allows only 6 open zones at the same time, so we need to take
care of the count of open zones while mounting.
Change-Id: Ie197b9e9e47b3397446ce2cf97168c9f68fea431
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 04abeb699d)
To keep six open zone constraints, make them not to be open over six
open zones.
Change-Id: If5d02581073f90db4cadd8f928cef9abc5bac8a7
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit e067dc3c6b)
allocated for each slab
Add the tracing interface on the kmalloc_large allocation path,
which can detect the number of pages allocated by the slab,
and if exceeds a threshold, trigger a panic or other actions.
Bug: 312897430
Change-Id: I5575d0e4f91dab1c6e074f3e907fee8ea9327fd7
Signed-off-by: Fangzheng Zhang <fangzheng.zhang@unisoc.com>
We will need vendor hook of set_user_nice with lock to avoid race
condition.
Bug: 300872872
Change-Id: I24fc1e13cc6578dcc418d956a5146ad29ff76a56
Signed-off-by: Rick Yiu <rickyiu@google.com>
ASoC need to use card->mutex with _INIT or _RUNTIME,
but there is no helper function for it.
This patch adds its helper function and use it.
Because people might misunderstand that _init() is mutex initialization,
this patch renames _INIT to _ROOT and adds new
snd_soc_card_mutex_lock_root() for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a5zlx3tw.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 303236405
(cherry picked from commit 0f3b818486)
[ Yixuan Jiang: Fix minor conflict ]
Change-Id: Ie8cd7aeeea759576423760d25b5fb5b2c9ae0d12
Signed-off-by: Yixuan Jiang <yixuanjiang@google.com>
soc-pcm.c has snd_soc_dpcm_mutex_lock/unlock(),
but other files can't use it because it is static function.
It requests snd_soc_pcm_runtime as parameter (A), but sometimes we
want to use it by snd_soc_card (B).
(A) static inline void snd_soc_dpcm_mutex_lock(struct snd_soc_pcm_runtime *rtd)
{
mutex_lock_nested(&rtd->card->pcm_mutex, rtd->card->pcm_subclass);
} ^^^^^^^^^
(B) mutex_lock_nested(&card->pcm_mutex, card->pcm_subclass);
^^^^
We want to use it with both "rtd" and "card" for dapm lock/unlock.
To enable it, this patch uses _Generic macro.
This patch makes snd_soc_dpcm_mutex_{un}lock() global function, and use it on
each files.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87bkk1x3ud.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 303236405
(cherry picked from commit 38e42f6d6c)
[ Yixuan Jiang: Fix minor conflict ]
Change-Id: Id942841c7ca1642b44b1229a7bf4ab1bc5373707
Signed-off-by: Yixuan Jiang <yixuanjiang@google.com>
soc.h has snd_soc_dapm_mutex_lock/unlock() definition and
many drivers are using it, but soc-dapm.c is not.
1st reason is snd_soc_dapm_mutex_lock/unlock() requests
snd_soc_dapm_context pointer as parameter (A), but sometimes soc-dapm.c
needs to use snd_soc_card (B).
(A) static inline void snd_soc_dapm_mutex_lock(struct snd_soc_dapm_context *dapm)
{
mutex_lock_nested(&dapm->card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME);
} ^^^^^^^^^^
(B) mutex_lock_nested(&card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME);
^^^^
2nd reason is it want to use SND_SOC_DAPM_CLASS_INIT for mutex_lock_nested(),
but helper is using _RUNTIME (A).
The conclusion is we want to use "dapm vs card" and "_RUNTIME vs _INIT"
for dapm lock/unlock. To enable this selfish request, this patch uses
_Generic macro. We can use snd_soc_dapm_mutex_lock/unlock() for both
dapm and card case.
snd_soc_dapm_mutex_lock(dapm); snd_soc_dapm_mutex_unlock(dapm);
snd_soc_dapm_mutex_lock(card); snd_soc_dapm_mutex_unlock(card);
Current soc-dapm.c is using both mutex_lock() and mutex_lock_nested().
This patch handles mutex_lock() as mutex_lock_nested(..., 0),
in other words, handles below as same.
mutex_lock(&card->dapm_mutex);
mutex_lock_nested(&card->dapm_mutex, SND_SOC_DAPM_CLASS_INIT);
Because people might misunderstand that _init() is mutex initialization,
this patch renames _INIT to _ROOT and adds new
snd_soc_dapm_mutex_lock_root() for it.
This patch also moves snd_soc_dapm_subclass definition from soc-dapm.h
to soc.h to keep related code together.
Because very complex soc.h vs soc-dapm.h relationship,
it is difficult/impossible to define these helper into soc-dapm.h.
Change-Id: I064718bbad9d053a0c84549be0a5e942f29a5dee
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87cz4hx3v0.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 303236405
(cherry picked from commit 4a778bdc7a)
[ Yixuan Jiang: Fix minor conflict ]
Change-Id: I0fa12ec9272847c320ccdb0d69eceb2a03853d4e
Signed-off-by: Yixuan Jiang <yixuanjiang@google.com>
vendor may have the need to modify update_load_sum function
Bug: 181105055
Change-Id: I35964977a4b8917c62773d48a37340f880774e38
Signed-off-by: Chungkai Mei <chungkai@google.com>
(cherry picked from commit 984523c368)
It is possible for a task to be thawed multiple times when mixing the
*legacy* cgroup freezer and system-wide freezer. To do this, freeze the
cgroup, do system-wide freeze/thaw, then thaw the cgroup. When this
happens, then a stale saved_state can be written to the task's state
and cause task to hang indefinitely. Fix this by only trying to thaw
tasks that are actually frozen.
This change also has the marginal benefit avoiding unnecessary
wake_up_state(p, TASK_FROZEN) if we know the task is already thawed.
There is not possibility of time-of-compare/time-of-use race when we skip
the wake_up_state because entering/exiting TASK_FROZEN is guarded by
freezer_lock.
Fixes: 8f0eed4a78a8 ("freezer,sched: Use saved_state to reduce some spurious wakeups")
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Abhijeet Dharmapurikar <quic_adharmap@quicinc.com>
Link: https://lore.kernel.org/r/20231120-freezer-state-multiple-thaws-v1-1-f2e1dd7ce5a2@quicinc.com
Bug: 292064955
Bug: 312992017
(cherry picked from commit 23ab79e8e469e2605beec2e3ccb40d19c68dd2e0
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/urgent)
Change-Id: I09cb09a3ef3641c71e3b3156bc3a9a3e69d4966e
Signed-off-by: Qi Feng <fengqi@xiaomi.corp-partner.google.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
This patch adds GKI symbol list for Exynosauto SoC.
We need to add below 3 function symbols and it required
by DP MST of DRM(Direct Rendering Manager) driver.
3 function symbol(s) added
'int drm_connector_set_path_property(struct drm_connector*, const char*)'
'int drm_helper_probe_detect(struct drm_connector*, struct drm_modeset_acquire_ctx*, bool)'
'int of_graph_get_endpoint_count(const struct device_node*)'
Bug: 313751443
Change-Id: I3a7e212f598d50f21ee2272ccb18ceaa5af72f42
Signed-off-by: Junho Cha <junhomax.cha@samsung.com>
This structure is at the heart of the module support for pKVM. Add a
description to help anyone trying to create a module.
Bug: 312200309
Change-Id: Ie1d9043a6a94d15dd8ef25c6f0f8d442da26bc1f
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
It is possible that typec_register_partner() returns ERR_PTR on failure.
When port->partner is an error, a NULL pointer dereference may occur as
shown below.
[91222.095236][ T319] typec port0: failed to register partner (-17)
...
[91225.061491][ T319] Unable to handle kernel NULL pointer dereference
at virtual address 000000000000039f
[91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc
[91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc
[91225.308067][ T319] Call trace:
[91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc
[91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8
[91225.355900][ T319] kthread_worker_fn+0x178/0x58c
[91225.355902][ T319] kthread+0x150/0x200
[91225.355905][ T319] ret_from_fork+0x10/0x30
Add a check for port->partner to avoid dereferencing a NULL pointer.
Fixes: 5e1d4c49fb ("usb: typec: tcpm: Determine common SVDM Version")
Cc: stable@vger.kernel.org
Signed-off-by: Jimmy Hu <hhhuuu@google.com>
Link: https://lore.kernel.org/r/20231020012132.100960-1-hhhuuu@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 280207787
(cherry picked from commit 4987daf86c152ff882d51572d154ad12e4ff3a4b)
Change-Id: I609640ff70258b8fd0e7f9eaad9eb60db35ccfad
Signed-off-by: Kyle Tso <kyletso@google.com>
add four symbol to oplus symbol list, which already EXPORTED
1. static_key_enable
2. static_key_disable
3. __traceiter_android_vh_alloc_pages_slowpath
4. __tracepoint_android_vh_alloc_pages_slowpath
Bug: 312913816
Change-Id: I2c5776c4b58b8b50e7e4c245492614412042cf9d
Signed-off-by: liwei <liwei1234@oppo.com>
When we use an async work queue to perform the function of pumping
usb requests to the usb controller, it is possible that amongst other
factors, thread scheduling affects at what cadence we're able to pump
requests. This could mean isoc usb requests miss their uframes - resulting
in video stream flickers on the host device.
To avoid this, we make the async_wq thread only produce isoc usb_requests
with uvc buffers encoded into them. The process of queueing to the
endpoint is done by the uvc_video_complete() handler. In case no
usb_requests are ready with encoded information, we just queue a zero
length request to the endpoint from the complete handler.
For bulk endpoints the async_wq thread still queues usb requests to the
endpoint.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Suggested-by: Avichal Rakesh <arakesh@google.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20231120062026.3759463-1-jchowdhary@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 301915972
(cherry picked from commit 6acba0345b68772830582ca1ca369a2f45631275
https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb usb-next)
Change-Id: I5597cc29e9caec69e4f3575938d7d640857aaa28
Signed-off-by: Avichal Rakesh <arakesh@google.com>
