* keystone/mirror-android12-5.10-2022-05: (135 commits)
BACKPORT: can: usb_8dev: usb_8dev_start_xmit(): fix double dev_kfree_skb() in error path
ANDROID: GKI: Update symbols to symbol list
ANDROID: oplus: Update the ABI xml and symbol list
UPSTREAM: remoteproc: Fix count check in rproc_coredump_write()
BACKPORT: esp: Fix possible buffer overflow in ESP transformation
ANDROID: Fix the drain_all_pages default condition broken by a hook
UPSTREAM: Revert "xfrm: xfrm_state_mtu should return at least 1280 for ipv6"
UPSTREAM: xfrm: fix MTU regression
ANDROID: signal: Add vendor hook for memory reaping
FROMGIT: usb: gadget: uvc: allow for application to cleanly shutdown
FROMGIT: usb: dwc3: gadget: increase tx fifo size for ss isoc endpoints
UPSTREAM: usb: gadget: configfs: clear deactivation flag in configfs_composite_unbind()
FROMGIT: usb: gadget: uvc: remove pause flag use
FROMGIT: usb: gadget: uvc: allow changing interface name via configfs
UPSTREAM: usb: gadget: uvc: Fix crash when encoding data for usb request
UPSTREAM: usb: gadget: uvc: test if ep->desc is valid on ep_queue
UPSTREAM: usb: gadget: uvc: only pump video data if necessary
UPSTREAM: usb: gadget: uvc: only schedule stream in streaming state
UPSTREAM: usb: dwc3: gadget: Give some time to schedule isoc
UPSTREAM: usb: gadget: uvc: make uvc_num_requests depend on gadget speed
...
Change-Id: I438ffbf5441deb75dadf2150e235232bc53c37ea
* keystone/mirror-android12-5.10-2022-04:
UPSTREAM: Revert "xfrm: xfrm_state_mtu should return at least 1280 for ipv6"
UPSTREAM: xfrm: fix MTU regression
Signed-off-by: keystone-kernel-automerger <keystone-kernel-automerger@google.com>
Change-Id: I623a3b2b08f90bd908935bb86c6b4595a3f9bf16
The condition introduced by a patch adding a vendor hook to skip
drain_all_pages is invalid and changes the default behavior for CMA
allocations. Fix the condition to restore default behavior.
Fixes: a2485b8abd ("ANDROID: vendor_hooks: Add hooks to for alloc_contig_range")
Bug: 232357688
Reported-by: Yong-Taek Lee <ytk.lee@samsung.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I686ad9dff57f604557f79cf4dc12cde55474e533
(cherry picked from commit 66f0c91b2f)
commit ebe48d368e97d007bfeb76fcb065d6cfc4c96645 upstream.
The maximum message size that can be send is bigger than
the maximum site that skb_page_frag_refill can allocate.
So it is possible to write beyond the allocated buffer.
Fix this by doing a fallback to COW in that case.
v2:
Avoid get get_order() costs as suggested by Linus Torvalds.
Bug: 227452856
Fixes: cac2661c53 ("esp4: Avoid skb_cow_data whenever possible")
Fixes: 03e2a30f6a ("esp6: Avoid skb_cow_data whenever possible")
Reported-by: valis <sec@valis.email>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I2c7f97914138271e7788adfcebbd0b2b8b43cdcb
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The condition introduced by a patch adding a vendor hook to skip
drain_all_pages is invalid and changes the default behavior for CMA
allocations. Fix the condition to restore default behavior.
Fixes: a2485b8abd ("ANDROID: vendor_hooks: Add hooks to for alloc_contig_range")
Bug: 232357688
Reported-by: Yong-Taek Lee <ytk.lee@samsung.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I686ad9dff57f604557f79cf4dc12cde55474e533
commit a6d95c5a628a09be129f25d5663a7e9db8261f51 upstream.
This reverts commit b515d2637276a3810d6595e10ab02c13bfd0b63a.
Commit b515d2637276a3810d6595e10ab02c13bfd0b63a ("xfrm: xfrm_state_mtu
should return at least 1280 for ipv6") in v5.14 breaks the TCP MSS
calculation in ipsec transport mode, resulting complete stalls of TCP
connections. This happens when the (P)MTU is 1280 or slighly larger.
The desired formula for the MSS is:
MSS = (MTU - ESP_overhead) - IP header - TCP header
However, the above commit clamps the (MTU - ESP_overhead) to a
minimum of 1280, turning the formula into
MSS = max(MTU - ESP overhead, 1280) - IP header - TCP header
With the (P)MTU near 1280, the calculated MSS is too large and the
resulting TCP packets never make it to the destination because they
are over the actual PMTU.
The above commit also causes suboptimal double fragmentation in
xfrm tunnel mode, as described in
https://lore.kernel.org/netdev/20210429202529.codhwpc7w6kbudug@dwarf.suse.cz/
The original problem the above commit was trying to fix is now fixed
by commit 6596a0229541270fb8d38d989f91b78838e5e9da ("xfrm: fix MTU
regression").
Bug: 232198719
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: If9f9f1015f1a494775f79efe7e84a37b63e48d3c
Signed-off-by: Lina Wang <lina.wang@mediatek.com>
commit a6d95c5a628a09be129f25d5663a7e9db8261f51 upstream.
This reverts commit b515d2637276a3810d6595e10ab02c13bfd0b63a.
Commit b515d2637276a3810d6595e10ab02c13bfd0b63a ("xfrm: xfrm_state_mtu
should return at least 1280 for ipv6") in v5.14 breaks the TCP MSS
calculation in ipsec transport mode, resulting complete stalls of TCP
connections. This happens when the (P)MTU is 1280 or slighly larger.
The desired formula for the MSS is:
MSS = (MTU - ESP_overhead) - IP header - TCP header
However, the above commit clamps the (MTU - ESP_overhead) to a
minimum of 1280, turning the formula into
MSS = max(MTU - ESP overhead, 1280) - IP header - TCP header
With the (P)MTU near 1280, the calculated MSS is too large and the
resulting TCP packets never make it to the destination because they
are over the actual PMTU.
The above commit also causes suboptimal double fragmentation in
xfrm tunnel mode, as described in
https://lore.kernel.org/netdev/20210429202529.codhwpc7w6kbudug@dwarf.suse.cz/
The original problem the above commit was trying to fix is now fixed
by commit 6596a0229541270fb8d38d989f91b78838e5e9da ("xfrm: fix MTU
regression").
Bug: 232198719
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: If9f9f1015f1a494775f79efe7e84a37b63e48d3c
Signed-off-by: Lina Wang <lina.wang@mediatek.com>
commit 6596a0229541270fb8d38d989f91b78838e5e9da upstream.
Commit 749439bfac ("ipv6: fix udpv6
sendmsg crash caused by too small MTU") breaks PMTU for xfrm.
A Packet Too Big ICMPv6 message received in response to an ESP
packet will prevent all further communication through the tunnel
if the reported MTU minus the ESP overhead is smaller than 1280.
E.g. in a case of a tunnel-mode ESP with sha256/aes the overhead
is 92 bytes. Receiving a PTB with MTU of 1371 or less will result
in all further packets in the tunnel dropped. A ping through the
tunnel fails with "ping: sendmsg: Invalid argument".
Apparently the MTU on the xfrm route is smaller than 1280 and
fails the check inside ip6_setup_cork() added by 749439bf.
We found this by debugging USGv6/ipv6ready failures. Failing
tests are: "Phase-2 Interoperability Test Scenario IPsec" /
5.3.11 and 5.4.11 (Tunnel Mode: Fragmentation).
Commit b515d2637276a3810d6595e10ab02c13bfd0b63a ("xfrm:
xfrm_state_mtu should return at least 1280 for ipv6") attempted
to fix this but caused another regression in TCP MSS calculations
and had to be reverted.
The patch below fixes the situation by dropping the MTU
check and instead checking for the underflows described in the
749439bf commit message.
Bug: 232198720
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Fixes: 749439bfac ("ipv6: fix udpv6 sendmsg crash caused by too small MTU")
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I8cd20af2f9074d177907c4ae69486ed125e74238
Signed-off-by: Lina Wang <lina.wang@mediatek.com>
commit 6596a0229541270fb8d38d989f91b78838e5e9da upstream.
Commit 749439bfac ("ipv6: fix udpv6
sendmsg crash caused by too small MTU") breaks PMTU for xfrm.
A Packet Too Big ICMPv6 message received in response to an ESP
packet will prevent all further communication through the tunnel
if the reported MTU minus the ESP overhead is smaller than 1280.
E.g. in a case of a tunnel-mode ESP with sha256/aes the overhead
is 92 bytes. Receiving a PTB with MTU of 1371 or less will result
in all further packets in the tunnel dropped. A ping through the
tunnel fails with "ping: sendmsg: Invalid argument".
Apparently the MTU on the xfrm route is smaller than 1280 and
fails the check inside ip6_setup_cork() added by 749439bf.
We found this by debugging USGv6/ipv6ready failures. Failing
tests are: "Phase-2 Interoperability Test Scenario IPsec" /
5.3.11 and 5.4.11 (Tunnel Mode: Fragmentation).
Commit b515d2637276a3810d6595e10ab02c13bfd0b63a ("xfrm:
xfrm_state_mtu should return at least 1280 for ipv6") attempted
to fix this but caused another regression in TCP MSS calculations
and had to be reverted.
The patch below fixes the situation by dropping the MTU
check and instead checking for the underflows described in the
749439bf commit message.
Bug: 232198720
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Fixes: 749439bfac ("ipv6: fix udpv6 sendmsg crash caused by too small MTU")
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I8cd20af2f9074d177907c4ae69486ed125e74238
Signed-off-by: Lina Wang <lina.wang@mediatek.com>
Since commit 3bcdb496f4 ("ANDROID: signal: Add vendor hook
for memory reaping"), but *current* does not need. Add another
hook here to determine killed process need be reaped.
(e.g. get_mm_counter)
Bug: 232062955
Change-Id: Ide13d3a2e8c199b063f41e071a2bf2fd60a91b04
Signed-off-by: liuhailong <liuhailong@oppo.com>
If any function like UVC is deactivating gadget as part of composition
switch which results in not calling pullup enablement, it is not getting
enabled after switch to new composition due to this deactivation flag
not cleared. This results in USB enumeration not happening after switch
to new USB composition. Hence clear deactivation flag inside gadget
structure in configfs_composite_unbind() before switch to new USB
composition.
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Signed-off-by: Dan Vacura <w36195@motorola.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20220413211038.72797-1-w36195@motorola.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 229140375
(cherry picked from commit bf95c4d4630c7a2c16e7b424fdea5177d9ce0864)
Change-Id: I0013ab8443e47788291951516baec3e7c8e445aa
Signed-off-by: Dan Vacura <w36195@motorola.com>
The pause flag doesn't appear to serve a purpose as it is possible for
the pump worker thread to not be running when new buffers are queued.
Before the following change was introduced: "43cd0023872e usb: gadget:
uvc_video: add worker to handle the frame pumping", the pause flag
status was discarded and never returned. This masked a current issues of
the userspace receiving non-zero values (considered unsuccessful) and
prevents trace_v4l2_qbuf() from being called.
Signed-off-by: Dan Vacura <w36195@motorola.com>
Link: https://lore.kernel.org/r/20220413192402.26063-1-w36195@motorola.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 229140375
(cherry picked from commit be30e3502771ac0b5080ec61223d915354cde1cc
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Change-Id: Id841e7f0dc6c79f74ca41bb93f2504effc2fefd8
Signed-off-by: Dan Vacura <w36195@motorola.com>
During the uvcg_video_pump() process, if an error occurs and
uvcg_queue_cancel() is called, the buffer queue will be cleared out, but
the current marker (queue->buf_used) of the active buffer (no longer
active) is not reset. On the next iteration of uvcg_video_pump() the
stale buf_used count will be used and the logic of min((unsigned
int)len, buf->bytesused - queue->buf_used) may incorrectly calculate a
nbytes size, causing an invalid memory access.
[80802.185460][ T315] configfs-gadget gadget: uvc: VS request completed
with status -18.
[80802.185519][ T315] configfs-gadget gadget: uvc: VS request completed
with status -18.
...
uvcg_queue_cancel() is called and the queue is cleared out, but the
marker queue->buf_used is not reset.
...
[80802.262328][ T8682] Unable to handle kernel paging request at virtual
address ffffffc03af9f000
...
...
[80802.263138][ T8682] Call trace:
[80802.263146][ T8682] __memcpy+0x12c/0x180
[80802.263155][ T8682] uvcg_video_pump+0xcc/0x1e0
[80802.263165][ T8682] process_one_work+0x2cc/0x568
[80802.263173][ T8682] worker_thread+0x28c/0x518
[80802.263181][ T8682] kthread+0x160/0x170
[80802.263188][ T8682] ret_from_fork+0x10/0x18
[80802.263198][ T8682] Code: a8c12829 a88130cb a8c130
Fixes: d692522577 ("usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework")
Cc: <stable@vger.kernel.org>
Signed-off-by: Dan Vacura <w36195@motorola.com>
Link: https://lore.kernel.org/r/20220331184024.23918-1-w36195@motorola.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 229140375
(cherry picked from commit 71d471e3faf90c9674cadc7605ac719e82cb7fac)
Change-Id: I0e801793e56537177b0ff08dd8a5460d98c9614a
Signed-off-by: Dan Vacura <w36195@motorola.com>
In the config_ep_by_speed_and_alt function, select the corresponding
descriptor through g->speed. But some legacy or not well designed
function drivers may not support the corresponding speed. So, we can
directly display warnings instead of causing kernel panic. At the
same time, it indicates the reasons in warning message.
Reviewed-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Qihang Hu <huqihang@oppo.com>
Link: https://lore.kernel.org/r/20211110101129.462357-1-huqihang@oppo.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 229140375
(cherry picked from commit 16d42759207fc3d1bff7cfd330a08a225e470ba0)
Signed-off-by: Dan Vacura <w36195@motorola.com>
Change-Id: Iaef2ecfc080dc4a97fe9911af4da78316af8e063
Allow additional arguments be passed to userprogs compilation.
Reproducible clang builds need to provide a sysroot and gcc path to
ensure the same toolchain is used across hosts. KCFLAGS is not currently
used for any user programs compilation, so add new USERCFLAGS and
USERLDFLAGS which serves similar purpose as HOSTCFLAGS/HOSTLDFLAGS.
Clang 13+ might detect GCC installation on hosts which have it installed
to a default location in /. With addition of these environment
variables, you can specify flags such as:
$ make USERCFLAGS=--sysroot=/path/to/sysroot
This can also be used to specify different sysroots such as musl or
bionic which may be installed on the host in paths that the compiler
may not search by default.
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Bug: 214127735
Link: https://lore.kernel.org/linux-kbuild/20220201213542.2808035-1-quic_eberman@quicinc.com/
Change-Id: I035309a569130774a1212f294973eee2830a6588
(cherry picked from commit df704104322c6bd1b3d40cb7ad109cba7453f3be)
Bug: 195565510
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: Ic8134eb902aa7d929e3121b2f69b1d258f570652
(cherry picked from commit 98c15b2bad1a277da43c65c642f8c3c3ee07bacc)
Supply additional check in order to prevent unexpected results.
Bug: 205573273
Fixes: b892bf75b2 ("ion: Switch ion to use dma-buf")
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[Lee: Patch now applies to ion_buffer.c instead of ion.c]
Change-Id: Ia6afdd9ca502caa9cad6619d438fc6c8e8457679
(cherry picked from commit fea24b07ed)
When clatd starts with ebpf offloaing, and NETIF_F_GRO_FRAGLIST is enable,
several skbs are gathered in skb_shinfo(skb)->frag_list. The first skb's
ipv6 header will be changed to ipv4 after bpf_skb_proto_6_to_4,
network_header\transport_header\mac_header have been updated as ipv4 acts,
but other skbs in frag_list didnot update anything, just ipv6 packets.
udp_queue_rcv_skb will call skb_segment_list to traverse other skbs in
frag_list and make sure right udp payload is delivered to user space.
Unfortunately, other skbs in frag_list who are still ipv6 packets are
updated like the first skb and will have wrong transport header length.
e.g.before bpf_skb_proto_6_to_4,the first skb and other skbs in frag_list
has the same network_header(24)& transport_header(64), after
bpf_skb_proto_6_to_4, ipv6 protocol has been changed to ipv4, the first
skb's network_header is 44,transport_header is 64, other skbs in frag_list
didnot change.After skb_segment_list, the other skbs in frag_list has
different network_header(24) and transport_header(44), so there will be 20
bytes different from original,that is difference between ipv6 header and
ipv4 header. Just change transport_header to be the same with original.
Actually, there are two solutions to fix it, one is traversing all skbs
and changing every skb header in bpf_skb_proto_6_to_4, the other is
modifying frag_list skb's header in skb_segment_list. Considering
efficiency, adopt the second one--- when the first skb and other skbs in
frag_list has different network_header length, restore them to make sure
right udp payload is delivered to user space.
Signed-off-by: Lina Wang <lina.wang@mediatek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit cf3ab8d4a797960b4be20565abb3bcd227b18a68 https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git master)
Bug: 218157620
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I36f2f329ec1a56bb0742141a7fa482cafa183ad3
(cherry picked from commit 1e037dd790)
When clatd starts with ebpf offloaing, and NETIF_F_GRO_FRAGLIST is enable,
several skbs are gathered in skb_shinfo(skb)->frag_list. The first skb's
ipv6 header will be changed to ipv4 after bpf_skb_proto_6_to_4,
network_header\transport_header\mac_header have been updated as ipv4 acts,
but other skbs in frag_list didnot update anything, just ipv6 packets.
udp_queue_rcv_skb will call skb_segment_list to traverse other skbs in
frag_list and make sure right udp payload is delivered to user space.
Unfortunately, other skbs in frag_list who are still ipv6 packets are
updated like the first skb and will have wrong transport header length.
e.g.before bpf_skb_proto_6_to_4,the first skb and other skbs in frag_list
has the same network_header(24)& transport_header(64), after
bpf_skb_proto_6_to_4, ipv6 protocol has been changed to ipv4, the first
skb's network_header is 44,transport_header is 64, other skbs in frag_list
didnot change.After skb_segment_list, the other skbs in frag_list has
different network_header(24) and transport_header(44), so there will be 20
bytes different from original,that is difference between ipv6 header and
ipv4 header. Just change transport_header to be the same with original.
Actually, there are two solutions to fix it, one is traversing all skbs
and changing every skb header in bpf_skb_proto_6_to_4, the other is
modifying frag_list skb's header in skb_segment_list. Considering
efficiency, adopt the second one--- when the first skb and other skbs in
frag_list has different network_header length, restore them to make sure
right udp payload is delivered to user space.
Signed-off-by: Lina Wang <lina.wang@mediatek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit cf3ab8d4a797960b4be20565abb3bcd227b18a68 https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git master)
Bug: 218157620
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I36f2f329ec1a56bb0742141a7fa482cafa183ad3
commit e914d8f00391520ecc4495dd0ca0124538ab7119 upstream.
Two processes under CLONE_VM cloning, user process can be corrupted by
seeing zeroed page unexpectedly.
CPU A CPU B
do_swap_page do_swap_page
SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path
swap_readpage valid data
swap_slot_free_notify
delete zram entry
swap_readpage zeroed(invalid) data
pte_lock
map the *zero data* to userspace
pte_unlock
pte_lock
if (!pte_same)
goto out_nomap;
pte_unlock
return and next refault will
read zeroed data
The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't
increase the refcount of swap slot at copy_mm so it couldn't catch up
whether it's safe or not to discard data from backing device. In the
case, only the lock it could rely on to synchronize swap slot freeing is
page table lock. Thus, this patch gets rid of the swap_slot_free_notify
function. With this patch, CPU A will see correct data.
CPU A CPU B
do_swap_page do_swap_page
SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path
swap_readpage original data
pte_lock
map the original data
swap_free
swap_range_free
bd_disk->fops->swap_slot_free_notify
swap_readpage read zeroed data
pte_unlock
pte_lock
if (!pte_same)
goto out_nomap;
pte_unlock
return
on next refault will see mapped data by CPU B
The concern of the patch would increase memory consumption since it
could keep wasted memory with compressed form in zram as well as
uncompressed form in address space. However, most of cases of zram uses
no readahead and do_swap_page is followed by swap_free so it will free
the compressed form from in zram quickly.
Link: https://lkml.kernel.org/r/YjTVVxIAsnKAXjTd@google.com
Fixes: 0bcac06f27 ("mm, swap: skip swapcache for swapin of synchronous device")
Reported-by: Ivan Babrou <ivan@cloudflare.com>
Tested-by: Ivan Babrou <ivan@cloudflare.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: David Hildenbrand <david@redhat.com>
Cc: <stable@vger.kernel.org> [4.14+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Bug: 214353194
(cherry picked from commit 20ed94f818)
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
linux-5.10.y)
Change-Id: I06552d47d3d71f97da49385fccdad80ae65dba26
Current might be preempt after spin_unlock(&lock->wait_lock),
we want to add a hook after wake_up_q(&wake_q) in which to
disable owner's privilege in scheduler.
Bug: 231647361
Change-Id: I3016da2fd31b8bdc8435df4e800f91381a64af4f
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
* keystone/mirror-android12-5.10-2022-04: (1854 commits)
BACKPORT: media: v4l2-mem2mem: Apply DST_QUEUE_OFF_BASE on MMAP buffers across ioctls
FROMLIST: remoteproc: Use unbounded workqueue for recovery work
UPSTREAM: xfrm: fix tunnel model fragmentation behavior
ANDROID: GKI: Enable CRYPTO_DES
ANDROID: GKI: set more vfs-only exports into their own namespace
ANDROID: Split ANDROID_STRUCT_PADDING into separate configs
ANDROID: selftests: incfs: skip large_file_test test is not enough free space
ANDROID: selftests: incfs: Add -fno-omit-frame-pointer
ANDROID: incremental-fs: limit mount stack depth
ANDROID: GKI: Update symbols to abi_gki_aarch64_oplus
ANDROID: vendor_hooks: Reduce pointless modversions CRC churn
UPSTREAM: locking/lockdep: Avoid potential access of invalid memory in lock_class
ANDROID: mm: Fix implicit declaration of function 'isolate_lru_page'
ANDROID: GKI: Update symbols to symbol list
ANDROID: GKI: Update symbols to symbol list
ANDROID: GKI: Add hook symbol to symbol list
Revert "ANDROID: dm-bow: Protect Ranges fetched and erased from the RB tree"
ANDROID: vendor_hooks: Add hooks to for free_unref_page_commit
ANDROID: vendor_hooks: Add hooks to for alloc_contig_range
ANDROID: GKI: Update symbols to symbol list
...
Signed-off-by: Daniel Norman <danielnorman@google.com>
Change-Id: Ieaa00e9702ce27689208b4702b0fe2b7e0c1005b
The list_for_each_entry_safe() macro saves the current item (n) and
the item after (n+1), so that n can be safely removed without
corrupting the list. However, when traversing the list and removing
items using gadget giveback, the DWC3 lock is briefly released,
allowing other routines to execute. There is a situation where, while
items are being removed from the cancelled_list using
dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable
routine is running in parallel (due to UDC unbind). As the cleanup
routine removes n, and the pullup disable removes n+1, once the
cleanup retakes the DWC3 lock, it references a request who was already
removed/handled. With list debug enabled, this leads to a panic.
Ensure all instances of the macro are replaced where gadget giveback
is used.
Example call stack:
Thread#1:
__dwc3_gadget_ep_set_halt() - CLEAR HALT
-> dwc3_gadget_ep_cleanup_cancelled_requests()
->list_for_each_entry_safe()
->dwc3_gadget_giveback(n)
->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list]
->spin_unlock
->Thread#2 executes
...
->dwc3_gadget_giveback(n+1)
->Already removed!
Thread#2:
dwc3_gadget_pullup()
->waiting for dwc3 spin_lock
...
->Thread#1 released lock
->dwc3_stop_active_transfers()
->dwc3_remove_requests()
->fetches n+1 item from cancelled_list (n removed by Thread#1)
->dwc3_gadget_giveback()
->dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list]
->spin_unlock
Fixes: d4f1afe5e8 ("usb: dwc3: gadget: move requests to cancelled_list")
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220414183521.23451-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 230843866
(cherry picked from commit bf594d1d0c1d7b895954018043536ffd327844f9)
Change-Id: I357028fb51441a7effe90d115f6faa3f2034d326
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
It is recommended by the Synopsis databook to issue a DCTL.CSftReset
when reconnecting from a device-initiated disconnect routine. This
resolves issues with enumeration during fast composition switching
cases, which result in an unknown device on the host.
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220316011358.3057-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 230843866
(cherry picked from commit 0066472de157439d58454f4a55786f1045ea5681)
Change-Id: Idcfbb43e844c22cdfcb1362177e9c1a8e9a7e18e
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
If a Setup packet is received but yet to DMA out, the controller will
not process the End Transfer command of any endpoint. Polling of its
DEPCMD.CmdAct may block setting up TRB for Setup packet, causing a
command timeout.
This may occur if the driver doesn’t service the completion interrupt of
the control status stage yet due to system latency, then it won’t
prepare TRB and start the transfer for the next Setup Stage. To the host
side, the control transfer had completed, and the host can send a new
Setup packet at this point.
In the meanwhile, if the driver receives an async call to dequeue a
request (triggering End Transfer) to any endpoint, then the driver will
service that End transfer first, blocking the control status stage
completion handler. Since no TRB is available for the Setup stage, the
Setup packet can’t be DMA’ed out and the End Transfer gets hung.
The driver must not block setting up of the Setup stage. So track and
only issue the End Transfer command only when there’s Setup TRB prepared
so that the controller can DMA out the Setup packet. Delay the End
transfer command if there's no Setup TRB available. This is applicable to
all DWC_usb3x IPs.
Co-developed-by: Wesley Cheng <quic_wcheng@quicinc.com>
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220309205402.4467-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 230843866
(cherry picked from commit e4cf6580ac740f766dae26203bd6311d353dcd42)
Change-Id: I7f643ae340a20f12d5f86965674aa58df1be3979
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Our test build is broken by KCFLAGS overrided in build.config.comm.
Since Linux Makefile supports 'export KCFLAGS=XXX' to customize the
KCFLAGS, and we should keep this functionality.
Bug: 230818006
Fixes: 5558db2674 ("ANDROID: Add flag to indicate compiling against ACK")
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Change-Id: I9425d79697bc1fe816ce82d523f91631dee6b8f4
Add memcg support for hooks in the reclaim path
Bug: 230450931
Change-Id: Ia3e6949985d915c8640139fbb93800d91e1e46f8
Signed-off-by: xiaofeng <xiaofeng5@xiaomi.com>
