From: mateusz.nowicki@posteo.net
To: Caleb Sander Mateos <csander@purestorage.com>
Cc: Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools
Date: Sat, 23 May 2026 08:17:38 +0000 [thread overview]
Message-ID: <8a73dd99b8280c5d1bde9c6caed8323b@posteo.net> (raw)
In-Reply-To: <CADUfDZoHibw8RA_OiWfptQwa2HjPho9OotNX56kf5MvnQi8GuQ@mail.gmail.com>
On 22.05.2026 17:27, Caleb Sander Mateos wrote:
> FYI there was a previous report and patch for this issue:
> https://lore.kernel.org/linux-nvme/20260309062840.2937858-2-iam@sung-woo.kim/T/#u
> . Looks like a v2 was promised but never arrived. Some attribution
> (Reported-by, Link?) for the original patch might be good.
>
Thanks, missed that thread. Added in v2:
Reported-by: Sung-woo Kim <iam@sung-woo.kim>
Link:
https://lore.kernel.org/r/20260309062840.2937858-2-iam@sung-woo.kim
Also added a Fixes: tag for d977506f8863
> I did like that the other patch switched the type of struct
> blk_mq_hw_ctx's numa_node field and the argument to struct
> blk_mq_ops's init_request function pointer from unsigned int to int to
> clarify that it was optional. But probably makes sense to do that as a
> follow-on commit separate from the bug fix.
>
I can take care of it, will send it as separate follow-up.
> Is numa_node >= nr_node_ids possible? I think just numa_node < 0
> should be fine, and would avoid a compiler warning about comparing int
> to unsigned int.
>
Right, dropped the nr_node_ids check. Went with == NUMA_NO_NODE
rather than < 0 to match the style in block/blk-mq.c
v2 incoming.
Thanks,
Mateusz
next prev parent reply other threads:[~2026-05-23 8:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 15:06 Mateusz Nowicki
2026-05-22 15:27 ` Caleb Sander Mateos
2026-05-23 8:17 ` mateusz.nowicki [this message]
2026-05-23 8:28 ` [PATCH v2] " Mateusz Nowicki
2026-05-25 5:56 ` Christoph Hellwig
2026-05-27 16:34 ` Keith Busch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8a73dd99b8280c5d1bde9c6caed8323b@posteo.net \
--to=mateusz.nowicki@posteo.net \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome