On Tue, Jun 25, 2019 at 8:58 PM Goldwyn Rodrigues <rgoldwyn@xxxxxxx> wrote: > > On 9:05 24/06, Christoph Hellwig wrote: > > On Fri, Jun 21, 2019 at 02:28:25PM -0500, Goldwyn Rodrigues wrote: > > > From: Goldwyn Rodrigues <rgoldwyn@xxxxxxxx> > > > > > > btrfs uses page->private as well to store extent_buffer. Make > > > the check stricter to make sure we are using page->private for iop by > > > comparing iblocksize < PAGE_SIZE. > > > > > > Signed-off-by: Goldwyn Rodrigues <rgoldwyn@xxxxxxxx> > > > > If btrfs uses page->private itself and also uses functions that call > > to_iomap_page we have a major problem, as we now have a usage conflict. > > > > How do you end up here? > > > > Btrfs uses page->private to identify which extent_buffer it belongs to. > So, if you read, it fills the page->private. Then you try to write to > it, iomap will assume it to be iomap_page pointer. > > I don't think we can move extent_buffer out of page->private for btrfs. > Any other ideas? The extent buffer is only for pages belonging to the btree inode (i.e. pages that correspond to a btree node/lead). Haven't looked in detail to this patchset, but you can't do buffered writes or direct IO against the btree inode, can you? So for file inodes, this problem doesn't exist. Thanks. > > -- > Goldwyn -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.”
