linux-erofs.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Andreas Gruenbacher <andreas.gruenbacher@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	linux-fsdevel@vger.kernel.org, linux-erofs@lists.ozlabs.org,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v5] iomap: support tail packing inline read
Date: Thu, 22 Jul 2021 08:57:18 +0800	[thread overview]
Message-ID: <YPjCbmgYdMji4WMH@B-P7TQMD6M-0146.local> (raw)
In-Reply-To: <YPi7MKYjMzjJjFB0@B-P7TQMD6M-0146.local>

On Thu, Jul 22, 2021 at 08:26:24AM +0800, Gao Xiang wrote:
> On Wed, Jul 21, 2021 at 05:19:11PM -0700, Darrick J. Wong wrote:
> > On Thu, Jul 22, 2021 at 08:12:46AM +0800, Gao Xiang wrote:

...

> > > > 
> > > > >  	addr = kmap_atomic(page);
> > > > > -	memcpy(addr, iomap->inline_data, size);
> > > > > -	memset(addr + size, 0, PAGE_SIZE - size);
> > > > > +	memcpy(addr + poff, iomap->inline_data - iomap->offset + pos, size);
> > > > 
> > > > I keep seeing this (iomap->inline_data + pos - iomap->offset)
> > > > construction in this patch, maybe it should be a helper?
> > > 
> > > I'm fine with this, (but I'm not good at naming), may I ask for
> > > some suggested naming? e.g.
> > > 
> > > static inline void *iomap_adjusted_inline_data(iomap, pos)
> > > 
> > > does that look good?
> > 
> > static inline void *
> > iomap_inline_buf(const struct iomap *iomap, loff_t pos)
> > {
> > 	return iomap->inline_data + pos - iomap->offset;
> > }
> > 
> > (gcc complaints about pointer arithmetic on void pointers notwithstanding)

Ok, will update, thanks!

