All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH 1/4] filemap: return pos of first dirty folio from range_has_writeback
Date: Thu, 18 Jul 2024 12:03:09 -0400	[thread overview]
Message-ID: <Zpk8vSx6AI53Cxyo@bfoster> (raw)
In-Reply-To: <ZpkwD2-q9_XRfX5P@casper.infradead.org>

On Thu, Jul 18, 2024 at 04:09:03PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 18, 2024 at 09:02:09AM -0400, Brian Foster wrote:
> > @@ -655,6 +655,8 @@ bool filemap_range_has_writeback(struct address_space *mapping,
> >  				folio_test_writeback(folio))
> >  			break;
> >  	}
> > +	if (folio)
> > +		*start_byte = folio_pos(folio);
> >  	rcu_read_unlock();
> >  	return folio != NULL;
> >  }
> 
> Distressingly, this is unsafe.
> 
> We have no reference on the folio at this point (not one that matters,
> anyway).  We have the rcu read lock, yes, but that doesn't protect enough
> to make folio_pos() safe.
> 
> Since we do't have folio_get() here, the folio can be freed, sent back to
> the page allocator, and then reallocated to literally any purpose.  As I'm
> reviewing patch 1/4, I have no idea if this is just a hint and you can
> survive it being completely wrong, or if this is going to cause problems.
> 

Ah, thanks. I was unsure about this when I hacked it up but then got
more focused on patch 3. I think for this implementation I'd want it to
be an accurate pos of the first dirty/wb folio. I think this could
possibly use filemap_range_has_writeback() (without patch 1) as more of
a hint/optimization, but that might involve doing the FGP_NOCREAT thing
from the previous variant of this prototype has and I was trying to
avoid that.

Do you think it would be reasonable to create a variant of this function
that did the relevant bits from __filemap_get_folio():

        if (!folio_try_get(folio))
                goto repeat;

        if (unlikely(folio != xas_reload(&xas))) {
                folio_put(folio);
                goto repeat;
        }
	/* check dirty/wb etc. */

... in order to either return a correct pos or maybe even a reference to
the folio itself? iomap_zero_iter() wants the locked folio anyways, but
that might be too ugly to pass through the iomap_folio_ops thing in
current form.

If that doesn't work, then I might chalk this up as another reason to
just do the flush thing I was rambling about in the cover letter...

Brian


  reply	other threads:[~2024-07-18 16:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-18 13:02 [PATCH RFC 0/4] iomap: zero dirty folios over unwritten mappings on zero range Brian Foster
2024-07-18 13:02 ` [PATCH 1/4] filemap: return pos of first dirty folio from range_has_writeback Brian Foster
2024-07-18 15:09   ` Matthew Wilcox
2024-07-18 16:03     ` Brian Foster [this message]
2024-07-18 13:02 ` [PATCH 2/4] iomap: refactor an iomap_revalidate() helper Brian Foster
2024-07-18 13:02 ` [PATCH 3/4] iomap: fix handling of dirty folios over unwritten extents Brian Foster
2024-07-19  0:25   ` Dave Chinner
2024-07-19 15:17     ` Brian Foster
2024-07-18 13:02 ` [PATCH 4/4] xfs: remove unnecessary flush of eof page from truncate Brian Foster
2024-07-18 15:36 ` [PATCH RFC 0/4] iomap: zero dirty folios over unwritten mappings on zero range Josef Bacik
2024-07-18 16:02   ` Darrick J. Wong
2024-07-18 16:40     ` Brian Foster
2024-07-19  1:10 ` Dave Chinner
2024-07-19 15:22   ` Brian Foster

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=Zpk8vSx6AI53Cxyo@bfoster \
    --to=bfoster@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.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 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.