mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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