Upstream commit bac1ec55 ("usb: xhci: Set quirk for
XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
which fixes XHC timeout, which was seen on synopsys XHCs while
using SG buffers. But the support for this quirk isn't present
in the DWC3 layer.

We will encounter this XHCI timeout/hung issue if we run iperf
loopback tests using RTL8156 ethernet adaptor on DWC3 targets
with scatter-gather enabled. This gets resolved after enabling
the XHCI_SG_TRB_CACHE_SIZE_QUIRK. This patch enables it using
the xhci device property since its needed for DWC3 controller.

In Synopsys DWC3 databook,
Table 9-3: xHCI Debug Capability Limitations
Chained TRBs greater than TRB cache size: The debug capability
driver must not create a multi-TRB TD that describes smaller
than a 1K packet that spreads across 8 or more TRBs on either
the IN TR or the OUT TR.

Cc: stable@vger.kernel.org #5.11
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20240116055816.1169821-2-quic_prashk@quicinc.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 322910830
(cherry picked from commit 817349b6
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-linus)
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Change-Id: I9a5bf2c4d43551406d452927084576387656953d

Upstream commit bac1ec55 ("usb: xhci: Set quirk for
XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
which fixes XHC timeout, which was seen on synopsys XHCs while
using SG buffers. Currently this quirk can only be set using
xhci private data. But there are some drivers like dwc3/host.c
which adds adds quirks using software node for xhci device.
Hence set this xhci quirk by iterating over device properties.

Cc: stable@vger.kernel.org # 5.11
Fixes: bac1ec55 ("usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK")
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Link: https://lore.kernel.org/r/20240116055816.1169821-3-quic_prashk@quicinc.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 322910830
(cherry picked from commit 520b391e
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-linus)
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Change-Id: I7cc21f5975cd82997f8eca38472f9c467df21dd6

Since the cmpxchg() to unlock the VMA (reset ref count from -1), is
enclosed in VM_BUG_ON_VMA() it gets compiled out in non-debug builds
(CONFIG_DEBUG_VM=n). This means that any VMA that underwent a fast-remap
will have it's refcount stuck at -1, making it not be eligible for
future speculative faults, and preventing freeing of the VMA.

Bug: 322411509
Change-Id: If5bf61c7d94268700f2c4f096d946201b68abdb8
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>

Add symbols used by SCMI based IIO sensor driver (scmi_iio.ko) and Marvell
88Q5152 Ethernet driver.

2 Added functions:
  [A] 'function void netdev_reset_tc(net_device*)'
  [A] 'function int pci_prepare_to_sleep(pci_dev*)'

Bug: 320707943
Signed-off-by: Wojciech Lewandowski <wojciech.lewandowski@ext.us.panasonic.com>
Change-Id: I96d9f4c84de9b78da69e34947710d8940806eaf5

CONFIG_ARM_SCMI_TRANSPORT_VIRTIO is required by SCMI based IIO sensor
driver (CONFIG_IIO_SCMI) to enable VirtIO SCMI support.

Bug: 320707943
Signed-off-by: Wojciech Lewandowski <wojciech.lewandowski@ext.us.panasonic.com>
Change-Id: I9ceff4a2f49f9b84e521ae45ad7a5013f8625ea2

The workqueue watchdog reports a lockup when there was not any progress
in the worker pool for a long time. The progress means that a pending
work item starts being proceed.

The progress is guaranteed by using idle workers or creating new workers
for pending work items.

There are several reasons why a new worker could not be created:

   + there is not enough memory

   + there is no free pool ID (IDR API)

   + the system reached PID limit

   + the process creating the new worker was interrupted

   + the last idle worker (manager) has not been scheduled for a long
     time. It was not able to even start creating the kthread.

None of these failures is reported at the moment. The only clue is that
show_one_worker_pool() prints that there is a manager. It is the last
idle worker that is responsible for creating a new one. But it is not
clear if create_worker() is failing and why.

Make the debugging easier by printing errors in create_worker().

The error code is important, especially from kthread_create_on_node().
It helps to distinguish the various reasons. For example, reaching
memory limit (-ENOMEM), other system limits (-EAGAIN), or process
interrupted (-EINTR).

Use pr_once() to avoid repeating the same error every CREATE_COOLDOWN
for each stuck worker pool.

Ratelimited printk() might be better. It would help to know if the problem
remains. It would be more clear if the create_worker() errors and workqueue
stalls are related. Also old messages might get lost when the internal log
buffer is full. The problem is that printk() might touch the watchdog.
For example, see touch_nmi_watchdog() in serial8250_console_write().
It would require synchronization of the begin and length of the ratelimit
interval with the workqueue watchdog. Otherwise, the error messages
might break the watchdog. This does not look worth the complexity.

Bug: 320570308

Change-Id: I306be476cd34e4b7f19ecb503144cb26b75ad24b
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit 3f0ea0b8)
Signed-off-by: Yi Sun <yi.sun@unisoc.com>

It was pointed out that since commit b6115e14 ("ANDROID:
uid_sys_stat: split the global lock uid_lock to the fine-grained locks
for each hlist in hash_table") taking a spin_lock in uid_lock()
causes a scheduling while atomic error if CONFIG_UID_SYS_STATS_DEBUG
is enabled, as get_full_task_comm() takes the mmap_write_lock()
which is a semaphore, breaking the proper ordering.

In the GKI CONFIG_UID_SYS_STATS_DEBUG is disabled, so this went
unnoticed.

The uid_sys_stats logic isn't ever going to go upstream (it depends
on reverting upstream logic) and will hopefully be replaced eventually.
So there's not much reason to drag around this debug logic that is
unused.

So drop it. Less code to schlep forward.

Bug: 320184870
Change-Id: I2cfce79d5a25a3eba11a5509444c07b4642ef2de
Signed-off-by: John Stultz <jstultz@google.com>

Amit Pundir at Linaro reported seeing crashes in uid_sys_stats
driver when building with GCC.

Looking into it, it seems the uid_entry_tmp value is used
while only partially initialized, causing potential out of bound
access on the uid_entry io arrays.

This likely has gone unnoticed with clang as I believe we're
using the zero initialization for stack variables security
feature.

So change the logic to fully initialize the uid_entry_tmp
value.

Fixes: f68d4f3c ("ANDROID: uid_sys_stat: instead update_io_stats_uid_locked to update_io_stats_uid")
Reported-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: John Stultz <jstultz@google.com>
Change-Id: I78de245e80ef60aabec78a615c7ba582ab5a2242

When handling error status from uvcg_video_usb_req_queue,
uvc_video_complete currently calls uvcg_queue_cancel with
video->req_lock held. uvcg_queue_cancel internally locks
queue->irqlock, which nests queue->irqlock inside
video->req_lock. This isn't a functional bug at the
moment, but does open up possibilities for ABBA
deadlocks in the future.

This patch fixes the accidental nesting by dropping
video->req_lock before calling uvcg_queue_cancel.

Fixes: 6acba034 ("usb:gadget:uvc Do not use worker thread to pump isoc usb requests")
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Link: https://lore.kernel.org/r/20240104215009.2252452-2-arakesh@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 314338409
(cherry picked from commit 9866dc43)
Change-Id: Ic50069f8584e0d236463a084b12cabcc845d3b6a
Signed-off-by: Avichal Rakesh <arakesh@google.com>

There is a path that may lead to freed memory being referenced,
causing kernel panics.

The kernel panic has the following stack trace:

Workqueue: uvcgadget uvcg_video_pump.c51fb85fece46625450f86adbf92c56c.cfi_jt
pstate: 60c00085 (nZCv daIf +PAN +UAO -TCO BTYPE=--)
pc : __list_del_entry_valid+0xc0/0xd4
lr : __list_del_entry_valid+0xc0/0xd4
Call trace:
  __list_del_entry_valid+0xc0/0xd4
  uvc_video_free_request+0x60/0x98
  uvcg_video_pump+0x1cc/0x204
  process_one_work+0x21c/0x4b8
  worker_thread+0x29c/0x574
  kthread+0x158/0x1b0
  ret_from_fork+0x10/0x30

The root cause is that uvcg_video_usb_req_queue frees the uvc_request
if is_enabled is false and returns an error status. video_pump also
frees the associated request if uvcg_video_usb_req_queue returns an
error status, leading to double free and accessing garbage memory.

To fix the issue, this patch removes freeing logic from
uvcg_video_usb_req_queue, and lets the callers to the function handle
queueing errors as they see fit.

Fixes: 6acba034 ("usb:gadget:uvc Do not use worker thread to pump isoc usb requests")
Tested-by: Avichal Rakesh <arakesh@google.com>
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Link: https://lore.kernel.org/r/20240104215009.2252452-1-arakesh@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 314338409
(cherry picked from commit fe814b5b)
Change-Id: I833c33e038ea5b34d5c580dfc612752ab1fa88a6
Signed-off-by: Avichal Rakesh <arakesh@google.com>

fuse_lseek_backing was returning the offset as an int, which would then
be treated as an ERR if in the range 4G-4096 and 4G.

Although the call would appear to work correctly, the file position
would be incorrect according to a subsequent fseek with SEEK_CUR.

Based on a change by chenyuwen <chenyuwen1@meizu.com> who found and
fixed this issue.

Bug: 319219307
Change-Id: I3aef5fb22751a72ce2bd7674ee081956a89fc752
Signed-off-by: chenyuwen <chenyuwen1@meizu.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>

Update symbols to symbol list externed by oppo memory group.

ABI DIFFERENCES HAVE BEEN DETECTED!

1 function symbol(s) added
  'bool is_transparent_hugepage(struct page *)'

Bug: 321196175

Change-Id: I6a7e58f51903fbdc3c4c7deb9e1d3accc2559027
Signed-off-by: huzhanyuan <huzhanyuan@oppo.com>

Current implementation blocks the running operations when Plug-out and
Plug-In is performed continuously, process gets stuck in
dwc3_thread_interrupt().

Code Flow:

	CPU1

	->Gadget_start
	->dwc3_interrupt
	->dwc3_thread_interrupt
	->dwc3_process_event_buf
	->dwc3_process_event_entry
	->dwc3_endpoint_interrupt
	->dwc3_ep0_interrupt
	->dwc3_ep0_inspect_setup
	->dwc3_ep0_stall_and_restart

By this time if pending_list is not empty, it will get the next request
on the given list and calls dwc3_gadget_giveback which will unmap request
and call its complete() callback to notify upper layers that it has
completed. Currently dwc3_gadget_giveback status is set to -ECONNRESET,
whereas it should be -ESHUTDOWN based on condition if not dwc->connected
is true.

Cc:  <stable@vger.kernel.org>
Fixes: d742220b ("usb: dwc3: ep0: giveback requests on stall_and_restart")
Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
Link: https://lore.kernel.org/r/20231222094704.20276-1-quic_uaggarwa@quicinc.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 320608609
(cherry picked from commit e9d40b21
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-next)

Change-Id: Ie1cb993fc9e24e6c2f6d6120bca409a6f2664c18
Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>

The current implementation of the mark_victim tracepoint provides only the
process ID (pid) of the victim process.  This limitation poses challenges
for userspace tools that need additional information about the OOM victim.
The association between pid and the additional data may be lost after the
kill, making it difficult for userspace to correlate the OOM event with
the specific process.

In order to mitigate this limitation, add the following fields:

- UID
   In Android each installed application has a unique UID. Including
   the `uid` assists in correlating OOM events with specific apps.

- Process Name (comm)
   Enables identification of the affected process.

- OOM Score
   Allows userspace to get additional insights of the relative kill
   priority of the OOM victim.

Link: https://lkml.kernel.org/r/20240111210539.636607-1-carlosgalo@google.com


Change-Id: Icc3ed013a9dfff9bb09f1d7588757e6028c17069
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 649ffb4cbb90a7f60f17dd74e57d814e762ea01d mm-unstable)
[ carlosgalo: Manually added struct cred change in mark_oom_victim function ]

Bug: 315560026
Change-Id: I81fb6f3447f432100ad4cd25e22db23768003388
Signed-off-by: Carlos Galo <carlosgalo@google.com>

A recent change to add a vendor hook inadvertently affected the CRC of
two existing exported symbols, due to an additional header inclusion.

This change hides the inclusion from genksyms, reverting the CRCs.

function symbol 'char * __get_task_comm(char *, size_t, struct task_struct *)' changed
  CRC changed from 0x84461de to 0x4428fb5e

function symbol 'int __traceiter_task_rename(void *, struct task_struct *, const char *)' changed
  CRC changed from 0x6012942d to 0x199d26ce

Bug: 317949078
Bug: 320644132
Fixes: 7348d925 ("ANDROID: vendor_hooks: Add a hook for set_task_comm")
Change-Id: Id065ae6244dbd337ed1dcbf3687c2ef3711d4415
Signed-off-by: Giuliano Procida <gprocida@google.com>

Currently for dwc3_usb31 controller, if maximum_speed is limited to
super-speed in DT, then device mode is limited to SS, but host mode
still works in SSP.

The documentation for max-speed property is as follows:

"Tells USB controllers we want to work up to a certain speed.
Incase  this isn't passed via DT, USB controllers should default to
their maximum HW capability."

