From: Matthew Wilcox <willy@infradead.org>
To: Ritesh Harjani <ritesh.list@gmail.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
Disha Goel <disgoel@linux.ibm.com>, Jan Kara <jack@suse.cz>
Subject: Re: [RFCv2 2/5] ext4: Remove PAGE_SIZE assumption of folio from mpage_submit_folio
Date: Mon, 12 Jun 2023 20:16:52 +0100 [thread overview]
Message-ID: <ZIdvJLE945Qbzy+H@casper.infradead.org> (raw)
In-Reply-To: <87352w7d1o.fsf@doe.com>
On Mon, Jun 12, 2023 at 11:55:55PM +0530, Ritesh Harjani wrote:
> Matthew Wilcox <willy@infradead.org> writes:
> I couldn't respond to your change because I still had some confusion
> around this suggestion -
>
> > So do we care if we write a random fragment of a page after a truncate?
> > If so, we should add:
> >
> > if (folio_pos(folio) >= size)
> > return 0; /* Do we need to account nr_to_write? */
>
> I was not sure whether if go with above case then whether it will
> work with collapse_range. I initially thought that collapse_range will
> truncate the pages between start and end of the file and then
> it can also reduce the inode->i_size. That means writeback can find an
> inode->i_size smaller than folio_pos(folio) which it is writing to.
> But in this case we can't skip the write in writeback case like above
> because that write is still required (a spurious write) even though
> i_size is reduced as it's corresponding FS blocks are not truncated.
>
> But just now looking at ext4_collapse_range() code it doesn't look like
> it is the problem because it waits for any dirty data to be written
> before truncate. So no matter which folio_pos(folio) the writeback is
> writing, there should not be an issue if we simply return 0 like how
> you suggested above.
>
> static int ext4_collapse_range(struct file *file, loff_t offset, loff_t len)
>
> <...>
> ioffset = round_down(offset, PAGE_SIZE);
> /*
> * Write tail of the last page before removed range since it will get
> * removed from the page cache below.
> */
>
> ret = filemap_write_and_wait_range(mapping, ioffset, offset);
> if (ret)
> goto out_mmap;
> /*
> * Write data that will be shifted to preserve them when discarding
> * page cache below. We are also protected from pages becoming dirty
> * by i_rwsem and invalidate_lock.
> */
> ret = filemap_write_and_wait_range(mapping, offset + len,
> LLONG_MAX);
> truncate_pagecache(inode, ioffset);
>
> <... within i_data_sem>
> i_size_write(inode, new_size);
>
> <...>
>
>
> However to avoid problems like this I felt, I will do some more code
> reading. And then I was mostly considering your second suggestion which
> is this. This will ensure we keep the current behavior as is and not
> change that.
>
> > If we simply don't care that we're doing a spurious write, then we can
> > do something like:
> >
> > - len = size & ~PAGE_MASK;
> > + len = size & (len - 1);
For all I know, I've found a bug here. I don't know enough about ext4; if
we have truncated a file, and then writeback a page that is past i_size,
will the block its writing to have been freed? Is this potentially a
silent data corruptor?
next prev parent reply other threads:[~2023-06-12 19:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 10:40 [RFCv2 0/5] ext4: misc left over folio changes Ritesh Harjani (IBM)
2023-05-15 10:40 ` [RFCv2 1/5] ext4: kill unused function ext4_journalled_write_inline_data Ritesh Harjani (IBM)
2023-05-15 10:40 ` [RFCv2 2/5] ext4: Remove PAGE_SIZE assumption of folio from mpage_submit_folio Ritesh Harjani (IBM)
2023-05-16 19:14 ` Matthew Wilcox
2023-06-11 5:58 ` Theodore Ts'o
2023-06-11 14:15 ` Matthew Wilcox
2023-06-11 14:25 ` Ritesh Harjani
2023-06-12 17:25 ` Ritesh Harjani
2023-06-12 17:43 ` Matthew Wilcox
2023-06-12 18:25 ` Ritesh Harjani
2023-06-12 19:16 ` Matthew Wilcox [this message]
2023-06-13 3:57 ` Ritesh Harjani
2023-06-13 9:59 ` Jan Kara
2023-06-13 19:39 ` Ritesh Harjani
2023-06-13 19:45 ` Matthew Wilcox
2023-06-13 20:43 ` Ritesh Harjani
2023-05-15 10:40 ` [RFCv2 3/5] ext4: Change remaining tracepoints to use folio Ritesh Harjani (IBM)
2023-05-15 10:40 ` [RFCv2 4/5] ext4: Make mpage_journal_page_buffers " Ritesh Harjani (IBM)
2023-05-16 19:16 ` Matthew Wilcox
2023-05-15 10:40 ` [RFCv2 5/5] ext4: Make ext4_write_inline_data_end() " Ritesh Harjani (IBM)
2023-05-16 19:27 ` [PATCH 6/5] ext4: Call fsverity_verify_folio() Matthew Wilcox (Oracle)
2023-05-17 6:45 ` Ritesh Harjani
2023-05-20 1:06 ` Eric Biggers
2023-06-09 3:14 ` [RFCv2 0/5] ext4: misc left over folio changes Theodore Ts'o
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=ZIdvJLE945Qbzy+H@casper.infradead.org \
--to=willy@infradead.org \
--cc=disgoel@linux.ibm.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).