All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Anuj Gupta <anuj20.g@samsung.com>,
	linux-block@vger.kernel.org
Subject: Re: [PATCH 3/3] block: don't free submitter owned integrity payload on I/O completion
Date: Sat, 29 Jun 2024 07:02:29 +0200	[thread overview]
Message-ID: <20240629050229.GA14993@lst.de> (raw)
In-Reply-To: <43ba3da2-8645-a255-0db8-c0352eb9d3d7@samsung.com>

On Fri, Jun 28, 2024 at 09:46:21PM +0530, Kanchan Joshi wrote:
> >   static inline bool bio_integrity_endio(struct bio *bio)
> >   {
> > -	if (bio_integrity(bio))
> > +	struct bio_integrity_payload *bip = bio_integrity(bio);
> > +
> > +	if (bip && (bip->bip_flags & BIP_BLOCK_INTEGRITY))
> >   		return __bio_integrity_endio(bio);
> 
> Seems we will need similar BIP_BLOCK_INTEGRITY check inside bio_uninit 
> too. At line 221 in below snippet [1].
> As that also frees integrity by calling bio_integrity_free. Earlier that 
> free was skipped due to BIP_INTEGRITY_USER flag. Now that flag has gone, 
> integrity will get freed and after that control may go back to 
> nvme-passthrough where it will try to unmap (and potentially copy back) 
> integrity.

bio_integrity_free clears the REQ_INTEGRITY flag and the bi_integrity
pointer, and bio_uninit checks for those using bio_integrity() first.
The check is alredy required for the existing code and that doesn't
change.

> Seems this patch is with "for-6.11/block".
> But with "for-next" you will see more places where this flag has been 
> used. And there will be conflicts because we have this patch there [1]. 
> Parts of this patch need changes to work with it. I can look more and 
> test next week.

Oh, the patch actually does part of what this one does, _and_ I've
reviewed it.  Jens, maybe just skip the patch we are replying to
(my one) for now, and I'll resend it for the next merge window
as the conflicts vs the 6.10 tree would be too annoying.


      reply	other threads:[~2024-06-29  5:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28 13:27 more integrity cleanups Christoph Hellwig
2024-06-28 13:27 ` [PATCH 1/3] block: split integrity support out of bio.h Christoph Hellwig
2024-06-28 13:27 ` [PATCH 2/3] block: also return bio_integrity_payload * from stubs Christoph Hellwig
2024-06-28 13:27 ` [PATCH 3/3] block: don't free submitter owned integrity payload on I/O completion Christoph Hellwig
2024-06-28 16:16   ` Kanchan Joshi
2024-06-29  5:02     ` Christoph Hellwig [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=20240629050229.GA14993@lst.de \
    --to=hch@lst.de \
    --cc=anuj20.g@samsung.com \
    --cc=axboe@kernel.dk \
    --cc=joshi.k@samsung.com \
    --cc=linux-block@vger.kernel.org \
    --cc=martin.petersen@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.