It doesn't specify that the property is only for device mode.
There are cases where we need to limit the host's maximum speed to
SuperSpeed only. Use this property for host mode to contrain host's
speed to SuperSpeed.

Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20231219041559.15789-1-quic_kriskura@quicinc.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 320619105
(cherry picked from commit 91736d06 https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git

 usb-next)
Change-Id: I458fa5cd44c1510a797f824e263eb3ea27bbb287
Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com>

Starting with FUSE 7.36, all the fields for the 32-bit FUSE init flags
have been allocated, so commit 53db2893 ("fuse: extend init flags")
introduces the new 32-bit flags2 field in fuse_init_in and
fuse_init_out. That change also adds the FUSE_INIT_RESERVED flag that
doesn't have any specific purpose yet, is just reserved and should not
be used, and (un)fortunately collides with FUSE_PASSTHROUGH.

This change fixes the conflict by simply setting the FUSE_PASSTHROUGH
value to the next, latest unused fuse2 bit.
Although this is not the best design choice, userspace will know what
FUSE_PASSTHROUGH bit to choose based on the FUSE major and minor version
for FUSE version:
- < 7.36:    FUSE_PASSTHROUGH is the 31st bit of flags;
- otherwise: FUSE_PASSTHROUGH is the 31st bit of flags2.

Test: launch_cvd (both android-mainline and android13-5.10) \
  `logcat FuseDaemon:V \*:S` shows no FUSE passthrough errors
Bug: 215310351
Signed-off-by: Alexandre Marciano Gimenez <raging@google.com>
Change-Id: I85d7582008b8c093b3172b3f41c6cdf09863dd45
(cherry picked from commit cffa61e7)

[ Upstream commit 3701cd39 ]

If dynset expressions provided by userspace is larger than the declared
set expressions, then bail out.

Bug: 316085841
Fixes: 48b0ae04 ("netfilter: nftables: netlink support for several set element expressions")
Reported-by: Xingyuan Mo <hdthky0@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit cf5f113c)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I4bd3f7e9148d4bc12bbc67ecdd605c2957eb8010

Update whitelist for the symbols used by the unisoc device and
update the ABI representation accordingly.

1 function symbol(s) added
  'int __traceiter_android_vh_rwsem_downgrade_wake_finish(void *, struct rw_semaphore *)'

1 variable symbol(s) added
  'struct tracepoint __tracepoint_android_vh_rwsem_downgrade_wake_finish'

Bug: 319178409
Change-Id: Ife1520ea7d9d6c39607d2f750a37a78d8d642486
Signed-off-by: Jing Xia <jing.xia@unisoc.com>

The commit d4528a28 ("ANDROID: vendor_hooks: Add hooks for
rwsem and mutex") adds the android_vh_rwsem_wake_finish hook to
rwsem_wake().It can get the point when a [write/read]_owner
releases the rwsem and wakes up other waiters of the rwsem.
However, it cannot cover a scenario that a task acquires the
write-lock first, then downgrades to the read-lock and wakes up
other waiters in list.

In order to avoid breaking other partner handlers that don't
expect to be called from rwsem_downgrade_wake,this patch adds
a new vendor hook named android_vh_rwsem_downgrade_wake_finish
to rwsem_downgrade_wake() as Todd Kjos suggested.

Bug: 319178409
Change-Id: I73f677d2aa813777f21f13fafc17b1f912f6ef7e
Signed-off-by: Jing Xia <jing.xia@unisoc.com>

Under certain circumstances a SoC can reach a critical temperaturelimit
and is unable to stabilize the temperature around a temperaturecontrol.
The system may ask for a specific power budget butbecause of the OPP
density, we can only choose an OPP with a powerbudget lower than the
requested one and under-utilize the CPU, thuslosing performance. In
other words, one OPP under-utilizes the CPUwith a power less than the
requested power budget and the next OPPexceeds the power budget. The
cpu idle cooling can solve this problem.

Bug: 299411923
Signed-off-by: Aran Dalton <arda@allwinnertech.com>
Change-Id: I1c17b340617e88be075097dc47f30ce94be2a4d7

commit 7315dc1e upstream.

NFT_MSG_DELSET deactivates all elements in the set, skip
set->ops->commit() to avoid the unnecessary clone (for the pipapo case)
as well as the sync GC cycle, which could deactivate again expired
elements in such set.

Bug: 318548348
Fixes: 5f68718b ("netfilter: nf_tables: GC transaction API to avoid race with control plane")
Reported-by: Kevin Rich <kevinrich1337@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 0105571f)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ie733688e27d9568d797fc1bc477261883b7dc8c1

[ Upstream commit e2b706c6 ]

When I perform the following test operations:
1.ip link add br0 type bridge
2.brctl addif br0 eth0
3.ip addr add 239.0.0.1/32 dev eth0
4.ip addr add 239.0.0.1/32 dev br0
5.ip addr add 224.0.0.1/32 dev br0
6.while ((1))
    do
        ifconfig br0 up
        ifconfig br0 down
    done
7.send IGMPv2 query packets to port eth0 continuously. For example,
./mausezahn ethX -c 0 "01 00 5e 00 00 01 00 72 19 88 aa 02 08 00 45 00 00
1c 00 01 00 00 01 02 0e 7f c0 a8 0a b7 e0 00 00 01 11 64 ee 9b 00 00 00 00"

