summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-01-19UPSTREAM: aio: fix use-after-free due to missing POLLFREE handlingandroid12-5.10-2021-09_r10aosp/android12-5.10-2021-09Eric Biggers2-32/+107
commit 50252e4b5e989ce64555c7aef7516bdefc2fea72 upstream. signalfd_poll() and binder_poll() are special in that they use a waitqueue whose lifetime is the current task, rather than the struct file as is normally the case. This is okay for blocking polls, since a blocking poll occurs within one task; however, non-blocking polls require another solution. This solution is for the queue to be cleared before it is freed, by sending a POLLFREE notification to all waiters. Unfortunately, only eventpoll handles POLLFREE. A second type of non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't handle POLLFREE. This allows a use-after-free to occur if a signalfd or binder fd is polled with aio poll, and the waitqueue gets freed. Fix this by making aio poll handle POLLFREE. A patch by Ramji Jiyani <ramjiyani@google.com> (https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com) tried to do this by making aio_poll_wake() always complete the request inline if POLLFREE is seen. However, that solution had two bugs. First, it introduced a deadlock, as it unconditionally locked the aio context while holding the waitqueue lock, which inverts the normal locking order. Second, it didn't consider that POLLFREE notifications are missed while the request has been temporarily de-queued. The second problem was solved by my previous patch. This patch then properly fixes the use-after-free by handling POLLFREE in a deadlock-free way. It does this by taking advantage of the fact that freeing of the waitqueue is RCU-delayed, similar to what eventpoll does. Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL") Cc: <stable@vger.kernel.org> # v4.18+ Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Change-Id: I1ef425160bde1022cfd7d250d09d8f0487e66e95
2022-01-19UPSTREAM: aio: keep poll requests on waitqueue until completedEric Biggers1-20/+63
commit 363bee27e25804d8981dd1c025b4ad49dc39c530 upstream. Currently, aio_poll_wake() will always remove the poll request from the waitqueue. Then, if aio_poll_complete_work() sees that none of the polled events are ready and the request isn't cancelled, it re-adds the request to the waitqueue. (This can easily happen when polling a file that doesn't pass an event mask when waking up its waitqueue.) This is fundamentally broken for two reasons: 1. If a wakeup occurs between vfs_poll() and the request being re-added to the waitqueue, it will be missed because the request wasn't on the waitqueue at the time. Therefore, IOCB_CMD_POLL might never complete even if the polled file is ready. 2. When the request isn't on the waitqueue, there is no way to be notified that the waitqueue is being freed (which happens when its lifetime is shorter than the struct file's). This is supposed to happen via the waitqueue entries being woken up with POLLFREE. Therefore, leave the requests on the waitqueue until they are actually completed (or cancelled). To keep track of when aio_poll_complete_work needs to be scheduled, use new fields in struct poll_iocb. Remove the 'done' field which is now redundant. Note that this is consistent with how sys_poll() and eventpoll work; their wakeup functions do *not* remove the waitqueue entries. Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL") Cc: <stable@vger.kernel.org> # v4.18+ Link: https://lore.kernel.org/r/20211209010455.42744-5-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Change-Id: Ia69b08e227f842defcda9f3cccef459deb265f09
2022-01-19UPSTREAM: signalfd: use wake_up_pollfree()Eric Biggers1-11/+1
commit 9537bae0da1f8d1e2361ab6d0479e8af7824e160 upstream. wake_up_poll() uses nr_exclusive=1, so it's not guaranteed to wake up all exclusive waiters. Yet, POLLFREE *must* wake up all waiters. epoll and aio poll are fortunately not affected by this, but it's very fragile. Thus, the new function wake_up_pollfree() has been introduced. Convert signalfd to use wake_up_pollfree(). Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Fixes: d80e731ecab4 ("epoll: introduce POLLFREE to flush ->signalfd_wqh before kfree()") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211209010455.42744-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Bug: 185125206 Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> Change-Id: I1d97ac9c9fbb28c164bd4b51deeefbbb139205e7
2022-01-19UPSTREAM: binder: use wake_up_pollfree()Eric Biggers1-12/+9
commit a880b28a71e39013e357fd3adccd1d8a31bc69a8 upstream. wake_up_poll() uses nr_exclusive=1, so it's not guaranteed to wake up all exclusive waiters. Yet, POLLFREE *must* wake up all waiters. epoll and aio poll are fortunately not affected by this, but it's very fragile. Thus, the new function wake_up_pollfree() has been introduced. Convert binder to use wake_up_pollfree(). Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Fixes: f5cb779ba163 ("ANDROID: binder: remove waitqueue when thread exits.") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211209010455.42744-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Bug: 185125206 Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> Change-Id: I8354c40ed73a7d88132a74a388704f0eb307a618
2022-01-19UPSTREAM: wait: add wake_up_pollfree()Eric Biggers2-0/+33
commit 42288cb44c4b5fff7653bc392b583a2b8bd6a8c0 upstream. Several ->poll() implementations are special in that they use a waitqueue whose lifetime is the current task, rather than the struct file as is normally the case. This is okay for blocking polls, since a blocking poll occurs within one task; however, non-blocking polls require another solution. This solution is for the queue to be cleared before it is freed, using 'wake_up_poll(wq, EPOLLHUP | POLLFREE);'. However, that has a bug: wake_up_poll() calls __wake_up() with nr_exclusive=1. Therefore, if there are multiple "exclusive" waiters, and the wakeup function for the first one returns a positive value, only that one will be called. That's *not* what's needed for POLLFREE; POLLFREE is special in that it really needs to wake up everyone. Considering the three non-blocking poll systems: - io_uring poll doesn't handle POLLFREE at all, so it is broken anyway. - aio poll is unaffected, since it doesn't support exclusive waits. However, that's fragile, as someone could add this feature later. - epoll doesn't appear to be broken by this, since its wakeup function returns 0 when it sees POLLFREE. But this is fragile. Although there is a workaround (see epoll), it's better to define a function which always sends POLLFREE to all waiters. Add such a function. Also make it verify that the queue really becomes empty after all waiters have been woken up. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211209010455.42744-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Bug: 185125206 Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> Change-Id: I4f69da5bbbad53975024d027fa1bbe22522c6efe
2022-01-19UPSTREAM: sctp: add param size validation for SCTP_PARAM_SET_PRIMARYMarcelo Ricardo Leitner1-3/+10
commit ef6c8d6ccf0c1dccdda092ebe8782777cd7803c9 upstream. When SCTP handles an INIT chunk, it calls for example: sctp_sf_do_5_1B_init sctp_verify_init sctp_verify_param sctp_process_init sctp_process_param handling of SCTP_PARAM_SET_PRIMARY sctp_verify_init() wasn't doing proper size validation and neither the later handling, allowing it to work over the chunk itself, possibly being uninitialized memory. Bug: 197154735 Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Aaron Ding <aaronding@google.com> Change-Id: I032230924ead7a03dfb3101e9cd4d48e36bfc616
2022-01-19UPSTREAM: sctp: validate chunk size in __rcv_asconf_lookupMarcelo Ricardo Leitner1-0/+3
commit b6ffe7671b24689c09faa5675dd58f93758a97ae upstream. In one of the fallbacks that SCTP has for identifying an association for an incoming packet, it looks for AddIp chunk (from ASCONF) and take a peek. Thing is, at this stage nothing was validating that the chunk actually had enough content for that, allowing the peek to happen over uninitialized memory. Similar check already exists in actual asconf handling in sctp_verify_asconf(). Bug: 197154735 Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Aaron Ding <aaronding@google.com> Change-Id: Ibfe53fc724143423353ed6b2984d2508ee4fc457
2022-01-19UPSTREAM: sctp: add size validation when walking chunksMarcelo Ricardo Leitner1-1/+1
[ Upstream commit 50619dbf8db77e98d821d615af4f634d08e22698 ] The first chunk in a packet is ensured to be present at the beginning of sctp_rcv(), as a packet needs to have at least 1 chunk. But the second one, may not be completely available and ch->length can be over uninitialized memory. Fix here is by only trying to walk on the next chunk if there is enough to hold at least the header, and then proceed with the ch->length validation that is already there. Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> Change-Id: Ic2b962d31bc5bd2a0bf8d064deead466d607b605
2022-01-19UPSTREAM: sctp: validate from_addr_param returnMarcelo Ricardo Leitner6-26/+44
[ Upstream commit 0c5dc070ff3d6246d22ddd931f23a6266249e3db ] Ilja reported that, simply putting it, nothing was validating that from_addr_param functions were operating on initialized memory. That is, the parameter itself was being validated by sctp_walk_params, but it doesn't check for types and their specific sizes and it could be a 0-length one, causing from_addr_param to potentially work over the next parameter or even uninitialized memory. The fix here is to, in all calls to from_addr_param, check if enough space is there for the wanted IP address type. Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> Change-Id: I7c84e42afa19aa569885a676af27e33999b76430
2021-12-16FROMGIT: USB: gadget: bRequestType is a bitfield, not a enumandroid12-5.10-2021-09_r9android12-5.10-2021-09_r8android-12.0.0_r0.42aosp/android-gs-raviole-5.10-android12-qpr1-dGreg Kroah-Hartman3-9/+9
Szymon rightly pointed out that the previous check for the endpoint direction in bRequestType was not looking at only the bit involved, but rather the whole value. Normally this is ok, but for some request types, bits other than bit 8 could be set and the check for the endpoint length could not stall correctly. Fix that up by only checking the single bit. Fixes: 153a2d7e3350 ("USB: gadget: detect too-big endpoint 0 requests") Cc: Felipe Balbi <balbi@kernel.org> Reported-by: Szymon Heidrich <szymon.heidrich@gmail.com> Link: https://lore.kernel.org/r/20211214184621.385828-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit f08adf5add9a071160c68bb2a61d697f39ab0758 https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus) Bug: 210292376 Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> Change-Id: I7e708b2b94433009c87f697346e0515d93454f48
2021-12-16UPSTREAM: USB: gadget: zero allocate endpoint 0 buffersGreg Kroah-Hartman2-2/+2
Under some conditions, USB gadget devices can show allocated buffer contents to a host. Fix this up by zero-allocating them so that any extra data will all just be zeros. Reported-by: Szymon Heidrich <szymon.heidrich@gmail.com> Tested-by: Szymon Heidrich <szymon.heidrich@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 86ebbc11bb3f60908a51f3e41a17e3f477c2eaa3) Bug: 210292367 Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> Change-Id: I72b4376cd4296a8b8af0ade2d702cd420146f3aa
2021-12-16UPSTREAM: USB: gadget: detect too-big endpoint 0 requestsGreg Kroah-Hartman3-1/+40
Sometimes USB hosts can ask for buffers that are too large from endpoint 0, which should not be allowed. If this happens for OUT requests, stall the endpoint, but for IN requests, trim the request size to the endpoint buffer size. Co-developed-by: Szymon Heidrich <szymon.heidrich@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 153a2d7e3350cc89d406ba2d35be8793a64c2038) Bug: 210292367 Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> Change-Id: I9bbd6154177d7a1fb6c2e3a3dffa96634d85bb7f
2021-12-10ANDROID: binder: fix regression in sender_euidTodd Kjos1-1/+1
A recent change to use proc->cred instead of proc->tsk as the source for sender_euid caused a failure in the CredentialsTest#CaptureLayersTest test. Revert 1 line of the patch to fix the test. The rest of the patch needs to remain since the subsequent patches rely on it. Before fixing upstream, we need to investigate more since the code looks correct so the issue may be a latent userspace bug. Bug: 205938623 Bug: 200688826 Fixes: d65efd5b73dc ("UPSTREAM: binder: use euid from cred instead of using task") Signed-off-by: Todd Kjos <tkjos@google.com> Signed-off-by: Aaron Ding <aaronding@google.com> Change-Id: I16543a50f43f79131234995fb0813de00795bd3d
2021-12-10BACKPORT: binder: use cred instead of task for getsecidTodd Kjos2-1/+6
Use the 'struct cred' saved at binder_open() to lookup the security ID via security_cred_getsecid(). This ensures that the security context that opened binder is the one used to generate the secctx. Cc: stable@vger.kernel.org # 5.4+ Fixes: ec74136ded79 ("binder: create node flag to request sender's security context") Signed-off-by: Todd Kjos <tkjos@google.com> Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Bug: 200688826 (cherry picked from commit 4d5b5539742d2554591751b4248b0204d20dcc9d) [ refactored to avoid changing KMI: struct binder_proc ] Change-Id: Ie023be3190caf20ca3901560455e9f027c9426cd
2021-12-10BACKPORT: binder: use cred instead of task for selinux checksTodd Kjos6-62/+59
Since binder was integrated with selinux, it has passed 'struct task_struct' associated with the binder_proc to represent the source and target of transactions. The conversion of task to SID was then done in the hook implementations. It turns out that there are race conditions which can result in an incorrect security context being used. Fix by using the 'struct cred' saved during binder_open and pass it to the selinux subsystem. Cc: stable@vger.kernel.org # 5.14 (need backport for earlier stables) Fixes: 79af73079d75 ("Add security hooks to binder and implement the hooks for SELinux.") Suggested-by: Jann Horn <jannh@google.com> Signed-off-by: Todd Kjos <tkjos@google.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Bug: 200688826 (cherry picked from commit 52f88693378a58094c538662ba652aff0253c4fe) [ refactored to avoid changing KMI: struct binder_proc ] Change-Id: I1664c1f0c2142c17e9ca0d6790bb94de79f531e3
2021-12-10BACKPORT: binder: use euid from cred instead of using taskTodd Kjos2-3/+32
Save the 'struct cred' associated with a binder process at initial open to avoid potential race conditions when converting to an euid. Set a transaction's sender_euid from the 'struct cred' saved at binder_open() instead of looking up the euid from the binder proc's 'struct task'. This ensures the euid is associated with the security context that of the task that opened binder. Cc: stable@vger.kernel.org # 4.4+ Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") Signed-off-by: Todd Kjos <tkjos@google.com> Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com> Suggested-by: Jann Horn <jannh@google.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Bug: 200688826 (cherry picked from commit 29bc22ac5e5bc63275e850f0c8fc549e3d0e306b) [ refactored to avoid changing KMI: struct binder_proc ] Change-Id: Icaf996a7f5543b7d6943dff3cbe89bfc3614044c
2021-11-22BACKPORT: ext4: fix race writing to an inline_data file while its xattrs are ↵android12-5.10-2021-09_r7android-12.0.0_r0.36Theodore Ts'o1-0/+6
changing commit a54c4613dac1500b40e4ab55199f7c51f028e848 upstream. The location of the system.data extended attribute can change whenever xattr_sem is not taken. So we need to recalculate the i_inline_off field since it mgiht have changed between ext4_write_begin() and ext4_write_end(). This means that caching i_inline_off is probably not helpful, so in the long run we should probably get rid of it and shrink the in-memory ext4 inode slightly, but let's fix the race the simple way for now. Bug: 199579676 Cc: stable@kernel.org Fixes: f19d5870cbf72 ("ext4: add normal write support for inline data") Reported-by: syzbot+13146364637c7363a7de@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Aaron Ding <aaronding@google.com> Change-Id: I174fd70385b155ba722fb5c9e6f9b2402882266b
2021-11-22Revert "BACKPORT: FROMLIST: scsi: ufs: Limit the queue depth to host->can_queue"Aaron Ding1-1/+5
This reverts commit 53367267d0fe375254f784e41831ab6502b53b3a. The change will soak for Mar QPR release Bug: 205080886 Signed-off-by: Aaron Ding <aaronding@google.com> Change-Id: I5f136846d1b006c399efd1af29ac205ae51f3cf0
2021-11-22Revert "BACKPORT: FROMLIST: scsi: core: Reserve one tag for the UFS driver"Aaron Ding2-8/+0
This reverts commit 5c782572d43bf1a47436fb0e35852f3038f06970. The change will soak for Mar QPR release Bug: 205080886 Signed-off-by: Aaron Ding <aaronding@google.com> Change-Id: If73f62dbb40453e4acea59ee054a75661d5b9b39
2021-11-22Revert "BACKPORT: FROMLIST: scsi: ufs: Fix a deadlock in the error handler"Aaron Ding1-1/+6
This reverts commit 0a07ca4e42c839ccc8cfcfa63078c9cb580c7d3b. The change will soak for Mar QPR release Bug: 205080886 Signed-off-by: Aaron Ding <aaronding@google.com> Change-Id: I34c0f4e1b7a22cfe24646afd5c91b60118b1fa8c
2021-11-17UPSTREAM: ip_gre: add validation for csum_startShreyansh Chouhan1-0/+2
[ Upstream commit 1d011c4803c72f3907eccfc1ec63caefb852fcbf ] Validate csum_start in gre_handle_offloads before we call _gre_xmit so that we do not crash later when the csum_start value is used in the lco_csum function call. This patch deals with ipv4 code. Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.") Reported-by: syzbot+ff8e1b9f2f36481e2efc@syzkaller.appspotmail.com Signed-off-by: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> Bug: 150694665 Change-Id: I584ff322e73564ecf9fbc9685af1bd9ceb09657f
2021-11-08BACKPORT: FROMLIST: scsi: ufs: Fix a deadlock in the error handlerandroid12-5.10-2021-09_r6Bart Van Assche1-6/+1
The following deadlock has been observed on a test setup: * All tags allocated. * The SCSI error handler calls ufshcd_eh_host_reset_handler() * ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler() * ufshcd_err_handler() locks up as follows: Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Call trace: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 schedule+0x12c/0x298 blk_mq_get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 ufshcd_reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 process_one_work+0x24c/0x66c worker_thread+0x3e8/0xa4c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved request. This patch is closely related to the upstream patch with the same title. Bug: 205080886 Link: https://lore.kernel.org/linux-scsi/700f0463-23a9-8465-f712-1188cb884dea@acm.org/T/#u Change-Id: I9e9ba3f45ba23ecf576380aa19701d3437af6cdd Signed-off-by: Bart Van Assche <bvanassche@google.com>
2021-11-08BACKPORT: FROMLIST: scsi: core: Reserve one tag for the UFS driverBart Van Assche2-0/+8
This is a GKI-compatible version of the following patch: "scsi: core: Add support for reserved tags". Bug: 205080886 Link: https://lore.kernel.org/linux-scsi/20211103000529.1549411-2-bvanassche@acm.org. Change-Id: I6273114ae8cc6c2a74c72f7bc090eb0319ec5772 Signed-off-by: Bart Van Assche <bvanassche@google.com>
2021-11-08BACKPORT: FROMLIST: scsi: ufs: Limit the queue depth to host->can_queueBart Van Assche1-5/+1
Before reducing 'can_queue' from 32 to 31, make ufshcd_change_queue_depth() restrict the queue depth to 'can_queue' instead of hba->nutrs (32). This is a backport of a subset of the following patch: "[PATCH 2/2] scsi: ufs: Fix a deadlock in the error handler". Bug: 205080886 Link: https://lore.kernel.org/linux-scsi/20211103000529.1549411-3-bvanassche@acm.org/ Change-Id: I6e694a9698f91293fc2987217e3f939726c397dd Signed-off-by: Bart Van Assche <bvanassche@google.com>
2021-10-21UPSTREAM: seq_file: disallow extremely large seq buffer allocationsandroid12-5.10-2021-09_r5android-12.0.0_r0.26Eric Sandeen1-0/+3
commit 8cae8cd89f05f6de223d63e6d15e31c8ba9cf53b upstream. There is no reasonable need for a buffer larger than this, and it avoids int overflow pitfalls. Fixes: 058504edd026 ("fs/seq_file: fallback to vmalloc allocation") Suggested-by: Al Viro <viro@zeniv.linux.org.uk> Reported-by: Qualys Security Advisory <qsa@qualys.com> Signed-off-by: Eric Sandeen <sandeen@redhat.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Bug: 195082750 Bug: 202859772 Change-Id: Ia1672a6b81925d8857180e952dd4ed459e0f82d4
2021-10-12UPSTREAM: usb: max-3421: Prevent corruption of freed memoryandroid12-5.10-2021-09_r4Mark Tomlinson1-30/+14
commit b5fdf5c6e6bee35837e160c00ac89327bdad031b upstream. The MAX-3421 USB driver remembers the state of the USB toggles for a device/endpoint. To save SPI writes, this was only done when a new device/endpoint was being used. Unfortunately, if the old device was removed, this would cause writes to freed memory. To fix this, a simpler scheme is used. The toggles are read from hardware when a URB is completed, and the toggles are always written to hardware when any URB transaction is started. This will cause a few more SPI transactions, but no causes kernel panics. Fixes: 2d53139f3162 ("Add support for using a MAX3421E chip as a host driver.") Cc: stable <stable@vger.kernel.org> Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20210625031456.8632-1-mark.tomlinson@alliedtelesis.co.nz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Bug: 202859772 Change-Id: I55e4fd4609e7e0c68986bcf10718f486d2e55cad
2021-10-07BACKPORT: FROMGIT: scsi: ufs: core: Stop clearing unit attentionsandroid12-5.10-2021-09_r3Bart Van Assche1-97/+0
Commit aa53f580e67b ("scsi: ufs: Minor adjustments to error handling") introduced a ufshcd_clear_ua_wluns() call in ufshcd_err_handling_unprepare(). As explained in detail by Adrian Hunter, this can trigger a deadlock. Avoid that deadlock by removing the code that clears the unit attention. This is safe because the only software that relies on clearing unit attentions is the Android Trusty software and because support for handling unit attentions has been added in the Trusty software. See also https://lore.kernel.org/linux-scsi/20210930124224.114031-2-adrian.hunter@intel.com/ Note that, should apply "scsi: ufs: retry START_STOP on UNIT_ATTENTION" before this patch, since this patch gives UNIT ATTENTION to scsi_execute(START_STOP). Bug: 194712579 (cherry picked from commit edc0596cc04bf0ac3a69c66e994d3ff8b650ff71 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next) Link: https://lore.kernel.org/r/20211001182015.1347587-3-jaegeuk@kernel.org Fixes: aa53f580e67b ("scsi: ufs: Minor adjustments to error handling") Cc: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Bart Van Assche <bvanassche@google.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Change-Id: I73656b8b6773558dc7a552700d283c1ae6dc25f7 (cherry picked from commit d5aea3dbfb3ecf401d3956e3012c1ad5380ec55c)
2021-10-07BACKPORT: FROMGIT: scsi: ufs: core: Retry START_STOP on UNIT_ATTENTIONJaegeuk Kim2-3/+24
Commit 57d104c153d3 ("ufs: add UFS power management support") made the UFS driver submit a REQUEST SENSE command before submitting a power management command to a WLUN to clear the POWER ON unit attention. Instead of submitting a REQUEST SENSE command before submitting a power management command, retry the power management command until it succeeds. This is the preparation to get rid of all UNIT ATTENTION code which should be handled by users. Bug: 194712579 Link: https://lore.kernel.org/r/20211001182015.1347587-2-jaegeuk@kernel.org (cherry picked from commit af21c3fd5b3ec540a97b367a70b26616ff7e0c55 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next) Cc: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Change-Id: I7e639d89ae9fbd5ff0f1b3a6e5cbe77682ebefc0 (cherry picked from commit 2b411f1257895f5d05ad2e221c856893af010012)
2021-10-04FROMLIST: scsi: ufs: Fix task management completionandroid12-5.10-2021-09_r2Adrian Hunter3-30/+32
The UFS driver uses blk_mq_tagset_busy_iter() when identifying task management requests to complete, however blk_mq_tagset_busy_iter() doesn't work. blk_mq_tagset_busy_iter() only iterates requests dispatched by the block layer. That appears as if it might have started since commit 37f4a24c2469a1 ("blk-mq: centralise related handling into blk_mq_get_driver_tag") which removed 'data->hctx->tags->rqs[rq->tag] = rq' from blk_mq_rq_ctx_init() which gets called: blk_get_request blk_mq_alloc_request __blk_mq_alloc_request blk_mq_rq_ctx_init Since UFS task management requests are not dispatched by the block layer, hctx->tags->rqs[rq->tag] remains NULL, and since blk_mq_tagset_busy_iter() relies on finding requests using hctx->tags->rqs[rq->tag], UFS task management requests are never found by blk_mq_tagset_busy_iter(). By using blk_mq_tagset_busy_iter(), the UFS driver was relying on internal details of the block layer, which was fragile and subsequently got broken. Fix by removing the use of blk_mq_tagset_busy_iter() and having the driver keep track of task management requests. Fixes: 1235fc569e0bf5 ("scsi: ufs: core: Fix task management request completion timeout") Fixes: 69a6c269c097d7 ("scsi: ufs: Use blk_{get,put}_request() to allocate and free TMFs") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Bug: 200291871 Link: https://lore.kernel.org/linux-scsi/20210922091059.4040-1-adrian.hunter@intel.com/ Change-Id: I4e11f40c7371fd66b3a6b570d06c956b113df142 Signed-off-by: Bart Van Assche <bvanassche@google.com>
2021-10-04ANDROID: scsi: ufs: Rename struct ufs_hba_with_hpb into ufs_hba_add_infoBart Van Assche4-14/+29
Before adding more data members in struct ufs_hba_with_hpb, rename this data structure. This patch does not change any functionality. Bug: 200291871 Change-Id: I6b0365ebcf8adf6cfa009218d8c4dc96fa629bde Signed-off-by: Bart Van Assche <bvanassche@google.com>
2021-10-04ANDROID: Update the ABI representationKonstantin Vyshetsky2-65/+76
Leaf changes summary: 2 artifacts changed Changed leaf types summary: 0 leaf type changed Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 1 Added function Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 1 Added variable 1 Added function: [A] 'function int __traceiter_android_rvh_ufs_complete_init(void*, ufs_hba*)' 1 Added variable: [A] 'tracepoint __tracepoint_android_rvh_ufs_complete_init' Bug: 185809932 Signed-off-by: Konstantin Vyshetsky <vkon@google.com> Change-Id: I48a831d2059901276b1a510d8af186c00ca2f9db (cherry picked from commit 5adc3c4124ee5066365c2b1721a4921bac65d229)
2021-10-04ANDROID: scsi: ufs: add complete init vendor hookKonstantin Vyshetsky3-0/+7
Currently the core UFS driver does not have a vops to notify when the device is operational. This commit introduces a hook, which serves to notify device completing initialization and is ready to accept I/O. This is required by the FIPS140-2 [1] self integrity test of inline encryption engine, which must run whenever the host controller is reset. The code requires sleeping while waiting for I/O to complete and allocating some memory dynamically, which requires the vendor hook to be restricted. [1] https://csrc.nist.gov/publications/detail/fips/140/2/final Bug: 185809932 Signed-off-by: Konstantin Vyshetsky <vkon@google.com> Change-Id: I6f476f9c2e2b50574d2898c3f1ef6b648d92df24 (cherry picked from commit e774e4eca69ce8ab60df04b27f524b586ab74f17)
2021-09-17ANDROID: enable MTK RNDISandroid12-5.10-2021-09_r1ASB-2021-10-05_12-5.10Denis Hsu2-26/+20
The performance of RNDIS driver in kernel 5.10 is insufficient to meet the requirement introduced by 5G. MTK RNDIS driver integrates TX/RX aggregation and fine-tune performance to achieve the goal. Leaf changes summary: 2 artifacts changed Changed leaf types summary: 0 leaf type changed Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 2 Added functions Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable 2 Added functions: [A] 'function int dev_set_mac_address(net_device*, sockaddr*, netlink_ext_ack*)' [A] 'function config_group* usb_os_desc_prepare_interf_dir(config_group*, int, usb_os_desc**, char**, module*)' Bug: 198379444 Change-Id: I04d669c6d67af778a283b5358c5f1e0b1ded83d4 Signed-off-by: Denis Hsu <denis.hsu@mediatek.com>
2021-09-17ANDROID: abi_gki_aarch64_qcom: Add 2 new symbols for gsiMichael Adisumarta2-5066/+5305
Add symbols for platform_msi_domain_free_irqs and gsi_update_almst_empty_thrshold. Leaf changes summary: 2 artifacts changed Changed leaf types summary: 0 leaf type changed Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 2 Added functions Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable 2 Added functions: [A] 'function int platform_msi_domain_alloc_irqs(device*, unsigned int, irq_write_msi_msg_t)' [A] 'function void platform_msi_domain_free_irqs(device*)' Bug: 200009693 Change-Id: I91d17a944fa838b3d8be2eea7eb2f0d7a41d211f Signed-off-by: Michael Adisumarta <madisuma@codeaurora.org> Signed-off-by: Paresh Purabhiya <quic_ppurabhi@quicinc.com> Signed-off-by: Todd Kjos <tkjos@google.com>
2021-09-17ANDROID: Update the ABI representationRick Yiu2-34/+44
Leaf changes summary: 1 artifact changed Changed leaf types summary: 0 leaf type changed Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 1 Added function Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable 1 Added function: [A] 'function void __rt_mutex_init(rt_mutex*, const char*, lock_class_key*)' Bug: 198085505 Signed-off-by: Rick Yiu <rickyiu@google.com> Change-Id: I97766c915eba89d6d085e32a20cbb416d58de90a
2021-09-17ANDROID: GKI: Update abi_gki_aarch64_qcom for rtc_tm_to_ktime and ↵jianbinz1-0/+2
rtc_ktime_to_tm Add rtc_tm_to_ktime and rtc_ktime_to_tm symbols. Bug: 200193632 Change-Id: Ibe43876597fd944b60b611107d7b9b8d50a64ef4 Signed-off-by: jianbin zhang <quic_jianbinz@quicinc.com>
2021-09-17ANDROID: fuse: Allocate zeroed memory for canonical pathBiao Li1-1/+1
The page used to contain the fuse_dentry_canonical_path to be handled in fuse_dev_do_write is allocated using __get_free_pages(GFP_KERNEL). The returned page may contain undefined data, that by chance may be considered as a valid path name that is not in the cache. In that case, if the FUSE daemon mistakenly doesn't fill the canonical path buffer, the FUSE driver may fall into two blocking request_wait_answer(fuse_dev_write->kern_path->fuse_lookup_name) causing a deadlock condition. The stack is as follows: find S 0 20511 20117 0x00000000 Call trace: [<ffffff8008085e78>] __switch_to+0xb8/0xd4 [<ffffff8008a0cac4>] __schedule+0x458/0x714 [<ffffff8008a0ce0c>] schedule+0x8c/0xa8 [<ffffff800833865c>] request_wait_answer+0x74/0x220 [<ffffff8008339f70>] __fuse_request_send+0x8c/0xa0 [<ffffff8008339fe4>] fuse_request_send+0x60/0x6c [<ffffff800833c1a8>] fuse_dentry_canonical_path+0xb8/0x104 [<ffffff800820b14c>] do_sys_open+0x1b4/0x260 [<ffffff800820b27c>] SyS_openat+0x3c/0x4c [<ffffff8008083540>] el0_svc_naked+0x34/0x38 mount.ntfs-3g S 0 5845 1 0x00000000 Call trace: [<ffffff8008085e78>] __switch_to+0xb8/0xd4 [<ffffff8008a0cac4>] __schedule+0x458/0x714 [<ffffff8008a0ce0c>] schedule+0x8c/0xa8 [<ffffff800833865c>] request_wait_answer+0x74/0x220 [<ffffff8008339f70>] __fuse_request_send+0x8c/0xa0 [<ffffff8008339fe4>] fuse_request_send+0x60/0x6c [<ffffff800833bdb0>] fuse_simple_request+0x128/0x16c [<ffffff800833dddc>] fuse_lookup_name+0x104/0x1b0 [<ffffff800833dee4>] fuse_lookup+0x5c/0x11c [<ffffff800821861c>] lookup_slow+0xfc/0x174 [<ffffff800821b474>] walk_component+0xf0/0x290 [<ffffff800821bbac>] path_lookupat+0xa0/0x128 [<ffffff800821c7f4>] filename_lookup+0x84/0x124 [<ffffff800821c8d8>] kern_path+0x44/0x54 [<ffffff800833b0c8>] fuse_dev_do_write+0x828/0xa0c [<ffffff800833b610>] fuse_dev_write+0x90/0xb4 [<ffffff800820b770>] do_iter_readv_writev+0xf4/0x13c [<ffffff800820cc88>] do_readv_writev+0xec/0x220 [<ffffff800820d05c>] vfs_writev+0x60/0x74 [<ffffff800820d0ec>] do_writev+0x7c/0x100 [<ffffff800820e348>] SyS_writev+0x38/0x48 [<ffffff8008083540>] el0_svc_naked+0x34/0x38 Fix by ensuring that the page allocated for the canonical path is zeroed. Bug: 194856119 Bug: 196051870 Fixes: 24ab59f6bb42 ("ANDROID: fuse: Add support for d_canonical_path") Signed-off-by: Biao Li <libiao@allwinnertech.com> Signed-off-by: Shuosheng Huang <huangshuosheng@allwinnertech.com> Signed-off-by: Alessio Balsini <balsini@google.com> Change-Id: I400815dc1049d90c308f5cf87ce60de97ff82131
2021-09-16FROMGIT: f2fs: should use GFP_NOFS for directory inodesJaegeuk Kim2-2/+2
We use inline_dentry which requires to allocate dentry page when adding a link. If we allow to reclaim memory from filesystem, we do down_read(&sbi->cp_rwsem) twice by f2fs_lock_op(). I think this should be okay, but how about stopping the lockdep complaint [1]? f2fs_create() - f2fs_lock_op() - f2fs_do_add_link() - __f2fs_find_entry - f2fs_get_read_data_page() -> kswapd - shrink_node - f2fs_evict_inode - f2fs_lock_op() [1] fs_reclaim ){+.+.}-{0:0} : kswapd0: lock_acquire+0x114/0x394 kswapd0: __fs_reclaim_acquire+0x40/0x50 kswapd0: prepare_alloc_pages+0x94/0x1ec kswapd0: __alloc_pages_nodemask+0x78/0x1b0 kswapd0: pagecache_get_page+0x2e0/0x57c kswapd0: f2fs_get_read_data_page+0xc0/0x394 kswapd0: f2fs_find_data_page+0xa4/0x23c kswapd0: find_in_level+0x1a8/0x36c kswapd0: __f2fs_find_entry+0x70/0x100 kswapd0: f2fs_do_add_link+0x84/0x1ec kswapd0: f2fs_mkdir+0xe4/0x1e4 kswapd0: vfs_mkdir+0x110/0x1c0 kswapd0: do_mkdirat+0xa4/0x160 kswapd0: __arm64_sys_mkdirat+0x24/0x34 kswapd0: el0_svc_common.llvm.17258447499513131576+0xc4/0x1e8 kswapd0: do_el0_svc+0x28/0xa0 kswapd0: el0_svc+0x24/0x38 kswapd0: el0_sync_handler+0x88/0xec kswapd0: el0_sync+0x1c0/0x200 kswapd0: -> #1 ( &sbi->cp_rwsem ){++++}-{3:3} : kswapd0: lock_acquire+0x114/0x394 kswapd0: down_read+0x7c/0x98 kswapd0: f2fs_do_truncate_blocks+0x78/0x3dc kswapd0: f2fs_truncate+0xc8/0x128 kswapd0: f2fs_evict_inode+0x2b8/0x8b8 kswapd0: evict+0xd4/0x2f8 kswapd0: iput+0x1c0/0x258 kswapd0: do_unlinkat+0x170/0x2a0 kswapd0: __arm64_sys_unlinkat+0x4c/0x68 kswapd0: el0_svc_common.llvm.17258447499513131576+0xc4/0x1e8 kswapd0: do_el0_svc+0x28/0xa0 kswapd0: el0_svc+0x24/0x38 kswapd0: el0_sync_handler+0x88/0xec kswapd0: el0_sync+0x1c0/0x200 Bug: 198991863 Cc: stable@vger.kernel.org Fixes: bdbc90fa55af ("f2fs: don't put dentry page in pagecache into highmem") Reviewed-by: Chao Yu <chao@kernel.org> Reviewed-by: Stanley Chu <stanley.chu@mediatek.com> Reviewed-by: Light Hsieh <light.hsieh@mediatek.com> Tested-by: Light Hsieh <light.hsieh@mediatek.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> (cherry picked from commit 92d602bc7177325e7453189a22e0c8764ed3453e https://https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev) Change-Id: Ie25d567390ea5185955356b330e04ebfa5c8836f
2021-09-16UPSTREAM: mm, slub: move slub_debug static key enabling outside slab_mutexVlastimil Babka2-9/+10
Paul E. McKenney reported [1] that commit 1f0723a4c0df ("mm, slub: enable slub_debug static key when creating cache with explicit debug flags") results in the lockdep complaint: ====================================================== WARNING: possible circular locking dependency detected 5.12.0+ #15 Not tainted ------------------------------------------------------ rcu_torture_sta/109 is trying to acquire lock: ffffffff96063cd0 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_enable+0x9/0x20 but task is already holding lock: ffffffff96173c28 (slab_mutex){+.+.}-{3:3}, at: kmem_cache_create_usercopy+0x2d/0x250 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (slab_mutex){+.+.}-{3:3}: lock_acquire+0xb9/0x3a0 __mutex_lock+0x8d/0x920 slub_cpu_dead+0x15/0xf0 cpuhp_invoke_callback+0x17a/0x7c0 cpuhp_invoke_callback_range+0x3b/0x80 _cpu_down+0xdf/0x2a0 cpu_down+0x2c/0x50 device_offline+0x82/0xb0 remove_cpu+0x1a/0x30 torture_offline+0x80/0x140 torture_onoff+0x147/0x260 kthread+0x10a/0x140 ret_from_fork+0x22/0x30 -> #0 (cpu_hotplug_lock){++++}-{0:0}: check_prev_add+0x8f/0xbf0 __lock_acquire+0x13f0/0x1d80 lock_acquire+0xb9/0x3a0 cpus_read_lock+0x21/0xa0 static_key_enable+0x9/0x20 __kmem_cache_create+0x38d/0x430 kmem_cache_create_usercopy+0x146/0x250 kmem_cache_create+0xd/0x10 rcu_torture_stats+0x79/0x280 kthread+0x10a/0x140 ret_from_fork+0x22/0x30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(slab_mutex); lock(cpu_hotplug_lock); lock(slab_mutex); lock(cpu_hotplug_lock); *** DEADLOCK *** 1 lock held by rcu_torture_sta/109: #0: ffffffff96173c28 (slab_mutex){+.+.}-{3:3}, at: kmem_cache_create_usercopy+0x2d/0x250 stack backtrace: CPU: 3 PID: 109 Comm: rcu_torture_sta Not tainted 5.12.0+ #15 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack+0x6d/0x89 check_noncircular+0xfe/0x110 ? lock_is_held_type+0x98/0x110 check_prev_add+0x8f/0xbf0 __lock_acquire+0x13f0/0x1d80 lock_acquire+0xb9/0x3a0 ? static_key_enable+0x9/0x20 ? mark_held_locks+0x49/0x70 cpus_read_lock+0x21/0xa0 ? static_key_enable+0x9/0x20 static_key_enable+0x9/0x20 __kmem_cache_create+0x38d/0x430 kmem_cache_create_usercopy+0x146/0x250 ? rcu_torture_stats_print+0xd0/0xd0 kmem_cache_create+0xd/0x10 rcu_torture_stats+0x79/0x280 ? rcu_torture_stats_print+0xd0/0xd0 kthread+0x10a/0x140 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 This is because there's one order of locking from the hotplug callbacks: lock(cpu_hotplug_lock); // from hotplug machinery itself lock(slab_mutex); // in e.g. slab_mem_going_offline_callback() And commit 1f0723a4c0df made the reverse sequence possible: lock(slab_mutex); // in kmem_cache_create_usercopy() lock(cpu_hotplug_lock); // kmem_cache_open() -> static_key_enable() The simplest fix is to move static_key_enable() to a place before slab_mutex is taken. That means kmem_cache_create_usercopy() in mm/slab_common.c which is not ideal for SLUB-specific code, but the #ifdef CONFIG_SLUB_DEBUG makes it at least self-contained and obvious. [1] https://lore.kernel.org/lkml/20210502171827.GA3670492@paulmck-ThinkPad-P17-Gen-1/ Link: https://lkml.kernel.org/r/20210504120019.26791-1-vbabka@suse.cz Fixes: 1f0723a4c0df ("mm, slub: enable slub_debug static key when creating cache with explicit debug flags") Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: Paul E. McKenney <paulmck@kernel.org> Tested-by: Paul E. McKenney <paulmck@kernel.org> Acked-by: David Rientjes <rientjes@google.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit afe0c26d1968fe3bbef6a45df945bfeff774ca75) Bug: 199581299 Signed-off-by: Liujie Xie <xieliujie@oppo.com> Change-Id: I72fd0d24e4ca0ee9bd261547133fb6046c8b5f6a
2021-09-16UPSTREAM: mm, slub: enable slub_debug static key when creating cache with ↵Vlastimil Babka1-0/+9
explicit debug flags Commit ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()") introduced a static key to optimize the case where no debugging is enabled for any cache. The static key is enabled when slub_debug boot parameter is passed, or CONFIG_SLUB_DEBUG_ON enabled. However, some caches might be created with one or more debugging flags explicitly passed to kmem_cache_create(), and the commit missed this. Thus the debugging functionality would not be actually performed for these caches unless the static key gets enabled by boot param or config. This patch fixes it by checking for debugging flags passed to kmem_cache_create() and enabling the static key accordingly. Note such explicit debugging flags should not be used outside of debugging and testing as they will now enable the static key globally. btrfs_init_cachep() creates a cache with SLAB_RED_ZONE but that's a mistake that's being corrected [1]. rcu_torture_stats() creates a cache with SLAB_STORE_USER, but that is a testing module so it's OK and will start working as intended after this patch. Also note that in case of backports to kernels before v5.12 that don't have commit 59450bbc12be ("mm, slab, slub: stop taking cpu hotplug lock"), static_branch_enable_cpuslocked() should be used. [1] https://lore.kernel.org/linux-btrfs/20210315141824.26099-1-dsterba@suse.com/ Link: https://lkml.kernel.org/r/20210315153415.24404-1-vbabka@suse.cz Fixes: ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()") Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: Oliver Glitta <glittao@gmail.com> Acked-by: David Rientjes <rientjes@google.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: "Paul E. McKenney" <paulmck@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 1f0723a4c0df36cbdffc6fac82cd3c5d57e06d66) Bug: 199581299 Signed-off-by: Liujie Xie <xieliujie@oppo.com> Change-Id: Ie075ba29e58a43fa96e7c177695d40103490c9ae
2021-09-15UPSTREAM: PM: sleep: core: Avoid setting power.must_resume to falsePrasad Sodagudi1-1/+1
There are variables(power.may_skip_resume and dev->power.must_resume) and DPM_FLAG_MAY_SKIP_RESUME flags to control the resume of devices after a system wide suspend transition. Setting the DPM_FLAG_MAY_SKIP_RESUME flag means that the driver allows its "noirq" and "early" resume callbacks to be skipped if the device can be left in suspend after a system-wide transition into the working state. PM core determines that the driver's "noirq" and "early" resume callbacks should be skipped or not with dev_pm_skip_resume() function by checking power.may_skip_resume variable. power.must_resume variable is getting set to false in __device_suspend() function without checking device's DPM_FLAG_MAY_SKIP_RESUME settings. In problematic scenario, where all the devices in the suspend_late stage are successful and some device can fail to suspend in suspend_noirq phase. So some devices successfully suspended in suspend_late stage are not getting chance to execute __device_suspend_noirq() to set dev->power.must_resume variable to true and not getting resumed in early_resume phase. Add a check for device's DPM_FLAG_MAY_SKIP_RESUME flag before setting power.must_resume variable in __device_suspend function. Fixes: 6e176bf8d461 ("PM: sleep: core: Do not skip callbacks in the resume phase") Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Bug: 195393473 Change-Id: I641a7ba20cc14f6519e1869b4651cda894400274 (cherry picked from commit 4a9344cd0aa4499beb3772bbecb40bb78888c0e1) Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
2021-09-15BACKPORT: FROMGIT: usb: gadget: f_uac2: Populate SS descriptors' ↵Jack Pham1-0/+3
wBytesPerInterval For Isochronous endpoints, the SS companion descriptor's wBytesPerInterval field is required to reserve bus time in order to transmit the required payload during the service interval. If left at 0, the UAC2 function is unable to transact data on its playback or capture endpoints in SuperSpeed mode. Since f_uac2 currently does not support any bursting this value can be exactly equal to the calculated wMaxPacketSize. Tested with Windows 10 as a host. Fixes: f8cb3d556be3 ("usb: f_uac2: adds support for SS and SSP") Cc: stable <stable@vger.kernel.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210909174811.12534-3-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Bug: 199044440 Change-Id: Ibf183102d577aa02746822d145d63a1c767557d2 (cherry picked from commit f0e8a206a2a53a919e1709c654cb65d519f7befb https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus) [jackp: Resolved merge conflict in f_uac2.c due to added code in upstream] Signed-off-by: Jack Pham <jackp@codeaurora.org>
2021-09-15BACKPORT: FROMGIT: usb: gadget: f_uac2: Add missing companion descriptor for ↵Jack Pham1-1/+15
feedback EP The f_uac2 function fails to enumerate when connected in SuperSpeed due to the feedback endpoint missing the companion descriptor. Add a new ss_epin_fback_desc_comp descriptor and append it behind the ss_epin_fback_desc both in the static definition of the ss_audio_desc structure as well as its dynamic construction in setup_headers(). Fixes: 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add feedback endpoint support") Cc: stable <stable@vger.kernel.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210909174811.12534-2-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Bug: 199044440 Change-Id: I8ae495878f38ec733af4ddf61a3f5d57f5cd5a80 (cherry picked from commit 595091a1426a3b2625dad322f69fe569dc9d8943 https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus) [jackp: Resolved merge conflict in f_uac2.c due to added code in upstream] Signed-off-by: Jack Pham <jackp@codeaurora.org>
2021-09-15Revert "FROMLIST: usb: gadget: f_uac2: Add missing companion descriptor for ↵Jack Pham1-5/+1
feedback EP" This reverts commit ab9ceb4334cd02e593c0eae77f54f6d75103846d. The change ended up getting reworked in upstream, so revert and reapply the latest change that merged. Bug: 199044440 Change-Id: If03d1c4a063e182e02b4a9b55c6e702ce860c2e0 Signed-off-by: Jack Pham <jackp@codeaurora.org>
2021-09-15ANDROID: Update the ABI representationPuma Hsu2-0/+29
Leaf changes summary: 4 artifacts changed Changed leaf types summary: 0 leaf type changed Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 2 Added functions Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 2 Added variables 2 Added functions: [A] 'function int __traceiter_android_vh_usb_dev_resume(void*, usb_device*, pm_message_t, int*)' [A] 'function int __traceiter_android_vh_usb_dev_suspend(void*, usb_device*, pm_message_t, int*)' 2 Added variables: [A] 'tracepoint __tracepoint_android_vh_usb_dev_resume' [A] 'tracepoint __tracepoint_android_vh_usb_dev_suspend' Bug: 187770891 Signed-off-by: Puma Hsu <pumahsu@google.com> Change-Id: I76f8ebca7ed9e1b4c9b863d6d9172e8ba8e53b5c
2021-09-14FROMGIT: binder: make sure fd closes completeTodd Kjos1-6/+17
During BC_FREE_BUFFER processing, the BINDER_TYPE_FDA object cleanup may close 1 or more fds. The close operations are completed using the task work mechanism -- which means the thread needs to return to userspace or the file object may never be dereferenced -- which can lead to hung processes. Force the binder thread back to userspace if an fd is closed during BC_FREE_BUFFER handling. Fixes: 80cd795630d6 ("binder: fix use-after-free due to ksys_close() during fdget()") Cc: stable <stable@vger.kernel.org> Reviewed-by: Martijn Coenen <maco@android.com> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Todd Kjos <tkjos@google.com> Link: https://lore.kernel.org/r/20210830195146.587206-1-tkjos@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Bug: 111997867 (cherry picked from commit 5fdb55c1ac9585eb23bb2541d5819224429e103d git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git Change-Id: Idffa9b54edfc289d95b24f7ae2aa11ae494c7158
2021-09-14ANDROID: abi_gki_aarch64_qcom: Add vsock functionsJay Jayanna2-327/+341
Leaf changes summary: 2 artifacts changed Changed leaf types summary: 0 leaf type changed Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 2 Added functions Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable 2 Added functions: [A] 'function void vsock_addr_init(struct sockaddr_vm *addr, u32 cid, u32 port)' [A] 'function void vsock_remove_sock(struct vsock_sock *vsk)' Bug: 199425983 Change-Id: I772835db6a1839f0ff658ebfbd1e898278dbcf48 Signed-off-by: Jay Jayanna <jayanna@codeaurora.org> Signed-off-by: Tony Truong <truong@codeaurora.org>
2021-09-14ANDROID: mm: unlock the page on speculative fault retryVinayak Menon1-0/+2
It is observed that certain file accesses are failing when speculative file faults are enabled via "allow_file_spec_access". This is because of not unlocking the page on error in filemap_map_pages, and the locked page causes endless retry of fault. Bug: 199706590 Fixes: 35eacb5c87b9 ("ANDROID: mm: allow vmas with vm_ops to be speculatively handled") Change-Id: Ic7643ea8188aa281754318866fde09eea094c5da Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
2021-09-14FROMGIT: binder: fix freeze raceLi Li3-6/+38
Currently cgroup freezer is used to freeze the application threads, and BINDER_FREEZE is used to freeze the corresponding binder interface. There's already a mechanism in ioctl(BINDER_FREEZE) to wait for any existing transactions to drain out before actually freezing the binder interface. But freezing an app requires 2 steps, freezing the binder interface with ioctl(BINDER_FREEZE) and then freezing the application main threads with cgroupfs. This is not an atomic operation. The following race issue might happen. 1) Binder interface is frozen by ioctl(BINDER_FREEZE); 2) Main thread A initiates a new sync binder transaction to process B; 3) Main thread A is frozen by "echo 1 > cgroup.freeze"; 4) The response from process B reaches the frozen thread, which will unexpectedly fail. This patch provides a mechanism to check if there's any new pending transaction happening between ioctl(BINDER_FREEZE) and freezing the main thread. If there's any, the main thread freezing operation can be rolled back to finish the pending transaction. Furthermore, the response might reach the binder driver before the rollback actually happens. That will still cause failed transaction. As the other process doesn't wait for another response of the response, the response transaction failure can be fixed by treating the response transaction like an oneway/async one, allowing it to reach the frozen thread. And it will be consumed when the thread gets unfrozen later. NOTE: This patch reuses the existing definition of struct binder_frozen_status_info but expands the bit assignments of __u32 member sync_recv. To ensure backward compatibility, bit 0 of sync_recv still indicates there's an outstanding sync binder transaction. This patch adds new information to bit 1 of sync_recv, indicating the binder transaction happens exactly when there's a race. If an existing userspace app runs on a new kernel, a sync binder call will set bit 0 of sync_recv so ioctl(BINDER_GET_FROZEN_INFO) still return the expected value (true). The app just doesn't check bit 1 intentionally so it doesn't have the ability to tell if there's a race. This behavior is aligned with what happens on an old kernel which doesn't set bit 1 at all. A new userspace app can 1) check bit 0 to know if there's a sync binder transaction happened when being frozen - same as before; and 2) check bit 1 to know if that sync binder transaction happened exactly when there's a race - a new information for rollback decision. Fixes: 432ff1e91694 ("binder: BINDER_FREEZE ioctl") Acked-by: Todd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Li Li <dualli@google.com> Test: stress test with apps being frozen and initiating binder calls at the same time, confirmed the pending transactions succeeded. Link: https://lore.kernel.org/r/20210910164210.2282716-2-dualli@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Bug: 198493121 (cherry picked from commit b564171ade70570b7f335fa8ed17adb28409e3ac git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git char-misc-linus) Change-Id: I488ba75056f18bb3094ba5007027b76b5caebec9
2021-09-14FROMLIST: dm-verity: skip verity_handle_error on I/O errorsAkilesh Kailash1-2/+11
If there is an I/O error and FEC correction fails, return an error instead of calling verity_handle_error(). Suggested-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Akilesh Kailash <akailash@google.com> Bug: 197830746 Change-Id: Idd5f65bb72c78a1cca44e5593e40880b2408b564 Link: https://lore.kernel.org/all/20210913092642.3237796-1-akailash@google.com/ Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>