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:	Mon, 23 Jan 2012 23:10:53 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Chinner <david@...morbit.com>
Cc:	"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, 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.

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.

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 very much NAK that whole idiotic approach, and object to it.  That
is the routine that is used even without any filesystem AT ALL, for
chissake.

So all your arguments are for something totally different that is
irrelevant for the whole discussion.  Really.

                       Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