This bug is marked as fixed by commit:
net: core: netlink: add helper refcount dec and lock function
net: sched: add helper function to take reference to Qdisc
net: sched: extend Qdisc with rcu
net: sched: rename qdisc_destroy() to qdisc_put()
net: sched: use Qdisc rcu API instead of relying on rtnl lock
But I can't find it in any tested tree for more than 90 days.
Is it a correct commit? Please update it by replying:
#syz fix: exact-commit-title
Until then the bug is still considered open and
new crashes with the same signature are ignored.
Clang warns:
drivers/staging/android/ion/ion-ioctl.c:71:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (--handle->user_ref_count == 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/android/ion/ion-ioctl.c:74:9: note: uninitialized use occurs here
return ret;
^~~
drivers/staging/android/ion/ion-ioctl.c:71:2: note: remove the 'if' if its condition is always true
if (--handle->user_ref_count == 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/android/ion/ion-ioctl.c:69:9: note: initialize the variable 'ret' to silence this warning
int ret;
^
= 0
1 warning generated.
The return value of user_ion_handle_put_nolock() is not checked in its
one call site in user_ion_free_nolock() so just make
user_ion_handle_put_nolock() return void to remove the warning.
Fixes: a8200613c8c9 ("ion: Protect kref from userspace manipulation")
Reported-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Nathan Chancellor <nathan(a)kernel.org>
---
drivers/staging/android/ion/ion-ioctl.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c
index a27865b94416..e020a23d05f2 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -64,14 +64,10 @@ static struct ion_handle *pass_to_user(struct ion_handle *handle)
}
/* Must hold the client lock */
-static int user_ion_handle_put_nolock(struct ion_handle *handle)
+static void user_ion_handle_put_nolock(struct ion_handle *handle)
{
- int ret;
-
if (--handle->user_ref_count == 0)
- ret = ion_handle_put_nolock(handle);
-
- return ret;
+ ion_handle_put_nolock(handle);
}
static void user_ion_free_nolock(struct ion_client *client,
base-commit: 65be5f5665a580424a7b1102f1a04c4259c559b5
--
2.37.1
We found a compile error when building tools/testing/selftests/bpf/ on 5.10.y.
tools/testing/selftests/bpf/prog_tests/sk_lookup.c:1092:15: error: 'struct bpf_sk_lookup' has no member named 'cookie'
1092 | if (CHECK(ctx.cookie == 0, "ctx.cookie", "no socket selected\n"))
| ^
To fix this bug, this patchset backports three patches from upstream:
https://lore.kernel.org/bpf/20210303101816.36774-1-lmb@cloudflare.com/
Patch 1 and 2 are necessary for bpf selftests build pass on 5.10.y.
Patch 3 does not impact building stage, but can avoid a test case
failure (by skipping it).
Lorenz Bauer (3):
bpf: Consolidate shared test timing code
bpf: Add PROG_TEST_RUN support for sk_lookup programs
selftests: bpf: Don't run sk_lookup in verifier tests
include/linux/bpf.h | 10 +
include/uapi/linux/bpf.h | 5 +-
net/bpf/test_run.c | 243 +++++++++++++-----
net/core/filter.c | 1 +
tools/include/uapi/linux/bpf.h | 5 +-
tools/testing/selftests/bpf/test_verifier.c | 4 +-
.../selftests/bpf/verifier/ctx_sk_lookup.c | 1 +
7 files changed, 204 insertions(+), 65 deletions(-)
--
2.27.0
From: Ming Lei <ming.lei(a)redhat.com>
commit 673235f915318ced5d7ec4b2bfd8cb909e6a4a55 upstream.
When queuing I/O request to LLD, STS_RESOURCE may be returned because:
- Host is in recovery or blocked
- Target queue throttling or target is blocked
- LLD rejection
In these scenarios BLK_STS_DEV_RESOURCE is returned to the block layer to
avoid an unnecessary re-run of the queue. However, all of the requests
queued to this SCSI device may complete immediately after reading
'sdev->device_busy' and BLK_STS_DEV_RESOURCE is returned to block layer. In
that case the current I/O won't get a chance to get queued since it is
invisible at that time for both scsi_run_queue_async() and blk-mq's
RESTART.
Fix the issue by not returning BLK_STS_DEV_RESOURCE in this situation.
Link: https://lore.kernel.org/r/20201202100419.525144-1-ming.lei@redhat.com
Fixes: 86ff7c2a80cd ("blk-mq: introduce BLK_STS_DEV_RESOURCE")
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Sumit Saxena <sumit.saxena(a)broadcom.com>
Cc: Kashyap Desai <kashyap.desai(a)broadcom.com>
Cc: Bart Van Assche <bvanassche(a)acm.org>
Cc: Ewan Milne <emilne(a)redhat.com>
Cc: Long Li <longli(a)microsoft.com>
Reported-by: John Garry <john.garry(a)huawei.com>
Tested-by: "chenxiang (M)" <chenxiang66(a)hisilicon.com>
Signed-off-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Yu Kuai <yukuai3(a)huawei.com>
---
drivers/scsi/scsi_lib.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 8e6d7ba95df1..98e363d0025b 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1719,8 +1719,7 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx *hctx,
case BLK_STS_OK:
break;
case BLK_STS_RESOURCE:
- if (atomic_read(&sdev->device_busy) ||
- scsi_device_blocked(sdev))
+ if (scsi_device_blocked(sdev))
ret = BLK_STS_DEV_RESOURCE;
break;
default:
--
2.31.1
Hi Greg,
This backport series contains mostly fixes from v5.14 release along
with one fix deferred from the first joint 5.10/5.15 series [1].
The upstream commit f8d92a66e810 ("xfs: prevent UAF in
xfs_log_item_in_current_chkpt") was already applied to 5.15.y, but its
5.10.y backport was more involved (required two non trivial dependency
patches), so it needed more time for review and testing.
Per Darrick's recommendation, on top of the usual regression tests,
I also ran the "recoveryloop" tests group for an extended period of
time to test for rare regressions.
Some recoveryloop tests were failing at rates less frequent than 1/100,
but no change in failure rate was observed between baseline (v5.10.131)
and the backport branch.
There was one exceptional test, xfs/455, that was reporting data
corruptions after crash at very low rate - less frequent than 1/1000
on both baseline and backport branch.
It is hard to draw solid conclusions with such rare failures, but the
test was run >10,000 times on baseline and >20,000 times on backport
branch, so as far as our test coverage can attest, these backports are
not introducing any obvious xfs regressions to 5.10.y.
Thanks,
Amir.
Changes from [v1]:
- Survived a week of crash recovery loop
- Added Acked-by Darrick
- CC stable
[1] https://lore.kernel.org/linux-xfs/20220623203641.1710377-1-leah.rumancik@gm…
[v1] https://lore.kernel.org/linux-xfs/20220726092125.3899077-1-amir73il@gmail.c…
Brian Foster (2):
xfs: hold buffer across unpin and potential shutdown processing
xfs: remove dead stale buf unpin handling code
Christoph Hellwig (1):
xfs: refactor xfs_file_fsync
Darrick J. Wong (3):
xfs: prevent UAF in xfs_log_item_in_current_chkpt
xfs: fix log intent recovery ENOSPC shutdowns when inactivating inodes
xfs: force the log offline when log intent item recovery fails
Dave Chinner (3):
xfs: xfs_log_force_lsn isn't passed a LSN
xfs: logging the on disk inode LSN can make it go backwards
xfs: Enforce attr3 buffer recovery order
fs/xfs/libxfs/xfs_log_format.h | 11 ++++-
fs/xfs/libxfs/xfs_types.h | 1 +
fs/xfs/xfs_buf_item.c | 60 ++++++++++--------------
fs/xfs/xfs_buf_item_recover.c | 1 +
fs/xfs/xfs_dquot_item.c | 2 +-
fs/xfs/xfs_file.c | 81 ++++++++++++++++++++-------------
fs/xfs/xfs_inode.c | 10 ++--
fs/xfs/xfs_inode_item.c | 4 +-
fs/xfs/xfs_inode_item.h | 2 +-
fs/xfs/xfs_inode_item_recover.c | 39 ++++++++++++----
fs/xfs/xfs_log.c | 30 ++++++------
fs/xfs/xfs_log.h | 4 +-
fs/xfs/xfs_log_cil.c | 32 +++++--------
fs/xfs/xfs_log_priv.h | 15 +++---
fs/xfs/xfs_log_recover.c | 5 +-
fs/xfs/xfs_mount.c | 10 +++-
fs/xfs/xfs_trans.c | 6 +--
fs/xfs/xfs_trans.h | 4 +-
18 files changed, 179 insertions(+), 138 deletions(-)
--
2.25.1
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
The gcc build warning prevents all clang-built kernels from working
properly, so comment it out to fix the build.
This is a -stable kernel only patch for now, it will be resolved
differently in mainline releases in the future.
Cc: "Jason A. Donenfeld" <Jason(a)zx2c4.com>
Cc: "Justin M. Forbes" <jforbes(a)fedoraproject.org>
Cc: Ard Biesheuvel <ardb(a)kernel.org>
Cc: Arnd Bergmann <arnd(a)kernel.org>
Cc: Nicolas Pitre <nico(a)linaro.org>
Cc: Nathan Chancellor <nathan(a)kernel.org>
Cc: Nick Desaulniers <ndesaulniers(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/lib/xor-neon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
index b99dd8e1c93f..7ba6cf826162 100644
--- a/arch/arm/lib/xor-neon.c
+++ b/arch/arm/lib/xor-neon.c
@@ -26,8 +26,9 @@ MODULE_LICENSE("GPL");
* While older versions of GCC do not generate incorrect code, they fail to
* recognize the parallel nature of these functions, and emit plain ARM code,
* which is known to be slower than the optimized ARM code in asm-arm/xor.h.
+ *
+ * #warning This code requires at least version 4.6 of GCC
*/
-#warning This code requires at least version 4.6 of GCC
#endif
#pragma GCC diagnostic ignored "-Wunused-variable"
--
2.37.1