The preceding tests may trigger the refcnt uaf issue of the mc list. The
stack is as follows:
	refcount_t: addition on 0; use-after-free.
	WARNING: CPU: 21 PID: 144 at lib/refcount.c:25 refcount_warn_saturate (lib/refcount.c:25)
	CPU: 21 PID: 144 Comm: ksoftirqd/21 Kdump: loaded Not tainted 6.7.0-rc1-next-20231117-dirty #80
	Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
	RIP: 0010:refcount_warn_saturate (lib/refcount.c:25)
	RSP: 0018:ffffb68f00657910 EFLAGS: 00010286
	RAX: 0000000000000000 RBX: ffff8a00c3bf96c0 RCX: ffff8a07b6160908
	RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff8a07b6160900
	RBP: ffff8a00cba36862 R08: 0000000000000000 R09: 00000000ffff7fff
	R10: ffffb68f006577c0 R11: ffffffffb0fdcdc8 R12: ffff8a00c3bf9680
	R13: ffff8a00c3bf96f0 R14: 0000000000000000 R15: ffff8a00d8766e00
	FS:  0000000000000000(0000) GS:ffff8a07b6140000(0000) knlGS:0000000000000000
	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	CR2: 000055f10b520b28 CR3: 000000039741a000 CR4: 00000000000006f0
	Call Trace:
	<TASK>
	igmp_heard_query (net/ipv4/igmp.c:1068)
	igmp_rcv (net/ipv4/igmp.c:1132)
	ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
	ip_local_deliver_finish (net/ipv4/ip_input.c:234)
	__netif_receive_skb_one_core (net/core/dev.c:5529)
	netif_receive_skb_internal (net/core/dev.c:5729)
	netif_receive_skb (net/core/dev.c:5788)
	br_handle_frame_finish (net/bridge/br_input.c:216)
	nf_hook_bridge_pre (net/bridge/br_input.c:294)
	__netif_receive_skb_core (net/core/dev.c:5423)
	__netif_receive_skb_list_core (net/core/dev.c:5606)
	__netif_receive_skb_list (net/core/dev.c:5674)
	netif_receive_skb_list_internal (net/core/dev.c:5764)
	napi_gro_receive (net/core/gro.c:609)
	e1000_clean_rx_irq (drivers/net/ethernet/intel/e1000/e1000_main.c:4467)
	e1000_clean (drivers/net/ethernet/intel/e1000/e1000_main.c:3805)
	__napi_poll (net/core/dev.c:6533)
	net_rx_action (net/core/dev.c:6735)
	__do_softirq (kernel/softirq.c:554)
	run_ksoftirqd (kernel/softirq.c:913)
	smpboot_thread_fn (kernel/smpboot.c:164)
	kthread (kernel/kthread.c:388)
	ret_from_fork (arch/x86/kernel/process.c:153)
	ret_from_fork_asm (arch/x86/entry/entry_64.S:250)
	</TASK>

The root causes are as follows:
Thread A					Thread B
...						netif_receive_skb
br_dev_stop					...
    br_multicast_leave_snoopers			...
        __ip_mc_dec_group			...
            __igmp_group_dropped		igmp_rcv
                igmp_stop_timer			    igmp_heard_query         //ref = 1
                ip_ma_put			        igmp_mod_timer
                    refcount_dec_and_test	            igmp_start_timer //ref = 0
			...                                     refcount_inc //ref increases from 0
When the device receives an IGMPv2 Query message, it starts the timer
immediately, regardless of whether the device is running. If the device is
down and has left the multicast group, it will cause the mc list refcount
uaf issue.

Bug: 316932391
Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 94445d95)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I277be2304e564994e05b981ccd6cd8cbb9dc85be

2 function symbol(s) added
  'struct drm_private_state* drm_atomic_get_new_private_obj_state(struct drm_atomic_state*, struct drm_private_obj*)'
  'uint64_t drm_format_info_min_pitch(const struct drm_format_info*, int, unsigned int)'

Bug: 319070243
Change-Id: I54d8e1c1ff2ecbddd54d61724577ddad1cbfde08
Signed-off-by: Qinglin Li <qinglin.li@amlogic.com>

commit 4b7de801 upstream.

Lee pointed out issue found by syscaller [0] hitting BUG in prog array
map poke update in prog_array_map_poke_run function due to error value
returned from bpf_arch_text_poke function.

There's race window where bpf_arch_text_poke can fail due to missing
bpf program kallsym symbols, which is accounted for with check for
-EINVAL in that BUG_ON call.

The problem is that in such case we won't update the tail call jump
and cause imbalance for the next tail call update check which will
fail with -EBUSY in bpf_arch_text_poke.

I'm hitting following race during the program load:

  CPU 0                             CPU 1

  bpf_prog_load
    bpf_check
      do_misc_fixups
        prog_array_map_poke_track

                                    map_update_elem
                                      bpf_fd_array_map_update_elem
                                        prog_array_map_poke_run

                                          bpf_arch_text_poke returns -EINVAL

    bpf_prog_kallsyms_add

After bpf_arch_text_poke (CPU 1) fails to update the tail call jump, the next
poke update fails on expected jump instruction check in bpf_arch_text_poke
with -EBUSY and triggers the BUG_ON in prog_array_map_poke_run.

Similar race exists on the program unload.

Fixing this by moving the update to bpf_arch_poke_desc_update function which
makes sure we call __bpf_arch_text_poke that skips the bpf address check.

Each architecture has slightly different approach wrt looking up bpf address
in bpf_arch_text_poke, so instead of splitting the function or adding new
'checkip' argument in previous version, it seems best to move the whole
map_poke_run update as arch specific code.

  [0] https://syzkaller.appspot.com/bug?extid=97a4fe20470e9bc30810



Bug: 309551558
Fixes: ebf7d1f5 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT")
Reported-by:  <syzbot+97a4fe20470e9bc30810@syzkaller.appspotmail.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Cc: Lee Jones <lee@kernel.org>
Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/bpf/20231206083041.1306660-2-jolsa@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 13578b4e)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I1291f0589e84f627ee44d07acb24196fab166c29

9 function symbol(s) added
  'int nf_log_buf_add(struct nf_log_buf *, const char *, ...)'
  'void nf_log_buf_close(struct nf_log_buf *)'
  'struct nf_log_buf * nf_log_buf_open()'
  'int nf_log_register(u_int8_t, struct nf_logger *)'
  'int nf_log_set(struct net *, u_int8_t, const struct nf_logger *)'
  'void nf_log_unregister(struct nf_logger *)'
  'void nf_log_unset(struct net *, const struct nf_logger *)'
  'int nf_logger_find_get(int, enum nf_log_type)'
  'void nf_logger_put(int, enum nf_log_type)'

Bug: 316040982

Change-Id: Icd40e3750160b579b1eea3710ac6c855585b2b4c
Signed-off-by: Norihiko Hama <Norihiko.Hama@alpsalpine.com>

2 function symbol(s) added
  'void arp_send(int, int, __be32, struct net_device *, __be32, const unsigned char *, const unsigned char *, const unsigned char *)'
  'void nf_log_packet(struct net *, u_int8_t, unsigned int, const struct sk_buff *, const struct net_device *, const struct net_device *, const struct nf_loginfo *, const char *, ...)'

1 variable symbol(s) added
  'int sysctl_nf_log_all_netns'

Bug: 316040982

Change-Id: Ie421b63df849c8ae5cafd18c890cc6e641a70fa3
Signed-off-by: Norihiko Hama <Norihiko.Hama@alpsalpine.com>

18 function symbol(s) added
  'void __audit_log_nfcfg(const char *, u8, unsigned int, enum audit_nfcfgop, gfp_t)'
  'int nf_register_sockopt(struct nf_sockopt_ops *)'
  'void nf_unregister_sockopt(struct nf_sockopt_ops *)'
  'void * vmalloc_node(unsigned long int, int)'
  'int xt_check_match(struct xt_mtchk_param *, unsigned int, u16, bool)'
  'int xt_check_target(struct xt_tgchk_param *, unsigned int, u16, bool)'
  'int xt_compat_add_offset(u_int8_t, unsigned int, int)'
  'int xt_compat_calc_jump(u_int8_t, unsigned int)'
  'void xt_compat_flush_offsets(u_int8_t)'
  'int xt_compat_init_offsets(u8, unsigned int)'
  'void xt_compat_lock(u_int8_t)'
  'int xt_compat_match_offset(const struct xt_match *)'
  'int xt_compat_target_offset(const struct xt_target *)'
  'void xt_compat_unlock(u_int8_t)'
  'int xt_data_to_user(void *, void *, int, int, int)'
  'struct xt_match * xt_find_match(u8, const char *, u8)'
  'struct xt_match * xt_request_find_match(uint8_t, const char *, uint8_t)'
  'struct xt_target * xt_request_find_target(u8, const char *, u8)'

1 variable symbol(s) added
  'u32 audit_enabled'

Bug: 316040982

Change-Id: I5d3bb3ad453ac4c231f7c23531d84a96673b1487
Signed-off-by: Norihiko Hama <Norihiko.Hama@alpsalpine.com>

35 function symbol(s) added
  'int __skb_vlan_pop(struct sk_buff *, u16 *)'
  'struct flow_rule * flow_rule_alloc(unsigned int)'
  'void * idr_get_next_ul(struct idr *, unsigned long int *)'
  'clock_t jiffies_to_clock_t(unsigned long int)'
  'int radix_tree_tagged(const struct xarray *, unsigned int)'
  'int skb_eth_pop(struct sk_buff *)'
  'int skb_eth_push(struct sk_buff *, const unsigned char *, const unsigned char *)'
  'void skb_flow_dissect_ct(const struct sk_buff *, struct flow_dissector *, void *, u16 *, size_t, bool, u16)'
  'void skb_flow_dissect_hash(const struct sk_buff *, struct flow_dissector *, void *)'
  'void skb_flow_dissect_meta(const struct sk_buff *, struct flow_dissector *, void *)'
  'void skb_flow_dissect_tunnel_info(const struct sk_buff *, struct flow_dissector *, void *)'
  'void skb_flow_dissector_init(struct flow_dissector *, const struct flow_dissector_key *, unsigned int)'
  'int skb_vlan_pop(struct sk_buff *)'
  'int skb_vlan_push(struct sk_buff *, __be16, u16)'
  'void tc_cleanup_flow_action(struct flow_action *)'
  'int tc_setup_cb_add(struct tcf_block *, struct tcf_proto *, enum tc_setup_type, void *, bool, u32 *, unsigned int *, bool)'
  'int tc_setup_cb_call(struct tcf_block *, enum tc_setup_type, void *, bool, bool)'
  'int tc_setup_cb_destroy(struct tcf_block *, struct tcf_proto *, enum tc_setup_type, void *, bool, u32 *, unsigned int *, bool)'
  'int tc_setup_cb_reoffload(struct tcf_block *, struct tcf_proto *, bool, flow_setup_cb_t *, enum tc_setup_type, void *, void *, u32 *, unsigned int *)'
  'int tc_setup_flow_action(struct flow_action *, const struct tcf_exts *)'
  'int tcf_action_check_ctrlact(int, struct tcf_proto *, struct tcf_chain * *, struct netlink_ext_ack *)'
  'struct tcf_chain * tcf_action_set_ctrlact(struct tc_action *, int, struct tcf_chain *)'
  'void tcf_action_update_stats(struct tc_action *, u64, u64, u64, bool)'
  'void tcf_chain_put_by_act(struct tcf_chain *)'
  'unsigned int tcf_exts_num_actions(struct tcf_exts *)'
  'int tcf_exts_terse_dump(struct sk_buff *, struct tcf_exts *)'
  'int tcf_generic_walker(struct tc_action_net *, struct sk_buff *, struct netlink_callback *, int, const struct tc_action_ops *, struct netlink_ext_ack *)'
  'int tcf_idr_check_alloc(struct tc_action_net *, u32 *, struct tc_action * *, int)'
  'void tcf_idr_cleanup(struct tc_action_net *, u32)'
  'int tcf_idr_create_from_flags(struct tc_action_net *, u32, struct nlattr *, struct tc_action * *, const struct tc_action_ops *, int, u32)'
  'int tcf_idr_release(struct tc_action *, bool)'
  'int tcf_idr_search(struct tc_action_net *, struct tc_action * *, u32)'
  'void tcf_idrinfo_destroy(const struct tc_action_ops *, struct tcf_idrinfo *)'
  'int tcf_register_action(struct tc_action_ops *, struct pernet_operations *)'
  'int tcf_unregister_action(struct tc_action_ops *, struct pernet_operations *)'

Bug: 316040982

Change-Id: I00ee6a74d989f064481ff0792e1fc7e13297259f
Signed-off-by: Norihiko Hama <Norihiko.Hama@alpsalpine.com>

3 function symbol(s) added
  'void led_blink_set_oneshot(struct led_classdev *, unsigned long int *, unsigned long int *, int)'
  'void led_set_brightness_nosleep(struct led_classdev *, unsigned int)'
  'void led_stop_software_blink(struct led_classdev *)'

Bug: 316040982

Change-Id: I572c748daf772e6d60e621e5de66c9c0197d87c3
Signed-off-by: Norihiko Hama <Norihiko.Hama@alpsalpine.com>

Initial add for oem specific symbol list

2 function symbol(s) added
  'void * devres_find(struct device *, dr_release_t, dr_match_t, void *)'
  'bool refcount_dec_if_one(refcount_t *)'

Bug: 316040982

Change-Id: Ife8808fead2e700f8213090d4a11b2666c43f04b
Signed-off-by: Norihiko Hama <Norihiko.Hama@alpsalpine.com>

1 function symbol(s) added
  'int __traceiter_android_rvh_set_task_comm(void *, struct task_struct *, bool)'

1 variable symbol(s) added
  'struct tracepoint __tracepoint_android_rvh_set_task_comm'

Bug: 317949078
Change-Id: Ie83da092349eb881e93f892aa391b108da313011
Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>

android_rvh_set_task_comm:
	To record vendor-specific task comm's change.

We need to know the name changes of specific tasks so that
we can notify the user layer of the pids of these tasks,
and then the user layer can set some attributes of the tasks
based on the names, such as priority scheduling, priority, etc.

Since the user layer is notified through netlink, and netlink may
cause blocking actions when sending messages, it's non-atomic context,
so set the hook be restricted.

Bug: 317949078
Change-Id: Ica30c123be339a7ef29c727bfaa7513efced5bd1
Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>

Task A calls binder_update_page_range() to allocate and insert pages on
a remote address space from Task B. For this, Task A pins the remote mm
via mmget_not_zero() first. This can race with Task B do_exit() and the
final mmput() refcount decrement will come from Task A.

  Task A            | Task B
  ------------------+------------------
  mmget_not_zero()  |
                    |  do_exit()
                    |    exit_mm()
                    |      mmput()
  mmput()           |
    exit_mmap()     |
      remove_vma()  |
        fput()      |

In this case, the work of ____fput() from Task B is queued up in Task A
as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
work gets executed. However, Task A instead sleep, waiting for a reply
from Task B that never comes (it's dead).

This means the binder_deferred_release() is blocked until an unrelated
binder event forces Task A to go back to userspace. All the associated
death notifications will also be delayed until then.

In order to fix this use mmput_async() that will schedule the work in
the corresponding mm->async_put_work WQ instead of Task A.

Fixes: 457b9a6f ("Staging: android: add binder driver")
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>

Bug: 293845143
Link: https://lore.kernel.org/all/20231201172212.1813387-4-cmllamas@google.com/


Change-Id: I2ec43b375e115c0daf21df3893da634dbefeed3e
Signed-off-by: Carlos Llamas <cmllamas@google.com>

KASAN-related crash observed on aosp-main cuttlefish with commit b37eb452.

In commit b37eb452 ("KMI workaround for CONFIG_NETFILTER_FAMILY_BRIDGE"),
type struct nf_hook_entries for global init_net are statically preserved
as 'init_nf_hooks_bridge' which is an array of type struct nf_hook_entries
instead of a member of struct net_ns.
And also 'init_nf_hooks_bridgep' addresses to init_nf_hooks_bridge.

netfilter_net_init() initialize the pointer array of type struct nf_hook_entries
but in case for nf_hook_birdge, get_nf_hooks_bridge() for init_net returns
the address of 'init_nf_hooks_bridgep' that is compatible with
type struct nf_hook_entries ** but it's not allocated array size of nf_hook_entries
(NF_INET_NUMHOOKS)

As the result, netfilter_net_init() initialize out-of-bounds memory and then
it possibly causes kernel panic with KASAN enabled configuration.

[   15.437905] ==================================================================
[   15.439156] BUG: KASAN: global-out-of-bounds in netfilter_net_init+0x17b/0x240
[   15.439156] Write of size 8 at addr ffffffff84e40488 by task swapper/0/1
[   15.439156]
[   15.439156] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.137-android13-8-...
[   15.439156] Hardware name: emulation qemu-x86/qemu-x86, BIOS 2023.04-gc2f63...
[   15.439156] Call Trace:
[   15.439156]  <TASK>
[   15.439156]  dump_stack_lvl+0xbb/0xf2
[   15.439156]  print_address_description+0x87/0x3b0
[   15.439156]  ? _raw_spin_lock_irqsave+0x80/0xe0
[   15.439156]  kasan_report+0x17a/0x1c0
[   15.439156]  ? netfilter_net_init+0x17b/0x240
[   15.439156]  ? netfilter_net_init+0x17b/0x240
[   15.439156]  __asan_store8+0x80/0x90
[   15.439156]  netfilter_net_init+0x17b/0x240
[   15.439156]  ops_init+0x1dd/0x290
[   15.439156]  ? kfree+0xc8/0x210
[   15.439156]  register_pernet_operations+0x176/0x350
[   15.439156]  ? alsa_sound_last_init+0x97/0x97
[   15.439156]  register_pernet_subsys+0x28/0x40
[   15.439156]  netfilter_init+0x16/0x4d
[   15.439156]  sock_init+0xa1/0xc6
[   15.439156]  do_one_initcall+0xfc/0x380
[   15.439156]  do_initcall_level+0x103/0x1dd
[   15.439156]  do_initcalls+0x4e/0x8e
[   15.439156]  do_basic_setup+0x6d/0x74
[   15.439156]  kernel_init_freeable+0x19a/0x21b
[   15.439156]  ? rest_init+0xe0/0xe0
[   15.439156]  kernel_init+0x1d/0x240
[   15.439156]  ? rest_init+0xe0/0xe0
[   15.439156]  ret_from_fork+0x1f/0x30
[   15.439156]  </TASK>
[   15.439156]
[   15.439156] The buggy address belongs to the variable:
[   15.439156]  init_nf_hooks_bridgep+0x8/0x20
[   15.439156]
[   15.439156] Memory state around the buggy address:
[   15.439156]  ffffffff84e40380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   15.439156]  ffffffff84e40400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   15.439156] >ffffffff84e40480: 00 f9 f9 f9 00 00 00 00 00 00 00 00 f9 f9 f9 f9
[   15.439156]                       ^
[   15.439156]  ffffffff84e40500: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00
[   15.439156]  ffffffff84e40580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   15.439156] ==================================================================

Tto fix the issue, it's just simple:
- type 'init_nf_hooks_bridge' makes changed to
  pointer array of type struct nf_hook_entries.
- type 'init_nf_hooks_bridgep' makes changed to pointer of pointer
  and it makes address to the array top of 'init_nf_hooks_bridge'.
- get_nf_hooks_bridge() for global init_net should return 'init_nf_hooks_bridgep'
  which address to pointer array so that netfilter_net_init can initialize.

Bug: 316040984
Fixes: b37eb452 ("KMI workaround for CONFIG_NETFILTER_FAMILY_BRIDGE")

Change-Id: I29a36da490e1ca18c04fd8c4dea235782f14b83b
Signed-off-by: Norihiko Hama <Norihiko.Hama@alpsalpine.com>

1 function symbol(s) added
  'int __traceiter_android_vh_rt_mutex_steal(void*, int, int, bool*)'

1 variable symbol(s) added
  'struct tracepoint __tracepoint_android_vh_rt_mutex_steal'

Bug: 317670024
Change-Id: I28f0379adaec041400e49cbd1e497b2f8c5c893d
Signed-off-by: xeiliujie <xieliujie@oppo.com>

Add hooks at rt_mutex_steal function so that oems can decide
whether tasks with the same priority steal the rt_mutex or
not. We did experiments and found that rt_mutex throughput
can benefit a lot when threads with the same priority can
steal the rt_mutex lock.

Bug: 317670024
Change-Id: Id60a7a41c6c77a67808982d3667946cabe4acc8f
Signed-off-by: xeiliujie <xieliujie@oppo.com>

There is a chance if a frequent switch of the governor
done in a loop result in timer list corruption where
timer cancel being done from two place one from
cancel_delayed_work_sync() and followed by expire_timers()
can be seen from the traces[1].

while true
do
        echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor
        echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor
done

It looks to be issue with devfreq driver where
device_monitor_[start/stop] need to synchronized so that
delayed work should get corrupted while it is either
being queued or running or being cancelled.

Let's use polling flag and devfreq lock to synchronize the
queueing the timer instance twice and work data being
corrupted.

[1]
...
..
<idle>-0    [003]   9436.209662:  timer_cancel   timer=0xffffff80444f0428
<idle>-0    [003]   9436.209664:  timer_expire_entry   timer=0xffffff80444f0428  now=0x10022da1c  function=__typeid__ZTSFvP10timer_listE_global_addr  baseclk=0x10022da1c
<idle>-0    [003]   9436.209718:  timer_expire_exit   timer=0xffffff80444f0428
kworker/u16:6-14217    [003]   9436.209863:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2b  now=0x10022da1c  flags=182452227
vendor.xxxyyy.ha-1593    [004]   9436.209888:  timer_cancel   timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593    [004]   9436.216390:  timer_init   timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593    [004]   9436.216392:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2c  now=0x10022da1d  flags=186646532
vendor.xxxyyy.ha-1593    [005]   9436.220992:  timer_cancel   timer=0xffffff80444f0428
xxxyyyTraceManag-7795    [004]   9436.261641:  timer_cancel   timer=0xffffff80444f0428

[2]

 9436.261653][    C4] Unable to handle kernel paging request at virtual address dead00000000012a
