On Thu, Nov 29, 2012 at 9:19 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I think I'll apply this for 3.7 (since it's too late to do anything > fancier), and then for 3.8 I will rip out all the locking entirely, > because looking at the fs/buffer.c patch I wrote up, it's all totally > unnecessary. > > Adding a ACCESS_ONCE() to the read of the i_blkbits value (when > creating new buffers) simply makes the whole locking thing pointless. > Just make the page lock protect the block size, and make it per-page, > and we're done.
There's a 'block-dev' branch in my git tree, if you guys want to play around with it. It actually reverts fs/block-dev.c back to the 3.6 state (except for some whitespace damage that I refused to re-introduce), so that part of the changes should be pretty safe and well tested. The fs/buffer.c changes, of course, are new. It's largely the same patch I already sent out, with a small helper function to simplify it, and to keep the whole ACCESS_ONCE() thing in just a single place. That branch may be re-based in case I get reports or acks or whatever, so don't rely on it (or if you do, please let me know, and I'll stop editing it). The fact that I could just revert the fs/block-dev.c part to a known state makes me wonder if this might be safe for 3.7 after all (the fs/buffer.c changes all *look* safe). That way we'd not have to worry about any new semantics (whether they be EBUSY or any possible locking slowdowns or RT issues). But I'll think about it, and it would be good for people to double-check my fs/buffer.c stuff. Mikulas, does that pass your testing? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/