From: Keith Busch <kbusch@kernel.org>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Keith Busch <kbusch@meta.com>,
linux-nvme@lists.infradead.org, hch@lst.de, sagi@grimberg.me
Subject: Re: New warning `nvme nvme0: using unchecked data buffer`
Date: Wed, 29 Jan 2025 12:00:02 -0700 [thread overview]
Message-ID: <Z5p6sruLjO9VZ_mS@kbusch-mbp> (raw)
In-Reply-To: <333105a9-3480-4694-93d6-0e092dda3751@molgen.mpg.de>
On Sun, Jan 26, 2025 at 09:37:09AM +0100, Paul Menzel wrote:
> Sorry for not proposing something. Linux 6.13 was released with the warning
> above. As nothing can be done about - it´s unlikely the vendor is going to
> enable it in the firmware on released devices - I propose to decrease the
> log level to info, and rephrase it:
>
> nvme0: Using unchecked data buffer. The passthrough interface was used but
> the device can only use implicit transfer length. Improper use might be
> cause for memory corruption observations. If in doubt contact the hardware
> vendor.
>
> It´s much longer, but helps the user to understand the situation much
> better.
That's quite verbose!
Let's take a step back a moment. This is a transfer mode the Linux nvme
driver has always supported. It was afterall the *only* way for the
first version of the protocol. I don't want to unnecessarily call
attention to hardware vendors who adhere to that version of the
spec; this is more of a notification to the people who think this was
worth making a CVE out of it.
So let's turn down the level from warn to info. Maybe remove the check
from the IO path and just print out device interesting capabilities
during initial enumeration:
nvme0: SGL+ MetaSGL- Etc...
prev parent reply other threads:[~2025-01-29 19:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 15:57 [PATCHv3 0/3] meta sgl and userspace protection Keith Busch
2024-11-18 15:57 ` [PATCHv3 1/3] nvme-pci: add support for sgl metadata Keith Busch
2024-11-18 16:27 ` Christoph Hellwig
2024-11-18 15:57 ` [PATCHv3 2/3] nvme: define the remaining used sgls constants Keith Busch
2024-11-18 16:28 ` Christoph Hellwig
2024-11-18 15:57 ` [PATCHv3 3/3] nvme-pci: use sgls for all user requests if possible Keith Busch
2024-11-18 16:28 ` Christoph Hellwig
2024-12-02 7:56 ` New warning `nvme nvme0: using unchecked data buffer` (was: [PATCHv3 3/3] nvme-pci: use sgls for all user requests if possible) Paul Menzel
2024-12-02 15:05 ` Keith Busch
2024-12-02 15:15 ` New warning `nvme nvme0: using unchecked data buffer` Paul Menzel
2024-12-02 15:49 ` Keith Busch
2025-01-26 8:37 ` Paul Menzel
2025-01-29 19:00 ` Keith Busch [this message]
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=Z5p6sruLjO9VZ_mS@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=hch@lst.de \
--cc=kbusch@meta.com \
--cc=linux-nvme@lists.infradead.org \
--cc=pmenzel@molgen.mpg.de \
--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