From: Keith Busch <kbusch@kernel.org>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: Christoph Hellwig <hch@lst.de>,
axboe@kernel.dk, sagi@grimberg.me,
linux-nvme@lists.infradead.org, vincentfu@gmail.com,
ankit.kumar@samsung.com, joshiiitr@gmail.com,
stable@vger.kernel.org, Vincent Fu <vincent.fu@samsung.com>
Subject: Re: [PATCH v4] nvme: fix corruption for passthrough meta/data
Date: Fri, 13 Oct 2023 07:54:03 -0600 [thread overview]
Message-ID: <ZSlL-6Oa5J9duahR@kbusch-mbp> (raw)
In-Reply-To: <8c755915-2366-28ff-ffd4-be17d797557c@samsung.com>
On Fri, Oct 13, 2023 at 03:44:38PM +0530, Kanchan Joshi wrote:
> On 10/13/2023 10:56 AM, Christoph Hellwig wrote:
> > On Fri, Oct 13, 2023 at 10:44:58AM +0530, Kanchan Joshi wrote:
> >> Changes since v3:
> >> - Block only unprivileged user
> >
> > That's not really what at least I had in mind. I'd much rather
> > completely disable unprivileged passthrough for now as an easy
> > backportable patch. And then only re-enable it later in a way
> > where it does require using SGLs for all data transfers.
> >
>
> I did not get how forcing SGLs can solve the issue at hand.
> The problem happened because (i) user specified short buffer/len, and
> (ii) kernel allocated buffer. Whether the buffer is fed to device using
> PRP or SGL does not seem to solve the large DMA problem.
The problem is a disconnect between the buffer size provided and the
implied size of the command. The idea with SGL is that it requires an
explicit buffer size, so the device will know the buffer is short and
return an appropriate error.
next prev parent reply other threads:[~2023-10-13 13:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20231013052157epcas5p3dc0698c56f9846191d315fa8d33ccb5c@epcas5p3.samsung.com>
2023-10-13 5:14 ` [PATCH v4] nvme: fix corruption for passthrough meta/data Kanchan Joshi
2023-10-13 5:26 ` Christoph Hellwig
2023-10-13 5:37 ` Kanchan Joshi
2023-10-13 10:14 ` Kanchan Joshi
2023-10-13 12:59 ` Kanchan Joshi
2023-10-13 13:54 ` Keith Busch [this message]
2023-10-13 15:11 ` Kanchan Joshi
2023-10-13 15:47 ` Christoph Hellwig
2023-10-13 18:35 ` Kanchan Joshi
2023-10-16 18:29 ` Keith Busch
2023-10-16 18:34 ` Christoph Hellwig
2023-10-15 19:19 ` Kanchan Joshi
2023-10-16 5:46 ` Christoph Hellwig
2023-10-26 14:33 ` Kanchan Joshi
2023-10-26 15:08 ` Keith Busch
2023-10-27 7:09 ` Kanchan Joshi
2023-10-13 5:32 ` Kanchan Joshi
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=ZSlL-6Oa5J9duahR@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=ankit.kumar@samsung.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=joshi.k@samsung.com \
--cc=joshiiitr@gmail.com \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=stable@vger.kernel.org \
--cc=vincent.fu@samsung.com \
--cc=vincentfu@gmail.com \
/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