[ 9436.261664][    C4] Mem abort info:
[ 9436.261666][    C4]   ESR = 0x96000044
[ 9436.261669][    C4]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 9436.261671][    C4]   SET = 0, FnV = 0
[ 9436.261673][    C4]   EA = 0, S1PTW = 0
[ 9436.261675][    C4] Data abort info:
[ 9436.261677][    C4]   ISV = 0, ISS = 0x00000044
[ 9436.261680][    C4]   CM = 0, WnR = 1
[ 9436.261682][    C4] [dead00000000012a] address between user and kernel address ranges
[ 9436.261685][    C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[ 9436.261701][    C4] Skip md ftrace buffer dump for: 0x3a982d0
...

[ 9436.262138][    C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S      W  O      5.10.149-android12-9-o-g17f915d29d0c #1
[ 9436.262141][    C4] Hardware name: Qualcomm Technologies, Inc.  (DT)
[ 9436.262144][    C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)
[ 9436.262161][    C4] pc : expire_timers+0x9c/0x438
[ 9436.262164][    C4] lr : expire_timers+0x2a4/0x438
[ 9436.262168][    C4] sp : ffffffc010023dd0
[ 9436.262171][    C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18
[ 9436.262178][    C4] x27: ffffffd063569dd0 x26: ffffffd063536008
[ 9436.262182][    C4] x25: 0000000000000001 x24: ffffff88f7c69280
[ 9436.262185][    C4] x23: 00000000000000e0 x22: dead000000000122
[ 9436.262188][    C4] x21: 000000010022da29 x20: ffffff8af72b4e80
[ 9436.262191][    C4] x19: ffffffc010023e50 x18: ffffffc010025038
[ 9436.262195][    C4] x17: 0000000000000240 x16: 0000000000000201
[ 9436.262199][    C4] x15: ffffffffffffffff x14: ffffff889f3c3100
[ 9436.262203][    C4] x13: ffffff889f3c3100 x12: 00000000049f56b8
[ 9436.262207][    C4] x11: 00000000049f56b8 x10: 00000000ffffffff
[ 9436.262212][    C4] x9 : ffffffc010023e50 x8 : dead000000000122
[ 9436.262216][    C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8
[ 9436.262220][    C4] x5 : 0000000000000000 x4 : 0000000000000101
[ 9436.262223][    C4] x3 : 0000000000000080 x2 : ffffff889edc155c
[ 9436.262227][    C4] x1 : ffffff8001005200 x0 : ffffff80444f0428
[ 9436.262232][    C4] Call trace:
[ 9436.262236][    C4]  expire_timers+0x9c/0x438
[ 9436.262240][    C4]  __run_timers+0x1f0/0x330
[ 9436.262245][    C4]  run_timer_softirq+0x28/0x58
[ 9436.262255][    C4]  efi_header_end+0x168/0x5ec
[ 9436.262265][    C4]  __irq_exit_rcu+0x108/0x124
[ 9436.262274][    C4]  __handle_domain_irq+0x118/0x1e4
[ 9436.262282][    C4]  gic_handle_irq.30369+0x6c/0x2bc
[ 9436.262286][    C4]  el0_irq_naked+0x60/0x6c

Bug: 317188938
Change-Id: I9a22325f6abbf28217c8f37b093cf77509b0139a
Link: https://lore.kernel.org/all/1700860318-4025-1-git-send-email-quic_mojha@quicinc.com/


Reported-by: Joyyoung Huang <huangzaiyang@oppo.com>
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
(cherry picked from commit aed5ed59
 https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git

 devfreq-next)
Signed-off-by: Srinivasarao Pathipati <quic_c_spathi@quicinc.com>

[ Upstream commit f0498d2a ]

Kuyo reported sporadic failures on a sched_setaffinity() vs CPU
hotplug stress-test -- notably affine_move_task() remains stuck in
wait_for_completion(), leading to a hung-task detector warning.

Specifically, it was reported that stop_one_cpu_nowait(.fn =
migration_cpu_stop) returns false -- this stopper is responsible for
the matching complete().

The race scenario is:

	CPU0					CPU1

					// doing _cpu_down()

  __set_cpus_allowed_ptr()
    task_rq_lock();
					takedown_cpu()
					  stop_machine_cpuslocked(take_cpu_down..)

					<PREEMPT: cpu_stopper_thread()
					  MULTI_STOP_PREPARE
					  ...
    __set_cpus_allowed_ptr_locked()
      affine_move_task()
        task_rq_unlock();

  <PREEMPT: cpu_stopper_thread()\>
    ack_state()
					  MULTI_STOP_RUN
					    take_cpu_down()
					      __cpu_disable();
					      stop_machine_park();
						stopper->enabled = false;
					 />
   />
	stop_one_cpu_nowait(.fn = migration_cpu_stop);
          if (stopper->enabled) // false!!!

That is, by doing stop_one_cpu_nowait() after dropping rq-lock, the
stopper thread gets a chance to preempt and allows the cpu-down for
the target CPU to complete.

OTOH, since stop_one_cpu_nowait() / cpu_stop_queue_work() needs to
issue a wakeup, it must not be ran under the scheduler locks.

Solve this apparent contradiction by keeping preemption disabled over
the unlock + queue_stopper combination:

	preempt_disable();
	task_rq_unlock(...);
	if (!stop_pending)
	  stop_one_cpu_nowait(...)
	preempt_enable();

This respects the lock ordering contraints while still avoiding the
above race. That is, if we find the CPU is online under rq-lock, the
targeted stop_one_cpu_nowait() must succeed.

Apply this pattern to all similar stop_one_cpu_nowait() invocations.

BUG: 317318329
Fixes: 6d337eab ("sched: Fix migrate_disable() vs set_cpus_allowed_ptr()")
Reported-by: "Kuyo Chang (張建文)" <Kuyo.Chang@mediatek.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: "Kuyo Chang (張建文)" <Kuyo.Chang@mediatek.com>
Link: https://lkml.kernel.org/r/20231010200442.GA16515@noisy.programming.kicks-ass.net


Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Dylan Chang <dylan.chang@nothing.tech>
Change-Id: Ib2cc52566f43c3c10f694ce9c1c6a6569b4e2687

We found an issue under Android OTA scenario that many BIOs have to do
FEC where the data under dm-verity is 100% complete and no corruption.

Android OTA has many dm-block layers, from upper to lower:
dm-verity
dm-snapshot
dm-origin & dm-cow
dm-linear
ufs

DM tables have to change 2 times during Android OTA merging process.
When doing table change, the dm-snapshot will be suspended for a while.
During this interval, many readahead IOs are submitted to dm_verity
from filesystem. Then the kverity works are busy doing FEC process
which cost too much time to finish dm-verity IO. This causes needless
delay which feels like system is hung.

After adding debugging it was found that each readahead IO needed
around 10s to finish when this situation occurred. This is due to IO
amplification:

dm-snapshot suspend
erofs_readahead     // 300+ io is submitted
	dm_submit_bio (dm_verity)
		dm_submit_bio (dm_snapshot)
		bio return EIO
		bio got nothing, it's empty
	verity_end_io
	verity_verify_io
	forloop range(0, io->n_blocks)    // each io->nblocks ~= 20
		verity_fec_decode
		fec_decode_rsb
		fec_read_bufs
		forloop range(0, v->fec->rsn) // v->fec->rsn = 253
			new_read
			submit_bio (dm_snapshot)
		end loop
	end loop
dm-snapshot resume

Readahead BIOs get nothing while dm-snapshot is suspended, so all of
them will cause verity's FEC.
Each readahead BIO needs to verify ~20 (io->nblocks) blocks.
Each block needs to do FEC, and every block needs to do 253
(v->fec->rsn) reads.
So during the suspend interval(~200ms), 300 readahead BIOs trigger
~1518000 (300*20*253) IOs to dm-snapshot.

As readahead IO is not required by userspace, and to fix this issue,
it is best to pass readahead errors to upper layer to handle it.

Cc: stable@vger.kernel.org
Fixes: a739ff3f ("dm verity: add support for forward error correction")
Bug: 316972624
Link: https://lore.kernel.org/dm-devel/b84fb49-bf63-3442-8c99-d565e134f2@redhat.com


Signed-off-by: Wu Bo <bo.wu@vivo.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Akilesh Kailash <akailash@google.com>
(cherry picked from commit 0193e396)
Change-Id: I73560e5660cebdc1997e1f9926cbb8888789eb46