public inbox for [email protected]
 help / color / mirror / Atom feed
From: Keith Busch <[email protected]>
To: Kanchan Joshi <[email protected]>
Cc: Keith Busch <[email protected]>,
	[email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected], [email protected]
Subject: Re: [PATCHv5 0/4] block integrity: directly map user space addresses
Date: Fri, 1 Dec 2023 15:49:40 -0700	[thread overview]
Message-ID: <ZWpjBCF4KueqKlPN@kbusch-mbp> (raw)
In-Reply-To: <ZWopLQWBIUGBad3z@kbusch-mbp>

On Fri, Dec 01, 2023 at 11:42:53AM -0700, Keith Busch wrote:
> On Fri, Dec 01, 2023 at 04:13:45PM +0530, Kanchan Joshi wrote:
> > On 12/1/2023 3:23 AM, Keith Busch wrote:
> > > From: Keith Busch<[email protected]>
> > 
> > This causes a regression (existed in previous version too).
> > System freeze on issuing single read/write io that used to work fine 
> > earlier:
> > fio -iodepth=1 -rw=randread -ioengine=io_uring_cmd -cmd_type=nvme 
> > -bs=4096 -numjobs=1 -size=4096 -filename=/dev/ng0n1 -md_per_io_size=8 
> > -name=pt
> > 
> > This is because we pin one bvec during submission, but unpin 4 on 
> > completion. bio_integrity_unpin_bvec() uses bip->bip_max_vcnt, which is 
> > set to 4 (equal to BIO_INLINE_VECS) in this case.
> > 
> > To use bip_max_vcnt the way this series uses, we need below patch/fix:
> 
> Thanks for the catch! Earlier versions of this series was capped by the
> byte count rather than the max_vcnt value, so the inline condition
> didn't matter before. I think your update looks good. I'll double check
> what's going on with my custom tests to see why it didn't see this
> problem.

Got it: I was using ioctl instead of iouring. ioctl doesn't set
REQ_ALLOC_CACHE, so we don't get a bio_set in bio_integrity_alloc(), and
that makes inline_vecs set similiar to what your diff does.

Jens already applied the latest series for the next merge. We can append
this or fold atop, or back it out and we can rework it for another
version. No rush; for your patch:

Reviewed-by: Keith Busch <[email protected]>

Thanks again!

> > diff --git a/block/bio-integrity.c b/block/bio-integrity.c
> > index 674a2c80454b..feef615e2c9c 100644
> > --- a/block/bio-integrity.c
> > +++ b/block/bio-integrity.c
> > @@ -69,15 +69,15 @@ struct bio_integrity_payload 
> > *bio_integrity_alloc(struct bio *bio,
> > 
> >          memset(bip, 0, sizeof(*bip));
> > 
> > +       /* always report as many vecs as asked explicitly, not inline 
> > vecs */
> > +       bip->bip_max_vcnt = nr_vecs;
> >          if (nr_vecs > inline_vecs) {
> > -               bip->bip_max_vcnt = nr_vecs;
> >                  bip->bip_vec = bvec_alloc(&bs->bvec_integrity_pool,
> >                                            &bip->bip_max_vcnt, gfp_mask);
> >                  if (!bip->bip_vec)
> >                          goto err;
> >          } else {
> >                  bip->bip_vec = bip->bip_inline_vecs;
> > -               bip->bip_max_vcnt = inline_vecs;
> >          }
> > 
> >          bip->bip_bio = bio;
> 

  reply	other threads:[~2023-12-01 22:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20231130215715epcas5p33208ca14e69a68402c04e5c743135e6c@epcas5p3.samsung.com>
2023-11-30 21:53 ` [PATCHv5 0/4] block integrity: directly map user space addresses Keith Busch
2023-11-30 21:53   ` [PATCHv5 1/4] block: bio-integrity: directly map user buffers Keith Busch
2023-11-30 21:53   ` [PATCHv5 2/4] nvme: use bio_integrity_map_user Keith Busch
2023-11-30 21:53   ` [PATCHv5 3/4] iouring: remove IORING_URING_CMD_POLLED Keith Busch
2023-11-30 21:53   ` [PATCHv5 4/4] io_uring: remove uring_cmd cookie Keith Busch
2023-11-30 23:09   ` [PATCHv5 0/4] block integrity: directly map user space addresses Jens Axboe
2023-12-01 10:43   ` Kanchan Joshi
2023-12-01 18:42     ` Keith Busch
2023-12-01 22:49       ` Keith Busch [this message]
2023-12-02  1:31         ` Jens Axboe
2023-12-02  2:04           ` Kanchan Joshi
2023-12-02 14:58             ` Jens Axboe

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=ZWpjBCF4KueqKlPN@kbusch-mbp \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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