> > 
> > > 
> > > > 
> > > > > +	memset(addr + poff + size, 0, PAGE_SIZE - poff - size);
> > > > >  	kunmap_atomic(addr);
> > > > > -	SetPageUptodate(page);
> > > > > +	iomap_set_range_uptodate(page, poff, PAGE_SIZE - poff);
> > > > > +	return PAGE_SIZE - poff;
> > > > >  }
> > > > >  
> > > > >  static inline bool iomap_block_needs_zeroing(struct inode *inode,
> > > > > @@ -245,19 +247,23 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data,
> > > > >  	loff_t orig_pos = pos;
> > > > >  	unsigned poff, plen;
> > > > >  	sector_t sector;
> > > > > +	int ret;
> > > > >  
> > > > > -	if (iomap->type == IOMAP_INLINE) {
> > > > > -		WARN_ON_ONCE(pos);
> > > > > -		iomap_read_inline_data(inode, page, iomap);
> > > > > -		return PAGE_SIZE;
> > > > > -	}
> > > > > -
> > > > > -	/* zero post-eof blocks as the page may be mapped */
> > > > >  	iop = iomap_page_create(inode, page);
> > > > > +	/* needs to skip some leading uptodate blocks */
> > > > >  	iomap_adjust_read_range(inode, iop, &pos, length, &poff, &plen);
> > > > >  	if (plen == 0)
> > > > >  		goto done;
> > > > >  
> > > > > +	if (iomap->type == IOMAP_INLINE) {
> > > > > +		ret = iomap_read_inline_data(inode, page, iomap, pos);
> > > > > +		if (ret < 0)
> > > > > +			return ret;
> > > > > +		plen = ret;
> > > > > +		goto done;
> > > > > +	}
> > > > > +
> > > > > +	/* zero post-eof blocks as the page may be mapped */
> > > > >  	if (iomap_block_needs_zeroing(inode, iomap, pos)) {
> > > > >  		zero_user(page, poff, plen);
> > > > >  		iomap_set_range_uptodate(page, poff, plen);
> > > > > @@ -589,6 +595,18 @@ __iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, int flags,
> > > > >  	return 0;
> > > > >  }
> > > > >  
> > > > > +static int iomap_write_begin_inline(struct inode *inode, loff_t pos,
> > > > > +		struct page *page, struct iomap *srcmap)
> > > > > +{
> > > > > +	/* needs more work for the tailpacking case, disable for now */
> > > > > +	if (WARN_ON_ONCE(srcmap->offset != 0))
> > > > > +		return -EIO;
> > > > > +	if (PageUptodate(page))
> > > > > +		return 0;
> > > > > +	iomap_read_inline_data(inode, page, srcmap, 0);
> > > > > +	return 0;
> > > > > +}
> > > > > +
> > > > >  static int
> > > > >  iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, unsigned flags,
> > > > >  		struct page **pagep, struct iomap *iomap, struct iomap *srcmap)
> > > > > @@ -618,7 +636,7 @@ iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, unsigned flags,
> > > > >  	}
> > > > >  
> > > > >  	if (srcmap->type == IOMAP_INLINE)
> > > > > -		iomap_read_inline_data(inode, page, srcmap);
> > > > > +		status = iomap_write_begin_inline(inode, pos, page, srcmap);
> > > > >  	else if (iomap->flags & IOMAP_F_BUFFER_HEAD)
> > > > >  		status = __block_write_begin_int(page, pos, len, NULL, srcmap);
> > > > >  	else
> > > > > diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> > > > > index 9398b8c31323..cbadb99fb88c 100644
> > > > > --- a/fs/iomap/direct-io.c
> > > > > +++ b/fs/iomap/direct-io.c
> > > > > @@ -379,22 +379,27 @@ iomap_dio_inline_actor(struct inode *inode, loff_t pos, loff_t length,
> > > > >  {
> > > > >  	struct iov_iter *iter = dio->submit.iter;
> > > > >  	size_t copied;
> > > > > +	void *dst = iomap->inline_data + pos - iomap->offset;
> > > > >  
> > > > > -	BUG_ON(pos + length > PAGE_SIZE - offset_in_page(iomap->inline_data));
> > > > > +	/* inline data must be inside a single page */
> > > > > +	if (WARN_ON_ONCE(length > PAGE_SIZE -
> > > > > +			 offset_in_page(iomap->inline_data)))
> > > > > +		return -EIO;
> > > > 
> > > > 	/*
> > > > 	 * iomap->inline_data is a kernel-mapped memory page, so we must
> > > > 	 * terminate the write at the end of that page.
> > > > 	 */
> > > > 	if (WARN_ON_ONCE(...))
> > > > 		return -EIO;
> > > 
> > > Ok.
> > > 
> > > > 
> > > > >  	if (dio->flags & IOMAP_DIO_WRITE) {
> > > > 
> > > > I thought we weren't allowing writes to an inline mapping unless
> > > > iomap->offset == 0?  Why is it necessary to change the directio write
> > > > path?  Shouldn't this be:
> > > > 
> > > > 		/* needs more work for the tailpacking case, disable for now */
> > > > 		if (WARN_ON_ONCE(pos > 0))
> > > > 			return -EIO;
> > > 
> > > That is because Andreas once pointed out a case in:
> > > https://lore.kernel.org/r/CAHpGcMJ4T6byxqmO6zZF78wuw01twaEvSW5N6s90qWm0q_jCXQ@mail.gmail.com/
> > > 
> > > "This should be a WARN_ON_ONCE(srcmap->offset != 0). Otherwise, something like:
> > > 
> > >   xfs_io -ft -c 'pwrite 1 2'
> > > 
> > > will fail because pos will be 1."
> > > 
> > > I think that is reasonable to gfs2. So I changed like this.
> > 
> > Ah, right.  I forgot that reads are always done for an entire page at a
> > time, whereas writes are of course byte-aligned.  I still wonder why any
> > changes are needed for directio write?
> 
> Very sorry about that, I misunderstood the hunk, here my original v1
> entirely disabled pos != 0 write direct I/O path like this:
> 
> https://lore.kernel.org/linux-fsdevel/20210716050724.225041-2-hsiangkao@linux.alibaba.com/
> "+	if (WARN_ON_ONCE(pos && (dio->flags & IOMAP_DIO_WRITE)))
> +		return -EIO;"
> 
> Then Christoph pointed out a case why pos != 0 may not be sufficient:
> https://lore.kernel.org/linux-fsdevel/YPFPDS5ktWJEUKTo@infradead.org/
> "I'm pretty sure gfs2 supports direct writes to inline data, so we should
> not disable it. "

Sorry, I was completely buried in the previous comments. I forgot to
mention the last part of this, then Christoph suggested:

https://lore.kernel.org/linux-fsdevel/YPVe41YqpfGLNsBS@infradead.org/

"We also need to take the offset into account for the write side.
 I guess it would be nice to have a local variable for the inline
 address to not duplicate that calculation multiple times."

I think that is reasonable since we allow pos != 0 direct write now,
so that was the whole story.

Thanks,
Gao Xiang

> 
> Thanks,
> Gao Xiang
> 

      reply	other threads:[~2021-07-22  0:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21  8:23 Gao Xiang
2021-07-21 22:24 ` Darrick J. Wong
2021-07-22  0:12   ` Gao Xiang
2021-07-22  0:19     ` Darrick J. Wong
2021-07-22  0:26       ` Gao Xiang
2021-07-22  0:57         ` Gao Xiang [this message]

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=YPjCbmgYdMji4WMH@B-P7TQMD6M-0146.local \
    --to=hsiangkao@linux.alibaba.com \
    --cc=andreas.gruenbacher@gmail.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@infradead.org \
    --subject='Re: [PATCH v5] iomap: support tail packing inline read' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).