The patch below does not apply to the 6.0-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
f3c23bea598a ("drm/amd/display: Uninitialized variables causing 4k60 UCLK to stay at DPM1 and not DPM0")
6d4727c80947 ("drm/amd/display: Add check for DET fetch latency hiding for dcn32")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From f3c23bea598ab7e8e4b8c5ca66598921310f718e Mon Sep 17 00:00:00 2001
From: Samson Tam <samson.tam(a)amd.com>
Date: Mon, 5 Dec 2022 11:08:40 -0500
Subject: [PATCH] drm/amd/display: Uninitialized variables causing 4k60 UCLK to
stay at DPM1 and not DPM0
[Why]
SwathSizePerSurfaceY[] and SwathSizePerSurfaceC[] values are uninitialized
because we are using += instead of = operator.
[How]
Assign values in loop with = operator.
Acked-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com>
Signed-off-by: Samson Tam <samson.tam(a)amd.com>
Reviewed-by: Aric Cyr <aric.cyr(a)amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org # 6.0.x, 6.1.x
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
index 5af601cff1a0..b53feeaf5cf1 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
@@ -6257,12 +6257,12 @@ bool dml32_CalculateDETSwathFillLatencyHiding(unsigned int NumberOfActiveSurface
double SwathSizePerSurfaceC[DC__NUM_DPP__MAX];
bool NotEnoughDETSwathFillLatencyHiding = false;
- /* calculate sum of single swath size for all pipes in bytes*/
+ /* calculate sum of single swath size for all pipes in bytes */
for (k = 0; k < NumberOfActiveSurfaces; k++) {
- SwathSizePerSurfaceY[k] += SwathHeightY[k] * SwathWidthY[k] * BytePerPixelInDETY[k] * NumOfDPP[k];
+ SwathSizePerSurfaceY[k] = SwathHeightY[k] * SwathWidthY[k] * BytePerPixelInDETY[k] * NumOfDPP[k];
if (SwathHeightC[k] != 0)
- SwathSizePerSurfaceC[k] += SwathHeightC[k] * SwathWidthC[k] * BytePerPixelInDETC[k] * NumOfDPP[k];
+ SwathSizePerSurfaceC[k] = SwathHeightC[k] * SwathWidthC[k] * BytePerPixelInDETC[k] * NumOfDPP[k];
else
SwathSizePerSurfaceC[k] = 0;
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
f3c23bea598a ("drm/amd/display: Uninitialized variables causing 4k60 UCLK to stay at DPM1 and not DPM0")
6d4727c80947 ("drm/amd/display: Add check for DET fetch latency hiding for dcn32")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From f3c23bea598ab7e8e4b8c5ca66598921310f718e Mon Sep 17 00:00:00 2001
From: Samson Tam <samson.tam(a)amd.com>
Date: Mon, 5 Dec 2022 11:08:40 -0500
Subject: [PATCH] drm/amd/display: Uninitialized variables causing 4k60 UCLK to
stay at DPM1 and not DPM0
[Why]
SwathSizePerSurfaceY[] and SwathSizePerSurfaceC[] values are uninitialized
because we are using += instead of = operator.
[How]
Assign values in loop with = operator.
Acked-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com>
Signed-off-by: Samson Tam <samson.tam(a)amd.com>
Reviewed-by: Aric Cyr <aric.cyr(a)amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org # 6.0.x, 6.1.x
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
index 5af601cff1a0..b53feeaf5cf1 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c
@@ -6257,12 +6257,12 @@ bool dml32_CalculateDETSwathFillLatencyHiding(unsigned int NumberOfActiveSurface
double SwathSizePerSurfaceC[DC__NUM_DPP__MAX];
bool NotEnoughDETSwathFillLatencyHiding = false;
- /* calculate sum of single swath size for all pipes in bytes*/
+ /* calculate sum of single swath size for all pipes in bytes */
for (k = 0; k < NumberOfActiveSurfaces; k++) {
- SwathSizePerSurfaceY[k] += SwathHeightY[k] * SwathWidthY[k] * BytePerPixelInDETY[k] * NumOfDPP[k];
+ SwathSizePerSurfaceY[k] = SwathHeightY[k] * SwathWidthY[k] * BytePerPixelInDETY[k] * NumOfDPP[k];
if (SwathHeightC[k] != 0)
- SwathSizePerSurfaceC[k] += SwathHeightC[k] * SwathWidthC[k] * BytePerPixelInDETC[k] * NumOfDPP[k];
+ SwathSizePerSurfaceC[k] = SwathHeightC[k] * SwathWidthC[k] * BytePerPixelInDETC[k] * NumOfDPP[k];
else
SwathSizePerSurfaceC[k] = 0;
From: Takashi Iwai <tiwai(a)suse.de>
commit 8423f0b6d513b259fdab9c9bf4aaa6188d054c2d upstream.
There is a small race window at snd_pcm_oss_sync() that is called from
OSS PCM SNDCTL_DSP_SYNC ioctl; namely the function calls
snd_pcm_oss_make_ready() at first, then takes the params_lock mutex
for the rest. When the stream is set up again by another thread
between them, it leads to inconsistency, and may result in unexpected
results such as NULL dereference of OSS buffer as a fuzzer spotted
recently.
The fix is simply to cover snd_pcm_oss_make_ready() call into the same
params_lock mutex with snd_pcm_oss_make_ready_locked() variant.
Reported-and-tested-by: butt3rflyh4ck <butterflyhuangxx(a)gmail.com>
Reviewed-by: Jaroslav Kysela <perex(a)perex.cz>
Cc: <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aa…
Link: https://lore.kernel.org/r/20220905060714.22549-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Zubin Mithra <zsm(a)google.com>
---
Note:
* 8423f0b6d513 is present in linux-5.15.y and linux-5.4.y; missing in
linux-5.10.y.
* Backport addresses conflict due to surrounding context.
* Tests run: build and boot.
sound/core/oss/pcm_oss.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/core/oss/pcm_oss.c b/sound/core/oss/pcm_oss.c
index f88de74da1eb..de6f94bee50b 100644
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1662,13 +1662,14 @@ static int snd_pcm_oss_sync(struct snd_pcm_oss_file *pcm_oss_file)
runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
goto __direct;
- if ((err = snd_pcm_oss_make_ready(substream)) < 0)
- return err;
atomic_inc(&runtime->oss.rw_ref);
if (mutex_lock_interruptible(&runtime->oss.params_lock)) {
atomic_dec(&runtime->oss.rw_ref);
return -ERESTARTSYS;
}
+ err = snd_pcm_oss_make_ready_locked(substream);
+ if (err < 0)
+ goto unlock;
format = snd_pcm_oss_format_from(runtime->oss.format);
width = snd_pcm_format_physical_width(format);
if (runtime->oss.buffer_used > 0) {
--
2.38.0.rc1.362.ged0d419d3c-goog
The patch below does not apply to the 6.0-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
12521a5d5cb7 ("io_uring: fix CQ waiting timeout handling")
35d90f95cfa7 ("io_uring: include task_work run after scheduling in wait for events")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 12521a5d5cb7ff0ad43eadfc9c135d86e1131fa8 Mon Sep 17 00:00:00 2001
From: Pavel Begunkov <asml.silence(a)gmail.com>
Date: Thu, 5 Jan 2023 10:49:15 +0000
Subject: [PATCH] io_uring: fix CQ waiting timeout handling
Jiffy to ktime CQ waiting conversion broke how we treat timeouts, in
particular we rearm it anew every time we get into
io_cqring_wait_schedule() without adjusting the timeout. Waiting for 2
CQEs and getting a task_work in the middle may double the timeout value,
or even worse in some cases task may wait indefinitely.
Cc: stable(a)vger.kernel.org
Fixes: 228339662b398 ("io_uring: don't convert to jiffies for waiting on timeouts")
Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com>
Link: https://lore.kernel.org/r/f7bffddd71b08f28a877d44d37ac953ddb01590d.16729156…
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 472574192dd6..2ac1cd8d23ea 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -2470,7 +2470,7 @@ int io_run_task_work_sig(struct io_ring_ctx *ctx)
/* when returns >0, the caller should retry */
static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx,
struct io_wait_queue *iowq,
- ktime_t timeout)
+ ktime_t *timeout)
{
int ret;
unsigned long check_cq;
@@ -2488,7 +2488,7 @@ static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx,
if (check_cq & BIT(IO_CHECK_CQ_DROPPED_BIT))
return -EBADR;
}
- if (!schedule_hrtimeout(&timeout, HRTIMER_MODE_ABS))
+ if (!schedule_hrtimeout(timeout, HRTIMER_MODE_ABS))
return -ETIME;
/*
@@ -2564,7 +2564,7 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, int min_events,
}
prepare_to_wait_exclusive(&ctx->cq_wait, &iowq.wq,
TASK_INTERRUPTIBLE);
- ret = io_cqring_wait_schedule(ctx, &iowq, timeout);
+ ret = io_cqring_wait_schedule(ctx, &iowq, &timeout);
if (__io_cqring_events_user(ctx) >= min_events)
break;
cond_resched();
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
12521a5d5cb7 ("io_uring: fix CQ waiting timeout handling")
35d90f95cfa7 ("io_uring: include task_work run after scheduling in wait for events")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 12521a5d5cb7ff0ad43eadfc9c135d86e1131fa8 Mon Sep 17 00:00:00 2001
From: Pavel Begunkov <asml.silence(a)gmail.com>
Date: Thu, 5 Jan 2023 10:49:15 +0000
Subject: [PATCH] io_uring: fix CQ waiting timeout handling
Jiffy to ktime CQ waiting conversion broke how we treat timeouts, in
particular we rearm it anew every time we get into
io_cqring_wait_schedule() without adjusting the timeout. Waiting for 2
CQEs and getting a task_work in the middle may double the timeout value,
or even worse in some cases task may wait indefinitely.
Cc: stable(a)vger.kernel.org
Fixes: 228339662b398 ("io_uring: don't convert to jiffies for waiting on timeouts")
Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com>
Link: https://lore.kernel.org/r/f7bffddd71b08f28a877d44d37ac953ddb01590d.16729156…
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 472574192dd6..2ac1cd8d23ea 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -2470,7 +2470,7 @@ int io_run_task_work_sig(struct io_ring_ctx *ctx)
/* when returns >0, the caller should retry */
static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx,
struct io_wait_queue *iowq,
- ktime_t timeout)
+ ktime_t *timeout)
{
int ret;
unsigned long check_cq;
@@ -2488,7 +2488,7 @@ static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx,
if (check_cq & BIT(IO_CHECK_CQ_DROPPED_BIT))
return -EBADR;
}
- if (!schedule_hrtimeout(&timeout, HRTIMER_MODE_ABS))
+ if (!schedule_hrtimeout(timeout, HRTIMER_MODE_ABS))
return -ETIME;
/*
@@ -2564,7 +2564,7 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, int min_events,
}
prepare_to_wait_exclusive(&ctx->cq_wait, &iowq.wq,
TASK_INTERRUPTIBLE);
- ret = io_cqring_wait_schedule(ctx, &iowq, timeout);
+ ret = io_cqring_wait_schedule(ctx, &iowq, &timeout);
if (__io_cqring_events_user(ctx) >= min_events)
break;
cond_resched();
The patch below does not apply to the 6.0-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
a26116c1e740 ("virtio_blk: Fix signedness bug in virtblk_prep_rq()")
258896fcc786 ("virtio-blk: use a helper to handle request queuing errors")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From a26116c1e74028914f281851488546c91cbae57d Mon Sep 17 00:00:00 2001
From: Rafael Mendonca <rafaelmendsr(a)gmail.com>
Date: Fri, 21 Oct 2022 17:41:26 -0300
Subject: [PATCH] virtio_blk: Fix signedness bug in virtblk_prep_rq()
The virtblk_map_data() function returns negative error codes, however, the
'nents' field of vbr->sg_table is an unsigned int, which causes the error
handling not to work correctly.
Cc: stable(a)vger.kernel.org
Fixes: 0e9911fa768f ("virtio-blk: support mq_ops->queue_rqs()")
Signed-off-by: Rafael Mendonca <rafaelmendsr(a)gmail.com>
Message-Id: <20221021204126.927603-1-rafaelmendsr(a)gmail.com>
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare(a)redhat.com>
Reviewed-by: Suwan Kim <suwan.kim027(a)gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha(a)redhat.com>
Acked-by: Jason Wang <jasowang(a)redhat.com>
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index dcbf86cd2155..6a77fa917428 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -334,14 +334,16 @@ static blk_status_t virtblk_prep_rq(struct blk_mq_hw_ctx *hctx,
struct virtblk_req *vbr)
{
blk_status_t status;
+ int num;
status = virtblk_setup_cmd(vblk->vdev, req, vbr);
if (unlikely(status))
return status;
- vbr->sg_table.nents = virtblk_map_data(hctx, req, vbr);
- if (unlikely(vbr->sg_table.nents < 0))
+ num = virtblk_map_data(hctx, req, vbr);
+ if (unlikely(num < 0))
return virtblk_fail_to_queue(req, -ENOMEM);
+ vbr->sg_table.nents = num;
blk_mq_start_request(req);
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
a26116c1e740 ("virtio_blk: Fix signedness bug in virtblk_prep_rq()")
258896fcc786 ("virtio-blk: use a helper to handle request queuing errors")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From a26116c1e74028914f281851488546c91cbae57d Mon Sep 17 00:00:00 2001
From: Rafael Mendonca <rafaelmendsr(a)gmail.com>
Date: Fri, 21 Oct 2022 17:41:26 -0300
Subject: [PATCH] virtio_blk: Fix signedness bug in virtblk_prep_rq()
The virtblk_map_data() function returns negative error codes, however, the
'nents' field of vbr->sg_table is an unsigned int, which causes the error
handling not to work correctly.
Cc: stable(a)vger.kernel.org
Fixes: 0e9911fa768f ("virtio-blk: support mq_ops->queue_rqs()")
Signed-off-by: Rafael Mendonca <rafaelmendsr(a)gmail.com>
Message-Id: <20221021204126.927603-1-rafaelmendsr(a)gmail.com>
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare(a)redhat.com>
Reviewed-by: Suwan Kim <suwan.kim027(a)gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha(a)redhat.com>
Acked-by: Jason Wang <jasowang(a)redhat.com>
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index dcbf86cd2155..6a77fa917428 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -334,14 +334,16 @@ static blk_status_t virtblk_prep_rq(struct blk_mq_hw_ctx *hctx,
struct virtblk_req *vbr)
{
blk_status_t status;
+ int num;
status = virtblk_setup_cmd(vblk->vdev, req, vbr);
if (unlikely(status))
return status;
- vbr->sg_table.nents = virtblk_map_data(hctx, req, vbr);
- if (unlikely(vbr->sg_table.nents < 0))
+ num = virtblk_map_data(hctx, req, vbr);
+ if (unlikely(num < 0))
return virtblk_fail_to_queue(req, -ENOMEM);
+ vbr->sg_table.nents = num;
blk_mq_start_request(req);
The patch below does not apply to the 6.0-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
d73a27b86fc7 ("btrfs: handle case when repair happens with dev-replace")
bacf60e51586 ("btrfs: move repair_io_failure to bio.c")
103c19723c80 ("btrfs: split the bio submission path into a separate file")
cb3e217bdb39 ("btrfs: use btrfs_dev_name() helper to handle missing devices better")
947a629988f1 ("btrfs: move tree block parentness check into validate_extent_buffer()")
789d6a3a876e ("btrfs: concentrate all tree block parentness check parameters into one structure")
ab2072b2921e ("btrfs: change how submit bio callback is passed to btrfs_wq_submit_bio")
7920b773bd8a ("btrfs: drop parameter compression_type from btrfs_submit_dio_repair_bio")
19af6a7d345a ("btrfs: change how repair action is passed to btrfs_repair_one_sector")
a2c8d27e5ee8 ("btrfs: use a structure to pass arguments to backref walking functions")
6ce6ba534418 ("btrfs: use a single argument for extent offset in backref walking functions")
22a3c0ac8ed0 ("btrfs: send: avoid unnecessary backref lookups when finding clone source")
aa5d3003ddee ("btrfs: move orphan prototypes into orphan.h")
7f0add250f82 ("btrfs: move super_block specific helpers into super.h")
c03b22076bd2 ("btrfs: move super prototypes into super.h")
5c11adcc383a ("btrfs: move verity prototypes into verity.h")
77407dc032e2 ("btrfs: move dev-replace prototypes into dev-replace.h")
2fc6822c99d7 ("btrfs: move scrub prototypes into scrub.h")
677074792a1d ("btrfs: move relocation prototypes into relocation.h")
33cf97a7b658 ("btrfs: move acl prototypes into acl.h")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From d73a27b86fc722c28a26ec64002e3a7dc86d1c07 Mon Sep 17 00:00:00 2001
From: Qu Wenruo <wqu(a)suse.com>
Date: Sun, 1 Jan 2023 09:02:21 +0800
Subject: [PATCH] btrfs: handle case when repair happens with dev-replace
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
[BUG]
There is a bug report that a BUG_ON() in btrfs_repair_io_failure()
(originally repair_io_failure() in v6.0 kernel) got triggered when
replacing a unreliable disk:
BTRFS warning (device sda1): csum failed root 257 ino 2397453 off 39624704 csum 0xb0d18c75 expected csum 0x4dae9c5e mirror 3
kernel BUG at fs/btrfs/extent_io.c:2380!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 9 PID: 3614331 Comm: kworker/u257:2 Tainted: G OE 6.0.0-5-amd64 #1 Debian 6.0.10-2
Hardware name: Micro-Star International Co., Ltd. MS-7C60/TRX40 PRO WIFI (MS-7C60), BIOS 2.70 07/01/2021
Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]
RIP: 0010:repair_io_failure+0x24a/0x260 [btrfs]
Call Trace:
<TASK>
clean_io_failure+0x14d/0x180 [btrfs]
end_bio_extent_readpage+0x412/0x6e0 [btrfs]
? __switch_to+0x106/0x420
process_one_work+0x1c7/0x380
worker_thread+0x4d/0x380
? rescuer_thread+0x3a0/0x3a0
kthread+0xe9/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x22/0x30
[CAUSE]
Before the BUG_ON(), we got some read errors from the replace target
first, note the mirror number (3, which is beyond RAID1 duplication,
thus it's read from the replace target device).
Then at the BUG_ON() location, we are trying to writeback the repaired
sectors back the failed device.
The check looks like this:
ret = btrfs_map_block(fs_info, BTRFS_MAP_WRITE, logical,
&map_length, &bioc, mirror_num);
if (ret)
goto out_counter_dec;
BUG_ON(mirror_num != bioc->mirror_num);
But inside btrfs_map_block(), we can modify bioc->mirror_num especially
for dev-replace:
if (dev_replace_is_ongoing && mirror_num == map->num_stripes + 1 &&
!need_full_stripe(op) && dev_replace->tgtdev != NULL) {
ret = get_extra_mirror_from_replace(fs_info, logical, *length,
dev_replace->srcdev->devid,
&mirror_num,
&physical_to_patch_in_first_stripe);
patch_the_first_stripe_for_dev_replace = 1;
}
Thus if we're repairing the replace target device, we're going to
trigger that BUG_ON().
But in reality, the read failure from the replace target device may be
that, our replace hasn't reached the range we're reading, thus we're
reading garbage, but with replace running, the range would be properly
filled later.
Thus in that case, we don't need to do anything but let the replace
routine to handle it.
[FIX]
Instead of a BUG_ON(), just skip the repair if we're repairing the
device replace target device.
Reported-by: 小太 <nospam(a)kota.moe>
Link: https://lore.kernel.org/linux-btrfs/CACsxjPYyJGQZ+yvjzxA1Nn2LuqkYqTCcUH43S=…
CC: stable(a)vger.kernel.org # 6.0+
Signed-off-by: Qu Wenruo <wqu(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/bio.c b/fs/btrfs/bio.c
index b8fb7ef6b520..8affc88b0e0a 100644
--- a/fs/btrfs/bio.c
+++ b/fs/btrfs/bio.c
@@ -329,7 +329,16 @@ int btrfs_repair_io_failure(struct btrfs_fs_info *fs_info, u64 ino, u64 start,
&map_length, &bioc, mirror_num);
if (ret)
goto out_counter_dec;
- BUG_ON(mirror_num != bioc->mirror_num);
+ /*
+ * This happens when dev-replace is also running, and the
+ * mirror_num indicates the dev-replace target.
+ *
+ * In this case, we don't need to do anything, as the read
+ * error just means the replace progress hasn't reached our
+ * read range, and later replace routine would handle it well.
+ */
+ if (mirror_num != bioc->mirror_num)
+ goto out_counter_dec;
}
sector = bioc->stripes[bioc->mirror_num - 1].physical >> 9;
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
d73a27b86fc7 ("btrfs: handle case when repair happens with dev-replace")
bacf60e51586 ("btrfs: move repair_io_failure to bio.c")
103c19723c80 ("btrfs: split the bio submission path into a separate file")
cb3e217bdb39 ("btrfs: use btrfs_dev_name() helper to handle missing devices better")
947a629988f1 ("btrfs: move tree block parentness check into validate_extent_buffer()")
789d6a3a876e ("btrfs: concentrate all tree block parentness check parameters into one structure")
ab2072b2921e ("btrfs: change how submit bio callback is passed to btrfs_wq_submit_bio")
7920b773bd8a ("btrfs: drop parameter compression_type from btrfs_submit_dio_repair_bio")
19af6a7d345a ("btrfs: change how repair action is passed to btrfs_repair_one_sector")
a2c8d27e5ee8 ("btrfs: use a structure to pass arguments to backref walking functions")
6ce6ba534418 ("btrfs: use a single argument for extent offset in backref walking functions")
22a3c0ac8ed0 ("btrfs: send: avoid unnecessary backref lookups when finding clone source")
aa5d3003ddee ("btrfs: move orphan prototypes into orphan.h")
7f0add250f82 ("btrfs: move super_block specific helpers into super.h")
c03b22076bd2 ("btrfs: move super prototypes into super.h")
5c11adcc383a ("btrfs: move verity prototypes into verity.h")
77407dc032e2 ("btrfs: move dev-replace prototypes into dev-replace.h")
2fc6822c99d7 ("btrfs: move scrub prototypes into scrub.h")
677074792a1d ("btrfs: move relocation prototypes into relocation.h")
33cf97a7b658 ("btrfs: move acl prototypes into acl.h")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From d73a27b86fc722c28a26ec64002e3a7dc86d1c07 Mon Sep 17 00:00:00 2001
From: Qu Wenruo <wqu(a)suse.com>
Date: Sun, 1 Jan 2023 09:02:21 +0800
Subject: [PATCH] btrfs: handle case when repair happens with dev-replace
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
[BUG]
There is a bug report that a BUG_ON() in btrfs_repair_io_failure()
(originally repair_io_failure() in v6.0 kernel) got triggered when
replacing a unreliable disk:
BTRFS warning (device sda1): csum failed root 257 ino 2397453 off 39624704 csum 0xb0d18c75 expected csum 0x4dae9c5e mirror 3
kernel BUG at fs/btrfs/extent_io.c:2380!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 9 PID: 3614331 Comm: kworker/u257:2 Tainted: G OE 6.0.0-5-amd64 #1 Debian 6.0.10-2
Hardware name: Micro-Star International Co., Ltd. MS-7C60/TRX40 PRO WIFI (MS-7C60), BIOS 2.70 07/01/2021
Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]
RIP: 0010:repair_io_failure+0x24a/0x260 [btrfs]
Call Trace:
<TASK>
clean_io_failure+0x14d/0x180 [btrfs]
end_bio_extent_readpage+0x412/0x6e0 [btrfs]
? __switch_to+0x106/0x420
process_one_work+0x1c7/0x380
worker_thread+0x4d/0x380
? rescuer_thread+0x3a0/0x3a0
kthread+0xe9/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x22/0x30
[CAUSE]
Before the BUG_ON(), we got some read errors from the replace target
first, note the mirror number (3, which is beyond RAID1 duplication,
thus it's read from the replace target device).
Then at the BUG_ON() location, we are trying to writeback the repaired
sectors back the failed device.
The check looks like this:
ret = btrfs_map_block(fs_info, BTRFS_MAP_WRITE, logical,
&map_length, &bioc, mirror_num);
if (ret)
goto out_counter_dec;
BUG_ON(mirror_num != bioc->mirror_num);
But inside btrfs_map_block(), we can modify bioc->mirror_num especially
for dev-replace:
if (dev_replace_is_ongoing && mirror_num == map->num_stripes + 1 &&
!need_full_stripe(op) && dev_replace->tgtdev != NULL) {
ret = get_extra_mirror_from_replace(fs_info, logical, *length,
dev_replace->srcdev->devid,
&mirror_num,
&physical_to_patch_in_first_stripe);
patch_the_first_stripe_for_dev_replace = 1;
}
Thus if we're repairing the replace target device, we're going to
trigger that BUG_ON().
But in reality, the read failure from the replace target device may be
that, our replace hasn't reached the range we're reading, thus we're
reading garbage, but with replace running, the range would be properly
filled later.
Thus in that case, we don't need to do anything but let the replace
routine to handle it.
[FIX]
Instead of a BUG_ON(), just skip the repair if we're repairing the
device replace target device.
Reported-by: 小太 <nospam(a)kota.moe>
Link: https://lore.kernel.org/linux-btrfs/CACsxjPYyJGQZ+yvjzxA1Nn2LuqkYqTCcUH43S=…
CC: stable(a)vger.kernel.org # 6.0+
Signed-off-by: Qu Wenruo <wqu(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/bio.c b/fs/btrfs/bio.c
index b8fb7ef6b520..8affc88b0e0a 100644
--- a/fs/btrfs/bio.c
+++ b/fs/btrfs/bio.c
@@ -329,7 +329,16 @@ int btrfs_repair_io_failure(struct btrfs_fs_info *fs_info, u64 ino, u64 start,
&map_length, &bioc, mirror_num);
if (ret)
goto out_counter_dec;
- BUG_ON(mirror_num != bioc->mirror_num);
+ /*
+ * This happens when dev-replace is also running, and the
+ * mirror_num indicates the dev-replace target.
+ *
+ * In this case, we don't need to do anything, as the read
+ * error just means the replace progress hasn't reached our
+ * read range, and later replace routine would handle it well.
+ */
+ if (mirror_num != bioc->mirror_num)
+ goto out_counter_dec;
}
sector = bioc->stripes[bioc->mirror_num - 1].physical >> 9;
Reitan Group or Reitangruppen is a Norwegian wholesaler and
retail franchiser. Included in its portfolio is REMA 1000, 7-
Eleven, HydroTexaco, Easy24, Narvesen, Spaceworld
anPressbyrån. The Reitan Group is owned by the Reitan Family and
led by Odd Reitan and has its headquarters at Lade Gaard at Lade
in Trondheim.
A brief introduction about our company. kindly provide us with
your 2023 catalog so we can make choices.
Your prompt response will be well appreciated.
Regards,
Kristin Genton
Oversea Marketing Manager
REMA 1000 REMA 1000 Norge
+47 24 09 85 00 Gladengveien 2, 0661, Oslo
Postboks 6428 Etterstad, 0605 Oslo
https://www.reitangruppen.no
--
Hello Dear
My name is Dr Ava Smith,a medical doctor from United States.
I have Dual citizenship which is English and French.
I will share pictures and more details about me as soon as i get
a response from you
Thanks
Ava
commit 27c0d217340e47ec995557f61423ef415afba987 upstream.
When a driver registers with a bus, it will attempt to match with every
device on the bus through the __driver_attach() function. Currently, if
the bus_type.match() function encounters an error that is not
-EPROBE_DEFER, __driver_attach() will return a negative error code, which
causes the driver registration logic to stop trying to match with the
remaining devices on the bus.
This behavior is not correct; a failure while matching a driver to a
device does not mean that the driver won't be able to match and bind
with other devices on the bus. Update the logic in __driver_attach()
to reflect this.
Fixes: 656b8035b0ee ("ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()")
Cc: stable(a)vger.kernel.org
Cc: Saravana Kannan <saravanak(a)google.com>
Signed-off-by: Isaac J. Manjarres <isaacmanjarres(a)google.com>
---
drivers/base/dd.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 10063d8a1b7d..1abd39ed3f9f 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -1068,8 +1068,12 @@ static int __driver_attach(struct device *dev, void *data)
*/
return 0;
} else if (ret < 0) {
- dev_dbg(dev, "Bus failed to match device: %d", ret);
- return ret;
+ dev_dbg(dev, "Bus failed to match device: %d\n", ret);
+ /*
+ * Driver could not match with device, but may match with
+ * another device on the bus.
+ */
+ return 0;
} /* ret > 0 means positive match */
if (driver_allows_async_probing(drv)) {
--
2.39.0.314.g84b9a713c41-goog
commit 27c0d217340e47ec995557f61423ef415afba987 upstream.
When a driver registers with a bus, it will attempt to match with every
device on the bus through the __driver_attach() function. Currently, if
the bus_type.match() function encounters an error that is not
-EPROBE_DEFER, __driver_attach() will return a negative error code, which
causes the driver registration logic to stop trying to match with the
remaining devices on the bus.
This behavior is not correct; a failure while matching a driver to a
device does not mean that the driver won't be able to match and bind
with other devices on the bus. Update the logic in __driver_attach()
to reflect this.
Fixes: 656b8035b0ee ("ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()")
Cc: stable(a)vger.kernel.org
Cc: Saravana Kannan <saravanak(a)google.com>
Signed-off-by: Isaac J. Manjarres <isaacmanjarres(a)google.com>
---
drivers/base/dd.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 63390a416b44..2dad29292487 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -902,8 +902,12 @@ static int __driver_attach(struct device *dev, void *data)
*/
return 0;
} else if (ret < 0) {
- dev_dbg(dev, "Bus failed to match device: %d", ret);
- return ret;
+ dev_dbg(dev, "Bus failed to match device: %d\n", ret);
+ /*
+ * Driver could not match with device, but may match with
+ * another device on the bus.
+ */
+ return 0;
} /* ret > 0 means positive match */
if (dev->parent && dev->bus->need_parent_lock)
--
2.39.0.314.g84b9a713c41-goog
The onboard_hub 'driver' consists of two drivers, a platform
driver and a USB driver. Currently when the onboard hub driver
is initialized it first registers the platform driver, then the
USB driver. This results in a race condition when the 'attach'
work is executed, which is scheduled when the platform device
is probed. The purpose of fhe 'attach' work is to bind elegible
USB hub devices to the onboard_hub USB driver. This fails if
the work runs before the USB driver has been registered.
Register the USB driver first, then the platform driver. This
increases the chances that the onboard_hub USB devices are probed
before their corresponding platform device, which the USB driver
tries to locate in _probe(). The driver already handles this
situation and defers probing if the onboard hub platform device
doesn't exist yet.
Cc: stable(a)vger.kernel.org
Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver")
Link: https://lore.kernel.org/lkml/Y6W00vQm3jfLflUJ@hovoldconsulting.com/T/#m0d64…
Reported-by: Alexander Stein <alexander.stein(a)ew.tq-group.com>
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
---
drivers/usb/misc/onboard_usb_hub.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c
index 94e7966e199d..db0844b30bbd 100644
--- a/drivers/usb/misc/onboard_usb_hub.c
+++ b/drivers/usb/misc/onboard_usb_hub.c
@@ -433,13 +433,13 @@ static int __init onboard_hub_init(void)
{
int ret;
- ret = platform_driver_register(&onboard_hub_driver);
+ ret = usb_register_device_driver(&onboard_hub_usbdev_driver, THIS_MODULE);
if (ret)
return ret;
- ret = usb_register_device_driver(&onboard_hub_usbdev_driver, THIS_MODULE);
+ ret = platform_driver_register(&onboard_hub_driver);
if (ret)
- platform_driver_unregister(&onboard_hub_driver);
+ usb_deregister_device_driver(&onboard_hub_usbdev_driver);
return ret;
}
--
2.39.0.314.g84b9a713c41-goog
The patch titled
Subject: mm/cma.c: delete kmemleak objects when freeing CMA areas to buddy at boot
has been added to the -mm mm-unstable branch. Its filename is
mm-cmac-delete-kmemleak-objects-when-freeing-cma-areas-to-buddy-at-boot.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: "Isaac J. Manjarres" <isaacmanjarres(a)google.com>
Subject: mm/cma.c: delete kmemleak objects when freeing CMA areas to buddy at boot
Date: Mon, 9 Jan 2023 14:16:23 -0800
Since every CMA region is now tracked by kmemleak at the time
cma_activate_area() is invoked, and cma_activate_area() is called for each
CMA region, invoke kmemleak_free_part_phys() during cma_activate_area() to
inform kmemleak that the CMA region will be freed. Doing so also removes
the need to invoke kmemleak_ignore_phys() when the global CMA region is
being created, as the kmemleak object for it will be deleted.
This helps resolve a crash when kmemleak and CONFIG_DEBUG_PAGEALLOC are
both enabled, since CONFIG_DEBUG_PAGEALLOC causes the CMA region to be
unmapped from the kernel's address space when the pages are freed to
buddy. Without this patch, kmemleak will attempt to scan the CMA regions,
even though they are unmapped, which leads to a page-fault.
Link: https://lkml.kernel.org/r/20230109221624.592315-3-isaacmanjarres@google.com
Signed-off-by: Isaac J. Manjarres <isaacmanjarres(a)google.com>
Cc: Isaac J. Manjarres <isaacmanjarres(a)google.com>
Cc: Saravana Kannan <saravanak(a)google.com>
Cc: Suren Baghdasaryan <surenb(a)google.com>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/cma.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/mm/cma.c~mm-cmac-delete-kmemleak-objects-when-freeing-cma-areas-to-buddy-at-boot
+++ a/mm/cma.c
@@ -103,6 +103,13 @@ static void __init cma_activate_area(str
goto out_error;
/*
+ * The CMA region was marked as allocated by kmemleak when it was either
+ * dynamically allocated or statically reserved. In any case,
+ * inform kmemleak that the region is about to be freed to the page allocator.
+ */
+ kmemleak_free_part_phys(cma_get_base(cma), cma_get_size(cma));
+
+ /*
* alloc_contig_range() requires the pfn range specified to be in the
* same zone. Simplify by forcing the entire CMA resv range to be in the
* same zone.
@@ -361,11 +368,6 @@ int __init cma_declare_contiguous_nid(ph
}
}
- /*
- * kmemleak scans/reads tracked objects for pointers to other
- * objects but this address isn't mapped and accessible
- */
- kmemleak_ignore_phys(addr);
base = addr;
}
_
Patches currently in -mm which might be from isaacmanjarres(a)google.com are
mm-cmac-make-kmemleak-aware-of-all-cma-regions.patch
mm-cmac-delete-kmemleak-objects-when-freeing-cma-areas-to-buddy-at-boot.patch
The patch titled
Subject: mm/cma.c: make kmemleak aware of all CMA regions
has been added to the -mm mm-unstable branch. Its filename is
mm-cmac-make-kmemleak-aware-of-all-cma-regions.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: "Isaac J. Manjarres" <isaacmanjarres(a)google.com>
Subject: mm/cma.c: make kmemleak aware of all CMA regions
Date: Mon, 9 Jan 2023 14:16:22 -0800
Patch series "Fixes for kmemleak tracking with CMA regions".
When trying to boot a device with an ARM64 kernel with the following
config options enabled:
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y
CONFIG_DEBUG_KMEMLEAK=y
a page-fault is encountered when kmemleak starts to scan the list of gray
or allocated objects that it maintains. Upon closer inspection, it was
observed that these page-faults always occurred when kmemleak attempted to
scan a CMA region.
At the moment, kmemleak is made aware of CMA regions that are specified
through the devicetree to be created at specific memory addresses or
dynamically allocated within a range of addresses. However, if the CMA
region is constrained to a certain range of addresses through the command
line, the region is reserved through the memblock_reserve() function, but
kmemleak_alloc_phys() is not invoked. Furthermore, kmemleak is never
informed about CMA regions being freed to buddy at boot, which is
problematic when CONFIG_DEBUG_PAGEALLOC is enabled, as all CMA regions are
unmapped from the kernel's address space, and subsequently causes a
page-fault when kmemleak attempts to scan any of them.
This series makes it so that kmemleak is aware of every CMA region before
they are freed to the buddy allocator, so that at that time, kmemleak can
be informed that each region is about to be freed, and thus it should not
attempt to scan those regions.
This patch (of 2):
Currently, kmemleak tracks CMA regions that are specified through the
devicetree. However, if the global CMA region is specified through the
commandline, kmemleak will be unaware of the CMA region because
kmemleak_alloc_phys() is not invoked after memblock_reserve(). Add the
missing call to kmemleak_alloc_phys() so that all CMA regions are tracked
by kmemleak before they are freed to the page allocator in
cma_activate_area().
Link: https://lkml.kernel.org/r/20230109221624.592315-1-isaacmanjarres@google.com
Link: https://lkml.kernel.org/r/20230109221624.592315-2-isaacmanjarres@google.com
Signed-off-by: Isaac J. Manjarres <isaacmanjarres(a)google.com>
Cc: <stable(a)vger.kernel.org>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: Saravana Kannan <saravanak(a)google.com>
Cc: Suren Baghdasaryan <surenb(a)google.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/cma.c | 2 ++
1 file changed, 2 insertions(+)
--- a/mm/cma.c~mm-cmac-make-kmemleak-aware-of-all-cma-regions
+++ a/mm/cma.c
@@ -318,6 +318,8 @@ int __init cma_declare_contiguous_nid(ph
ret = -EBUSY;
goto err;
}
+
+ kmemleak_alloc_phys(base, size, 0);
} else {
phys_addr_t addr = 0;
_
Patches currently in -mm which might be from isaacmanjarres(a)google.com are
mm-cmac-make-kmemleak-aware-of-all-cma-regions.patch
mm-cmac-delete-kmemleak-objects-when-freeing-cma-areas-to-buddy-at-boot.patch
The patch titled
Subject: nommu: fix split_vma() map_count error
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
nommu-fix-split_vma-map_count-error.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Liam Howlett <liam.howlett(a)oracle.com>
Subject: nommu: fix split_vma() map_count error
Date: Mon, 9 Jan 2023 20:58:20 +0000
During the maple tree conversion of nommu, an error in counting the VMAs
was introduced by counting the existing VMA again. The counting used to
be decremented by one and incremented by two, but now it only increments
by two. Fix the counting error by moving the increment outside the
setup_vma_to_mm() function to the callers.
Link: https://lkml.kernel.org/r/20230109205809.956325-1-Liam.Howlett@oracle.com
Fixes: 8220543df148 ("nommu: remove uses of VMA linked list")
Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Yu Zhao <yuzhao(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/nommu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/mm/nommu.c~nommu-fix-split_vma-map_count-error
+++ a/mm/nommu.c
@@ -559,7 +559,6 @@ void vma_mas_remove(struct vm_area_struc
static void setup_vma_to_mm(struct vm_area_struct *vma, struct mm_struct *mm)
{
- mm->map_count++;
vma->vm_mm = mm;
/* add the VMA to the mapping */
@@ -587,6 +586,7 @@ static void mas_add_vma_to_mm(struct ma_
BUG_ON(!vma->vm_region);
setup_vma_to_mm(vma, mm);
+ mm->map_count++;
/* add the VMA to the tree */
vma_mas_store(vma, mas);
@@ -1347,6 +1347,7 @@ int split_vma(struct mm_struct *mm, stru
if (vma->vm_file)
return -ENOMEM;
+ mm = vma->vm_mm;
if (mm->map_count >= sysctl_max_map_count)
return -ENOMEM;
@@ -1398,6 +1399,7 @@ int split_vma(struct mm_struct *mm, stru
mas_set_range(&mas, vma->vm_start, vma->vm_end - 1);
mas_store(&mas, vma);
vma_mas_store(new, &mas);
+ mm->map_count++;
return 0;
err_mas_preallocate:
_
Patches currently in -mm which might be from liam.howlett(a)oracle.com are
nommu-fix-memory-leak-in-do_mmap-error-path.patch
nommu-fix-do_munmap-error-path.patch
nommu-fix-split_vma-map_count-error.patch
maple_tree-remove-gfp_zero-from-kmem_cache_alloc-and-kmem_cache_alloc_bulk.patch
The patch titled
Subject: nommu: fix do_munmap() error path
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
nommu-fix-do_munmap-error-path.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Liam Howlett <liam.howlett(a)oracle.com>
Subject: nommu: fix do_munmap() error path
Date: Mon, 9 Jan 2023 20:57:21 +0000
When removing a VMA from the tree fails due to no memory, do not free the
VMA since a reference still exists.
Link: https://lkml.kernel.org/r/20230109205708.956103-1-Liam.Howlett@oracle.com
Fixes: 8220543df148 ("nommu: remove uses of VMA linked list")
Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Yu Zhao <yuzhao(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/nommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/mm/nommu.c~nommu-fix-do_munmap-error-path
+++ a/mm/nommu.c
@@ -1509,7 +1509,8 @@ int do_munmap(struct mm_struct *mm, unsi
erase_whole_vma:
if (delete_vma_from_mm(vma))
ret = -ENOMEM;
- delete_vma(mm, vma);
+ else
+ delete_vma(mm, vma);
return ret;
}
_
Patches currently in -mm which might be from liam.howlett(a)oracle.com are
nommu-fix-memory-leak-in-do_mmap-error-path.patch
nommu-fix-do_munmap-error-path.patch
nommu-fix-split_vma-map_count-error.patch
maple_tree-remove-gfp_zero-from-kmem_cache_alloc-and-kmem_cache_alloc_bulk.patch
The patch titled
Subject: nommu: fix memory leak in do_mmap() error path
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
nommu-fix-memory-leak-in-do_mmap-error-path.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Liam Howlett <liam.howlett(a)oracle.com>
Subject: nommu: fix memory leak in do_mmap() error path
Date: Mon, 9 Jan 2023 20:55:21 +0000
The preallocation of the maple tree nodes may leak if the error path to
"error_just_free" is taken. Fix this by moving the freeing of the maple
tree nodes to a shared location for all error paths.
Link: https://lkml.kernel.org/r/20230109205507.955577-1-Liam.Howlett@oracle.com
Fixes: 8220543df148 ("nommu: remove uses of VMA linked list")
Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Yu Zhao <yuzhao(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/nommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/nommu.c~nommu-fix-memory-leak-in-do_mmap-error-path
+++ a/mm/nommu.c
@@ -1240,6 +1240,7 @@ share:
error_just_free:
up_write(&nommu_region_sem);
error:
+ mas_destroy(&mas);
if (region->vm_file)
fput(region->vm_file);
kmem_cache_free(vm_region_jar, region);
@@ -1250,7 +1251,6 @@ error:
sharing_violation:
up_write(&nommu_region_sem);
- mas_destroy(&mas);
pr_warn("Attempt to share mismatched mappings\n");
ret = -EINVAL;
goto error;
_
Patches currently in -mm which might be from liam.howlett(a)oracle.com are
nommu-fix-memory-leak-in-do_mmap-error-path.patch
nommu-fix-do_munmap-error-path.patch
nommu-fix-split_vma-map_count-error.patch
maple_tree-remove-gfp_zero-from-kmem_cache_alloc-and-kmem_cache_alloc_bulk.patch
Since every CMA region is now tracked by kmemleak at the time
cma_activate_area() is invoked, and cma_activate_area() is called
for each CMA region, invoke kmemleak_free_part_phys() during
cma_activate_area() to inform kmemleak that the CMA region will
be freed. Doing so also removes the need to invoke
kmemleak_ignore_phys() when the global CMA region is being created,
as the kmemleak object for it will be deleted.
This helps resolve a crash when kmemleak and CONFIG_DEBUG_PAGEALLOC
are both enabled, since CONFIG_DEBUG_PAGEALLOC causes the CMA region
to be unmapped from the kernel's address space when the pages are freed
to buddy. Without this patch, kmemleak will attempt to scan the CMA
regions, even though they are unmapped, which leads to a page-fault.
Cc: stable(a)vger.kernel.org
Signed-off-by: Isaac J. Manjarres <isaacmanjarres(a)google.com>
---
mm/cma.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/mm/cma.c b/mm/cma.c
index 674b7fdd563e..dd25b095d9ca 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -102,6 +102,13 @@ static void __init cma_activate_area(struct cma *cma)
if (!cma->bitmap)
goto out_error;
+ /*
+ * The CMA region was marked as allocated by kmemleak when it was either
+ * dynamically allocated or statically reserved. In any case,
+ * inform kmemleak that the region is about to be freed to the page allocator.
+ */
+ kmemleak_free_part_phys(cma_get_base(cma), cma_get_size(cma));
+
/*
* alloc_contig_range() requires the pfn range specified to be in the
* same zone. Simplify by forcing the entire CMA resv range to be in the
@@ -361,11 +368,6 @@ int __init cma_declare_contiguous_nid(phys_addr_t base,
}
}
- /*
- * kmemleak scans/reads tracked objects for pointers to other
- * objects but this address isn't mapped and accessible
- */
- kmemleak_ignore_phys(addr);
base = addr;
}
--
2.39.0.314.g84b9a713c41-goog
Currently, kmemleak tracks CMA regions that are specified through the
devicetree. However, if the global CMA region is specified through
the commandline, kmemleak will be unaware of the CMA region because
kmemleak_alloc_phys() is not invoked after memblock_reserve(). Add
the missing call to kmemleak_alloc_phys() so that all CMA regions are
tracked by kmemleak before they are freed to the page allocator in
cma_activate_area().
Cc: stable(a)vger.kernel.org
Signed-off-by: Isaac J. Manjarres <isaacmanjarres(a)google.com>
---
mm/cma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c
index 4a978e09547a..674b7fdd563e 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -318,6 +318,8 @@ int __init cma_declare_contiguous_nid(phys_addr_t base,
ret = -EBUSY;
goto err;
}
+
+ kmemleak_alloc_phys(base, size, 0);
} else {
phys_addr_t addr = 0;
--
2.39.0.314.g84b9a713c41-goog
Hi Greg,
What follows is backports of the upstream commits
6a877d2450ac x86/fpu: Take task_struct* in copy_sigframe_from_user_to_xstate()
1c813ce03055 x86/fpu: Add a pkru argument to copy_uabi_from_kernel_to_xstate().
2c87767c35ee x86/fpu: Add a pkru argument to copy_uabi_to_xstate()
4a804c4f8356 x86/fpu: Allow PKRU to be (once again) written by ptrace.
d7e5aceace51 x86/fpu: Emulate XRSTOR's behavior if the xfeatures PKRU bit is not set
6ea25770b043 selftests/vm/pkeys: Add a regression test for setting PKRU through ptrace
Those commits fix a regression introduced in 5.14 (by e84ba47e313d) related to
handling of PKRU through ptrace(2).
The only substantive difference between this patch series and the upstream
patch series is that, because on upstream kernels KVM also calls into
copy_uabi_to_xstate(), while on 5.15 KVM has its own separate code path,
this patch series copies (five lines of) previously KVM-specific code into
copy_uabi_to_xstate() whereas the upstream patch series moves previously
KVM-specific code into copy_uabi_to_xstate(). All other changes are
adjustments for context that varies or refactorings that are newer than 5.15.
During the maple tree conversion of nommu, an error in counting the VMAs
was introduced by counting the existing VMA again. The counting used to
be decremented by one and incremented by two, but now it only increments
by two. Fix the counting error by moving the increment outside the
setup_vma_to_mm() function to the callers.
Fixes: 8220543df148 ("nommu: remove uses of VMA linked list")
Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
---
mm/nommu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 844af5be7640..5b83938ecb67 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -559,7 +559,6 @@ void vma_mas_remove(struct vm_area_struct *vma, struct ma_state *mas)
static void setup_vma_to_mm(struct vm_area_struct *vma, struct mm_struct *mm)
{
- mm->map_count++;
vma->vm_mm = mm;
/* add the VMA to the mapping */
@@ -587,6 +586,7 @@ static void mas_add_vma_to_mm(struct ma_state *mas, struct mm_struct *mm,
BUG_ON(!vma->vm_region);
setup_vma_to_mm(vma, mm);
+ mm->map_count++;
/* add the VMA to the tree */
vma_mas_store(vma, mas);
@@ -1347,6 +1347,7 @@ int split_vma(struct mm_struct *mm, struct vm_area_struct *vma,
if (vma->vm_file)
return -ENOMEM;
+ mm = vma->vm_mm;
if (mm->map_count >= sysctl_max_map_count)
return -ENOMEM;
@@ -1398,6 +1399,7 @@ int split_vma(struct mm_struct *mm, struct vm_area_struct *vma,
mas_set_range(&mas, vma->vm_start, vma->vm_end - 1);
mas_store(&mas, vma);
vma_mas_store(new, &mas);
+ mm->map_count++;
return 0;
err_mas_preallocate:
--
2.35.1
When removing a VMA from the tree fails due to no memory, do not free
the VMA since a reference still exists.
Fixes: 8220543df148 ("nommu: remove uses of VMA linked list")
Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
---
mm/nommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index c8252f01d5db..844af5be7640 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1509,7 +1509,8 @@ int do_munmap(struct mm_struct *mm, unsigned long start, size_t len, struct list
erase_whole_vma:
if (delete_vma_from_mm(vma))
ret = -ENOMEM;
- delete_vma(mm, vma);
+ else
+ delete_vma(mm, vma);
return ret;
}
--
2.35.1
The preallocation of the maple tree nodes may leak if the error path to
"error_just_free" is taken. Fix this by moving the freeing of the maple
tree nodes to a shared location for all error paths.
Fixes: 8220543df148 ("nommu: remove uses of VMA linked list")
Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
---
mm/nommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 214c70e1d059..c8252f01d5db 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1240,6 +1240,7 @@ unsigned long do_mmap(struct file *file,
error_just_free:
up_write(&nommu_region_sem);
error:
+ mas_destroy(&mas);
if (region->vm_file)
fput(region->vm_file);
kmem_cache_free(vm_region_jar, region);
@@ -1250,7 +1251,6 @@ unsigned long do_mmap(struct file *file,
sharing_violation:
up_write(&nommu_region_sem);
- mas_destroy(&mas);
pr_warn("Attempt to share mismatched mappings\n");
ret = -EINVAL;
goto error;
--
2.35.1
Greetings and the peace of the Lord be with you. I send this message
with a painful and broken heart. please get back to me as soon as
possible. I have a there is a confidential matter to be discussed with
you. Regards
commit c72a7e42592b2e18d862cf120876070947000d7a upstream.
This patch fixes the error "ravb 11c20000.ethernet eth0: failed to switch
device to config mode" during unbind.
We are doing register access after pm_runtime_put_sync().
We usually do cleanup in reverse order of init. Currently in
remove(), the "pm_runtime_put_sync" is not in reverse order.
Probe
reset_control_deassert(rstc);
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
remove
pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
..
ravb_mdio_release(priv);
pm_runtime_disable(&pdev->dev);
Consider the call to unregister_netdev()
unregister_netdev->unregister_netdevice_queue->rollback_registered_many
that calls the below functions which access the registers after
pm_runtime_put_sync()
1) ravb_get_stats
2) ravb_close
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Cc: stable(a)vger.kernel.org # 4.9.y
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com>
Link: https://lore.kernel.org/r/20221214105118.2495313-1-biju.das.jz@bp.renesas.c…
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
[biju: cherry-picked from 6.0 stable]
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
---
Resending to 4.9 with confilcts[1] fixed
[1] https://lore.kernel.org/stable/1672841813129164@kroah.com/
---
drivers/net/ethernet/renesas/ravb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 2bebf39fe047..eeb8005d75d0 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2129,11 +2129,11 @@ static int ravb_remove(struct platform_device *pdev)
priv->desc_bat_dma);
/* Set reset mode */
ravb_write(ndev, CCC_OPC_RESET, CCC);
- pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
netif_napi_del(&priv->napi[RAVB_NC]);
netif_napi_del(&priv->napi[RAVB_BE]);
ravb_mdio_release(priv);
+ pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
free_netdev(ndev);
platform_set_drvdata(pdev, NULL);
--
2.25.1
commit c72a7e42592b2e18d862cf120876070947000d7a upstream.
This patch fixes the error "ravb 11c20000.ethernet eth0: failed to switch
device to config mode" during unbind.
We are doing register access after pm_runtime_put_sync().
We usually do cleanup in reverse order of init. Currently in
remove(), the "pm_runtime_put_sync" is not in reverse order.
Probe
reset_control_deassert(rstc);
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
remove
pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
..
ravb_mdio_release(priv);
pm_runtime_disable(&pdev->dev);
Consider the call to unregister_netdev()
unregister_netdev->unregister_netdevice_queue->rollback_registered_many
that calls the below functions which access the registers after
pm_runtime_put_sync()
1) ravb_get_stats
2) ravb_close
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Cc: stable(a)vger.kernel.org # 4.14.y
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com>
Link: https://lore.kernel.org/r/20221214105118.2495313-1-biju.das.jz@bp.renesas.c…
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
[biju: cherry-picked from 6.0 stable]
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
---
Resending to 4.14 with confilcts[1] fixed
[1] https://lore.kernel.org/stable/16728418126244@kroah.com/
---
drivers/net/ethernet/renesas/ravb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 5513475e2a82..4c8a4e6efb9f 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2195,11 +2195,11 @@ static int ravb_remove(struct platform_device *pdev)
priv->desc_bat_dma);
/* Set reset mode */
ravb_write(ndev, CCC_OPC_RESET, CCC);
- pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
netif_napi_del(&priv->napi[RAVB_NC]);
netif_napi_del(&priv->napi[RAVB_BE]);
ravb_mdio_release(priv);
+ pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
free_netdev(ndev);
platform_set_drvdata(pdev, NULL);
--
2.25.1
commit c72a7e42592b2e18d862cf120876070947000d7a upstream.
This patch fixes the error "ravb 11c20000.ethernet eth0: failed to switch
device to config mode" during unbind.
We are doing register access after pm_runtime_put_sync().
We usually do cleanup in reverse order of init. Currently in
remove(), the "pm_runtime_put_sync" is not in reverse order.
Probe
reset_control_deassert(rstc);
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
remove
pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
..
ravb_mdio_release(priv);
pm_runtime_disable(&pdev->dev);
Consider the call to unregister_netdev()
unregister_netdev->unregister_netdevice_queue->rollback_registered_many
that calls the below functions which access the registers after
pm_runtime_put_sync()
1) ravb_get_stats
2) ravb_close
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Cc: stable(a)vger.kernel.org # 4.19.y
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com>
Link: https://lore.kernel.org/r/20221214105118.2495313-1-biju.das.jz@bp.renesas.c…
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
[biju: cherry-picked from 6.0 stable]
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
---
Resending to 4.19 with confilcts[1] fixed
[1] https://lore.kernel.org/stable/1672841811246154@kroah.com/
---
drivers/net/ethernet/renesas/ravb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 9077014f6f40..ff374d0d80a7 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2199,11 +2199,11 @@ static int ravb_remove(struct platform_device *pdev)
priv->desc_bat_dma);
/* Set reset mode */
ravb_write(ndev, CCC_OPC_RESET, CCC);
- pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
netif_napi_del(&priv->napi[RAVB_NC]);
netif_napi_del(&priv->napi[RAVB_BE]);
ravb_mdio_release(priv);
+ pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
free_netdev(ndev);
platform_set_drvdata(pdev, NULL);
--
2.25.1
commit c72a7e42592b2e18d862cf120876070947000d7a upstream.
This patch fixes the error "ravb 11c20000.ethernet eth0: failed to switch
device to config mode" during unbind.
We are doing register access after pm_runtime_put_sync().
We usually do cleanup in reverse order of init. Currently in
remove(), the "pm_runtime_put_sync" is not in reverse order.
Probe
reset_control_deassert(rstc);
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
remove
pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
..
ravb_mdio_release(priv);
pm_runtime_disable(&pdev->dev);
Consider the call to unregister_netdev()
unregister_netdev->unregister_netdevice_queue->rollback_registered_many
that calls the below functions which access the registers after
pm_runtime_put_sync()
1) ravb_get_stats
2) ravb_close
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Cc: stable(a)vger.kernel.org # 5.4.y
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com>
Link: https://lore.kernel.org/r/20221214105118.2495313-1-biju.das.jz@bp.renesas.c…
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
[biju: cherry-picked from 6.0 stable]
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
---
Resending to 5.4 with confilcts[1] fixed
[1] https://lore.kernel.org/stable/1672841810167252@kroah.com/
---
drivers/net/ethernet/renesas/ravb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 95fd1f2d5439..3fd5155bdd5f 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2216,11 +2216,11 @@ static int ravb_remove(struct platform_device *pdev)
priv->desc_bat_dma);
/* Set reset mode */
ravb_write(ndev, CCC_OPC_RESET, CCC);
- pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
netif_napi_del(&priv->napi[RAVB_NC]);
netif_napi_del(&priv->napi[RAVB_BE]);
ravb_mdio_release(priv);
+ pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
free_netdev(ndev);
platform_set_drvdata(pdev, NULL);
--
2.25.1
commit c72a7e42592b2e18d862cf120876070947000d7a upstream.
This patch fixes the error "ravb 11c20000.ethernet eth0: failed to switch
device to config mode" during unbind.
We are doing register access after pm_runtime_put_sync().
We usually do cleanup in reverse order of init. Currently in
remove(), the "pm_runtime_put_sync" is not in reverse order.
Probe
reset_control_deassert(rstc);
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
remove
pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
..
ravb_mdio_release(priv);
pm_runtime_disable(&pdev->dev);
Consider the call to unregister_netdev()
unregister_netdev->unregister_netdevice_queue->rollback_registered_many
that calls the below functions which access the registers after
pm_runtime_put_sync()
1) ravb_get_stats
2) ravb_close
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Cc: stable(a)vger.kernel.org # 5.10.y
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com>
Link: https://lore.kernel.org/r/20221214105118.2495313-1-biju.das.jz@bp.renesas.c…
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
[biju: cherry-picked from 6.0 stable]
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
---
Resending to 5.10 with confilcts[1] fixed
[1] https://lore.kernel.org/stable/1672841808222172@kroah.com/
---
drivers/net/ethernet/renesas/ravb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 9e7b85e178fd..9ec6d63691aa 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2253,11 +2253,11 @@ static int ravb_remove(struct platform_device *pdev)
priv->desc_bat_dma);
/* Set reset mode */
ravb_write(ndev, CCC_OPC_RESET, CCC);
- pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
netif_napi_del(&priv->napi[RAVB_NC]);
netif_napi_del(&priv->napi[RAVB_BE]);
ravb_mdio_release(priv);
+ pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
free_netdev(ndev);
platform_set_drvdata(pdev, NULL);
--
2.25.1
commit c72a7e42592b2e18d862cf120876070947000d7a upstream.
This patch fixes the error "ravb 11c20000.ethernet eth0: failed to switch
device to config mode" during unbind.
We are doing register access after pm_runtime_put_sync().
We usually do cleanup in reverse order of init. Currently in
remove(), the "pm_runtime_put_sync" is not in reverse order.
Probe
reset_control_deassert(rstc);
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
remove
pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
..
ravb_mdio_release(priv);
pm_runtime_disable(&pdev->dev);
Consider the call to unregister_netdev()
unregister_netdev->unregister_netdevice_queue->rollback_registered_many
that calls the below functions which access the registers after
pm_runtime_put_sync()
1) ravb_get_stats
2) ravb_close
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Cc: stable(a)vger.kernel.org # 5.15.y
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com>
Link: https://lore.kernel.org/r/20221214105118.2495313-1-biju.das.jz@bp.renesas.c…
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
[biju: cherry-picked from 6.0 stable]
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
---
Resending to 5.15 with confilcts[1] fixed
[1] https://lore.kernel.org/stable/167284180749230@kroah.com/
---
drivers/net/ethernet/renesas/ravb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 77a19336abec..c89bcdd15f16 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2378,11 +2378,11 @@ static int ravb_remove(struct platform_device *pdev)
priv->desc_bat_dma);
/* Set reset mode */
ravb_write(ndev, CCC_OPC_RESET, CCC);
- pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
netif_napi_del(&priv->napi[RAVB_NC]);
netif_napi_del(&priv->napi[RAVB_BE]);
ravb_mdio_release(priv);
+ pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
reset_control_assert(priv->rstc);
free_netdev(ndev);
--
2.25.1
--
Dear Friend,
I am (George Abah) from the United Kingdom, an Executive Assistant
working with the Global Asymmetric-Chain Funding Inc. Having taken
cognizance of your profile, I would like to discuss a partnership
opportunity with you regarding Finance. If you have any viable project or
innovative Business plan with high ROI, you can as well bring them on
board as financing is also available under reasonable and considerable
terms and conditions.I look forward to your response so we can discuss for
more introduction and to have a mutual understanding.
Best Wishes
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
2ba48b20049b ("btrfs: fix compat_ro checks against remount")
d7f67ac9a928 ("btrfs: relax block-group-tree feature dependency checks")
a05d3c915314 ("btrfs: check superblock to ensure the fs was not modified at thaw time")
49f468c93807 ("btrfs: don't print 'has skinny extents' anymore on mount")
6b769dac219d ("btrfs: don't print 'flagging with big metadata' anymore on mount")
e26b04c4c919 ("btrfs: properly flag filesystem with BTRFS_FEATURE_INCOMPAT_BIG_METADATA")
dc4d31684974 ("btrfs: reject log replay if there is unsupported RO compat flag")
0591f0403621 ("btrfs: prevent remounting to v1 space cache for subpage mount")
d5321a0fa8bc ("btrfs: add "0x" prefix for unsupported optional features")
8481dd80ab1e ("btrfs: subpage: introduce btrfs_subpage_bitmap_info")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 2ba48b20049b5a76f34a85f853c9496d1b10533a Mon Sep 17 00:00:00 2001
From: Qu Wenruo <wqu(a)suse.com>
Date: Thu, 22 Dec 2022 07:59:17 +0800
Subject: [PATCH] btrfs: fix compat_ro checks against remount
[BUG]
Even with commit 81d5d61454c3 ("btrfs: enhance unsupported compat RO
flags handling"), btrfs can still mount a fs with unsupported compat_ro
flags read-only, then remount it RW:
# btrfs ins dump-super /dev/loop0 | grep compat_ro_flags -A 3
compat_ro_flags 0x403
( FREE_SPACE_TREE |
FREE_SPACE_TREE_VALID |
unknown flag: 0x400 )
# mount /dev/loop0 /mnt/btrfs
mount: /mnt/btrfs: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.
^^^ RW mount failed as expected ^^^
# dmesg -t | tail -n5
loop0: detected capacity change from 0 to 1048576
BTRFS: device fsid cb5b82f5-0fdd-4d81-9b4b-78533c324afa devid 1 transid 7 /dev/loop0 scanned by mount (1146)
BTRFS info (device loop0): using crc32c (crc32c-intel) checksum algorithm
BTRFS info (device loop0): using free space tree
BTRFS error (device loop0): cannot mount read-write because of unknown compat_ro features (0x403)
BTRFS error (device loop0): open_ctree failed
# mount /dev/loop0 -o ro /mnt/btrfs
# mount -o remount,rw /mnt/btrfs
^^^ RW remount succeeded unexpectedly ^^^
[CAUSE]
Currently we use btrfs_check_features() to check compat_ro flags against
our current mount flags.
That function get reused between open_ctree() and btrfs_remount().
But for btrfs_remount(), the super block we passed in still has the old
mount flags, thus btrfs_check_features() still believes we're mounting
read-only.
[FIX]
Replace the existing @sb argument with @is_rw_mount.
As originally we only use @sb to determine if the mount is RW.
Now it's callers' responsibility to determine if the mount is RW, and
since there are only two callers, the check is pretty simple:
- caller in open_ctree()
Just pass !sb_rdonly().
- caller in btrfs_remount()
Pass !(*flags & SB_RDONLY), as our check should be against the new
flags.
Now we can correctly reject the RW remount:
# mount /dev/loop0 -o ro /mnt/btrfs
# mount -o remount,rw /mnt/btrfs
mount: /mnt/btrfs: mount point not mounted or bad option.
dmesg(1) may have more information after failed mount system call.
# dmesg -t | tail -n 1
BTRFS error (device loop0: state M): cannot mount read-write because of unknown compat_ro features (0x403)
Reported-by: Chung-Chiang Cheng <shepjeng(a)gmail.com>
Fixes: 81d5d61454c3 ("btrfs: enhance unsupported compat RO flags handling")
CC: stable(a)vger.kernel.org # 5.15+
Reviewed-by: Anand Jain <anand.jain(a)oracle.com>
Signed-off-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 9940cc39dbc9..8aeaada1fcae 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3384,6 +3384,8 @@ int btrfs_start_pre_rw_mount(struct btrfs_fs_info *fs_info)
/*
* Do various sanity and dependency checks of different features.
*
+ * @is_rw_mount: If the mount is read-write.
+ *
* This is the place for less strict checks (like for subpage or artificial
* feature dependencies).
*
@@ -3394,7 +3396,7 @@ int btrfs_start_pre_rw_mount(struct btrfs_fs_info *fs_info)
* (space cache related) can modify on-disk format like free space tree and
* screw up certain feature dependencies.
*/
-int btrfs_check_features(struct btrfs_fs_info *fs_info, struct super_block *sb)
+int btrfs_check_features(struct btrfs_fs_info *fs_info, bool is_rw_mount)
{
struct btrfs_super_block *disk_super = fs_info->super_copy;
u64 incompat = btrfs_super_incompat_flags(disk_super);
@@ -3433,7 +3435,7 @@ int btrfs_check_features(struct btrfs_fs_info *fs_info, struct super_block *sb)
if (btrfs_super_nodesize(disk_super) > PAGE_SIZE)
incompat |= BTRFS_FEATURE_INCOMPAT_BIG_METADATA;
- if (compat_ro_unsupp && !sb_rdonly(sb)) {
+ if (compat_ro_unsupp && is_rw_mount) {
btrfs_err(fs_info,
"cannot mount read-write because of unknown compat_ro features (0x%llx)",
compat_ro);
@@ -3636,7 +3638,7 @@ int __cold open_ctree(struct super_block *sb, struct btrfs_fs_devices *fs_device
goto fail_alloc;
}
- ret = btrfs_check_features(fs_info, sb);
+ ret = btrfs_check_features(fs_info, !sb_rdonly(sb));
if (ret < 0) {
err = ret;
goto fail_alloc;
diff --git a/fs/btrfs/disk-io.h b/fs/btrfs/disk-io.h
index 363935cfc084..f2f295eb6103 100644
--- a/fs/btrfs/disk-io.h
+++ b/fs/btrfs/disk-io.h
@@ -50,7 +50,7 @@ int __cold open_ctree(struct super_block *sb,
void __cold close_ctree(struct btrfs_fs_info *fs_info);
int btrfs_validate_super(struct btrfs_fs_info *fs_info,
struct btrfs_super_block *sb, int mirror_num);
-int btrfs_check_features(struct btrfs_fs_info *fs_info, struct super_block *sb);
+int btrfs_check_features(struct btrfs_fs_info *fs_info, bool is_rw_mount);
int write_all_supers(struct btrfs_fs_info *fs_info, int max_mirrors);
struct btrfs_super_block *btrfs_read_dev_super(struct block_device *bdev);
struct btrfs_super_block *btrfs_read_dev_one_super(struct block_device *bdev,
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index d5de18d6517e..433ce221dc5c 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1705,7 +1705,7 @@ static int btrfs_remount(struct super_block *sb, int *flags, char *data)
if (ret)
goto restore;
- ret = btrfs_check_features(fs_info, sb);
+ ret = btrfs_check_features(fs_info, !(*flags & SB_RDONLY));
if (ret < 0)
goto restore;
The patch below does not apply to the 6.0-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
2ba48b20049b ("btrfs: fix compat_ro checks against remount")
d7f67ac9a928 ("btrfs: relax block-group-tree feature dependency checks")
a05d3c915314 ("btrfs: check superblock to ensure the fs was not modified at thaw time")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 2ba48b20049b5a76f34a85f853c9496d1b10533a Mon Sep 17 00:00:00 2001
From: Qu Wenruo <wqu(a)suse.com>
Date: Thu, 22 Dec 2022 07:59:17 +0800
Subject: [PATCH] btrfs: fix compat_ro checks against remount
[BUG]
Even with commit 81d5d61454c3 ("btrfs: enhance unsupported compat RO
flags handling"), btrfs can still mount a fs with unsupported compat_ro
flags read-only, then remount it RW:
# btrfs ins dump-super /dev/loop0 | grep compat_ro_flags -A 3
compat_ro_flags 0x403
( FREE_SPACE_TREE |
FREE_SPACE_TREE_VALID |
unknown flag: 0x400 )
# mount /dev/loop0 /mnt/btrfs
mount: /mnt/btrfs: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.
^^^ RW mount failed as expected ^^^
# dmesg -t | tail -n5
loop0: detected capacity change from 0 to 1048576
BTRFS: device fsid cb5b82f5-0fdd-4d81-9b4b-78533c324afa devid 1 transid 7 /dev/loop0 scanned by mount (1146)
BTRFS info (device loop0): using crc32c (crc32c-intel) checksum algorithm
BTRFS info (device loop0): using free space tree
BTRFS error (device loop0): cannot mount read-write because of unknown compat_ro features (0x403)
BTRFS error (device loop0): open_ctree failed
# mount /dev/loop0 -o ro /mnt/btrfs
# mount -o remount,rw /mnt/btrfs
^^^ RW remount succeeded unexpectedly ^^^
[CAUSE]
Currently we use btrfs_check_features() to check compat_ro flags against
our current mount flags.
That function get reused between open_ctree() and btrfs_remount().
But for btrfs_remount(), the super block we passed in still has the old
mount flags, thus btrfs_check_features() still believes we're mounting
read-only.
[FIX]
Replace the existing @sb argument with @is_rw_mount.
As originally we only use @sb to determine if the mount is RW.
Now it's callers' responsibility to determine if the mount is RW, and
since there are only two callers, the check is pretty simple:
- caller in open_ctree()
Just pass !sb_rdonly().
- caller in btrfs_remount()
Pass !(*flags & SB_RDONLY), as our check should be against the new
flags.
Now we can correctly reject the RW remount:
# mount /dev/loop0 -o ro /mnt/btrfs
# mount -o remount,rw /mnt/btrfs
mount: /mnt/btrfs: mount point not mounted or bad option.
dmesg(1) may have more information after failed mount system call.
# dmesg -t | tail -n 1
BTRFS error (device loop0: state M): cannot mount read-write because of unknown compat_ro features (0x403)
Reported-by: Chung-Chiang Cheng <shepjeng(a)gmail.com>
Fixes: 81d5d61454c3 ("btrfs: enhance unsupported compat RO flags handling")
CC: stable(a)vger.kernel.org # 5.15+
Reviewed-by: Anand Jain <anand.jain(a)oracle.com>
Signed-off-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 9940cc39dbc9..8aeaada1fcae 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3384,6 +3384,8 @@ int btrfs_start_pre_rw_mount(struct btrfs_fs_info *fs_info)
/*
* Do various sanity and dependency checks of different features.
*
+ * @is_rw_mount: If the mount is read-write.
+ *
* This is the place for less strict checks (like for subpage or artificial
* feature dependencies).
*
@@ -3394,7 +3396,7 @@ int btrfs_start_pre_rw_mount(struct btrfs_fs_info *fs_info)
* (space cache related) can modify on-disk format like free space tree and
* screw up certain feature dependencies.
*/
-int btrfs_check_features(struct btrfs_fs_info *fs_info, struct super_block *sb)
+int btrfs_check_features(struct btrfs_fs_info *fs_info, bool is_rw_mount)
{
struct btrfs_super_block *disk_super = fs_info->super_copy;
u64 incompat = btrfs_super_incompat_flags(disk_super);
@@ -3433,7 +3435,7 @@ int btrfs_check_features(struct btrfs_fs_info *fs_info, struct super_block *sb)
if (btrfs_super_nodesize(disk_super) > PAGE_SIZE)
incompat |= BTRFS_FEATURE_INCOMPAT_BIG_METADATA;
- if (compat_ro_unsupp && !sb_rdonly(sb)) {
+ if (compat_ro_unsupp && is_rw_mount) {
btrfs_err(fs_info,
"cannot mount read-write because of unknown compat_ro features (0x%llx)",
compat_ro);
@@ -3636,7 +3638,7 @@ int __cold open_ctree(struct super_block *sb, struct btrfs_fs_devices *fs_device
goto fail_alloc;
}
- ret = btrfs_check_features(fs_info, sb);
+ ret = btrfs_check_features(fs_info, !sb_rdonly(sb));
if (ret < 0) {
err = ret;
goto fail_alloc;
diff --git a/fs/btrfs/disk-io.h b/fs/btrfs/disk-io.h
index 363935cfc084..f2f295eb6103 100644
--- a/fs/btrfs/disk-io.h
+++ b/fs/btrfs/disk-io.h
@@ -50,7 +50,7 @@ int __cold open_ctree(struct super_block *sb,
void __cold close_ctree(struct btrfs_fs_info *fs_info);
int btrfs_validate_super(struct btrfs_fs_info *fs_info,
struct btrfs_super_block *sb, int mirror_num);
-int btrfs_check_features(struct btrfs_fs_info *fs_info, struct super_block *sb);
+int btrfs_check_features(struct btrfs_fs_info *fs_info, bool is_rw_mount);
int write_all_supers(struct btrfs_fs_info *fs_info, int max_mirrors);
struct btrfs_super_block *btrfs_read_dev_super(struct block_device *bdev);
struct btrfs_super_block *btrfs_read_dev_one_super(struct block_device *bdev,
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index d5de18d6517e..433ce221dc5c 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1705,7 +1705,7 @@ static int btrfs_remount(struct super_block *sb, int *flags, char *data)
if (ret)
goto restore;
- ret = btrfs_check_features(fs_info, sb);
+ ret = btrfs_check_features(fs_info, !(*flags & SB_RDONLY));
if (ret < 0)
goto restore;
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
c72a7e42592b ("ravb: Fix "failed to switch device to config mode" message during unbind")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From c72a7e42592b2e18d862cf120876070947000d7a Mon Sep 17 00:00:00 2001
From: Biju Das <biju.das.jz(a)bp.renesas.com>
Date: Wed, 14 Dec 2022 10:51:18 +0000
Subject: [PATCH] ravb: Fix "failed to switch device to config mode" message
during unbind
This patch fixes the error "ravb 11c20000.ethernet eth0: failed to switch
device to config mode" during unbind.
We are doing register access after pm_runtime_put_sync().
We usually do cleanup in reverse order of init. Currently in
remove(), the "pm_runtime_put_sync" is not in reverse order.
Probe
reset_control_deassert(rstc);
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
remove
pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
..
ravb_mdio_release(priv);
pm_runtime_disable(&pdev->dev);
Consider the call to unregister_netdev()
unregister_netdev->unregister_netdevice_queue->rollback_registered_many
that calls the below functions which access the registers after
pm_runtime_put_sync()
1) ravb_get_stats
2) ravb_close
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Cc: stable(a)vger.kernel.org
Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com>
Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com>
Link: https://lore.kernel.org/r/20221214105118.2495313-1-biju.das.jz@bp.renesas.c…
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 33f723a9f471..b4e0fc7f65bd 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2903,12 +2903,12 @@ static int ravb_remove(struct platform_device *pdev)
priv->desc_bat_dma);
/* Set reset mode */
ravb_write(ndev, CCC_OPC_RESET, CCC);
- pm_runtime_put_sync(&pdev->dev);
unregister_netdev(ndev);
if (info->nc_queues)
netif_napi_del(&priv->napi[RAVB_NC]);
netif_napi_del(&priv->napi[RAVB_BE]);
ravb_mdio_release(priv);
+ pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
reset_control_assert(priv->rstc);
free_netdev(ndev);
From: ChiYuan Huang <cy_huang(a)richtek.com>
There's the altmode re-registeration issue after data role
swap (DR_SWAP).
Comparing to USBPD 2.0, in USBPD 3.0, it loose the limit that only DFP
can initiate the VDM command to get partner identity information.
For a USBPD 3.0 UFP device, it may already get the identity information
from its port partner before DR_SWAP. If DR_SWAP send or receive at the
mean time, 'send_discover' flag will be raised again. It causes discover
identify action restart while entering ready state. And after all
discover actions are done, the 'tcpm_register_altmodes' will be called.
If old altmode is not unregistered, this sysfs create fail can be found.
In 'DR_SWAP_CHANGE_DR' state case, only DFP will unregister altmodes.
For UFP, the original altmodes keep registered.
This patch fix the logic that after DR_SWAP, 'tcpm_unregister_altmodes'
must be called whatever the current data role is.
Reviewed-by: Macpaul Lin <macpaul.lin(a)mediatek.com>
Fixes: ae8a2ca8a221 ("usb: typec: Group all TCPCI/TCPM code together)
Reported-by: TommyYl Chen <tommyyl.chen(a)mediatek.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: ChiYuan Huang <cy_huang(a)richtek.com>
---
Since v2:
1. Correct the mail sent from Richtek.
2. Add 'Reviewed-by' tag.
---
drivers/usb/typec/tcpm/tcpm.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 904c7b4..59b366b 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -4594,14 +4594,13 @@ static void run_state_machine(struct tcpm_port *port)
tcpm_set_state(port, ready_state(port), 0);
break;
case DR_SWAP_CHANGE_DR:
- if (port->data_role == TYPEC_HOST) {
- tcpm_unregister_altmodes(port);
+ tcpm_unregister_altmodes(port);
+ if (port->data_role == TYPEC_HOST)
tcpm_set_roles(port, true, port->pwr_role,
TYPEC_DEVICE);
- } else {
+ else
tcpm_set_roles(port, true, port->pwr_role,
TYPEC_HOST);
- }
tcpm_ams_finish(port);
tcpm_set_state(port, ready_state(port), 0);
break;
--
2.7.4
************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!
From: Qian Yingjin <qian(a)ddn.com>
I was running traces of the read code against an RAID storage
system to understand why read requests were being misaligned
against the underlying RAID strips. I found that the page end
offset calculation in filemap_get_read_batch() was off by one.
When a read is submitted with end offset 1048575, then it
calculates the end page for read of 256 when it should be 255.
"last_index" is the index of the page beyond the end of the read
and it should be skipped when get a batch of pages for read in
@filemap_get_read_batch().
The below simple patch fixes the problem. This code was introduced
in kernel 5.12.
Fixes: cbd59c48ae2b ("mm/filemap: use head pages in generic_file_buffered_read")
Signed-off-by: Qian Yingjin <qian(a)ddn.com>
---
mm/filemap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index c4d4ace9cc70..0e20a8d6dd93 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2588,18 +2588,19 @@ static int filemap_get_pages(struct kiocb *iocb, struct iov_iter *iter,
struct folio *folio;
int err = 0;
+ /* "last_index" is the index of the page beyond the end of the read */
last_index = DIV_ROUND_UP(iocb->ki_pos + iter->count, PAGE_SIZE);
retry:
if (fatal_signal_pending(current))
return -EINTR;
- filemap_get_read_batch(mapping, index, last_index, fbatch);
+ filemap_get_read_batch(mapping, index, last_index - 1, fbatch);
if (!folio_batch_count(fbatch)) {
if (iocb->ki_flags & IOCB_NOIO)
return -EAGAIN;
page_cache_sync_readahead(mapping, ra, filp, index,
last_index - index);
- filemap_get_read_batch(mapping, index, last_index, fbatch);
+ filemap_get_read_batch(mapping, index, last_index - 1, fbatch);
}
if (!folio_batch_count(fbatch)) {
if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_WAITQ))
--
2.34.1
From: ChiYuan Huang <cy_huang(a)richtek.com>
There's the altmode re-registeration issue after data role
swap (DR_SWAP).
Comparing to USBPD 2.0, in USBPD 3.0, it loose the limit that only DFP
can initiate the VDM command to get partner identity information.
For a USBPD 3.0 UFP device, it may already get the identity information
from its port partner before DR_SWAP. If DR_SWAP send or receive at the
mean time, 'send_discover' flag will be raised again. It causes discover
identify action restart while entering ready state. And after all
discover actions are done, the 'tcpm_register_altmodes' will be called.
If old altmode is not unregistered, this sysfs create fail can be found.
In 'DR_SWAP_CHANGE_DR' state case, only DFP will unregister altmodes.
For UFP, the original altmodes keep registered.
This patch fix the logic that after DR_SWAP, 'tcpm_unregister_altmodes'
must be called whatever the current data role is.
Reviewed-by: Macpaul Lin <macpaul.lin(a)mediatek.com>
Fixes: ae8a2ca8a221 ("usb: typec: Group all TCPCI/TCPM code together)
Reported-by: TommyYl Chen <tommyyl.chen(a)mediatek.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: ChiYuan Huang <cy_huang(a)richtek.com>
---
Since v2:
1. Correct the mail sent from Richtek.
2. Add 'Reviewed-by' tag.
---
drivers/usb/typec/tcpm/tcpm.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 904c7b4..59b366b 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -4594,14 +4594,13 @@ static void run_state_machine(struct tcpm_port *port)
tcpm_set_state(port, ready_state(port), 0);
break;
case DR_SWAP_CHANGE_DR:
- if (port->data_role == TYPEC_HOST) {
- tcpm_unregister_altmodes(port);
+ tcpm_unregister_altmodes(port);
+ if (port->data_role == TYPEC_HOST)
tcpm_set_roles(port, true, port->pwr_role,
TYPEC_DEVICE);
- } else {
+ else
tcpm_set_roles(port, true, port->pwr_role,
TYPEC_HOST);
- }
tcpm_ams_finish(port);
tcpm_set_state(port, ready_state(port), 0);
break;
--
2.7.4
************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!
The SID SRAM on at least some SoCs (A64 and D1) returns different values
when read with bus cycles narrower than 32 bits. This is not immediately
obvious, because memcpy_fromio() uses word-size accesses as long as
enough data is being copied.
The vendor driver always uses 32-bit MMIO reads, so do the same here.
This is faster than the register-based method, which is currently used
as a workaround on A64. And it fixes the values returned on D1, where
the SRAM method was being used.
The special case for the last word is needed to maintain .word_size == 1
for sysfs ABI compatibility, as noted previously in commit de2a3eaea552
("nvmem: sunxi_sid: Optimize register read-out method").
Cc: stable(a)vger.kernel.org
Fixes: 07ae4fde9efa ("nvmem: sunxi_sid: Add support for D1 variant")
Tested-by: Heiko Stuebner <heiko(a)sntech.de>
Signed-off-by: Samuel Holland <samuel(a)sholland.org>
---
(no changes since v1)
drivers/nvmem/sunxi_sid.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
index 5750e1f4bcdb..92dfe4cb10e3 100644
--- a/drivers/nvmem/sunxi_sid.c
+++ b/drivers/nvmem/sunxi_sid.c
@@ -41,8 +41,21 @@ static int sunxi_sid_read(void *context, unsigned int offset,
void *val, size_t bytes)
{
struct sunxi_sid *sid = context;
+ u32 word;
+
+ /* .stride = 4 so offset is guaranteed to be aligned */
+ __ioread32_copy(val, sid->base + sid->value_offset + offset, bytes / 4);
- memcpy_fromio(val, sid->base + sid->value_offset + offset, bytes);
+ val += round_down(bytes, 4);
+ offset += round_down(bytes, 4);
+ bytes = bytes % 4;
+
+ if (!bytes)
+ return 0;
+
+ /* Handle any trailing bytes */
+ word = readl_relaxed(sid->base + sid->value_offset + offset);
+ memcpy(val, &word, bytes);
return 0;
}
--
2.37.4
From: Lino Sanfilippo <l.sanfilippo(a)kunbus.com>
In RS485 mode the transmission of a high priority character fails since it
is written to the data register before the transmitter is enabled. Fix this
in pl011_tx_chars() by enabling RS485 transmission before writing the
character.
Fixes: 8d479237727c ("serial: amba-pl011: add RS485 support")
Cc: stable(a)vger.kernel.org
Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com>
---
drivers/tty/serial/amba-pl011.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index d75c39f4622b..d8c2f3455eeb 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1466,6 +1466,10 @@ static bool pl011_tx_chars(struct uart_amba_port *uap, bool from_irq)
struct circ_buf *xmit = &uap->port.state->xmit;
int count = uap->fifosize >> 1;
+ if ((uap->port.rs485.flags & SER_RS485_ENABLED) &&
+ !uap->rs485_tx_started)
+ pl011_rs485_tx_start(uap);
+
if (uap->port.x_char) {
if (!pl011_tx_char(uap, uap->port.x_char, from_irq))
return true;
@@ -1477,10 +1481,6 @@ static bool pl011_tx_chars(struct uart_amba_port *uap, bool from_irq)
return false;
}
- if ((uap->port.rs485.flags & SER_RS485_ENABLED) &&
- !uap->rs485_tx_started)
- pl011_rs485_tx_start(uap);
-
/* If we are using DMA mode, try to send some characters. */
if (pl011_dma_tx_irq(uap))
return true;
base-commit: 93928d485d9df12be724cbdf1caa7d197b65001e
--
2.39.0
Dear Sir/Madam,
An open Tender for the supply of your company products to (Doha,
Qatar). Urgently furnish us in full details about the standard of your
product. We will appreciate it more if you give us with Details:
Specification and Catalogs or Price list via Email.To avoid making a
wrong choice of products before placing an order for it.
Terms of payment:An upfront payment of 80% (T/T) will be made to your
account for production,While 20% will be paid before shipment.
Thanks and Regards
--
Hello,
I tried e-mailing you more than twice but my email bounced back
failure, Note this, soonest you receive this email revert to me before
I deliver the message it's importunate, pressing, crucial. Await your
response.
Best regards
Mrs. Latifah Adamaou,
The self-refresh helper framework overloads "disable" to sometimes mean
"go into self-refresh mode," and this mode activates automatically
(e.g., after some period of unchanging display output). In such cases,
the display pipe is still considered "on", and user-space is not aware
that we went into self-refresh mode. Thus, users may expect that
vblank-related features (such as DRM_IOCTL_WAIT_VBLANK) still work
properly.
However, we trigger the WARN_ONCE() here if a CRTC driver tries to leave
vblank enabled.
Add a different expectation: that CRTCs *should* leave vblank enabled
when going into self-refresh.
This patch is preparation for another patch -- "drm/rockchip: vop: Leave
vblank enabled in self-refresh" -- which resolves conflicts between the
above self-refresh behavior and the API tests in IGT's kms_vblank test
module.
v2:
* add 'ret != 0' warning case for self-refresh
* describe failing test case and relation to drm/rockchip patch better
Cc: <stable(a)vger.kernel.org> # dependency for "drm/rockchip: vop: Leave
# vblank enabled in self-refresh"
Signed-off-by: Brian Norris <briannorris(a)chromium.org>
---
drivers/gpu/drm/drm_atomic_helper.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index d579fd8f7cb8..a22485e3e924 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1209,7 +1209,16 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
continue;
ret = drm_crtc_vblank_get(crtc);
- WARN_ONCE(ret != -EINVAL, "driver forgot to call drm_crtc_vblank_off()\n");
+ /*
+ * Self-refresh is not a true "disable"; ensure vblank remains
+ * enabled.
+ */
+ if (new_crtc_state->self_refresh_active)
+ WARN_ONCE(ret != 0,
+ "driver disabled vblank in self-refresh\n");
+ else
+ WARN_ONCE(ret != -EINVAL,
+ "driver forgot to call drm_crtc_vblank_off()\n");
if (ret == 0)
drm_crtc_vblank_put(crtc);
}
--
2.39.0.314.g84b9a713c41-goog
The patch titled
Subject: proc: fix PIE proc-empty-vm, proc-pid-vm tests
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
proc-fix-pie-proc-empty-vm-proc-pid-vm-tests.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Alexey Dobriyan <adobriyan(a)gmail.com>
Subject: proc: fix PIE proc-empty-vm, proc-pid-vm tests
Date: Fri, 6 Jan 2023 22:30:14 +0300
vsyscall detection code uses direct call to the beginning of
the vsyscall page:
asm ("call %P0" :: "i" (0xffffffffff600000))
It generates "call rel32" instruction but it is not relocated if binary
is PIE, so binary segfaults into random userspace address and vsyscall
page status is detected incorrectly.
Do more direct:
asm ("call *%rax")
which doesn't do need any relocaltions.
Mark g_vsyscall as volatile for a good measure, I didn't find instruction
setting it to 0. Now the code is obviously correct:
xor eax, eax
mov rdi, rbp
mov rsi, rbp
mov DWORD PTR [rip+0x2d15], eax # g_vsyscall = 0
mov rax, 0xffffffffff600000
call rax
mov DWORD PTR [rip+0x2d02], 1 # g_vsyscall = 1
mov eax, DWORD PTR ds:0xffffffffff600000
mov DWORD PTR [rip+0x2cf1], 2 # g_vsyscall = 2
mov edi, [rip+0x2ceb] # exit(g_vsyscall)
call exit
Note: fixed proc-empty-vm test oopses 5.19.0-28-generic kernel
but this is separate story.
Link: https://lkml.kernel.org/r/Y7h2xvzKLg36DSq8@p183
Fixes: 5bc73bb3451b9 ("proc: test how it holds up with mapping'less process")
Signed-off-by: Alexey Dobriyan <adobriyan(a)gmail.com>
Reported-by: Mirsad Goran Todorovac <mirsad.todorovac(a)alu.unizg.hr>
Tested-by: Mirsad Goran Todorovac <mirsad.todorovac(a)alu.unizg.hr>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
tools/testing/selftests/proc/proc-empty-vm.c | 12 +++++++-----
tools/testing/selftests/proc/proc-pid-vm.c | 9 +++++----
2 files changed, 12 insertions(+), 9 deletions(-)
--- a/tools/testing/selftests/proc/proc-empty-vm.c~proc-fix-pie-proc-empty-vm-proc-pid-vm-tests
+++ a/tools/testing/selftests/proc/proc-empty-vm.c
@@ -25,6 +25,7 @@
#undef NDEBUG
#include <assert.h>
#include <errno.h>
+#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
@@ -41,7 +42,7 @@
* 1: vsyscall VMA is --xp vsyscall=xonly
* 2: vsyscall VMA is r-xp vsyscall=emulate
*/
-static int g_vsyscall;
+static volatile int g_vsyscall;
static const char *g_proc_pid_maps_vsyscall;
static const char *g_proc_pid_smaps_vsyscall;
@@ -147,11 +148,12 @@ static void vsyscall(void)
g_vsyscall = 0;
/* gettimeofday(NULL, NULL); */
+ uint64_t rax = 0xffffffffff600000;
asm volatile (
- "call %P0"
- :
- : "i" (0xffffffffff600000), "D" (NULL), "S" (NULL)
- : "rax", "rcx", "r11"
+ "call *%[rax]"
+ : [rax] "+a" (rax)
+ : "D" (NULL), "S" (NULL)
+ : "rcx", "r11"
);
g_vsyscall = 1;
--- a/tools/testing/selftests/proc/proc-pid-vm.c~proc-fix-pie-proc-empty-vm-proc-pid-vm-tests
+++ a/tools/testing/selftests/proc/proc-pid-vm.c
@@ -257,11 +257,12 @@ static void vsyscall(void)
g_vsyscall = 0;
/* gettimeofday(NULL, NULL); */
+ uint64_t rax = 0xffffffffff600000;
asm volatile (
- "call %P0"
- :
- : "i" (0xffffffffff600000), "D" (NULL), "S" (NULL)
- : "rax", "rcx", "r11"
+ "call *%[rax]"
+ : [rax] "+a" (rax)
+ : "D" (NULL), "S" (NULL)
+ : "rcx", "r11"
);
g_vsyscall = 1;
_
Patches currently in -mm which might be from adobriyan(a)gmail.com are
proc-fix-pie-proc-empty-vm-proc-pid-vm-tests.patch
proc-mark-proc-cmdline-as-permanent.patch
usb_kill_urb warranties that all the handlers are finished when it
returns, but does not protect against threads that might be handling
asynchronously the urb.
For UVC, the function uvc_ctrl_status_event_async() takes care of
control changes asynchronously.
If the code is executed in the following order:
CPU 0 CPU 1
===== =====
uvc_status_complete()
uvc_status_stop()
uvc_ctrl_status_event_work()
uvc_status_start() -> FAIL
Then uvc_status_start will keep failing and this error will be shown:
<4>[ 5.540139] URB 0000000000000000 submitted while active
drivers/usb/core/urb.c:378 usb_submit_urb+0x4c3/0x528
Let's improve the current situation, by not re-submiting the urb if
we are stopping the status event. Also process the queued work
(if any) during stop.
CPU 0 CPU 1
===== =====
uvc_status_complete()
uvc_status_stop()
uvc_status_start()
uvc_ctrl_status_event_work() -> FAIL
Hopefully, with the usb layer protection this should be enough to cover
all the cases.
Cc: stable(a)vger.kernel.org
Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives")
Reviewed-by: Yunke Cao <yunkec(a)chromium.org>
Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org>
---
uvc: Fix race condition on uvc
Make sure that all the async work is finished when we stop the status urb.
To: Hillf Danton <hdanton(a)sina.com>
To: Yunke Cao <yunkec(a)chromium.org>
To: Sergey Senozhatsky <senozhatsky(a)chromium.org>
To: Max Staudt <mstaudt(a)google.com>
To: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
To: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: linux-media(a)vger.kernel.org
Cc: linux-kernel(a)vger.kernel.org
---
Changes in v7:
- Use smp_store_release. (Thanks Hilf!)
- Rebase on top of uvc/next.
- Link to v6: https://lore.kernel.org/r/20221212-uvc-race-v6-0-2a662f8de011@chromium.org
Changes in v6:
- Improve comments. (Thanks Laurent).
- Use true/false instead of 1/0 (Thanks Laurent).
- Link to v5: https://lore.kernel.org/r/20221212-uvc-race-v5-0-3db3933d1608@chromium.org
Changes in v5:
- atomic_t do not impose barriers, use smp_mb() instead. (Thanks Laurent)
- Add an extra cancel_work_sync().
- Link to v4: https://lore.kernel.org/r/20221212-uvc-race-v4-0-38d7075b03f5@chromium.org
Changes in v4:
- Replace bool with atomic_t to avoid compiler reordering.
- First complete the async work and then kill the urb to avoid race (Thanks Laurent!)
- Link to v3: https://lore.kernel.org/r/20221212-uvc-race-v3-0-954efc752c9a@chromium.org
Changes in v3:
- Remove the patch for dev->status, makes more sense in another series, and makes
the zero day less nervous.
- Update reviewed-by (thanks Yunke!).
- Link to v2: https://lore.kernel.org/r/20221212-uvc-race-v2-0-54496cc3b8ab@chromium.org
Changes in v2:
- Add a patch for not kalloc dev->status
- Redo the logic mechanism, so it also works with suspend (Thanks Yunke!)
- Link to v1: https://lore.kernel.org/r/20221212-uvc-race-v1-0-c52e1783c31d@chromium.org
---
drivers/media/usb/uvc/uvc_ctrl.c | 5 +++++
drivers/media/usb/uvc/uvc_status.c | 33 +++++++++++++++++++++++++++++++++
drivers/media/usb/uvc/uvcvideo.h | 1 +
3 files changed, 39 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index e07b56bbf853..30c417768376 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -6,6 +6,7 @@
* Laurent Pinchart (laurent.pinchart(a)ideasonboard.com)
*/
+#include <asm/barrier.h>
#include <linux/bitops.h>
#include <linux/kernel.h>
#include <linux/list.h>
@@ -1509,6 +1510,10 @@ static void uvc_ctrl_status_event_work(struct work_struct *work)
uvc_ctrl_status_event(w->chain, w->ctrl, w->data);
+ /* The barrier is needed to synchronize with uvc_status_stop(). */
+ if (smp_load_acquire(&dev->flush_status))
+ return;
+
/* Resubmit the URB. */
w->urb->interval = dev->int_ep->desc.bInterval;
ret = usb_submit_urb(w->urb, GFP_KERNEL);
diff --git a/drivers/media/usb/uvc/uvc_status.c b/drivers/media/usb/uvc/uvc_status.c
index 602830a8023e..21e13b8441da 100644
--- a/drivers/media/usb/uvc/uvc_status.c
+++ b/drivers/media/usb/uvc/uvc_status.c
@@ -6,6 +6,7 @@
* Laurent Pinchart (laurent.pinchart(a)ideasonboard.com)
*/
+#include <asm/barrier.h>
#include <linux/kernel.h>
#include <linux/input.h>
#include <linux/slab.h>
@@ -311,5 +312,37 @@ int uvc_status_start(struct uvc_device *dev, gfp_t flags)
void uvc_status_stop(struct uvc_device *dev)
{
+ struct uvc_ctrl_work *w = &dev->async_ctrl;
+
+ /*
+ * Prevent the asynchronous control handler from requeing the URB. The
+ * barrier is needed so the flush_status change is visible to other
+ * CPUs running the asynchronous handler before usb_kill_urb() is
+ * called below.
+ */
+ smp_store_release(&dev->flush_status, true);
+
+ /* If there is any status event on the queue, process it. */
+ if (cancel_work_sync(&w->work))
+ uvc_ctrl_status_event(w->chain, w->ctrl, w->data);
+
+ /* Kill the urb. */
usb_kill_urb(dev->int_urb);
+
+ /*
+ * The URB completion handler may have queued asynchronous work. This
+ * won't resubmit the URB as flush_status is set, but it needs to be
+ * cancelled before returning or it could then race with a future
+ * uvc_status_start() call.
+ */
+ if (cancel_work_sync(&w->work))
+ uvc_ctrl_status_event(w->chain, w->ctrl, w->data);
+
+ /*
+ * From this point, there are no events on the queue and the status URB
+ * is dead, this is, no events will be queued until uvc_status_start()
+ * is called. The barrier is needed to make sure that it is written to
+ * memory before uvc_status_start() is called again.
+ */
+ smp_store_release(&dev->flush_status, false);
}
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index ae0066eceffd..b2b277cccbdb 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -578,6 +578,7 @@ struct uvc_device {
struct usb_host_endpoint *int_ep;
struct urb *int_urb;
struct uvc_status *status;
+ bool flush_status;
struct input_dev *input;
char input_phys[64];
---
base-commit: fb1316b0ff3fc3cd98637040ee17ab7be753aac7
change-id: 20221212-uvc-race-09276ea68bf8
Best regards,
--
Ricardo Ribalda <ribalda(a)chromium.org>
On Fri, Jan 6, 2023 at 6:04 PM Luigi Semenzato <semenzato(a)chromium.org> wrote:
>
> I worked a fair amount on TPM 1.0 about 10 years ago and I even vaguely remember suspend-related problems. I'd be happy to take a look. The linked thread shows that Peter Huewe was copied. I know Peter well, his opinion can be trusted. Unfortunately I don't immediately see a link to a patch, can you help?
Sorry, I should have included that:
https://lore.kernel.org/lkml/20230106030156.3258307-1-Jason@zx2c4.com/
Instead of blocking system suspend when TPM_ORD_SAVESTATE fails, it
just lets the system sleep anyway. This means that presumably the
system might sleep without having called TPM_ORD_SAVESTATE. Trying to
figure out how bad that is.
And yes, Peter Huewe certainly knows about TPMs, especially as he
maintains the code in Linux, but the maintainers haven't been so much
available, unfortunately. This bug happens to intersect with something
mostly related that I work on (the rng), so I'm motivated to at least
prevent the worst of the breakage, but I otherwise don't know anything
about the Linux TPM driver.
Jason
Zero-length arrays are deprecated[1]. Replace struct io_uring_buf_ring's
"bufs" with a flexible array member. (How is the size of this array
verified?) Detected with GCC 13, using -fstrict-flex-arrays=3:
In function 'io_ring_buffer_select',
inlined from 'io_buffer_select' at io_uring/kbuf.c:183:10:
io_uring/kbuf.c:141:23: warning: array subscript 255 is outside the bounds of an interior zero-length array 'struct io_uring_buf[0]' [-Wzero-length-bounds]
141 | buf = &br->bufs[head];
| ^~~~~~~~~~~~~~~
In file included from include/linux/io_uring.h:7,
from io_uring/kbuf.c:10:
include/uapi/linux/io_uring.h: In function 'io_buffer_select':
include/uapi/linux/io_uring.h:628:41: note: while referencing 'bufs'
628 | struct io_uring_buf bufs[0];
| ^~~~
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-…
Fixes: c7fb19428d67 ("io_uring: add support for ring mapped supplied buffers")
Cc: Jens Axboe <axboe(a)kernel.dk>
Cc: Pavel Begunkov <asml.silence(a)gmail.com>
Cc: "Gustavo A. R. Silva" <gustavoars(a)kernel.org>
Cc: stable(a)vger.kernel.org
Cc: io-uring(a)vger.kernel.org
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
v2: use helper since these flex arrays are in a union.
v1: https://lore.kernel.org/lkml/20230105033743.never.628-kees@kernel.org
---
include/uapi/linux/io_uring.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
index 2780bce62faf..434f62e0fb72 100644
--- a/include/uapi/linux/io_uring.h
+++ b/include/uapi/linux/io_uring.h
@@ -625,7 +625,7 @@ struct io_uring_buf_ring {
__u16 resv3;
__u16 tail;
};
- struct io_uring_buf bufs[0];
+ __DECLARE_FLEX_ARRAY(struct io_uring_buf, bufs);
};
};
--
2.34.1
Hi community.
Previously our team reported a race condition in IMA relates to LSM
based rules which would case IMA to match files that should be filtered
out under normal condition. The issue was originally analyzed and fixed
on mainstream. The patch and the discussion could be found here:
https://lore.kernel.org/all/20220921125804.59490-1-guozihua@huawei.com/
After that, we did a regression test on 4.19 LTS and the same issue
arises. Further analysis reveled that the issue is from a completely
different cause.
The cause is that selinux_audit_rule_init() would set the rule (which is
a second level pointer) to NULL immediately after called. The relevant
codes are as shown:
security/selinux/ss/services.c:
> int selinux_audit_rule_init(u32 field, u32 op, char *rulestr, void **vrule)
> {
> struct selinux_state *state = &selinux_state;
> struct policydb *policydb = &state->ss->policydb;
> struct selinux_audit_rule *tmprule;
> struct role_datum *roledatum;
> struct type_datum *typedatum;
> struct user_datum *userdatum;
> struct selinux_audit_rule **rule = (struct selinux_audit_rule **)vrule;
> int rc = 0;
>
> *rule = NULL;
*rule is set to NULL here, which means the rule on IMA side is also NULL.
>
> if (!state->initialized)
> return -EOPNOTSUPP;
...
> out:
> read_unlock(&state->ss->policy_rwlock);
>
> if (rc) {
> selinux_audit_rule_free(tmprule);
> tmprule = NULL;
> }
>
> *rule = tmprule;
rule is updated at the end of the function.
>
> return rc;
> }
security/integrity/ima/ima_policy.c:
> static bool ima_match_rules(struct ima_rule_entry *rule, struct inode *inode,
> const struct cred *cred, u32 secid,
> enum ima_hooks func, int mask)
> {...
> for (i = 0; i < MAX_LSM_RULES; i++) {
> int rc = 0;
> u32 osid;
> int retried = 0;
>
> if (!rule->lsm[i].rule)
> continue;
Setting rule to NULL would lead to LSM based rule matching being skipped.
> retry:
> switch (i) {
To solve this issue, there are multiple approaches we might take and I
would like some input from the community.
The first proposed solution would be to change
selinux_audit_rule_init(). Remove the set to NULL bit and update the
rule pointer with cmpxchg.
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index a9f2bc8443bd..aa74b04ccaf7 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -3297,10 +3297,9 @@ int selinux_audit_rule_init(u32 field, u32 op, char *rulestr, void **vrule)
> struct type_datum *typedatum;
> struct user_datum *userdatum;
> struct selinux_audit_rule **rule = (struct selinux_audit_rule **)vrule;
> + struct selinux_audit_rule *orig = rule;
> int rc = 0;
>
> - *rule = NULL;
> -
> if (!state->initialized)
> return -EOPNOTSUPP;
>
> @@ -3382,7 +3381,8 @@ int selinux_audit_rule_init(u32 field, u32 op, char *rulestr, void **vrule)
> tmprule = NULL;
> }
>
> - *rule = tmprule;
> + if (cmpxchg(rule, orig, tmprule) != orig)
> + selinux_audit_rule_free(tmprule);
>
> return rc;
> }
This solution would be an easy fix, but might influence other modules
calling selinux_audit_rule_init() directly or indirectly (on 4.19 LTS,
only auditfilter and IMA it seems). And it might be worth returning an
error code such as -EAGAIN.
Or, we can access rules via RCU, similar to what we do on 5.10. This
could means more code change and testing.
Reported-by: Huaxin Lu <luhuaxin1(a)huawei.com>
--
Best
GUO Zihua
The patch titled
Subject: nilfs2: fix general protection fault in nilfs_btree_insert()
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
nilfs2-fix-general-protection-fault-in-nilfs_btree_insert.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com>
Subject: nilfs2: fix general protection fault in nilfs_btree_insert()
Date: Thu, 5 Jan 2023 14:53:56 +0900
If nilfs2 reads a corrupted disk image and tries to reads a b-tree node
block by calling __nilfs_btree_get_block() against an invalid virtual
block address, it returns -ENOENT because conversion of the virtual block
address to a disk block address fails. However, this return value is the
same as the internal code that b-tree lookup routines return to indicate
that the block being searched does not exist, so functions that operate on
that b-tree may misbehave.
When nilfs_btree_insert() receives this spurious 'not found' code from
nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was
successful and continues the insert operation using incomplete lookup path
data, causing the following crash:
general protection fault, probably for non-canonical address
0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
...
RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]
RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]
RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238
Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89
ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c
28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02
...
Call Trace:
<TASK>
nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]
nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147
nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101
__block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991
__block_write_begin fs/buffer.c:2041 [inline]
block_write_begin+0x93/0x1e0 fs/buffer.c:2102
nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261
generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772
__generic_file_write_iter+0x176/0x400 mm/filemap.c:3900
generic_file_write_iter+0xab/0x310 mm/filemap.c:3932
call_write_iter include/linux/fs.h:2186 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x7dc/0xc50 fs/read_write.c:584
ksys_write+0x177/0x2a0 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
...
</TASK>
This patch fixes the root cause of this problem by replacing the error
code that __nilfs_btree_get_block() returns on block address conversion
failure from -ENOENT to another internal code -EINVAL which means that the
b-tree metadata is corrupted.
By returning -EINVAL, it propagates without glitches, and for all relevant
b-tree operations, functions in the upper bmap layer output an error
message indicating corrupted b-tree metadata via
nilfs_bmap_convert_error(), and code -EIO will be eventually returned as
it should be.
Link: https://lkml.kernel.org/r/000000000000bd89e205f0e38355@google.com
Link: https://lkml.kernel.org/r/20230105055356.8811-1-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com>
Reported-by: syzbot+ede796cecd5296353515(a)syzkaller.appspotmail.com
Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/nilfs2/btree.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/fs/nilfs2/btree.c~nilfs2-fix-general-protection-fault-in-nilfs_btree_insert
+++ a/fs/nilfs2/btree.c
@@ -480,9 +480,18 @@ static int __nilfs_btree_get_block(const
ret = nilfs_btnode_submit_block(btnc, ptr, 0, REQ_OP_READ, &bh,
&submit_ptr);
if (ret) {
- if (ret != -EEXIST)
- return ret;
- goto out_check;
+ if (likely(ret == -EEXIST))
+ goto out_check;
+ if (ret == -ENOENT) {
+ /*
+ * Block address translation failed due to invalid
+ * value of 'ptr'. In this case, return internal code
+ * -EINVAL (broken bmap) to notify bmap layer of fatal
+ * metadata corruption.
+ */
+ ret = -EINVAL;
+ }
+ return ret;
}
if (ra) {
_
Patches currently in -mm which might be from konishi.ryusuke(a)gmail.com are
nilfs2-fix-general-protection-fault-in-nilfs_btree_insert.patch
The primary task of the onboard_usb_hub driver is to control the
power of an onboard USB hub. The driver gets the regulator from the
device tree property "vdd-supply" of the hub's DT node. Some boards
have device tree nodes for USB hubs supported by this driver, but
don't specify a "vdd-supply". This is not an error per se, it just
means that the onboard hub driver can't be used for these hubs, so
don't create platform devices for such nodes.
This change doesn't completely fix the reported regression. It
should fix it for the RPi 3 B Plus and boards with similar hub
configurations (compatible DT nodes without "vdd-supply"), boards
that actually use the onboard hub driver could still be impacted
by the race conditions discussed in that thread. Not creating the
platform devices for nodes without "vdd-supply" is the right
thing to do, independently from the race condition, which will
be fixed in future patch.
Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver")
Link: https://lore.kernel.org/r/d04bcc45-3471-4417-b30b-5cf9880d785d@i2se.com/
Reported-by: Stefan Wahren <stefan.wahren(a)i2se.com>
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
---
Changes in v2:
- don't create platform devices when "vdd-supply" is missing,
rather than returning an error from _find_onboard_hub()
- check for "vdd-supply" not "vdd" (Johan)
- updated subject and commit message
- added 'Link' tag (regzbot)
drivers/usb/misc/onboard_usb_hub_pdevs.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/misc/onboard_usb_hub_pdevs.c b/drivers/usb/misc/onboard_usb_hub_pdevs.c
index ed22a18f4ab7..8cea53b0907e 100644
--- a/drivers/usb/misc/onboard_usb_hub_pdevs.c
+++ b/drivers/usb/misc/onboard_usb_hub_pdevs.c
@@ -101,6 +101,19 @@ void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *p
}
}
+ /*
+ * The primary task of the onboard_usb_hub driver is to control
+ * the power of an USB onboard hub. Some boards have device tree
+ * nodes for USB hubs supported by this driver, but don't
+ * specify a "vdd-supply", which is needed by the driver. This is
+ * not a DT error per se, it just means that the onboard hub
+ * driver can't be used with these nodes, so don't create a
+ * a platform device for such a node.
+ */
+ if (!of_get_property(np, "vdd-supply", NULL) &&
+ !of_get_property(npc, "vdd-supply", NULL))
+ goto node_put;
+
pdev = of_platform_device_create(np, NULL, &parent_hub->dev);
if (!pdev) {
dev_err(&parent_hub->dev,
--
2.39.0.314.g84b9a713c41-goog
[Public]
Hi,
At *least* 9 models of laptops across manufacturers have problems with suspend that are root caused
to the firmware not properly implementing an AMD specific codepath, but that did implement a
Microsoft specific one properly. To fix the suspend issues on Linux, a number of commits have been
worked out over the last few kernel releases.
We have eventually landed at we're going to just use the Microsoft codepath in Linux.
All the patches to accomplish this are now landed in 6.2-rc1, and also in 6.1.3.
Now that have this all working satisfactorily I'd like to bring those fixes into 6.0.y and 5.15.y as well.
Here is the series of commits for 6.0.y:
100a57379380 ACPI: x86: s2idle: Move _HID handling for AMD systems into structures
fd894f05cf30 ACPI: x86: s2idle: If a new AMD _HID is missing assume Rembrandt
a0bc002393d4 ACPI: x86: s2idle: Add module parameter to prefer Microsoft GUID
d0f61e89f08d ACPI: x86: s2idle: Add a quirk for ASUS TUF Gaming A17 FA707RE
ddeea2c3cb88 ACPI: x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14
888ca9c7955e ACPI: x86: s2idle: Add a quirk for Lenovo Slim 7 Pro 14ARH7
631b54519e8e ACPI: x86: s2idle: Add a quirk for ASUSTeK COMPUTER INC. ROG Flow X13
39f81776c680 ACPI: x86: s2idle: Fix a NULL pointer dereference
54bd1e548701 ACPI: x86: s2idle: Add another ID to s2idle_dmi_table
577821f756cf ACPI: x86: s2idle: Force AMD GUID/_REV 2 on HP Elitebook 865
e6d180a35bc0 ACPI: x86: s2idle: Stop using AMD specific codepath for Rembrandt+
Here is the series of commits for 5.15.y:
ed470febf837 ACPI: PM: s2idle: Add support for upcoming AMD uPEP HID AMDI008
1a2dcab517cb ACPI: PM: s2idle: Use LPS0 idle if ACPI_FADT_LOW_POWER_S0 is unset
100a57379380 ACPI: x86: s2idle: Move _HID handling for AMD systems into structures
fd894f05cf30 ACPI: x86: s2idle: If a new AMD _HID is missing assume Rembrandt
a0bc002393d4 ACPI: x86: s2idle: Add module parameter to prefer Microsoft GUID
d0f61e89f08d ACPI: x86: s2idle: Add a quirk for ASUS TUF Gaming A17 FA707RE
ddeea2c3cb88 ACPI: x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14
888ca9c7955e ACPI: x86: s2idle: Add a quirk for Lenovo Slim 7 Pro 14ARH7
631b54519e8e ACPI: x86: s2idle: Add a quirk for ASUSTeK COMPUTER INC. ROG Flow X13
39f81776c680 ACPI: x86: s2idle: Fix a NULL pointer dereference
54bd1e548701 ACPI: x86: s2idle: Add another ID to s2idle_dmi_table
577821f756cf ACPI: x86: s2idle: Force AMD GUID/_REV 2 on HP Elitebook 865
e6d180a35bc0 ACPI: x86: s2idle: Stop using AMD specific codepath for Rembrandt+
Can you please backport these for a future stable release?
Much appreciated,
Userfaultfd-wp uses pte markers to mark wr-protected pages for both shmem
and hugetlb. Shmem has pre-allocation ready for markers, but hugetlb path
was overlooked.
Doing so by calling huge_pte_alloc() if the initial pgtable walk fails to
find the huge ptep. It's possible that huge_pte_alloc() can fail with high
memory pressure, in that case stop the loop immediately and fail silently.
This is not the most ideal solution but it matches with what we do with
shmem meanwhile it avoids the splat in dmesg.
Cc: linux-stable <stable(a)vger.kernel.org> # 5.19+
Fixes: 60dfaad65aa9 ("mm/hugetlb: allow uffd wr-protect none ptes")
Reported-by: James Houghton <jthoughton(a)google.com>
Signed-off-by: Peter Xu <peterx(a)redhat.com>
---
mm/hugetlb.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index bf7a1f628357..017d9159cddf 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6649,8 +6649,17 @@ unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
spinlock_t *ptl;
ptep = hugetlb_walk(vma, address, psize);
if (!ptep) {
- address |= last_addr_mask;
- continue;
+ if (!uffd_wp) {
+ address |= last_addr_mask;
+ continue;
+ }
+ /*
+ * Userfaultfd wr-protect requires pgtable
+ * pre-allocations to install pte markers.
+ */
+ ptep = huge_pte_alloc(mm, vma, address, psize);
+ if (!ptep)
+ break;
}
ptl = huge_pte_lock(h, mm, ptep);
if (huge_pmd_unshare(mm, vma, address, ptep)) {
--
2.37.3
Removing the firmware framebuffer from the driver means that even
if the driver doesn't support the IP blocks in a GPU it will no
longer be functional after the driver fails to initialize.
This change will ensure that unsupported IP blocks at least cause
the driver to work with the EFI framebuffer.
Cc: stable(a)vger.kernel.org
Suggested-by: Alex Deucher <alexander.deucher(a)amd.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar(a)amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++++++++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ------
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 9a1a5c2864a0..cdb681398a99 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -37,6 +37,7 @@
#include <linux/pci-p2pdma.h>
#include <drm/drm_atomic_helper.h>
+#include <drm/drm_aperture.h>
#include <drm/drm_probe_helper.h>
#include <drm/amdgpu_drm.h>
#include <linux/vgaarb.h>
@@ -89,6 +90,8 @@ MODULE_FIRMWARE("amdgpu/navi12_gpu_info.bin");
#define AMDGPU_MAX_RETRY_LIMIT 2
#define AMDGPU_RETRY_SRIOV_RESET(r) ((r) == -EBUSY || (r) == -ETIMEDOUT || (r) == -EINVAL)
+static const struct drm_driver amdgpu_kms_driver;
+
const char *amdgpu_asic_name[] = {
"TAHITI",
"PITCAIRN",
@@ -3685,6 +3688,11 @@ int amdgpu_device_init(struct amdgpu_device *adev,
if (r)
return r;
+ /* Get rid of things like offb */
+ r = drm_aperture_remove_conflicting_pci_framebuffers(adev->pdev, &amdgpu_kms_driver);
+ if (r)
+ return r;
+
/* Enable TMZ based on IP_VERSION */
amdgpu_gmc_tmz_set(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index db7e34eacc35..b9f14ec9edb2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -23,7 +23,6 @@
*/
#include <drm/amdgpu_drm.h>
-#include <drm/drm_aperture.h>
#include <drm/drm_drv.h>
#include <drm/drm_gem.h>
#include <drm/drm_vblank.h>
@@ -2096,11 +2095,6 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
}
#endif
- /* Get rid of things like offb */
- ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &amdgpu_kms_driver);
- if (ret)
- return ret;
-
adev = devm_drm_dev_alloc(&pdev->dev, &amdgpu_kms_driver, typeof(*adev), ddev);
if (IS_ERR(adev))
return PTR_ERR(adev);
--
2.34.1
During suspend and resume, the channel state needs to be saved locally.
Otherwise, the endpoint may access the channels while they were being
suspended and causing access violations.
Fix it by saving the channel state locally during suspend and resume.
Cc: <stable(a)vger.kernel.org> # 5.19
Fixes: e4b7b5f0f30a ("bus: mhi: ep: Add support for suspending and resuming channels")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org>
---
drivers/bus/mhi/ep/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bus/mhi/ep/main.c b/drivers/bus/mhi/ep/main.c
index 2362fcc8b32c..bcaaba97ef63 100644
--- a/drivers/bus/mhi/ep/main.c
+++ b/drivers/bus/mhi/ep/main.c
@@ -1122,6 +1122,7 @@ void mhi_ep_suspend_channels(struct mhi_ep_cntrl *mhi_cntrl)
dev_dbg(&mhi_chan->mhi_dev->dev, "Suspending channel\n");
/* Set channel state to SUSPENDED */
+ mhi_chan->state = MHI_CH_STATE_SUSPENDED;
tmp &= ~CHAN_CTX_CHSTATE_MASK;
tmp |= FIELD_PREP(CHAN_CTX_CHSTATE_MASK, MHI_CH_STATE_SUSPENDED);
mhi_cntrl->ch_ctx_cache[i].chcfg = cpu_to_le32(tmp);
@@ -1151,6 +1152,7 @@ void mhi_ep_resume_channels(struct mhi_ep_cntrl *mhi_cntrl)
dev_dbg(&mhi_chan->mhi_dev->dev, "Resuming channel\n");
/* Set channel state to RUNNING */
+ mhi_chan->state = MHI_CH_STATE_RUNNING;
tmp &= ~CHAN_CTX_CHSTATE_MASK;
tmp |= FIELD_PREP(CHAN_CTX_CHSTATE_MASK, MHI_CH_STATE_RUNNING);
mhi_cntrl->ch_ctx_cache[i].chcfg = cpu_to_le32(tmp);
--
2.25.1
There is a good chance that while the channel ring gets processed, the STOP
or RESET command for the channel might be received from the MHI host. In
those cases, the entire channel ring processing needs to be protected by
chan->lock to prevent the race where the corresponding channel ring might
be reset.
While at it, let's also add a sanity check to make sure that the ring is
started before processing it. Because, if the STOP/RESET command gets
processed while mhi_ep_ch_ring_worker() waited for chan->lock, the ring
would've been reset.
Cc: <stable(a)vger.kernel.org> # 5.19
Fixes: 03c0bb8ec983 ("bus: mhi: ep: Add support for processing channel rings")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org>
---
drivers/bus/mhi/ep/main.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/mhi/ep/main.c b/drivers/bus/mhi/ep/main.c
index 0bce6610ebf1..2362fcc8b32c 100644
--- a/drivers/bus/mhi/ep/main.c
+++ b/drivers/bus/mhi/ep/main.c
@@ -730,24 +730,37 @@ static void mhi_ep_ch_ring_worker(struct work_struct *work)
list_del(&itr->node);
ring = itr->ring;
+ chan = &mhi_cntrl->mhi_chan[ring->ch_id];
+ mutex_lock(&chan->lock);
+
+ /*
+ * The ring could've stopped while we waited to grab the (chan->lock), so do
+ * a sanity check before going further.
+ */
+ if (!ring->started) {
+ mutex_unlock(&chan->lock);
+ kfree(itr);
+ continue;
+ }
+
/* Update the write offset for the ring */
ret = mhi_ep_update_wr_offset(ring);
if (ret) {
dev_err(dev, "Error updating write offset for ring\n");
+ mutex_unlock(&chan->lock);
kfree(itr);
continue;
}
/* Sanity check to make sure there are elements in the ring */
if (ring->rd_offset == ring->wr_offset) {
+ mutex_unlock(&chan->lock);
kfree(itr);
continue;
}
el = &ring->ring_cache[ring->rd_offset];
- chan = &mhi_cntrl->mhi_chan[ring->ch_id];
- mutex_lock(&chan->lock);
dev_dbg(dev, "Processing the ring for channel (%u)\n", ring->ch_id);
ret = mhi_ep_process_ch_ring(ring, el);
if (ret) {
--
2.25.1
> On Jan 5, 2023, at 6:43 AM, Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> wrote:
>
> On Wed, Jan 04, 2023 at 04:56:31PM -0500, Joel Fernandes wrote:
>>
>>
>>>> On Jan 4, 2023, at 12:29 AM, Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> wrote:
>>>
>>> On Tue, Jan 03, 2023 at 04:16:07PM +0000, Joel Fernandes wrote:
>>>>> On Tue, Jan 03, 2023 at 09:13:30AM +0100, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 5.10.162 release.
>>>>> There are 63 patches in this series, all will be posted as a response
>>>>> to this one. If anyone has any issues with these being applied, please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Thu, 05 Jan 2023 08:12:47 +0000.
>>>>> Anything received after that time might be too late.
>>>>>
>>>>> The whole patch series can be found in one patch at:
>>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.162-r…
>>>>> or in the git tree and branch at:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
>>>>> and the diffstat can be found below.
>>>>>
>>>>> thanks,
>>>>
>>>> Testing fails. Could you please pick these 2 up?
>>>> https://lore.kernel.org/r/20221230153215.1333921-1-joel@joelfernandes.org
>>>> https://lore.kernel.org/all/20221230153215.1333921-2-joel@joelfernandes.org/
>>>
>>> That is not a regression from 5.10.161, right?
>>
>> Yes it is not.
>>
>>> This release is only for
>>> the io_uring stuff to make sure that backport was done correctly.
>>>
>>> The current "to apply" queue for the stable trees is very large right
>>> now due to everyone waiting to get tiny things into -rc1 instead of
>>> before then, so the above two are still not yet queued up, sorry.
>>
>> Sure not a problem, I can resend again later if it is still not queued.
>
> You should have already received the email notices saying they were
> queued :)
I happen to take messages from Skynet with a grain of salt ;-).
But thank you for the automated notification!
- Joel
From: Francesco Dolcini <francesco.dolcini(a)toradex.com>
Add a fallback mechanism to handle the case in which #size-cells is set
to <0>. According to the DT binding the nand controller node should have
set it to 0 and this is not compatible with the legacy way of
specifying partitions directly as child nodes of the nand-controller node.
This fixes a boot failure on colibri-imx7 and potentially other boards.
Cc: stable(a)vger.kernel.org
Fixes: 753395ea1e45 ("ARM: dts: imx7: Fix NAND controller size-cells")
Link: https://lore.kernel.org/all/Y4dgBTGNWpM6SQXI@francesco-nb.int.toradex.com/
Signed-off-by: Francesco Dolcini <francesco.dolcini(a)toradex.com>
---
drivers/mtd/parsers/ofpart_core.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/mtd/parsers/ofpart_core.c b/drivers/mtd/parsers/ofpart_core.c
index 192190c42fc8..aa3b7fa61e50 100644
--- a/drivers/mtd/parsers/ofpart_core.c
+++ b/drivers/mtd/parsers/ofpart_core.c
@@ -122,6 +122,17 @@ static int parse_fixed_partitions(struct mtd_info *master,
a_cells = of_n_addr_cells(pp);
s_cells = of_n_size_cells(pp);
+ if (s_cells == 0) {
+ /*
+ * Use #size-cells = <1> for backward compatibility
+ * in case #size-cells is set to <0> and firmware adds
+ * OF partitions without setting it.
+ */
+ pr_warn_once("%s: ofpart partition %pOF (%pOF) #size-cells is <0>, using <1> for backward compatibility.\n",
+ master->name, pp,
+ mtd_node);
+ s_cells = 1;
+ }
if (len / 4 != a_cells + s_cells) {
pr_debug("%s: ofpart partition %pOF (%pOF) error parsing reg property.\n",
master->name, pp,
--
2.25.1
Saludo de la Sra. Angela Larsson,
Mi amado, Dios me ha tocado entregarte este dinero considerando mi
último deseo, y también debes saber que mi contacto contigo es por
gracia especial de Dios, por favor, comprende que no me estás ayudando
a mí, sino que estás trabajando para Dios. creador del cielo y de la
tierra. Y de nuevo viuda sufriendo de una larga enfermedad.
Actualmente estoy ingresado en un hospital de ligustro en el país,
tengo algunos fondos que heredé de mi difunto y amado esposo, el Sr.
Larsson Wisdom, la suma de ($ 5,500,000.00USD) que depositó en el
banco aquí y necesito un muy honesto y temeroso de Dios cristiano que
puede usar estos fondos para la obra de Dios. Quiero que tú y la
iglesia siempre oren por mí porque el señor es mi pastor. Mi felicidad
es que viví una vida de cristiano digno y quien quiera servir al Señor
debe servirlo en espíritu y Verdad.
Por favor, si pudiera utilizar estos fondos para la obra del Señor,
tenga la amabilidad de responderme. No olvide orar siempre por mí
porque toda mi esperanza de sobrevivir está en Dios, el creador, que
tiene la muerte y la vida.
Espero recibir tu respuesta.
Sra. Ángela Larsson.
From: Jan Kara <jack(a)suse.cz>
commit a44e84a9b7764c72896f7241a0ec9ac7e7ef38dd upstream.
When manipulating xattr blocks, we can deadlock infinitely looping
inside ext4_xattr_block_set() where we constantly keep finding xattr
block for reuse in mbcache but we are unable to reuse it because its
reference count is too big. This happens because cache entry for the
xattr block is marked as reusable (e_reusable set) although its
reference count is too big. When this inconsistency happens, this
inconsistent state is kept indefinitely and so ext4_xattr_block_set()
keeps retrying indefinitely.
The inconsistent state is caused by non-atomic update of e_reusable bit.
e_reusable is part of a bitfield and e_reusable update can race with
update of e_referenced bit in the same bitfield resulting in loss of one
of the updates. Fix the problem by using atomic bitops instead.
This bug has been around for many years, but it became *much* easier
to hit after commit 65f8b80053a1 ("ext4: fix race when reusing xattr
blocks").
A special backport to 5.15 was necessary due to changes to reference counting.
Cc: stable(a)vger.kernel.org # 5.15
Fixes: 6048c64b2609 ("mbcache: add reusable flag to cache entries")
Fixes: 65f8b80053a1 ("ext4: fix race when reusing xattr blocks")
Reported-and-tested-by: Jeremi Piotrowski <jpiotrowski(a)linux.microsoft.com>
Reported-by: Thilo Fromm <t-lo(a)linux.microsoft.com>
Link: https://lore.kernel.org/r/c77bf00f-4618-7149-56f1-b8d1664b9d07@linux.micros…
Signed-off-by: Jan Kara <jack(a)suse.cz>
Reviewed-by: Andreas Dilger <adilger(a)dilger.ca>
Link: https://lore.kernel.org/r/20221123193950.16758-1-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Signed-off-by: Jeremi Piotrowski <jpiotrowski(a)linux.microsoft.com>
---
fs/ext4/xattr.c | 4 ++--
fs/mbcache.c | 14 ++++++++------
include/linux/mbcache.h | 9 +++++++--
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 533216e80fa2..22700812a4d3 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1281,7 +1281,7 @@ ext4_xattr_release_block(handle_t *handle, struct inode *inode,
ce = mb_cache_entry_get(ea_block_cache, hash,
bh->b_blocknr);
if (ce) {
- ce->e_reusable = 1;
+ set_bit(MBE_REUSABLE_B, &ce->e_flags);
mb_cache_entry_put(ea_block_cache, ce);
}
}
@@ -2042,7 +2042,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
}
BHDR(new_bh)->h_refcount = cpu_to_le32(ref);
if (ref == EXT4_XATTR_REFCOUNT_MAX)
- ce->e_reusable = 0;
+ clear_bit(MBE_REUSABLE_B, &ce->e_flags);
ea_bdebug(new_bh, "reusing; refcount now=%d",
ref);
ext4_xattr_block_csum_set(inode, new_bh);
diff --git a/fs/mbcache.c b/fs/mbcache.c
index 2010bc80a3f2..ac07b50ea3df 100644
--- a/fs/mbcache.c
+++ b/fs/mbcache.c
@@ -94,8 +94,9 @@ int mb_cache_entry_create(struct mb_cache *cache, gfp_t mask, u32 key,
atomic_set(&entry->e_refcnt, 1);
entry->e_key = key;
entry->e_value = value;
- entry->e_reusable = reusable;
- entry->e_referenced = 0;
+ entry->e_flags = 0;
+ if (reusable)
+ set_bit(MBE_REUSABLE_B, &entry->e_flags);
head = mb_cache_entry_head(cache, key);
hlist_bl_lock(head);
hlist_bl_for_each_entry(dup, dup_node, head, e_hash_list) {
@@ -155,7 +156,8 @@ static struct mb_cache_entry *__entry_find(struct mb_cache *cache,
while (node) {
entry = hlist_bl_entry(node, struct mb_cache_entry,
e_hash_list);
- if (entry->e_key == key && entry->e_reusable) {
+ if (entry->e_key == key &&
+ test_bit(MBE_REUSABLE_B, &entry->e_flags)) {
atomic_inc(&entry->e_refcnt);
goto out;
}
@@ -325,7 +327,7 @@ EXPORT_SYMBOL(mb_cache_entry_delete_or_get);
void mb_cache_entry_touch(struct mb_cache *cache,
struct mb_cache_entry *entry)
{
- entry->e_referenced = 1;
+ set_bit(MBE_REFERENCED_B, &entry->e_flags);
}
EXPORT_SYMBOL(mb_cache_entry_touch);
@@ -350,8 +352,8 @@ static unsigned long mb_cache_shrink(struct mb_cache *cache,
while (nr_to_scan-- && !list_empty(&cache->c_list)) {
entry = list_first_entry(&cache->c_list,
struct mb_cache_entry, e_list);
- if (entry->e_referenced || atomic_read(&entry->e_refcnt) > 2) {
- entry->e_referenced = 0;
+ if (test_bit(MBE_REFERENCED_B, &entry->e_flags) || atomic_read(&entry->e_refcnt) > 2) {
+ clear_bit(MBE_REFERENCED_B, &entry->e_flags);
list_move_tail(&entry->e_list, &cache->c_list);
continue;
}
diff --git a/include/linux/mbcache.h b/include/linux/mbcache.h
index 8eca7f25c432..62927f7e2588 100644
--- a/include/linux/mbcache.h
+++ b/include/linux/mbcache.h
@@ -10,6 +10,12 @@
struct mb_cache;
+/* Cache entry flags */
+enum {
+ MBE_REFERENCED_B = 0,
+ MBE_REUSABLE_B
+};
+
struct mb_cache_entry {
/* List of entries in cache - protected by cache->c_list_lock */
struct list_head e_list;
@@ -18,8 +24,7 @@ struct mb_cache_entry {
atomic_t e_refcnt;
/* Key in hash - stable during lifetime of the entry */
u32 e_key;
- u32 e_referenced:1;
- u32 e_reusable:1;
+ unsigned long e_flags;
/* User provided value - stable during lifetime of the entry */
u64 e_value;
};
--
2.25.1
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
a44e84a9b776 ("ext4: fix deadlock due to mbcache entry corruption")
307af6c87937 ("mbcache: automatically delete entries from cache on freeing")
65f8b80053a1 ("ext4: fix race when reusing xattr blocks")
fd48e9acdf26 ("ext4: unindent codeblock in ext4_xattr_block_set()")
6bc0d63dad7f ("ext4: remove EA inode entry from mbcache on inode eviction")
3dc96bba65f5 ("mbcache: add functions to delete entry if unused")
58318914186c ("mbcache: don't reclaim used entries")
4efd9f0d120c ("ext4: use kmemdup() to replace kmalloc + memcpy")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From a44e84a9b7764c72896f7241a0ec9ac7e7ef38dd Mon Sep 17 00:00:00 2001
From: Jan Kara <jack(a)suse.cz>
Date: Wed, 23 Nov 2022 20:39:50 +0100
Subject: [PATCH] ext4: fix deadlock due to mbcache entry corruption
When manipulating xattr blocks, we can deadlock infinitely looping
inside ext4_xattr_block_set() where we constantly keep finding xattr
block for reuse in mbcache but we are unable to reuse it because its
reference count is too big. This happens because cache entry for the
xattr block is marked as reusable (e_reusable set) although its
reference count is too big. When this inconsistency happens, this
inconsistent state is kept indefinitely and so ext4_xattr_block_set()
keeps retrying indefinitely.
The inconsistent state is caused by non-atomic update of e_reusable bit.
e_reusable is part of a bitfield and e_reusable update can race with
update of e_referenced bit in the same bitfield resulting in loss of one
of the updates. Fix the problem by using atomic bitops instead.
This bug has been around for many years, but it became *much* easier
to hit after commit 65f8b80053a1 ("ext4: fix race when reusing xattr
blocks").
Cc: stable(a)vger.kernel.org
Fixes: 6048c64b2609 ("mbcache: add reusable flag to cache entries")
Fixes: 65f8b80053a1 ("ext4: fix race when reusing xattr blocks")
Reported-and-tested-by: Jeremi Piotrowski <jpiotrowski(a)linux.microsoft.com>
Reported-by: Thilo Fromm <t-lo(a)linux.microsoft.com>
Link: https://lore.kernel.org/r/c77bf00f-4618-7149-56f1-b8d1664b9d07@linux.micros…
Signed-off-by: Jan Kara <jack(a)suse.cz>
Reviewed-by: Andreas Dilger <adilger(a)dilger.ca>
Link: https://lore.kernel.org/r/20221123193950.16758-1-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 4d1c701f0eec..6bdd502527f8 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1281,7 +1281,7 @@ ext4_xattr_release_block(handle_t *handle, struct inode *inode,
ce = mb_cache_entry_get(ea_block_cache, hash,
bh->b_blocknr);
if (ce) {
- ce->e_reusable = 1;
+ set_bit(MBE_REUSABLE_B, &ce->e_flags);
mb_cache_entry_put(ea_block_cache, ce);
}
}
@@ -2043,7 +2043,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
}
BHDR(new_bh)->h_refcount = cpu_to_le32(ref);
if (ref == EXT4_XATTR_REFCOUNT_MAX)
- ce->e_reusable = 0;
+ clear_bit(MBE_REUSABLE_B, &ce->e_flags);
ea_bdebug(new_bh, "reusing; refcount now=%d",
ref);
ext4_xattr_block_csum_set(inode, new_bh);
diff --git a/fs/mbcache.c b/fs/mbcache.c
index e272ad738faf..2a4b8b549e93 100644
--- a/fs/mbcache.c
+++ b/fs/mbcache.c
@@ -100,8 +100,9 @@ int mb_cache_entry_create(struct mb_cache *cache, gfp_t mask, u32 key,
atomic_set(&entry->e_refcnt, 2);
entry->e_key = key;
entry->e_value = value;
- entry->e_reusable = reusable;
- entry->e_referenced = 0;
+ entry->e_flags = 0;
+ if (reusable)
+ set_bit(MBE_REUSABLE_B, &entry->e_flags);
head = mb_cache_entry_head(cache, key);
hlist_bl_lock(head);
hlist_bl_for_each_entry(dup, dup_node, head, e_hash_list) {
@@ -165,7 +166,8 @@ static struct mb_cache_entry *__entry_find(struct mb_cache *cache,
while (node) {
entry = hlist_bl_entry(node, struct mb_cache_entry,
e_hash_list);
- if (entry->e_key == key && entry->e_reusable &&
+ if (entry->e_key == key &&
+ test_bit(MBE_REUSABLE_B, &entry->e_flags) &&
atomic_inc_not_zero(&entry->e_refcnt))
goto out;
node = node->next;
@@ -284,7 +286,7 @@ EXPORT_SYMBOL(mb_cache_entry_delete_or_get);
void mb_cache_entry_touch(struct mb_cache *cache,
struct mb_cache_entry *entry)
{
- entry->e_referenced = 1;
+ set_bit(MBE_REFERENCED_B, &entry->e_flags);
}
EXPORT_SYMBOL(mb_cache_entry_touch);
@@ -309,9 +311,9 @@ static unsigned long mb_cache_shrink(struct mb_cache *cache,
entry = list_first_entry(&cache->c_list,
struct mb_cache_entry, e_list);
/* Drop initial hash reference if there is no user */
- if (entry->e_referenced ||
+ if (test_bit(MBE_REFERENCED_B, &entry->e_flags) ||
atomic_cmpxchg(&entry->e_refcnt, 1, 0) != 1) {
- entry->e_referenced = 0;
+ clear_bit(MBE_REFERENCED_B, &entry->e_flags);
list_move_tail(&entry->e_list, &cache->c_list);
continue;
}
diff --git a/include/linux/mbcache.h b/include/linux/mbcache.h
index 2da63fd7b98f..97e64184767d 100644
--- a/include/linux/mbcache.h
+++ b/include/linux/mbcache.h
@@ -10,6 +10,12 @@
struct mb_cache;
+/* Cache entry flags */
+enum {
+ MBE_REFERENCED_B = 0,
+ MBE_REUSABLE_B
+};
+
struct mb_cache_entry {
/* List of entries in cache - protected by cache->c_list_lock */
struct list_head e_list;
@@ -26,8 +32,7 @@ struct mb_cache_entry {
atomic_t e_refcnt;
/* Key in hash - stable during lifetime of the entry */
u32 e_key;
- u32 e_referenced:1;
- u32 e_reusable:1;
+ unsigned long e_flags;
/* User provided value - stable during lifetime of the entry */
u64 e_value;
};
When wait_event_interruptible() has been interrupted by a signal the
tx.state value might not be ISOTP_IDLE. Force the state machines
into idle state to inhibit the timer handlers to continue working.
Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
Cc: stable(a)vger.kernel.org
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
---
V2: fixed checkpatch warnings m(
V3: added 'Fixes:' tag
net/can/isotp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/can/isotp.c b/net/can/isotp.c
index 0476a506d4a4..fc81d77724a1 100644
--- a/net/can/isotp.c
+++ b/net/can/isotp.c
@@ -1150,10 +1150,14 @@ static int isotp_release(struct socket *sock)
net = sock_net(sk);
/* wait for complete transmission of current pdu */
wait_event_interruptible(so->wait, so->tx.state == ISOTP_IDLE);
+ /* force state machines to be idle also when a signal occurred */
+ so->tx.state = ISOTP_IDLE;
+ so->rx.state = ISOTP_IDLE;
+
spin_lock(&isotp_notifier_lock);
while (isotp_busy_notifier == so) {
spin_unlock(&isotp_notifier_lock);
schedule_timeout_uninterruptible(1);
spin_lock(&isotp_notifier_lock);
--
2.30.2
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
ff4837f7fe59 ("tracing: Fix issue of missing one synthetic field")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ff4837f7fe59ff018eca4705a70eca5e0b486b97 Mon Sep 17 00:00:00 2001
From: Zheng Yejian <zhengyejian1(a)huawei.com>
Date: Wed, 7 Dec 2022 17:15:57 +0800
Subject: [PATCH] tracing: Fix issue of missing one synthetic field
The maximum number of synthetic fields supported is defined as
SYNTH_FIELDS_MAX which value currently is 64, but it actually fails
when try to generate a synthetic event with 64 fields by executing like:
# echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\
int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\
int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\
int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\
int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\
int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\
int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\
int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\
int v63; int v64" >> /sys/kernel/tracing/synthetic_events
Correct the field counting to fix it.
Link: https://lore.kernel.org/linux-trace-kernel/20221207091557.3137904-1-zhengye…
Cc: <mhiramat(a)kernel.org>
Cc: <zanussi(a)kernel.org>
Cc: stable(a)vger.kernel.org
Fixes: c9e759b1e845 ("tracing: Rework synthetic event command parsing")
Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com>
Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org>
diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c
index c3b582d19b62..67592eed0be8 100644
--- a/kernel/trace/trace_events_synth.c
+++ b/kernel/trace/trace_events_synth.c
@@ -1282,12 +1282,12 @@ static int __create_synth_event(const char *name, const char *raw_fields)
goto err_free_arg;
}
- fields[n_fields++] = field;
if (n_fields == SYNTH_FIELDS_MAX) {
synth_err(SYNTH_ERR_TOO_MANY_FIELDS, 0);
ret = -EINVAL;
goto err_free_arg;
}
+ fields[n_fields++] = field;
n_fields_this_loop++;
}
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
2820e5d0820a ("block: mq-deadline: Fix dd_finish_request() for zoned devices")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 2820e5d0820ac4daedff1272616a53d9c7682fd2 Mon Sep 17 00:00:00 2001
From: Damien Le Moal <damien.lemoal(a)opensource.wdc.com>
Date: Thu, 24 Nov 2022 11:12:07 +0900
Subject: [PATCH] block: mq-deadline: Fix dd_finish_request() for zoned devices
dd_finish_request() tests if the per prio fifo_list is not empty to
determine if request dispatching must be restarted for handling blocked
write requests to zoned devices with a call to
blk_mq_sched_mark_restart_hctx(). While simple, this implementation has
2 problems:
1) Only the priority level of the completed request is considered.
However, writes to a zone may be blocked due to other writes to the
same zone using a different priority level. While this is unlikely to
happen in practice, as writing a zone with different IO priorirites
does not make sense, nothing in the code prevents this from
happening.
2) The use of list_empty() is dangerous as dd_finish_request() does not
take dd->lock and may run concurrently with the insert and dispatch
code.
Fix these 2 problems by testing the write fifo list of all priority
levels using the new helper dd_has_write_work(), and by testing each
fifo list using list_empty_careful().
Fixes: c807ab520fc3 ("block/mq-deadline: Add I/O priority support")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Damien Le Moal <damien.lemoal(a)opensource.wdc.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com>
Link: https://lore.kernel.org/r/20221124021208.242541-2-damien.lemoal@opensource.…
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/block/mq-deadline.c b/block/mq-deadline.c
index 5639921dfa92..36374481cb87 100644
--- a/block/mq-deadline.c
+++ b/block/mq-deadline.c
@@ -789,6 +789,18 @@ static void dd_prepare_request(struct request *rq)
rq->elv.priv[0] = NULL;
}
+static bool dd_has_write_work(struct blk_mq_hw_ctx *hctx)
+{
+ struct deadline_data *dd = hctx->queue->elevator->elevator_data;
+ enum dd_prio p;
+
+ for (p = 0; p <= DD_PRIO_MAX; p++)
+ if (!list_empty_careful(&dd->per_prio[p].fifo_list[DD_WRITE]))
+ return true;
+
+ return false;
+}
+
/*
* Callback from inside blk_mq_free_request().
*
@@ -828,9 +840,10 @@ static void dd_finish_request(struct request *rq)
spin_lock_irqsave(&dd->zone_lock, flags);
blk_req_zone_write_unlock(rq);
- if (!list_empty(&per_prio->fifo_list[DD_WRITE]))
- blk_mq_sched_mark_restart_hctx(rq->mq_hctx);
spin_unlock_irqrestore(&dd->zone_lock, flags);
+
+ if (dd_has_write_work(rq->mq_hctx))
+ blk_mq_sched_mark_restart_hctx(rq->mq_hctx);
}
}
Following kernel BUG noticed on qemu_arm and BeagleBoard x15 while running
selftests: netfilter: nft_fib.sh test case.
This is always reproducible on stable-rc 6.1 and 6.0 [1].
Build, config, vmlinux and System.map links provided.
unwind: Unknown symbol address bf02e1c8
BUG: spinlock recursion on CPU#0, modprobe/762
lock: unwind_lock+0x0/0x24, .magic: dead4ead, .owner:
modprobe/762, .owner_cpu: 0
Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org>
[ 49.898742] kselftest: Running tests in netfilter
TAP version 13
1..14
# selftests: netfilter: nft_fib.sh
# /dev/stdin:4:10-28: Error: Could not process rule: No such file or directory
# fib saddr . iif oif missing counter log prefix
\"nsrouter-L7wUUW2r nft_rpfilter: \" drop
# ^^^^^^^^^^^^^^^^^^^
# /dev/stdin:4:10-28: Error: Could not process rule: No such file or directory
# fib saddr . iif oif missing counter log prefix
\"ns1-L7wUUW2r nft_rpfilter: \" drop
# ^^^^^^^^^^^^^^^^^^^
# /dev/stdin:4:10-28: Error: Could not process rule: No such file or directory
# fib saddr . iif oif missing counter log prefix
\"ns2-L7wUUW2r nft_rpfilter: \" drop
# ^^^^^^^^^^^^^^^^^^^
[ 55.484253] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
[ 55.569226] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 55.670281] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 55.674377] IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
# PASS: fib expression did not cause unwanted packet drops
# Error: Could not process rule: No such file or directory
# flush table inet filter
# ^^^^^^
# /dev/stdin:4:20-38: Error: Could not process rule: No such file or directory
# ip daddr 1.1.1.1 fib saddr . iif oif missing counter drop
# ^^^^^^^^^^^^^^^^^^^
# /dev/stdin:5:23-41: Error: Could not process rule: No such file or directory
# ip6 daddr 1c3::c01d fib saddr . iif oif missing counter drop
# ^^^^^^^^^^^^^^^^^^^
# Error: No such file or directory
# list table inet filter
# ^^^^^^
# Netns nsrouter-L7wUUW2r fib counter doesn't match expected packet
count of 0 for 1.1.1.1
# Error: No such file or directory
# list table inet filter
# ^^^^^^
not ok 1 selftests: netfilter: nft_fib.sh # exit=1
# selftests: netfilter: nft_nat.sh
[ 70.428411] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
[ 70.961660] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 70.965547] IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
[ 71.027372] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
# /dev/stdin:52:16-40: Error: Could not process rule: No such file or directory
# counter name ip saddr map @nsincounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:53:61-87: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
saddr map @nsincounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:57:16-41: Error: Could not process rule: No such file or directory
# counter name ip daddr map @nsoutcounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:58:61-88: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
daddr map @nsoutcounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:52:16-40: Error: Could not process rule: No such file or directory
# counter name ip saddr map @nsincounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:53:61-87: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
saddr map @nsincounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:57:16-41: Error: Could not process rule: No such file or directory
# counter name ip daddr map @nsoutcounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:58:61-88: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
daddr map @nsoutcounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:52:16-40: Error: Could not process rule: No such file or directory
# counter name ip saddr map @nsincounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:53:61-87: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
saddr map @nsincounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:57:16-41: Error: Could not process rule: No such file or directory
# counter name ip daddr map @nsoutcounter
# ^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:58:61-88: Error: Could not process rule: No such file or directory
# icmpv6 type { \"echo-request\", \"echo-reply\" } counter name ip6
daddr map @nsoutcounter6
#
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# /dev/stdin:6:34-42: Error: Could not process rule: No such file or directory
# ip saddr 10.0.2.2 counter name \"ns0insl\"
# ^^^^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# ERROR: ns0in counter in ns1-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_counters 1
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# ERROR: ns0out counter in ns1-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_counters 2
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# ERROR: ns0in6 counter in ns1-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_counters 3
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# ERROR: ns0out6 counter in ns1-0Hc1Kf82 has unexpected value
(expected packets 1 bytes 104) at check_counters 4
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# ERROR: ns0in counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at check_ns0_counters 1
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# ERROR: ns0in6 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# ERROR: ns0out counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at check_ns0_counters 2
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# ERROR: ns0out6 counter in ns0-0Hc1Kf82 has unexpected value
(expected packets 0 bytes 0) at check_ns0_counters3
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns1in
# ^^^^^^
# ERROR: ns1in counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_ns0_counters 4
# Error: No such file or directory
# list counter inet filter ns1in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns1in6
# ^^^^^^
# ERROR: ns1 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_ns0_counters 5
# Error: No such file or directory
# list counter inet filter ns1
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns1out
# ^^^^^^
# ERROR: ns1out counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_ns0_counters 4
# Error: No such file or directory
# list counter inet filter ns1out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns1out6
# ^^^^^^
# ERROR: ns1 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_ns0_counters 5
# Error: No such file or directory
# list counter inet filter ns1
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# ERROR: ns0in counter in ns2-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_counters 1
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# ERROR: ns0out counter in ns2-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_counters 2
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# ERROR: ns0in6 counter in ns2-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_counters 3
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# ERROR: ns0out6 counter in ns2-0Hc1Kf82 has unexpected value
(expected packets 1 bytes 104) at check_counters 4
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# ERROR: ns0in counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at check_ns0_counters 1
# Error: No such file or directory
# list counter inet filter ns0in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# ERROR: ns0in6 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at
# Error: No such file or directory
# list counter inet filter ns0in6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# ERROR: ns0out counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 0 bytes 0) at check_ns0_counters 2
# Error: No such file or directory
# list counter inet filter ns0out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# ERROR: ns0out6 counter in ns0-0Hc1Kf82 has unexpected value
(expected packets 0 bytes 0) at check_ns0_counters3
# Error: No such file or directory
# list counter inet filter ns0out6
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns2in
# ^^^^^^
# ERROR: ns2in counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_ns0_counters 4
# Error: No such file or directory
# list counter inet filter ns2in
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns2in6
# ^^^^^^
# ERROR: ns2 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_ns0_counters 5
# Error: No such file or directory
# list counter inet filter ns2
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns2out
# ^^^^^^
# ERROR: ns2out counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 84) at check_ns0_counters 4
# Error: No such file or directory
# list counter inet filter ns2out
# ^^^^^^
# Error: No such file or directory
# list counter inet filter ns2out6
# ^^^^^^
# ERROR: ns2 counter in ns0-0Hc1Kf82 has unexpected value (expected
packets 1 bytes 104) at check_ns0_counters 5
# Error: No such file or directory
# list counter inet filter ns2
# ^^^^^^
[ 92.417219] unwind: Unknown symbol address bf02e1c8
[ 92.417611] BUG: spinlock recursion on CPU#0, modprobe/762
[ 92.417622] lock: unwind_lock+0x0/0x24, .magic: dead4ead, .owner:
modprobe/762, .owner_cpu: 0
[ 92.417649] CPU: 0 PID: 762 Comm: modprobe Not tainted 6.1.4-rc1 #1
[ 92.417657] Hardware name: Generic DT based system
[ 92.417662] unwind_backtrace from show_stack+0x18/0x1c
[ 92.417682] show_stack from dump_stack_lvl+0x58/0x70
[ 92.417703] dump_stack_lvl from do_raw_spin_lock+0xcc/0xf0
[ 92.417719] do_raw_spin_lock from _raw_spin_lock_irqsave+0x60/0x74
[ 92.417740] _raw_spin_lock_irqsave from unwind_frame+0x470/0x840
[ 92.417760] unwind_frame from __save_stack_trace+0xa4/0xe0
[ 92.417775] __save_stack_trace from stack_trace_save+0x40/0x60
[ 92.417792] stack_trace_save from save_trace+0x50/0x410
[ 92.417805] save_trace from __lock_acquire+0x16dc/0x2a8c
[ 92.417815] __lock_acquire from lock_acquire+0x110/0x364
[ 92.417826] lock_acquire from _raw_spin_lock_irqsave+0x58/0x74
[ 92.417847] _raw_spin_lock_irqsave from down_trylock+0x14/0x34
[ 92.417872] down_trylock from __down_trylock_console_sem+0x30/0x98
[ 92.417894] __down_trylock_console_sem from vprintk_emit+0x98/0x35c
[ 92.417914] vprintk_emit from vprintk_default+0x28/0x30
[ 92.417933] vprintk_default from _printk+0x30/0x54
[ 92.417954] _printk from search_index+0xcc/0xd8
[ 92.417974] search_index from unwind_frame+0x630/0x840
[ 92.417989] unwind_frame from __save_stack_trace+0xa4/0xe0
[ 92.417999] __save_stack_trace from stack_trace_save+0x40/0x60
[ 92.418021] stack_trace_save from set_track_prepare+0x2c/0x58
[ 92.418044] set_track_prepare from free_debug_processing+0x380/0x61c
[ 92.418063] free_debug_processing from kmem_cache_free+0x270/0x45c
[ 92.418077] kmem_cache_free from rcu_core+0x3c8/0x1140
[ 92.418093] rcu_core from __do_softirq+0x130/0x538
[ 92.418109] __do_softirq from __irq_exit_rcu+0x14c/0x170
[ 92.418122] __irq_exit_rcu from irq_exit+0x10/0x30
[ 92.418132] irq_exit from call_with_stack+0x18/0x20
[ 92.418146] call_with_stack from __irq_svc+0x9c/0xb8
[ 92.418160] Exception stack(0xf8f59cc0 to 0xf8f59d08)
[ 92.418171] 9cc0: c634b108 f8f9e940 0000021c 00034068 00000028
c634b100 00000d01 f8fa7040
[ 92.418180] 9ce0: c634b108 c634b100 c25e54d0 ffffffbf bf02e020
f8f59d10 bf02e304 bf02e1c8
[ 92.418187] 9d00: 200d0113 ffffffff
[ 92.418191] __irq_svc from sha1_ce_transform+0x188/0x1bc [sha1_arm_ce]
[ 118.427094] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 118.430231] (detected by 1, t=2602 jiffies, g=13749, q=213 ncpus=2)
[ 118.433459] rcu: All QSes seen, last rcu_sched kthread activity
2602 (-18164--20766), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 118.438830] rcu: rcu_sched kthread timer wakeup didn't happen for
2601 jiffies! g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[ 118.444321] rcu: Possible timer handling issue on cpu=0 timer-softirq=3501
[ 118.447958] rcu: rcu_sched kthread starved for 2602 jiffies! g13749
f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[ 118.453202] rcu: Unless rcu_sched kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 118.457584] rcu: RCU grace-period kthread stack dump:
[ 118.460282] task:rcu_sched state:R stack:0 pid:14
ppid:2 flags:0x00000000
[ 118.464277] __schedule from schedule+0x60/0x100
[ 118.466571] schedule from schedule_timeout+0xbc/0x20c
[ 118.469192] schedule_timeout from rcu_gp_fqs_loop+0x180/0x8d0
[ 118.472165] rcu_gp_fqs_loop from rcu_gp_kthread+0x268/0x3c0
[ 118.475096] rcu_gp_kthread from kthread+0xfc/0x11c
[ 118.477675] kthread from ret_from_fork+0x14/0x2c
[ 118.479938] Exception stack(0xf0871fb0 to 0xf0871ff8)
[ 118.482620] 1fa0: 00000000
00000000 00000000 00000000
[ 118.486777] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 118.490778] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 118.494227] rcu: Stack dump where RCU GP kthread last ran:
[ 118.496920] Sending NMI from CPU 1 to CPUs 0:
[ 196.487089] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 196.490069] (detected by 1, t=10408 jiffies, g=13749, q=291 ncpus=2)
[ 196.493125] rcu: All QSes seen, last rcu_sched kthread activity
10408 (-10358--20766), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 196.498543] rcu: rcu_sched kthread timer wakeup didn't happen for
10407 jiffies! g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[ 196.503820] rcu: Possible timer handling issue on cpu=0 timer-softirq=3501
[ 196.507068] rcu: rcu_sched kthread starved for 10408 jiffies!
g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[ 196.511845] rcu: Unless rcu_sched kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 196.515998] rcu: RCU grace-period kthread stack dump:
[ 196.518341] task:rcu_sched state:R stack:0 pid:14
ppid:2 flags:0x00000000
[ 196.522212] __schedule from schedule+0x60/0x100
[ 196.524392] schedule from schedule_timeout+0xbc/0x20c
[ 196.526793] schedule_timeout from rcu_gp_fqs_loop+0x180/0x8d0
[ 196.529554] rcu_gp_fqs_loop from rcu_gp_kthread+0x268/0x3c0
[ 196.532231] rcu_gp_kthread from kthread+0xfc/0x11c
[ 196.534515] kthread from ret_from_fork+0x14/0x2c
[ 196.536814] Exception stack(0xf0871fb0 to 0xf0871ff8)
[ 196.539163] 1fa0: 00000000
00000000 00000000 00000000
[ 196.542933] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 196.546718] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 196.549759] rcu: Stack dump where RCU GP kthread last ran:
[ 196.552305] Sending NMI from CPU 1 to CPUs 0:
[ 274.537090] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 274.539913] (detected by 1, t=18213 jiffies, g=13749, q=294 ncpus=2)
[ 274.542844] rcu: All QSes seen, last rcu_sched kthread activity
18213 (-2553--20766), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 274.548052] rcu: rcu_sched kthread timer wakeup didn't happen for
18212 jiffies! g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[ 274.553130] rcu: Possible timer handling issue on cpu=0 timer-softirq=3501
[ 274.556276] rcu: rcu_sched kthread starved for 18213 jiffies!
g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[ 274.560932] rcu: Unless rcu_sched kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 274.564906] rcu: RCU grace-period kthread stack dump:
[ 274.567183] task:rcu_sched state:R stack:0 pid:14
ppid:2 flags:0x00000000
[ 274.570945] __schedule from schedule+0x60/0x100
[ 274.573114] schedule from schedule_timeout+0xbc/0x20c
[ 274.575482] schedule_timeout from rcu_gp_fqs_loop+0x180/0x8d0
[ 274.578110] rcu_gp_fqs_loop from rcu_gp_kthread+0x268/0x3c0
[ 274.580685] rcu_gp_kthread from kthread+0xfc/0x11c
[ 274.582907] kthread from ret_from_fork+0x14/0x2c
[ 274.585072] Exception stack(0xf0871fb0 to 0xf0871ff8)
[ 274.587375] 1fa0: 00000000
00000000 00000000 00000000
[ 274.591035] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 274.594733] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 274.597716] rcu: Stack dump where RCU GP kthread last ran:
[ 274.600211] Sending NMI from CPU 1 to CPUs 0:
[ 352.587095] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 352.589951] (detected by 1, t=26018 jiffies, g=13749, q=302 ncpus=2)
[ 352.592812] rcu: All QSes seen, last rcu_sched kthread activity
26018 (5252--20766), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 352.597854] rcu: rcu_sched kthread timer wakeup didn't happen for
26017 jiffies! g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[ 352.603086] rcu: Possible timer handling issue on cpu=0 timer-softirq=3501
[ 352.606120] rcu: rcu_sched kthread starved for 26018 jiffies!
g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[ 352.610625] rcu: Unless rcu_sched kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 352.614522] rcu: RCU grace-period kthread stack dump:
[ 352.616787] task:rcu_sched state:R stack:0 pid:14
ppid:2 flags:0x00000000
[ 352.620470] __schedule from schedule+0x60/0x100
[ 352.622642] schedule from schedule_timeout+0xbc/0x20c
[ 352.625133] schedule_timeout from rcu_gp_fqs_loop+0x180/0x8d0
[ 352.627944] rcu_gp_fqs_loop from rcu_gp_kthread+0x268/0x3c0
[ 352.630522] rcu_gp_kthread from kthread+0xfc/0x11c
[ 352.632711] kthread from ret_from_fork+0x14/0x2c
[ 352.634870] Exception stack(0xf0871fb0 to 0xf0871ff8)
[ 352.637127] 1fa0: 00000000
00000000 00000000 00000000
[ 352.640687] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 352.644262] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 352.647148] rcu: Stack dump where RCU GP kthread last ran:
[ 352.649559] Sending NMI from CPU 1 to CPUs 0:
[ 430.637222] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 430.640203] (detected by 1, t=33823 jiffies, g=13749, q=314 ncpus=2)
[ 430.643245] rcu: All QSes seen, last rcu_sched kthread activity
33823 (13057--20766), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 430.648624] rcu: rcu_sched kthread timer wakeup didn't happen for
33822 jiffies! g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[ 430.653861] rcu: Possible timer handling issue on cpu=0 timer-softirq=3501
[ 430.657085] rcu: rcu_sched kthread starved for 33823 jiffies!
g13749 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[ 430.661780] rcu: Unless rcu_sched kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 430.665876] rcu: RCU grace-period kthread stack dump:
[ 430.668225] task:rcu_sched state:R stack:0 pid:14
ppid:2 flags:0x00000000
[ 430.672089] __schedule from schedule+0x60/0x100
[ 430.674294] schedule from schedule_timeout+0xbc/0x20c
[ 430.676805] schedule_timeout from rcu_gp_fqs_loop+0x180/0x8d0
[ 430.679569] rcu_gp_fqs_loop from rcu_gp_kthread+0x268/0x3c0
[ 430.682281] rcu_gp_kthread from kthread+0xfc/0x11c
[ 430.684608] kthread from ret_from_fork+0x14/0x2c
[ 430.686809] Exception stack(0xf0871fb0 to 0xf0871ff8)
[ 430.689211] 1fa0: 00000000
00000000 00000000 00000000
[ 430.692951] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 430.696735] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 430.699829] rcu: Stack dump where RCU GP kthread last ran:
[ 430.702415] Sending NMI from CPU 1 to CPUs 0:
[1]
https://lkft.validation.linaro.org/scheduler/job/6022385#L1224https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.3…https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.3…
metadata:
git_ref: linux-6.1.y
git_repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
git_sha: a31425cbf493ef8bc7f7ce775a1028b1e0612f32
git_describe: v6.1.3-208-ga31425cbf493
kernel_version: 6.1.4-rc1
kernel-config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2JrzrHzfFQKu8CwO4A3H…
build-url: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc/-/pipelines/7…
artifact-location:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2JrzrHzfFQKu8CwO4A3H…
toolchain: gcc-10
vmlinux.xz: https://storage.tuxsuite.com/public/linaro/lkft/builds/2JrzrHzfFQKu8CwO4A3H…
System.map: https://storage.tuxsuite.com/public/linaro/lkft/builds/2JrzrHzfFQKu8CwO4A3H…
--
Linaro LKFT
https://lkft.linaro.org
Backports the following three patches to fix the issue of IMA mishandling
LSM based rule during LSM policy update, causing a file to match an
unexpected rule.
v5:
goes back to ima_lsm_free_rule() instead to avoid freeing
rule->fsname.
v4:
Make use of the exisiting ima_free_rule() instead of backported
ima_lsm_free_rule(). Which resolves additional memory leak issues.
v3:
Backport "LSM: switch to blocking policy update notifiers" as well, as
the prerequsite of "ima: use the lsm policy update notifier".
v2:
Re-adjust the bacported logic.
GUO Zihua (1):
ima: Handle -ESTALE returned by ima_filter_rule_match()
Janne Karhunen (2):
LSM: switch to blocking policy update notifiers
ima: use the lsm policy update notifier
drivers/infiniband/core/device.c | 4 +-
include/linux/security.h | 12 +--
security/integrity/ima/ima.h | 2 +
security/integrity/ima/ima_main.c | 8 ++
security/integrity/ima/ima_policy.c | 151 ++++++++++++++++++++++------
security/security.c | 23 +++--
security/selinux/hooks.c | 2 +-
security/selinux/selinuxfs.c | 2 +-
8 files changed, 156 insertions(+), 48 deletions(-)
--
2.17.1
Removing the firmware framebuffer from the driver means that even
if the driver doesn't support the IP blocks in a GPU it will no
longer be functional after the driver fails to initialize.
This change will ensure that unsupported IP blocks at least cause
the driver to work with the EFI framebuffer.
Cc: stable(a)vger.kernel.org
Suggested-by: Alex Deucher <alexander.deucher(a)amd.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++++++++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ------
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 9a1a5c2864a0..cdb681398a99 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -37,6 +37,7 @@
#include <linux/pci-p2pdma.h>
#include <drm/drm_atomic_helper.h>
+#include <drm/drm_aperture.h>
#include <drm/drm_probe_helper.h>
#include <drm/amdgpu_drm.h>
#include <linux/vgaarb.h>
@@ -89,6 +90,8 @@ MODULE_FIRMWARE("amdgpu/navi12_gpu_info.bin");
#define AMDGPU_MAX_RETRY_LIMIT 2
#define AMDGPU_RETRY_SRIOV_RESET(r) ((r) == -EBUSY || (r) == -ETIMEDOUT || (r) == -EINVAL)
+static const struct drm_driver amdgpu_kms_driver;
+
const char *amdgpu_asic_name[] = {
"TAHITI",
"PITCAIRN",
@@ -3685,6 +3688,11 @@ int amdgpu_device_init(struct amdgpu_device *adev,
if (r)
return r;
+ /* Get rid of things like offb */
+ r = drm_aperture_remove_conflicting_pci_framebuffers(adev->pdev, &amdgpu_kms_driver);
+ if (r)
+ return r;
+
/* Enable TMZ based on IP_VERSION */
amdgpu_gmc_tmz_set(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index db7e34eacc35..b9f14ec9edb2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -23,7 +23,6 @@
*/
#include <drm/amdgpu_drm.h>
-#include <drm/drm_aperture.h>
#include <drm/drm_drv.h>
#include <drm/drm_gem.h>
#include <drm/drm_vblank.h>
@@ -2096,11 +2095,6 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
}
#endif
- /* Get rid of things like offb */
- ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &amdgpu_kms_driver);
- if (ret)
- return ret;
-
adev = devm_drm_dev_alloc(&pdev->dev, &amdgpu_kms_driver, typeof(*adev), ddev);
if (IS_ERR(adev))
return PTR_ERR(adev);
--
2.34.1
Backports the following three patches to fix the issue of IMA mishandling
LSM based rule during LSM policy update, causing a file to match an
unexpected rule.
v4:
Make use of the exisiting ima_free_rule() instead of backported
ima_lsm_free_rule(). Which resolves additional memory leak issues.
v3:
Backport "LSM: switch to blocking policy update notifiers" as well, as
the prerequsite of "ima: use the lsm policy update notifier".
v2:
Re-adjust the bacported logic.
GUO Zihua (1):
ima: Handle -ESTALE returned by ima_filter_rule_match()
Janne Karhunen (2):
LSM: switch to blocking policy update notifiers
ima: use the lsm policy update notifier
drivers/infiniband/core/device.c | 4 +-
include/linux/security.h | 12 +--
security/integrity/ima/ima.h | 2 +
security/integrity/ima/ima_main.c | 8 ++
security/integrity/ima/ima_policy.c | 136 ++++++++++++++++++++++------
security/security.c | 23 +++--
security/selinux/hooks.c | 2 +-
security/selinux/selinuxfs.c | 2 +-
8 files changed, 143 insertions(+), 46 deletions(-)
--
2.17.1
The patch titled
Subject: mm/hugetlb: pre-allocate pgtable pages for uffd wr-protects
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-hugetlb-pre-allocate-pgtable-pages-for-uffd-wr-protects.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Peter Xu <peterx(a)redhat.com>
Subject: mm/hugetlb: pre-allocate pgtable pages for uffd wr-protects
Date: Wed, 4 Jan 2023 17:52:05 -0500
Userfaultfd-wp uses pte markers to mark wr-protected pages for both shmem
and hugetlb. Shmem has pre-allocation ready for markers, but hugetlb path
was overlooked.
Doing so by calling huge_pte_alloc() if the initial pgtable walk fails to
find the huge ptep. It's possible that huge_pte_alloc() can fail with
high memory pressure, in that case stop the loop immediately and fail
silently. This is not the most ideal solution but it matches with what we
do with shmem meanwhile it avoids the splat in dmesg.
Link: https://lkml.kernel.org/r/20230104225207.1066932-2-peterx@redhat.com
Fixes: 60dfaad65aa9 ("mm/hugetlb: allow uffd wr-protect none ptes")
Signed-off-by: Peter Xu <peterx(a)redhat.com>
Reported-by: James Houghton <jthoughton(a)google.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Axel Rasmussen <axelrasmussen(a)google.com>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: Muchun Song <songmuchun(a)bytedance.com>
Cc: Nadav Amit <nadav.amit(a)gmail.com>
Cc: <stable(a)vger.kernel.org> [5.19+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/hugetlb.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/mm/hugetlb.c~mm-hugetlb-pre-allocate-pgtable-pages-for-uffd-wr-protects
+++ a/mm/hugetlb.c
@@ -6660,8 +6660,17 @@ unsigned long hugetlb_change_protection(
spinlock_t *ptl;
ptep = huge_pte_offset(mm, address, psize);
if (!ptep) {
- address |= last_addr_mask;
- continue;
+ if (!uffd_wp) {
+ address |= last_addr_mask;
+ continue;
+ }
+ /*
+ * Userfaultfd wr-protect requires pgtable
+ * pre-allocations to install pte markers.
+ */
+ ptep = huge_pte_alloc(mm, vma, address, psize);
+ if (!ptep)
+ break;
}
ptl = huge_pte_lock(h, mm, ptep);
if (huge_pmd_unshare(mm, vma, address, ptep)) {
_
Patches currently in -mm which might be from peterx(a)redhat.com are
mm-hugetlb-pre-allocate-pgtable-pages-for-uffd-wr-protects.patch
mm-uffd-fix-pte-marker-when-fork-without-fork-event.patch
mm-fix-a-few-rare-cases-of-using-swapin-error-pte-marker.patch
mm-uffd-always-wr-protect-pte-in-ptepmd_mkuffd_wp.patch
mm-hugetlb-let-vma_offset_start-to-return-start.patch
mm-hugetlb-dont-wait-for-migration-entry-during-follow-page.patch
mm-hugetlb-document-huge_pte_offset-usage.patch
mm-hugetlb-move-swap-entry-handling-into-vma-lock-when-faulted.patch
mm-hugetlb-make-userfaultfd_huge_must_wait-safe-to-pmd-unshare.patch
mm-hugetlb-make-hugetlb_follow_page_mask-safe-to-pmd-unshare.patch
mm-hugetlb-make-follow_hugetlb_page-safe-to-pmd-unshare.patch
mm-hugetlb-make-walk_hugetlb_range-safe-to-pmd-unshare.patch
mm-hugetlb-introduce-hugetlb_walk.patch
mm-mprotect-use-long-for-page-accountings-and-retval.patch
mm-uffd-detect-pgtable-allocation-failures.patch
The patch titled
Subject: mm: fix vma->anon_name memory leak for anonymous shmem VMAs
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-fix-vma-anon_name-memory-leak-for-anonymous-shmem-vmas.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Suren Baghdasaryan <surenb(a)google.com>
Subject: mm: fix vma->anon_name memory leak for anonymous shmem VMAs
Date: Wed, 4 Jan 2023 16:02:40 -0800
free_anon_vma_name() is missing a check for anonymous shmem VMA which
leads to a memory leak due to refcount not being dropped. Fix this by
calling anon_vma_name_put() unconditionally. It will free vma->anon_name
whenever it's non-NULL.
Link: https://lkml.kernel.org/r/20230105000241.1450843-1-surenb@google.com
Fixes: d09e8ca6cb93 ("mm: anonymous shared memory naming")
Signed-off-by: Suren Baghdasaryan <surenb(a)google.com>
Suggested-by: David Hildenbrand <david(a)redhat.com>
Reported-by: syzbot+91edf9178386a07d06a7(a)syzkaller.appspotmail.com
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Hugh Dickins <hughd(a)google.com>
Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/mm_inline.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/include/linux/mm_inline.h~mm-fix-vma-anon_name-memory-leak-for-anonymous-shmem-vmas
+++ a/include/linux/mm_inline.h
@@ -413,8 +413,7 @@ static inline void free_anon_vma_name(st
* Not using anon_vma_name because it generates a warning if mmap_lock
* is not held, which might be the case here.
*/
- if (!vma->vm_file)
- anon_vma_name_put(vma->anon_name);
+ anon_vma_name_put(vma->anon_name);
}
static inline bool anon_vma_name_eq(struct anon_vma_name *anon_name1,
_
Patches currently in -mm which might be from surenb(a)google.com are
mm-fix-vma-anon_name-memory-leak-for-anonymous-shmem-vmas.patch
These fixes have been in next, though not as these commits.
I'd like to apologize again to contributors for missing the merge
window with new features. These by necessity have been pushed out
to the next merge window. This pull only has bugfixes.
I put automation in place to help prevent missing merge window
in the future.
The following changes since commit 1b929c02afd37871d5afb9d498426f83432e71c2:
Linux 6.2-rc1 (2022-12-25 13:41:39 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to a26116c1e74028914f281851488546c91cbae57d:
virtio_blk: Fix signedness bug in virtblk_prep_rq() (2022-12-28 05:28:11 -0500)
----------------------------------------------------------------
virtio,vhost,vdpa: fixes, cleanups
mostly fixes all over the place, a couple of cleanups.
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
----------------------------------------------------------------
Angus Chen (2):
virtio_pci: modify ENOENT to EINVAL
virtio_blk: use UINT_MAX instead of -1U
Cindy Lu (2):
vhost_vdpa: fix the crash in unmap a large memory
vdpa_sim_net: should not drop the multicast/broadcast packet
Colin Ian King (1):
RDMA/mlx5: remove variable i
Davidlohr Bueso (2):
tools/virtio: remove stray characters
tools/virtio: remove smp_read_barrier_depends()
Dawei Li (1):
virtio: Implementing attribute show with sysfs_emit
Dmitry Fomichev (1):
virtio-blk: use a helper to handle request queuing errors
Eli Cohen (5):
vdpa/mlx5: Fix rule forwarding VLAN to TIR
vdpa/mlx5: Return error on vlan ctrl commands if not supported
vdpa/mlx5: Fix wrong mac address deletion
vdpa/mlx5: Avoid using reslock in event_handler
vdpa/mlx5: Avoid overwriting CVQ iotlb
Harshit Mogalapalli (1):
vduse: Validate vq_num in vduse_validate_config()
Jason Wang (2):
vdpa: conditionally fill max max queue pair for stats
vdpasim: fix memory leak when freeing IOTLBs
Rafael Mendonca (1):
virtio_blk: Fix signedness bug in virtblk_prep_rq()
Ricardo Cañuelo (1):
tools/virtio: initialize spinlocks in vring_test.c
Rong Wang (1):
vdpa/vp_vdpa: fix kfree a wrong pointer in vp_vdpa_remove
Shaomin Deng (1):
tools: Delete the unneeded semicolon after curly braces
Shaoqin Huang (2):
virtio_pci: use helper function is_power_of_2()
virtio_ring: use helper function is_power_of_2()
Si-Wei Liu (1):
vdpa: merge functionally duplicated dev_features attributes
Stefano Garzarella (4):
vringh: fix range used in iotlb_translate()
vhost: fix range used in translate_desc()
vhost-vdpa: fix an iotlb memory leak
vdpa_sim: fix vringh initialization in vdpasim_queue_ready()
Wei Yongjun (1):
virtio-crypto: fix memory leak in virtio_crypto_alg_skcipher_close_session()
Yuan Can (1):
vhost/vsock: Fix error handling in vhost_vsock_init()
ruanjinjie (1):
vdpa_sim: fix possible memory leak in vdpasim_net_init() and vdpasim_blk_init()
wangjianli (1):
tools/virtio: Variable type completion
drivers/block/virtio_blk.c | 35 +++++-----
.../crypto/virtio/virtio_crypto_skcipher_algs.c | 3 +-
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 5 +-
drivers/vdpa/mlx5/core/mr.c | 46 +++++++------
drivers/vdpa/mlx5/net/mlx5_vnet.c | 78 +++++++---------------
drivers/vdpa/vdpa.c | 11 ++-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 7 +-
drivers/vdpa/vdpa_sim/vdpa_sim_blk.c | 4 +-
drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 7 +-
drivers/vdpa/vdpa_user/vduse_dev.c | 3 +
drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +-
drivers/vhost/vdpa.c | 52 +++++++++------
drivers/vhost/vhost.c | 4 +-
drivers/vhost/vringh.c | 5 +-
drivers/vhost/vsock.c | 9 ++-
drivers/virtio/virtio.c | 12 ++--
drivers/virtio/virtio_pci_modern.c | 4 +-
drivers/virtio/virtio_ring.c | 2 +-
include/uapi/linux/vdpa.h | 4 +-
tools/virtio/ringtest/main.h | 37 +++++-----
tools/virtio/virtio-trace/trace-agent-ctl.c | 2 +-
tools/virtio/virtio_test.c | 2 +-
tools/virtio/vringh_test.c | 2 +
23 files changed, 173 insertions(+), 163 deletions(-)
From: "Joel Fernandes (Google)" <joel(a)joelfernandes.org>
During rcutorture shutdown, the rcu_torture_cleanup() function calls
torture_cleanup_begin(), which sets the fullstop global variable to
FULLSTOP_RMMOD. This causes the rcutorture threads for readers and
fakewriters to exit all of their "while" loops and start shutting down.
They then call torture_kthread_stopping(), which in turn waits for
kthread_stop() to be called. However, rcu_torture_cleanup() has
not yet called kthread_stop() on those threads, and before it gets a
chance to do so, multiple instances of torture_kthread_stopping() invoke
schedule_timeout_interruptible(1) in a tight loop. Tracing confirms that
TIMER_SOFTIRQ can then continuously execute timer callbacks. If that
TIMER_SOFTIRQ preempts the task executing rcu_torture_cleanup(), that
task might never invoke kthread_stop().
This commit improves this situation by increasing the timeout passed to
schedule_timeout_interruptible() from one jiffy to 1/20th of a second.
This change prevents TIMER_SOFTIRQ from monopolizing its CPU, thus
allowing rcu_torture_cleanup() to carry out the needed kthread_stop()
invocations. Testing has shown 100 runs of TREE07 passing reliably,
as oppose to the tens-of-percent failure rates seen beforehand.
Cc: Paul McKenney <paulmck(a)kernel.org>
Cc: Frederic Weisbecker <fweisbec(a)gmail.com>
Cc: Zhouyi Zhou <zhouzhouyi(a)gmail.com>
Cc: <stable(a)vger.kernel.org> # 6.0.x
Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org>
Tested-by: Zhouyi Zhou <zhouzhouyi(a)gmail.com>
Reviewed-by: Davidlohr Bueso <dave(a)stgolabs.net>
Signed-off-by: Paul E. McKenney <paulmck(a)kernel.org>
---
kernel/torture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/torture.c b/kernel/torture.c
index 29afc62f2bfec..1a0519b836ac9 100644
--- a/kernel/torture.c
+++ b/kernel/torture.c
@@ -915,7 +915,7 @@ void torture_kthread_stopping(char *title)
VERBOSE_TOROUT_STRING(buf);
while (!kthread_should_stop()) {
torture_shutdown_absorb(title);
- schedule_timeout_uninterruptible(1);
+ schedule_timeout_uninterruptible(HZ / 20);
}
}
EXPORT_SYMBOL_GPL(torture_kthread_stopping);
--
2.31.1.189.g2e36527f23
Hello,
I am running Manjaro, after upgrading from kernel 6.0.15 to 6.1.1
(https://gitlab.manjaro.org/packages/core/linux61) I have noticed that
suspend stopped working, what I can see in the logs is the following
issue which IMO points to cs35l41
Machine:
Type: Laptop System: LENOVO product: 82N6 v: Legion 7 16ACHg6
journalctl output below:
Jan 02 21:52:54 legion16 systemd[1]: Starting System Suspend...
Jan 02 21:52:54 legion16 wpa_supplicant[1193]: wlp4s0:
CTRL-EVENT-DSCP-POLICY clear_all
Jan 02 21:52:54 legion16 systemd-sleep[2912]: Entering sleep state
'suspend'...
Jan 02 21:52:54 legion16 kernel: PM: suspend entry (deep)
Jan 02 21:52:54 legion16 kernel: Filesystems sync: 0.008 seconds
Jan 02 21:52:54 legion16 wpa_supplicant[1193]: wlp4s0:
CTRL-EVENT-DSCP-POLICY clear_all
Jan 02 21:52:54 legion16 wpa_supplicant[1193]: nl80211: deinit
ifname=wlp4s0 disabled_11b_rates=0
Jan 02 21:52:54 legion16 plasmashell[1770]: qml: [DEBUG] - onNewData
Jan 02 21:52:54 legion16 kernel: Freezing user space processes ...
(elapsed 0.002 seconds) done.
Jan 02 21:52:54 legion16 kernel: OOM killer disabled.
Jan 02 21:52:54 legion16 kernel: Freezing remaining freezable tasks ...
(elapsed 0.001 seconds) done.
Jan 02 21:52:54 legion16 kernel: printk: Suspending console(s) (use
no_console_suspend to debug)
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: System Suspend not supported
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.0: System Suspend not supported
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: PM: dpm_run_callback():
cs35l41_system_suspend+0x0/0xd0 [snd_hda_scodec_cs35l41] returns -22
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.0: PM: dpm_run_callback():
cs35l41_system_suspend+0x0/0xd0 [snd_hda_scodec_cs35l41] returns -22
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: PM: failed to suspend async: error -22
Jan 02 21:52:54 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.0: PM: failed to suspend async: error -22
Jan 02 21:52:54 legion16 kernel: PM: Some devices failed to suspend, or
early wake event detected
Jan 02 21:52:54 legion16 kernel: OOM killer enabled.
Jan 02 21:52:54 legion16 kernel: Restarting tasks ... done.
Jan 02 21:52:54 legion16 kernel: random: crng reseeded on system resumption
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO: Relay listener
(dynamic+https://relays.syncthing.net/endpoint) shutting down
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO:
listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint:
service dynamic+https://relays.syncthing.net/endpoint failed: could not
find a connectable relay
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO: Relay listener
(dynamic+https://relays.syncthing.net/endpoint) starting
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO: Relay listener
(dynamic+https://relays.syncthing.net/endpoint) shutting down
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO:
listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint:
service dynamic+https://relays.syncthing.net/endpoint failed: Get
"https://relays.syncthing.net/endpoint": dial tcp: lookup
relays.syncthing.net on [::1]:53: read udp [::1]:58193->[::1]:53: read:
connection refused
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO: Relay listener
(dynamic+https://relays.syncthing.net/endpoint) starting
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO: Relay listener
(dynamic+https://relays.syncthing.net/endpoint) shutting down
Jan 02 21:52:54 legion16 syncthing[1588]: [RBC2R] INFO:
listenerSupervisor@dynamic+https://relays.syncthing.net/endpoint:
service dynamic+https://relays.syncthing.net/endpoint failed: Get
"https://relays.syncthing.net/endpoint": dial tcp: lookup
relays.syncthing.net on [::1]:53: read udp [::1]:35430->[::1]:53: read:
connection refused
Jan 02 21:52:55 legion16 bluetoothd[942]: Controller resume with wake
event 0x0
Jan 02 21:52:55 legion16 kernel: PM: suspend exit
Jan 02 21:52:55 legion16 kernel: PM: suspend entry (s2idle)
Jan 02 21:52:55 legion16 kernel: Filesystems sync: 0.004 seconds
Jan 02 21:52:55 legion16 kernel: Freezing user space processes ...
(elapsed 0.001 seconds) done.
Jan 02 21:52:55 legion16 kernel: OOM killer disabled.
Jan 02 21:52:55 legion16 kernel: Freezing remaining freezable tasks ...
(elapsed 0.216 seconds) done.
Jan 02 21:52:55 legion16 kernel: printk: Suspending console(s) (use
no_console_suspend to debug)
Jan 02 21:52:55 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: System Suspend not supported
Jan 02 21:52:55 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: PM: dpm_run_callback():
cs35l41_system_suspend+0x0/0xd0 [snd_hda_scodec_cs35l41] returns -22
Jan 02 21:52:55 legion16 kernel: cs35l41-hda
i2c-CLSA0100:00-cs35l41-hda.1: PM: failed to suspend async: error -22
Jan 02 21:52:55 legion16 kernel: PM: Some devices failed to suspend, or
early wake event detected
Jan 02 21:52:55 legion16 kernel: OOM killer enabled.
Jan 02 21:52:55 legion16 plasmashell[1770]: qml: [DEBUG] - onNewData
Jan 02 21:52:55 legion16 kernel: Restarting tasks ... done.
Jan 02 21:52:55 legion16 kernel: random: crng reseeded on system resumption
Jan 02 21:52:55 legion16 systemd-sleep[2912]: Failed to put system to
sleep. System resumed again: Invalid argument
Jan 02 21:52:55 legion16 kernel: PM: suspend exit
Jan 02 21:52:55 legion16 bluetoothd[942]: Controller resume with wake
event 0x0
Jan 02 21:52:55 legion16 systemd[1]: systemd-suspend.service: Main
process exited, code=exited, status=1/FAILURE
Jan 02 21:52:55 legion16 systemd[1]: systemd-suspend.service: Failed
with result 'exit-code'.
Jan 02 21:52:55 legion16 systemd[1]: Failed to start System Suspend.
Jan 02 21:52:55 legion16 systemd[1]: Dependency failed for Suspend.
I have to admit I have not tried 6.1.2 yet but I could not find any
changes related to this module (opposite to 6.1 where there was quite a
few including suspend - commit dca45efbe3c870a4ad2107fe625109b3765c0fea).
I can provide any additional information or logs if necessary.
Best Regards,
Waldek