linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: John Hubbard <jhubbard@nvidia.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	David Hildenbrand <david@redhat.com>,
	David Howells <dhowells@redhat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	willy@infradead.org, linux-mm@kvack.org,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org
Subject: Re: Does GUP page unpinning have to be done in the pinning context?
Date: Sun, 11 May 2025 23:21:45 -0700	[thread overview]
Message-ID: <aCGTeY2HswIFHsD0@infradead.org> (raw)
In-Reply-To: <21dfcbfc-5295-4493-8ae1-eaa82f018472@nvidia.com>

On Thu, Apr 10, 2025 at 12:11:42PM -0700, John Hubbard wrote:
> Oh actually I think I was wrong in my earlier reply about clearing
> the dirty bit. Because in Jan Kara's original bug report, what
> happened was that periodic writeback came in while the pages
> were pinned, and cleared the dirty bit--and also deleted the
> page buffers (file system specific behavior) that are required
> for writeback.
> 
> So then later when the pages are unpinned and marked dirty,
> that causes the next writeback to fail in an unexpected way
> (it used to cause ext4 BUG checks, in fact).
> 
> So the problem here is that these pinned pages can get cleaned
> while they are pinned, and then dirtied again by DMA (invisible
> to the filesystem).

I've looked around a bit.  We do skip pinned pags in shrink_folio_list
(btw, can someone please split that thing up, it's so huge that it
is completely unreadable) but that's not really relevant for clearing
the dirty bit for filemap folios these days despite comments talking
about just that.

So I guess, yes - we'd need to skip folio_maybe_dma_pinned() in
writeback, or wait for the bit to be cleared for data integrity
writeback.  Which doesn't sound too hard, but there might be
pitfalls.



      parent reply	other threads:[~2025-05-12  6:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-04 10:20 David Howells
2025-04-04 10:29 ` David Hildenbrand
2025-04-04 16:59   ` John Hubbard
2025-04-07  6:39     ` Christoph Hellwig
2025-04-10  2:56       ` John Hubbard
2025-04-10  7:28         ` Christoph Hellwig
2025-04-10 19:11           ` John Hubbard
2025-04-10 19:14             ` Matthew Wilcox
2025-04-10 19:34               ` John Hubbard
2025-05-12  6:21             ` 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=aCGTeY2HswIFHsD0@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=david@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.org \
    /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