[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121130163601.GA32238@infradead.org>
Date: Fri, 30 Nov 2012 11:36:01 -0500
From: Christoph Hellwig <hch@...radead.org>
To: Dave Chinner <david@...morbit.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Chris Mason <chris.mason@...ionio.com>,
Chris Mason <clmason@...ionio.com>,
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 Fri, Nov 30, 2012 at 01:49:10PM +1100, Dave Chinner wrote:
> > Ugh. That's a big violation of how buffer-heads are supposed to work:
> > the block number is very much defined to be in multiples of b_size
> > (see for example "submit_bh()" that turns it into a sector number).
> >
> > But you're right. The direct-IO code really *is* violating that, and
> > knows that get_block() ends up being defined in i_blkbits regardless
> > of b_size.
>
> Same with mpage_readpages(), so it's not just direct IO that has
> this problem....
The mpage code may actually fall back to BHs.
I have a version of the direct I/O code that uses the iomap_ops from the
multi-page write code that you originally started. It uses the new op
as primary interface for direct I/O and provides a helper for
filesystems that still use buffer heads internally. I'll try to dust it
off and send out a version for the current kernel.
--
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/
Powered by blists - more mailing lists