linux-kernel - Re: [PATCH] fs: nobh_truncate

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] [day] [month] [year] [list]

Message-Id: <20070305153108.27bd0f33.akpm@linux-foundation.org>
Date:	Mon, 5 Mar 2007 15:31:08 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Will Trives <will@...vescon.com.au>,
	linux-kernel@...r.kernel.org,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Chuck Ebbert <cebbert@...hat.com>
Subject: Re: [PATCH] fs: nobh_truncate_page() fix

On Mon, 05 Mar 2007 17:10:11 -0600
Dave Kleikamp <shaggy@...ux.vnet.ibm.com> wrote:

> On Mon, 2007-03-05 at 14:57 -0800, Andrew Morton wrote:
> > Is OK, I think.  nobh_prepare_write() brings the outside-from-and-to
> > sections of the page uptodate and memset in nobh_truncate_page() brings the
> > rest of the page uptodate.
> > 
> > We bring the to->PAGE_CACHE_SIZE section uptodate twice, which could be
> > optimised.
> 
> Why not have nobh_truncate_page() call prepare_write() with to =
> PAGE_CACHE_SIZE?  I don't really grok:
> 
> to = (offset + blocksize) & ~(blocksize - 1);

OK, let's say we have a 4k pagesize and a 1k fs blocksize and someone does
ftruncate(fd, 1024 + 100).

We need to:

- load bytes (0 ...  1024+100) from disk (these are live file data)

- zero the bytes (1024+100 ...  1024+1024) (these are data outside the
  truncation point, but inside the fs block which straddles the truncation
  point)

- zero the bytes (1024+1024 ...  4096) (these are the rest of the
  pagecache page, outside the truncation point).

- mark the page dirty so those zeroes outside the truncation point but
  inside the block which straddles i_size (ie: (1024+100 ...  1024+1024)
  get written back.

Now, it just so happens that

	nobh_prepare_write(NULL, page, 1024+100, 1024+1024)

will indeed load bytes (0 ...  1024+1024) from disk, and will then zero out
bytes (1024+100 ...  4096) for us (I think - assumes that ->get_block does
the right thing with buffer_mapped)).  We could exploit that knowledge of
prepare_write() internals in nobh_truncate_page().

But as it stands, nobh_truncate_page() is being formal and is not making
assumptions about what nobh_prepare_write() does with blocks outside
i_size.
-
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/