From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
darrick.wong@oracle.com, david@fromorbit.com
Subject: Re: [PATCH 3/6] iomap: Check iblocksize before transforming page->private
Date: Tue, 25 Jun 2019 13:56:59 -0500 [thread overview]
Message-ID: <20190625185659.tqaikm27onz6g3jt@fiona> (raw)
In-Reply-To: <20190624070536.GA3675@lst.de>
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@suse.com>
> >
> > 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@suse.com>
>
> 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?
--
Goldwyn
next prev parent reply other threads:[~2019-06-25 18:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-21 19:28 [PATCH 0/6] Btrfs iomap Goldwyn Rodrigues
2019-06-21 19:28 ` [PATCH 1/6] iomap: Use a IOMAP_COW/srcmap for a read-modify-write I/O Goldwyn Rodrigues
2019-06-22 0:46 ` Darrick J. Wong
2019-06-25 19:17 ` Goldwyn Rodrigues
2019-06-26 6:21 ` Christoph Hellwig
2019-06-24 7:07 ` Christoph Hellwig
2019-06-25 19:14 ` Goldwyn Rodrigues
2019-06-26 1:36 ` Shiyang Ruan
2019-06-26 6:39 ` Christoph Hellwig
2019-06-26 16:10 ` Goldwyn Rodrigues
2019-06-26 17:34 ` Darrick J. Wong
2019-06-26 18:00 ` Darrick J. Wong
2019-06-26 18:42 ` Goldwyn Rodrigues
2019-06-21 19:28 ` [PATCH 2/6] iomap: Read page from srcmap for IOMAP_COW Goldwyn Rodrigues
2019-06-22 0:41 ` Darrick J. Wong
2019-06-21 19:28 ` [PATCH 3/6] iomap: Check iblocksize before transforming page->private Goldwyn Rodrigues
2019-06-22 0:21 ` Darrick J. Wong
2019-06-25 19:22 ` Goldwyn Rodrigues
2019-06-24 7:05 ` Christoph Hellwig
2019-06-25 18:56 ` Goldwyn Rodrigues [this message]
2019-06-25 20:04 ` Filipe Manana
2019-06-26 3:03 ` Goldwyn Rodrigues
2019-06-26 6:42 ` Nikolay Borisov
2019-06-26 6:16 ` Christoph Hellwig
2019-06-21 19:28 ` [PATCH 4/6] btrfs: Add a simple buffered iomap write Goldwyn Rodrigues
2019-06-21 19:28 ` [PATCH 5/6] btrfs: Add CoW in iomap based writes Goldwyn Rodrigues
2019-06-21 19:28 ` [PATCH 6/6] btrfs: remove buffered write code made unnecessary Goldwyn Rodrigues
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190625185659.tqaikm27onz6g3jt@fiona \
--to=rgoldwyn@suse.de \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.