lkml.org 
[lkml]   [2009]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateTue, 31 Mar 2009 18:42:34 -0400 (EDT)
FromMikulas Patocka <>
SubjectRe: [PATCH] fix bmap-vs-truncate race
On Tue, 31 Mar 2009, Christoph Hellwig wrote:

> On Mon, Mar 30, 2009 at 03:20:24PM -0400, Mikulas Patocka wrote:
> > Hi
> >
> > I'm submitting this patch for 2.6.30 merge window.
>
> Please not. i_alloc_sem is really a horrible hack needed for a couple
> filesystems only and we should not leak it into more generic code but
> rather move the few instances into the filesystem.

Could you please document locking rules for get_block(), truncate, bmap &
direct i/o in Documentation/filesystems/Locking ?
There is a lot of text about directories, but nothing about locking of
block mappings.

I was living under an impression that get_block() cannot be called on a
block that is being truncated. That's what read/write/direct-io vs
truncate seems to guarante --- truncate will first lower i_size
(preventing any new pages past i_size from being created), then destroy
any existing pages past i_size (that includes waiting for pagelock until
all get_blocks on that page end) and finally truncate the metadata on the
filesystem.

So there should be no situation when you truncate block and call get_block
on it simultaneously. If get_block can race with truncate, document it.

There are filesystems that don't do any locking on get_block() (for
example UFS, HPFS; FAT does it only for bmap and doesn't do it for general
accesses) and other filesystems verify indirect block chains obsessively
if they were truncated under get_block (why? because of bmap? or some
other possibility?) --- so the rules should really be documented.

Mikulas


\
 
 \ /
  Last update: 2009-04-01 00:45    [from the cache]
©2003-2010