linux-kernel - Re: [RFC PATCH 0/3] Stop clearing uptodate flag on write IO error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Jan 2012 13:13:14 +0100
From:	Jan Kara <jack@...e.cz>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dave Chinner <david@...morbit.com>, Ted Ts'o <tytso@....edu>,
	Jan Kara <jack@...e.cz>, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Edward Shishkin <edward@...hat.com>
Subject: Re: [RFC PATCH 0/3] Stop clearing uptodate flag on write IO error

On Mon 23-01-12 23:10:53, Linus Torvalds wrote:
> On Mon, Jan 23, 2012 at 10:12 PM, Dave Chinner <david@...morbit.com> wrote:
> >
> > You still haven't grasped that there are many different
> > classes of IO errors and that some require different handling to
> > others. :/
> 
> I think *you* haven't grasped what we're talking about.
> 
> Did you look at the thread?
> 
> We're not talking about some filesystem-specific buffer handling.
> We're talking about the *default* hander in fs/buffer.c for IO
> completion.
  Well, not sure if you remember but the change I was proposing was only
for filesystems that would promise (in their fstype) they they know better
how to handle IO errors. 

> A filesystem can override that handler if it wants to and you can do
> whatever the f*ck you want in your filesystem end-of-io handler.
  That's another possibility but a flag in fstype and a check in default
end-of-io handler looked like an easier solution to me.

> But dammit, in the default handler - which BY DEFINITION IS ABOUT
> FILESYSTEMS THAT DO NOT DO THOSE "many different classes of IO errors"
> that you continue to blather about, there really are two choices:
>  - throw the damn thing away
>  - retry the write forever
> 
> It really is that simple. The thing I objected to was Jan claiming
> that clearing the up-to-date flag made no semantic sense. That's just
> crazy talk.
> 
> What does *not* make any semantic sense is to just mark the damn thing
> clean after an IO error!
  I agree that just keeping the uptodate flag was a half-baked proposal. I
ultimately want to set the dirty flag back as well and we seem to agree
that that would be logically correct. But then, as you noted, filesystem
has to propely handle unwriteable pages to not bring system OOM (or
actually block all writes due to exceeded dirty limit) and that is more
complicated (distinguishing path temporarily down from USB stick is gone
etc.) so I didn't want to go there in the beginning. But it seems I'll have
to ;)

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/