linux-kernel - Re: [PATCH v2] Do a proper locking for mmap and block size change

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

Message-ID: <CA+55aFztXAXB+MQvtUZSv9t1kET+yfFpBELZ7qxcPV-_u80Hew@mail.gmail.com>
Date:	Thu, 29 Nov 2012 11:50:43 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Chris Mason <chris.mason@...ionio.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mikulas Patocka <mpatocka@...hat.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Jens Axboe <axboe@...nel.dk>,
	Jeff Chua <jeff.chua.linux@...il.com>,
	Lai Jiangshan <laijs@...fujitsu.com>, Jan Kara <jack@...e.cz>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v2] Do a proper locking for mmap and block size change

On Thu, Nov 29, 2012 at 11:26 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> (I now realize that Mikulas was talking about this mess, while I
> thought he was talking about the AIO code which is largely sane).

Oh wow.

The direct-IO code really doesn't seem to care at all. I don't think
it needs locking either (it seems to do everything with a private
buffer-head), and the problem appears solely to be that it reads
i_blksize multiple times, so changing it just happens to confuse the
direct-io code.

If it were to read it only once, and then use that value, it looks
like it should all JustWork(tm).

And the right thing to do would seem to just add it to the
"dio_submit" structure, that we already have. And it already *has* a
blkbits field, but that's the "IO blocksize", not the "getblocks
blocksize", if I read that mess correctly.

Of course, it then *ALREADY* has that "blkfactor" thing, which is the
difference between i_blkbits and blktbits, so it effective *does* have
i_blkbits already in the dio_submit structure. But despite it all, it
keeps re-reading i_blksize.

Christ. That code is a mess.

              Linus
--
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/