linux-kernel - Re: [Ocfs2-devel] [PATCH] Revert "writeback: limit write_cache

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, 28 Jun 2010 19:20:33 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Chinner <david@...morbit.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	ocfs2-devel@....oracle.com, Tao Ma <tao.ma@...cle.com>,
	Dave Chinner <dchinner@...hat.com>,
	Christoph Hellwig <hch@....de>, Mark Fasheh <mfasheh@...e.com>
Subject: Re: [Ocfs2-devel] [PATCH] Revert "writeback: limit write_cache_pages 
	integrity scanning to current EOF"

On Mon, Jun 28, 2010 at 6:58 PM, Joel Becker <Joel.Becker@...cle.com> wrote:
>
>        Well, shit.  Something has changed in here, or we're really
> really (un)lucky.  We visited this code a year ago or so when we had
> serious zeroing problems, and we tested the hell out of it.  Now it is
> broken again.  And it sure looks like that block_write_full_page() check
> has been there since before git.

Hmm. I'm actually starting to worry that we should do the revert after all.

Why? Locking. That page-writeback.c thing decides to limit the end to
the inode size the same way that block_write_full_page() does, but
block_write_full_page() holds the page lock, while page-writeback.c
does not. Which means that as a race against somebody else doing a
truncate(), the two things really are pretty different.

That said, write_cache_pages() obviously doesn't actually invalidate
the page (the way block_write_full_page() does), so locking matters a
whole lot less for it. If somebody is doing a concurrent truncate or a
concurrent write, then for the data to really show up reliably on disk
there would obviously have to be a separate sync operation involved,
so even with the lack of any locking, it should be safe.

I dunno. Filesystem corruption makes me nervous. So I'm certainly
totally willing to do the revert if that makes ocfs2 work again. Even
if "work again" happens to be partly by mistake, and for some reason
that isn't obvious.

Your call, I guess.  If any ocfs2 fix looks scary, and you'd prefer to
have an -rc4 (in a few days - not today) with just the revert, I'm ok
with that. Even if it's only a "at least no worse than 2.6.34"
situation rather than a real fix.

                 Linus
--
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/