* Re: [PATCH v2 2/5] nbd: replace socks pointer array with xarray
From: yu kuai @ 2026-07-05 10:02 UTC (permalink / raw)
To: Yang Erkun, josef, axboe, hch, yukuai
Cc: yi.zhang, chengzhihao1, echo.chenlin, leo.lilong, wangkefeng.wang,
linux-block, nbd
In-Reply-To: <20260625084458.4171890-3-yangerkun@huawei.com>
Hi,
在 2026/6/25 16:44, Yang Erkun 写道:
> Replace the krealloc-based struct nbd_sock **socks array with struct
> xarray socks. Each nbd sock is fully initialized before being stored
> into the xarray via xa_store(), ensuring concurrent readers calling
> xa_load() never observe a partially initialized socket.
>
> Convert all array index accesses to xa_load() and open-coded for-loops
> to xa_for_each().
>
> Signed-off-by: Long Li<leo.lilong@huawei.com>
xarray may not be good idea for IO hot path because of the overhead.
https://lore.kernel.org/all/60f9a88b-b750-3579-bdfd-5421f2040406@huaweicloud.com/
--
Thanks,
Kuai
^ permalink raw reply
* [PATCH] xen-blkfront: fix double completion of split requests on resume
From: Doruk Tan Ozturk @ 2026-07-05 11:56 UTC (permalink / raw)
To: Roger Pau Monné, Juergen Gross
Cc: Stefano Stabellini, Oleksandr Tyshchenko, Jens Axboe, xen-devel,
linux-block, linux-kernel, Doruk Tan Ozturk
When a block request is too large for a single ring entry and the
backend does not support indirect descriptors, blkfront splits it
across two ring requests. blkif_ring_get_request() is called twice
and both shadow slots (shadow[id] and shadow[extra_id]) are made to
point at the *same* struct request, linked together through
associated_id.
On the normal completion path blkif_completion() collapses the pair:
it recycles the second slot via add_id_to_freelist() and only completes
the request once. The suspend/resume path in blkfront_resume() does
not. It walks every physical shadow slot and, for each slot whose
->request is set, calls blk_mq_end_request() or re-queues
->request. For an in-flight split request this visits the shared
struct request twice, so on resume/migration the same request is
ended (or re-queued) two times. The second visit is a double
blk_mq_end_request() (refcount underflow / double free) and a
use-after-free read of req->bio, which was cleared on the first visit.
Skip the secondary slot of a split request in the resume walk, so each
logical request is completed or re-queued exactly once, matching how
blkif_completion() already treats the pair. The secondary slot is the
one that is linked (associated_id != NO_ASSOCIATED_ID) and carries no
scatter-gather list (num_sg == 0); the first slot always keeps the
scatter-gather list.
This was found by 0sec automated security-research tooling
(https://0sec.ai). The bug is only reachable on suspend/resume or live
migration of a guest whose backend lacks indirect-descriptor support, so
it has no local reproducer; the fix is by source inspection against the
existing blkif_completion() collapse logic.
Fixes: 6cc568339047 ("xen/blkfront: Handle non-indirect grant with 64KB pages")
Assisted-by: 0sec:claude-opus-4-8
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
drivers/block/xen-blkfront.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index f765970578f9..b2e83fd0c77b 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2079,6 +2079,15 @@ static int blkfront_resume(struct xenbus_device *dev)
if (!shadow[j].request)
continue;
+ /*
+ * Split requests alias one request across two shadow
+ * slots; skip the sg-less secondary so it completes
+ * once, like blkif_completion() does.
+ */
+ if (shadow[j].associated_id != NO_ASSOCIATED_ID &&
+ shadow[j].num_sg == 0)
+ continue;
+
/*
* Get the bios in the request so we can re-queue them.
*/
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/7] rust: Use kernel style vertical imports in various drivers
From: Gary Guo @ 2026-07-05 12:08 UTC (permalink / raw)
To: Guru Das Srinagesh, Andrew Lunn
Cc: Miguel Ojeda, rust-for-linux, linux-kernel, Danilo Krummrich,
Abdiel Janulgue, Daniel Almeida, Robin Murphy, Andreas Hindborg,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Alice Ryhl, Trevor Gross, Tamir Duberstein, Alexandre Courbot,
Onur Özkan, Drew Fustini, Guo Ren, Fu Wei, Michal Wilczynski,
Uwe Kleine-König, Rafael J. Wysocki, Viresh Kumar,
Jens Axboe, FUJITA Tomonori, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Airlie, Simona Vetter, driver-core, linux-riscv, linux-pwm,
linux-pm, linux-block, netdev, nova-gpu, dri-devel
In-Reply-To: <akmnh0AKFfu9-OYn@gurudas.dev>
On Sun Jul 5, 2026 at 1:38 AM BST, Guru Das Srinagesh wrote:
> On Mon, Jun 29, 2026 at 04:06:36PM +0200, Andrew Lunn wrote:
>> On Sun, Jun 28, 2026 at 08:38:14PM -0700, Guru Das Srinagesh wrote:
>> > Came across a recent commit bc58905eb07 ("samples: rust_misc_device: use
>> > vertical import style") and found a few more locations that could
>> > benefit from this cleanup. No functional changes.
>> >
>> > Signed-off-by: Guru Das Srinagesh <linux@gurudas.dev>
>> > ---
>> > Guru Das Srinagesh (7):
>> > samples: rust_dma: use vertical import style
>> > pwm: th1520: use vertical import style
>> > cpufreq: rcpufreq_dt: use vertical import style
>> > block: rnull: use vertical import style
>> > net: phy: ax88796b: use vertical import style
>> > net: phy: qt2025: use vertical import style
>> > drm/nova: use vertical import style
>>
>> You have multiple subsystems here, so you need to split this patch
>> setup, per subsystem, and submit them separately. Maintainers only
>> accept patchsets for their own subsystems.
>>
>> For netdev, please take a read of:
>>
>> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>>
>> You need to get the correct tree, and set the Subject: line correctly.
>>
>> Andrew
>
> Hi Andrew,
>
> Thanks for the feedback.
>
> I was aware of the per-subsystem rule, but reasoned that since these changes are
> purely about Rust import formatting coding style with no functional impact on any
> subsystem, they might go through the rust-for-linux tree with acks from the
> respective subsystem maintainers. The Rust coding style is independent of any
> subsystem-specific guidelines.
Patches should usually be merged via their usual tree, otherwise you're just
creating unnecessary merge conflicts.
There are obiviously exceptions to this for series that need to touch multiple
subsystems and cannot be split, but it is not the case for this sort of small
cleanups.
Best,
Gary
>
> Is that reasoning off-base, or is the right path to split these out per subsystem
> regardless?
^ permalink raw reply
* Re: [PATCH 3/7] cpufreq: rcpufreq_dt: use vertical import style
From: Miguel Ojeda @ 2026-07-05 12:12 UTC (permalink / raw)
To: Miguel Ojeda, Zhongqiu Han, Miguel Ojeda, rust-for-linux,
linux-kernel, Danilo Krummrich, Abdiel Janulgue, Daniel Almeida,
Robin Murphy, Andreas Hindborg, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Tamir Duberstein, Alexandre Courbot, Onur Özkan,
Drew Fustini, Guo Ren, Fu Wei, Michal Wilczynski,
Uwe Kleine-König, Rafael J. Wysocki, Viresh Kumar,
Jens Axboe, FUJITA Tomonori, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Airlie, Simona Vetter, driver-core,
linux-riscv, linux-pwm, linux-pm, linux-block, netdev, nova-gpu,
dri-devel
In-Reply-To: <akmtA7EbVBdhRAOq@gurudas.dev>
On Sun, Jul 5, 2026 at 3:02 AM Guru Das Srinagesh <linux@gurudas.dev> wrote:
>
> But unfortunately, since `imports_layout` is an unstable option currently [1], it
> cannot be used straightaway.
Yeah, we are trying to get that one stabilized -- upstream `rustfmt`
is aware and working on it. More context at:
https://github.com/rust-lang/rustfmt/issues/6829
https://github.com/Rust-for-Linux/linux/issues/398
> However, .rustfmt.toml already has a section of commented-out unstable options kept
> as a reference for when they stabilize. Would it make sense to add `#imports_layout =
> "Vertical"` there? If so, I can include it in v2.
That may be a bit confusing, because we still need to add the `//`
comments. And if you add them, then `rustfmt` will format properly,
i.e. you don't need the unstable option.
Put another way: the intended workflow is to add the `//` and then to
run `make ... rustfmt`.
I hope that clarifies!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 0/7] rust: Use kernel style vertical imports in various drivers
From: Miguel Ojeda @ 2026-07-05 12:22 UTC (permalink / raw)
To: Andrew Lunn, Miguel Ojeda, rust-for-linux, linux-kernel,
Danilo Krummrich, Abdiel Janulgue, Daniel Almeida, Robin Murphy,
Andreas Hindborg, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, Trevor Gross, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Drew Fustini, Guo Ren, Fu Wei,
Michal Wilczynski, Uwe Kleine-König, Rafael J. Wysocki,
Viresh Kumar, Jens Axboe, FUJITA Tomonori, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Airlie, Simona Vetter, driver-core,
linux-riscv, linux-pwm, linux-pm, linux-block, netdev, nova-gpu,
dri-devel
In-Reply-To: <akmnh0AKFfu9-OYn@gurudas.dev>
On Sun, Jul 5, 2026 at 2:38 AM Guru Das Srinagesh <linux@gurudas.dev> wrote:
>
> Miguel, could you please indicate if you have a preference here?
Gary is right -- it depends.
Generally speaking, it is best to do changes through each tree;
especially so if it is the kind of thing that may be prone to
conflicts.
In certain cases, yes, I may take treewide changes, with Acked-by's
from maintainers (and very exceptionally I have done it without that
if e.g. it is trivial enough and enough time has passed -- trusting
that people trust me to do so).
It is part of why the Rust tree exists, i.e. as a fallback and also
for convenience in certain cases.
I hope that clarifies.
Cheers,
Miguel
^ permalink raw reply
* [syzbot] Monthly block report (Jul 2026)
From: syzbot @ 2026-07-05 12:32 UTC (permalink / raw)
To: linux-block, linux-kernel, syzkaller-bugs
Hello block maintainers/developers,
This is a 31-day syzbot report for the block subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/block
During the period, 0 new issues were detected and 0 were fixed.
In total, 19 issues are still open and 112 have already been fixed.
There are also 25 low-priority issues.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 1162 No general protection fault in lo_rw_aio
https://syzkaller.appspot.com/bug?extid=cd8a9a308e879a4e2c28
<2> 31 No INFO: task hung in read_cache_folio (6)
https://syzkaller.appspot.com/bug?extid=9db0864859224b833108
<3> 102 No INFO: rcu detected stall in blkdev_release (3)
https://syzkaller.appspot.com/bug?extid=07d6f9c5d7633ed4a5c8
<4> 89 Yes INFO: rcu detected stall in kjournald2 (2)
https://syzkaller.appspot.com/bug?extid=14c6ac6811273526cfa5
<5> 25 No KASAN: slab-out-of-bounds Read in blk_mq_free_rqs
https://syzkaller.appspot.com/bug?extid=e90526cab23b9efcd03c
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH 0/7] rust: Use kernel style vertical imports in various drivers
From: Andrew Lunn @ 2026-07-05 15:03 UTC (permalink / raw)
To: Miguel Ojeda, rust-for-linux, linux-kernel, Danilo Krummrich,
Abdiel Janulgue, Daniel Almeida, Robin Murphy, Andreas Hindborg,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Alice Ryhl, Trevor Gross, Tamir Duberstein, Alexandre Courbot,
Onur Özkan, Drew Fustini, Guo Ren, Fu Wei, Michal Wilczynski,
Uwe Kleine-König, Rafael J. Wysocki, Viresh Kumar,
Jens Axboe, FUJITA Tomonori, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Airlie, Simona Vetter, driver-core, linux-riscv, linux-pwm,
linux-pm, linux-block, netdev, nova-gpu, dri-devel
In-Reply-To: <akmnh0AKFfu9-OYn@gurudas.dev>
> Is that reasoning off-base, or is the right path to split these out per subsystem
> regardless?
Adding to what others have said, some subsystems have there own CI
system which tests every patch. Does it build? Does it add new
warning, is sparse happy, are there more self test failures. What do
different AIs think of the patch etc. Cross subsystem patches don't
always hit the per subsystem CI tests.
So in general, it is better to submit per subsystem.
Andrew
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox