From: Theodore Ts'o <tytso@mit.edu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [REGRESSION] 998ef75ddb and aio-dio-invalidate-failure w/ data=journal
Date: Wed, 7 Oct 2015 11:43:03 -0400 [thread overview]
Message-ID: <20151007154303.GC24678@thunk.org> (raw)
In-Reply-To: <CA+55aFycvHK2z_0QZ34wEJf5fBMxWDaeOs85cFSmpKnNONDxLQ@mail.gmail.com>
On Wed, Oct 07, 2015 at 08:32:16AM +0100, Linus Torvalds wrote:
> And none of *those* requirements change just because "copied" would be
> zero. If you avoid zeroing the buffers and marking them dirty, nothing
> will ever initialize them on disk, andn if the prefault then later
> fails during retry, no later write will happen either. So now
> eventually later, a read() can see stale data from disk.
Shoot. You're right, we could end up allowing a stale data to be
exposed. If we knew the caller of write_end() was guaranteed to
retry, we could skip the jbd2_journal_stop() call and keep the handle
open, which would prevent the transaction from closing. But if the
write gets abandoned, then the transaction would never close, and
things would grind to a halt.
> I do think this is an ext4 bug, and you'll need to do something *like*
> that patch. Maybe Dave's patch is good as-is. It's the "I think you
> need to do more" that I worry about. Not at -rc4 time. Not with a core
> filesystem like ext4. Let's not hurry this too much.
Agreed, I know what to do, and and the change is not something I'd
want to get in -rc4. I'll target a fix for the next merge window.
- Ted
next prev parent reply other threads:[~2015-10-07 15:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 15:22 [REGRESSION] 998ef75ddb and aio-dio-invalidate-failure w/ data=journal Theodore Ts'o
2015-10-05 15:58 ` Linus Torvalds
2015-10-05 16:23 ` Dave Hansen
2015-10-05 20:22 ` Linus Torvalds
2015-10-05 20:48 ` Dave Hansen
2015-10-05 21:18 ` Linus Torvalds
2015-10-05 21:55 ` Linus Torvalds
2015-10-05 23:33 ` Dave Hansen
2015-10-06 9:01 ` Linus Torvalds
2015-10-05 20:49 ` H. Peter Anvin
2015-10-06 7:56 ` Ingo Molnar
2015-10-06 9:10 ` Linus Torvalds
2015-10-06 9:27 ` Ingo Molnar
2015-10-06 13:29 ` Linus Torvalds
2015-10-06 13:42 ` Ingo Molnar
2015-10-05 16:03 ` Dave Hansen
2015-10-05 18:04 ` Dave Hansen
2015-10-07 3:34 ` Theodore Ts'o
2015-10-07 7:32 ` Linus Torvalds
2015-10-07 15:43 ` Theodore Ts'o [this message]
2015-10-09 4:01 ` [PATCH] ext4: use private version of page_zero_new_buffers() for data=journal mode Theodore Ts'o
2015-10-13 6:06 ` Leonid V. Fedorenchik
2015-10-15 11:17 ` Jan Kara
2025-01-26 17:01 ` Mateusz Guzik
2025-01-26 18:48 ` Linus Torvalds
2025-01-26 19:49 ` Mateusz Guzik
2025-01-26 22:03 ` Linus Torvalds
2025-01-26 22:45 ` Mateusz Guzik
2025-01-27 20:52 ` Dave Hansen
2025-01-27 21:46 ` Dave Chinner
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=20151007154303.GC24678@thunk.org \
--to=tytso@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).