kthread_create_on_cpu no longer marks the created thread as a per cpu
thread, so the affinity might get lost on suspend or other hotplug
events.
Export kthread_set_per_cpu so a module that needs a kthread to stay on a
specific cpu can accomplish that.
Bug: 274202992
Change-Id: Iaafc12f93f341f9e0586cb051b7f1c941f140866
Signed-off-by: Arve Hjønnevåg <arve@android.com>
(cherry picked from commit 4fdc7e4658)
The following list of commits, which are in the 6.1.57 release, add a
new field in struct ipv6_devconf and this breaks the abi. Fix this by
using one of the reserved slots for upstream changes and update the stg
file to preserve the build.
b691264274 ("net: release reference to inet6_dev pointer")
bad004c384 ("net: change accept_ra_min_rtr_lft to affect all RA lifetimes")
ec4162bb70 ("net: add sysctl accept_ra_min_rtr_lft")
type 'struct ipv6_devconf' changed
member 'union { struct { __s32 accept_ra_min_lft; u32 padding; }; struct { u64 android_kabi_reserved1; }; union { }; }' was added
member 'u64 android_kabi_reserved1' was removed
Bug: 320243175
Change-Id: Icddcad574f3c29f6d3e63b10f8c7e51bdf46fe7f
Signed-off-by: Carlos Llamas <cmllamas@google.com>
The android_kabi.h header file uses the __stringify() macro without
explicitly including its definition via linux/stringify.h. This can
result in build breaking when using the ANDROID_KABI_USE macro:
common/include/linux/ipv6.h:83:2: error: expected ')'
ANDROID_KABI_USE(1, struct { __s32 accept_ra_min_lft; u32 padding; });
^
[...]
common/include/linux/android_kabi.h:44:24: note: expanded from macro '__ANDROID_KABI_CHECK_SIZE_ALIGN'
__FILE__ ":" __stringify(__LINE__) ": " \
^
To fix this let android_kabi.h include stringify.h explicitly instead of
relying on includes of previous unrelated header files.
Bug: 324437514
Change-Id: I16cced44e723871b2e1a92b312e60f38e41fea70
Signed-off-by: Carlos Llamas <cmllamas@google.com>
I encountered a race issue after lengthy (~594647 sec) stress tests on
a 64k-page arm64 VM with several 4k-block EROFS images. The timing
is like below:
z_erofs_try_inplace_io z_erofs_fill_bio_vec
cmpxchg(&compressed_bvecs[].page,
NULL, ..)
[access bufvec]
compressed_bvecs[] = *bvec;
Previously, z_erofs_submit_queue() just accessed bufvec->page only, so
other fields in bufvec didn't matter. After the subpage block support
is landed, .offset and .end can be used too, but filling bufvec isn't
an atomic operation which can cause inconsistency.
Let's use a spinlock to keep the atomicity of each bufvec.
Fixes: 192351616a9d ("erofs: support I/O submission for sub-page compressed blocks")
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Sandeep Dhavale <dhavale@google.com>
Reviewed-by: Yue Hu <huyue2@coolpad.com>
Link: https://lore.kernel.org/r/20240125120039.3228103-1-hsiangkao@linux.alibaba.com
Bug: 324640522
(cherry picked from commit cc4b2dd95f0d1eba8c691b36e8f4d1795582f1ff
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ master)
[dhavale: introduced spinlock in struct erofs_workgroup, upstream has a
change where atomic is replaced by lockref but pulling that and related
changes will cause unnecessary churn. Adding spinlock keeps the spirit
of the change in-tact by fixing the race. Also updated commit message
as we are not using lockref.]
Change-Id: Id20a0a433277ab71d46bce48c81824564d1b391d
Signed-off-by: Sandeep Dhavale <dhavale@google.com>
Instead of invalidating the tlb of the guest every page it relinquishes,
invalidate once before the host is informed about the free pages.
Bug: 315173520
Change-Id: I8450fd552a27dfc791efa15e884982aeedaa3234
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Move out the kvm specific page_relinquish call and introduce a generic
hypervisor_ops structure. Based on the hypervisor running underneath the
guest, populate the operations to make specific hypercalls.
Bug: 315173520
Change-Id: I93d5a92553a04d56811b0666dec6eacc1ca168e7
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Full LTO takes the '-mbranch-protection=none' passed to the compiler
when generating the dynamic shadow call stack patching code as a hint to
stop emitting PAC instructions altogether. (Thin LTO appears unaffected
by this)
Work around this by disabling LTO for the compilation unit, which
appears to convince the linker that it should still use PAC in the rest
of the kernel..
Fixes: 3b619e22c4 ("arm64: implement dynamic shadow call stack for Clang")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://lore.kernel.org/r/20240123133052.1417449-6-ardb+git@google.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit d104a6fef3fec137d8d44961224ab76edbd6cbc7)
Bug: 317883735
Change-Id: Ic4bdb0a6e527f8cb2745282b81945aa7b7231502
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Blocks are tracked by u32, so the max permitted filesize is
(U32_MAX + 1) * BLOCK_SIZE. Additionally, in order to support crypto
data unit sizes of 4K with a 16K block with IV_INO_LBLK_{32,64}, we must
further restrict max filesize to (U32_MAX + 1) * 4096. This does not
affect 4K blocksize f2fs as the natural limit for files are well below
that.
Fixes: cf46c5872022 ("BACKPORT: Support Block Size == Page Size")
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Change-Id: I8697e37841e1882a3f613e9aab1857ad7e4c3f2f
Bug: 248132568
(cherry picked from commit a6a010f5def544af3efcfe21683905a712b60536)
This allows f2fs to support cases where the block size = page size for
both 4K and 16K block sizes. Other sizes should work as well, should the
need arise. This does not currently support 4K Block size filesystems if
the page size is 16K.
Change-Id: Ifab03cddeec1389a6a3fb64174063ffccbb93072
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 248132568
(cherry picked from commit 8b8e202be3264fc33464f8dc319e0c1563ac89d8)
(fixed minor conflict in fs/f2fs/inode.c)
If the PD is disabled for the port, port->pds will be left as NULL,
which causes the following crash during caps intilisation. Fix the
crash.
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Call trace:
tcpm_register_port+0xaec/0xc44
qcom_pmic_typec_probe+0x1a4/0x254
platform_probe+0x68/0xc0
really_probe+0x148/0x2ac
__driver_probe_device+0x78/0x12c
driver_probe_device+0xd8/0x160
Bluetooth: hci0: QCA Product ID :0x0000000a
__device_attach_driver+0xb8/0x138
bus_for_each_drv+0x80/0xdc
Bluetooth: hci0: QCA SOC Version :0x40020150
__device_attach+0x9c/0x188
device_initial_probe+0x14/0x20
bus_probe_device+0xac/0xb0
deferred_probe_work_func+0x8c/0xc8
process_one_work+0x1ec/0x51c
worker_thread+0x1ec/0x3e4
kthread+0x120/0x124
ret_from_fork+0x10/0x20
Fixes: cd099cde4ed2 ("usb: typec: tcpm: Support multiple capabilities")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20240113-pmi632-typec-v2-5-182d9aa0a5b3@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
BUG: 206108037
(cherry picked from commit f2e5d3de7e1fbf24483e7f996e519b3ebc3935a1)
Change-Id: If3e81f4bc7c22830d8b0e8400b6e2fc8719a7f6b
Signed-off-by: Kyle Tso <kyletso@google.com>
commit f342de4e2f33e0e39165d8639387aa6c19dff660 upstream.
This reverts commit e0abdadcc6.
core.c:nf_hook_slow assumes that the upper 16 bits of NF_DROP
verdicts contain a valid errno, i.e. -EPERM, -EHOSTUNREACH or similar,
or 0.
Due to the reverted commit, its possible to provide a positive
value, e.g. NF_ACCEPT (1), which results in use-after-free.
Its not clear to me why this commit was made.
NF_QUEUE is not used by nftables; "queue" rules in nftables
will result in use of "nft_queue" expression.
If we later need to allow specifiying errno values from userspace
(do not know why), this has to call NF_DROP_GETERR and check that
"err <= 0" holds true.
Bug: 323034288
Fixes: e0abdadcc6 ("netfilter: nf_tables: accept QUEUE/DROP verdict parameters")
Cc: stable@vger.kernel.org
Reported-by: Notselwyn <notselwyn@pwning.tech>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8e34430e33)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ie6c699cea6f92cd4a7642f196d5f5cbffe268a6d
The d_canonical_path is added for Android. The another fuse daemon
such as ntfs.3g do not implement it. The fsnotify can not work when
using those fuse daemon.
Fixes: aca265111a ("ANDROID: fuse: Add support for d_canonical_path")
Change-Id: I4244431fa1520b5bc33e07da456b3062b635dc5c
Signed-off-by: chenyuwen <chenyuwen1@meizu.com>
The function is required by out of tree cpufreq governors.
Bug: 322549912
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: Ib62bb957d72878a56cbbd955447b372cdad3b92c
Both kernel modules are important for testing block layer and SCSI core
performance and functionality. Hence enable these in the kernel
configuration.
Bug: 323406846
Change-Id: I23cee78cd7d4e5f891395624a6bed01cffee4aa8
Signed-off-by: Bart Van Assche <bvanassche@google.com>
There are two tracepoints in dwc3_readl() and dwc3_writel().
This patch will export the tracepoints so that vendor modules
can use them.
Bug: 184920962
Signed-off-by: Ray Chi <raychi@google.com>
Change-Id: I1170d853be1fa1c47afbba133567b1996418d8e8
Some hardware has a way to restore all keyslots at once that is
significantly faster than restoring each keyslot individually, as is
done by blk_ksm_reprogram_all_keys(). Add a hook
"android_rvh_ufs_reprogram_all_keys" that allows overriding the
restoration of all keyslots after UFS reset. This may sleep, so this
must be a "restricted" Android vendor hook rather than a regular one.
Note that currently this functionality can't be upstreamed, as support
for the hardware that needs it would need to be upstreamed first.
(cherry picked from commit e2e063f507)
Bug: 162257402
Bug: 181905172
Bug: 241106918
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Kenny Root <kroot@google.com>
Change-Id: I0b25393a5131941f085892560e08a64e63cd1369
Add hook for binder_detect_low_async_space_locked, which gives the vendor a choice whether or not this alloc new buf should go on or not
Bug: 322915513
Change-Id: Ie7f1567dae6dee0fb22b014cd1eacc3308ccb205
Signed-off-by: chenweitao <chenweitao@oppo.com>
type 'struct tcpm_port' changed
byte size changed from 12536 to 12552
member 'struct usb_power_delivery** pds' was added
member 'struct pd_data** pd_list' was added
member 'struct usb_power_delivery* pd' was removed
5 members ('struct usb_power_delivery_capabilities* port_source_caps' .. 'struct usb_power_delivery_capabilities* partner_sink_caps') changed
offset changed by 64
member 'struct usb_power_delivery* selected_pd' was added
5 members ('u32 sink_request' .. 'unsigned int nr_sink_caps') changed
offset changed by 128
member 'unsigned int pd_count' was added
14 members ('u32 src_pdo[7]' .. 'u32 supply_voltage') changed
offset changed by 160
32 members ('struct power_supply* psy' .. 'u8* logbuffer[1024]') changed
offset changed by 128
Bug: 206108037
Change-Id: I533d197558e12eefeb4984dbbd58c8f5b4d9e9ac
Signed-off-by: Kyle Tso <kyletso@google.com>
Refactor tcpm_fw_get_caps to support the multiple pd capabilities got
from fwnode. For backward compatibility, the original single capability
is still applicable. The fetched data is stored in the newly defined
structure "pd_data" and there is an array "pd_list" to store the
pointers to them. A dedicated array "pds" is used to store the handles
of the registered usb_power_delivery instances.
Also implement the .pd_get and .pd_set ops which are introduced in
commit a7cff92f06 ("usb: typec: USB Power Delivery helpers for ports
and partners"). Once the .pd_set is called, the current capability will
be updated and state machine will re-negotiate the power contract if
possible.
Signed-off-by: Kyle Tso <kyletso@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20231216104630.2720818-3-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 206108037
(cherry picked from commit cd099cde4ed264403b434d8344994f97ac2a4349)
Signed-off-by: Kyle Tso <kyletso@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:eab651bc575f23415e8aa8cb39b45a92fcf8eeee)
Merged-In: I58ee6e321f304b758507287ced314cc7a07466eb
Change-Id: I58ee6e321f304b758507287ced314cc7a07466eb
[ Upstream commit 810c38a369a0a0ce625b5c12169abce1dd9ccd53 ]
Because rose_ioctl() accesses sk->sk_receive_queue
without holding a sk->sk_receive_queue.lock, it can
cause a race with rose_accept().
A use-after-free for skb occurs with the following flow.
```
rose_ioctl() -> skb_peek()
rose_accept() -> skb_dequeue() -> kfree_skb()
```
Add sk->sk_receive_queue.lock to rose_ioctl() to fix this issue.
Bug: 321175740
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Hyunwoo Kim <v4bel@theori.io>
Link: https://lore.kernel.org/r/20231209100538.GA407321@v4bel-B760M-AORUS-ELITE-AX
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 3f1f6a94d8)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I94d2aae6221fb95cb285e1a6d0c6fe39a70e35d2
[ Upstream commit af73483f4e8b6f5c68c9aa63257bdd929a9c194a ]
The IDA usually detects double-frees, but that detection failed to
consider the case when there are no nearby IDs allocated and so we have a
NULL bitmap rather than simply having a clear bit. Add some tests to the
test-suite to be sure we don't inadvertently reintroduce this problem.
Unfortunately they're quite noisy so include a message to disregard
the warnings.
Bug: 321878978
Reported-by: Zhenghan Wang <wzhmmmmm@gmail.com>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 5dbcdaf4db)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I4919e5c64af12f86fe1a91e1e9224a58eedbf345
This reverts commit 63eafbb6b3.
Keeps the ABI stable by taking advantage of a hole in the structure!
Bug: 307236803
Change-Id: Ic5f7ebeb3a9b13afdb3bfff7e54c4a93b863dab6
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Adding the following symbols:
- update_misfit_status
Bug: 318526590
Change-Id: I6bd490130932021298b4c72ee68725998ff2fb69
Signed-off-by: Chungkai Mei <chungkai@google.com>
Current scheduler cannot update misfit status immediately when we set uclamp min for some latency-sensitive tasks, it may cause some latency for these tasks so we may need to update misfit status in vendor kernel.
Bug: 318526590
Change-Id: I0f03d2e52588822d1a9ef9a5f24944dff4f4e4a0
Signed-off-by: Chungkai Mei <chungkai@google.com>
In current scenario if Plug-out and Plug-In performed continuously
there could be a chance while checking for dwc->gadget_driver in
dwc3_gadget_suspend, a NULL pointer dereference may occur.
Call Stack:
CPU1: CPU2:
gadget_unbind_driver dwc3_suspend_common
dwc3_gadget_stop dwc3_gadget_suspend
dwc3_disconnect_gadget
CPU1 basically clears the variable and CPU2 checks the variable.
Consider CPU1 is running and right before gadget_driver is cleared
and in parallel CPU2 executes dwc3_gadget_suspend where it finds
dwc->gadget_driver which is not NULL and resumes execution and then
CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where
it checks dwc->gadget_driver is already NULL because of which the
NULL pointer deference occur.
Cc: <stable@vger.kernel.org>
Fixes: 9772b47a4c ("usb: dwc3: gadget: Fix suspend/resume during device mode")
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
(cherry picked from commit 61a348857e869432e6a920ad8ea9132e8d44c316 )
Bug: 322899161
Link: https://lore.kernel.org/all/20240119094825.26530-1-quic_uaggarwa@quicinc.com/
Change-Id: I2f1663f19ebdd6c6b5b1874a66c81fd3f75b0e9a
Signed-off-by: Rajashekar kuruva <quic_kuruva@quicinc.com>
Currently, the function update_port_device_state gets the usb_hub from
udev->parent by calling usb_hub_to_struct_hub.
However, in case the actconfig or the maxchild is 0, the usb_hub would
be NULL and upon further accessing to get port_dev would result in null
pointer dereference.
Fix this by introducing an if check after the usb_hub is populated.
Fixes: 83cb2604f6 ("usb: core: add sysfs entry for usb device state")
Cc: stable@vger.kernel.org
Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Bug: 321600650
Link: https://lore.kernel.org/all/20240110095814.7626-1-quic_ugoswami@quicinc.com/
Change-Id: I3fef553dce36a7ec2d335008fe8d51d848d6abd2
Signed-off-by: Rajashekar kuruva <quic_kuruva@quicinc.com>
Enable NVMe multipath support to get access to /dev/nvmeXnY block
devices.
Bug: 318459546
Change-Id: Id452462b4dbb474f1e3a53f5010f09edf63642bc
Signed-off-by: Daniel Mentz <danielmentz@google.com>
The ASR8601 SoC combines ARMv8.2 CPUs from ARM with a GIC-500,
also from ARM. However, the two are incompatible as the former
expose an affinity in the form of (cluster, core, thread),
while the latter can only deal with (cluster, core). If nothing
is done, the GIC simply cannot route interrupts to the CPUs.
Implement a workaround that shifts the affinity down by a level,
ensuring the delivery of interrupts despite the implementation
mismatch.
Signed-off-by: zhengyan <zhengyan@asrmicro.com>
[maz: rewrote commit message, reimplemented the workaround
in a manageable way]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Bug: 282025214
Change-Id: Id62a4f45ec52c1de543bbd712879dc34688d7904
(cherry picked from commit b4d81fab1e)
[meitao: Resolved minor conflict in drivers/irqchip/irq-gic-v3.c ]
Signed-off-by: meitaogao <meitaogao@asrmicro.com>
(cherry picked from commit f17cd56e4e4273eef892e424adb030ec8e96b095)
The GICv3 driver uses multiple formats for the affinity, all
derived from a reading of MPDR_EL1 on one CPU or another.
Simplify the handling of these affinity by moving the access
to the CPU affinity via cpu_logical_map() inside the helper,
and rename it accordingly.
This will be helpful to support some more broken hardware.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Bug: 282025214
Change-Id: I2e6b9861d20336bec689a2e704b7fc50035841e7
(cherry picked from commit 3c65cbb7c5)
[meitao: Resolved minor conflict in drivers/irqchip/irq-gic-v3.c ]
Signed-off-by: meitaogao <meitaogao@asrmicro.com>
(cherry picked from commit 035e150e1af7221255b952865aaf80a4c1c6d96d)
In presence of a lot of small weight tasks like sched_idle tasks, normal
or high weight tasks can see their ideal runtime (sched_slice) to increase
to hundreds ms whereas it normally stays below sysctl_sched_latency.
2 normal tasks running on a CPU will have a max sched_slice of 12ms
(half of the sched_period). This means that they will make progress
every sysctl_sched_latency period.
If we now add 1000 idle tasks on the CPU, the sched_period becomes
3006 ms and the ideal runtime of the normal tasks becomes 609 ms.
It will even become 1500ms if the idle tasks belongs to an idle cgroup.
This means that the scheduler will look for picking another waiting task
after 609ms running time (1500ms respectively). The idle tasks change
significantly the way the 2 normal tasks interleave their running time
slot whereas they should have a small impact.
Such long sched_slice can delay significantly the release of resources
as the tasks can wait hundreds of ms before the next running slot just
because of idle tasks queued on the rq.
Cap the ideal_runtime to sysctl_sched_latency to make sure that tasks will
regularly make progress and will not be significantly impacted by
idle/background tasks queued on the rq.
Bug: 315185352
Bug: 269111781
Change-Id: I27f956ee275d17ef708d8d27dc082c66ed5a5275
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Link: https://lore.kernel.org/r/20230113133613.257342-1-vincent.guittot@linaro.org
(cherry picked from commit 79ba1e607d)
Signed-off-by: Qais Yousef <qyousef@google.com>
(cherry picked from commit e32aeb03b9)
Signed-off-by: Qais Yousef <qyousef@google.com>
