On Thu, Nov 29, 2012 at 9:19 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
