On Wed, 28 Nov 2012, Linus Torvalds wrote: > A bigger issue is for things that emulate what blkdev.c does, and > doesn't do the locking. I see code in md/bitmap.c that seems a bit > suspicious, for example. That said, it's not *new* breakage, and the > "lock at mmap/read/write() time" approach doesn't fix it either (since > the mapping will be different for the underlying MD device). So I do > think that we should take a look at all the users of > "alloc_page_buffers()" and "create_empty_buffers()" to see what *they* > do to protect the block-size, but I think that's an independent issue > from the raw device access case in fs/block_dev.c.. > > I guess I have to actually test my patch. I don't have very > interesting test-cases, though. > > Linus Yes, it md looks suspicious. It disables write access in deny_bitmap_write_access (that functions looks buggy on its own - what happens if i_writecount == 0 or if it is already negative on entry?). So we could disallow changing block size if i_writecount < 0, that should do the trick. Mikulas -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
