iomap 5.15 branch construction ...

iomap 5.15 branch construction ...

[Darrick J. Wong]

Hi everyone!

iomap has become very popular for this cycle, with seemingly a lot of
overlapping patches and whatnot.  Does this accurately reflect all the
stuff that people are trying to send for 5.15?

1. So far, I think these v2 patches from Christoph are ready to go:

	iomap: simplify iomap_readpage_actor
	iomap: simplify iomap_add_to_ioend

2. This is the v9 "iomap: Support file tail packing" patch from Gao,
with a rather heavily edited commit:

	iomap: support reading inline data from non-zero pos

Should I wait for a v10 patch with spelling fixes as requested by
Andreas?  And if there is a v10 submission, please update the commit
message.

3. Matthew also threw in a patch:

	iomap: Support inline data with block size < page size

for which Andreas also sent some suggestions, so I guess I'm waiting for
a v2 of that patch?  It looks to me like the last time he sent that
series (on 24 July) he incorporated Gao's patch as patch 1 of the
series?

4. Andreas has a patch:

	iomap: Fix some typos and bad grammar

which looks more or less ready to go.

5. Christoph also had a series:

	RFC: switch iomap to an iterator model

Which I reviewed and sent some comments for, but (AFAICT) haven't seen a
non-RFC resubmission yet.  Is that still coming for 5.15?

6. Earlier, Eric Biggers had a patchset that made some iomap changes
ahead of porting f2fs to use directio.  I /think/ those changes were
dropped in the latest submission because the intended use of those
changes (counters of the number of pages undergoing reads or writes,
iirc?) has been replaced with something simpler.  IOWs, f2fs doesn't
need any iomap changes for 5.15, right?

7. Andreas also had a patchset:

	gfs2: Fix mmap + page fault deadlocks

That I've left unread because Linus started complaining about patch 1.
Is that not going forward, then?

So, I /think/ that's all I've received for this next cycle.  Did I miss
anything?  Matthew said he might roll some of these up and send me a
pull request, which would be nice... :)

--D

Re: iomap 5.15 branch construction ...

[Andreas Gruenbacher]

On Tue, Aug 3, 2021 at 12:11 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> Hi everyone!
>
> iomap has become very popular for this cycle, with seemingly a lot of
> overlapping patches and whatnot.  Does this accurately reflect all the
> stuff that people are trying to send for 5.15?
>
> 1. So far, I think these v2 patches from Christoph are ready to go:
>
>         iomap: simplify iomap_readpage_actor
>         iomap: simplify iomap_add_to_ioend
>
> 2. This is the v9 "iomap: Support file tail packing" patch from Gao,
> with a rather heavily edited commit:
>
>         iomap: support reading inline data from non-zero pos
>
> Should I wait for a v10 patch with spelling fixes as requested by
> Andreas?  And if there is a v10 submission, please update the commit
> message.
>
> 3. Matthew also threw in a patch:
>
>         iomap: Support inline data with block size < page size
>
> for which Andreas also sent some suggestions, so I guess I'm waiting for
> a v2 of that patch?  It looks to me like the last time he sent that
> series (on 24 July) he incorporated Gao's patch as patch 1 of the
> series?
>
> 4. Andreas has a patch:
>
>         iomap: Fix some typos and bad grammar
>
> which looks more or less ready to go.
>
> 5. Christoph also had a series:
>
>         RFC: switch iomap to an iterator model
>
> Which I reviewed and sent some comments for, but (AFAICT) haven't seen a
> non-RFC resubmission yet.  Is that still coming for 5.15?
>
> 6. Earlier, Eric Biggers had a patchset that made some iomap changes
> ahead of porting f2fs to use directio.  I /think/ those changes were
> dropped in the latest submission because the intended use of those
> changes (counters of the number of pages undergoing reads or writes,
> iirc?) has been replaced with something simpler.  IOWs, f2fs doesn't
> need any iomap changes for 5.15, right?
>
> 7. Andreas also had a patchset:
>
>         gfs2: Fix mmap + page fault deadlocks
>
> That I've left unread because Linus started complaining about patch 1.
> Is that not going forward, then?

Still working on it; it's way nastier than expected.

> So, I /think/ that's all I've received for this next cycle.  Did I miss
> anything?  Matthew said he might roll some of these up and send me a
> pull request, which would be nice... :)
>
> --D
>

Andreas

Re: iomap 5.15 branch construction ...

[Eric Biggers]

On Mon, Aug 02, 2021 at 03:11:14PM -0700, Darrick J. Wong wrote:
> 6. Earlier, Eric Biggers had a patchset that made some iomap changes
> ahead of porting f2fs to use directio.  I /think/ those changes were
> dropped in the latest submission because the intended use of those
> changes (counters of the number of pages undergoing reads or writes,
> iirc?) has been replaced with something simpler.  IOWs, f2fs doesn't
> need any iomap changes for 5.15, right?

Converting f2fs to use iomap for direct I/O doesn't require any iomap changes.
You might be referring to
https://lkml.kernel.org/r/20210604210908.2105870-7-satyat@google.com
("iomap: support direct I/O with fscrypt using blk-crypto"), which will be
needed to support direct I/O on encrypted files.  Direct I/O support on
encrypted files will be a new feature, and it's being held up for other reasons.
So there's nothing for you to do for 5.15.  (And separately, using iomap for
direct I/O in f2fs is being held up by existing f2fs direct I/O bugs.)

- Eric

Re: iomap 5.15 branch construction ...

[Darrick J. Wong]

On Mon, Aug 02, 2021 at 03:34:52PM -0700, Eric Biggers wrote:
> On Mon, Aug 02, 2021 at 03:11:14PM -0700, Darrick J. Wong wrote:
> > 6. Earlier, Eric Biggers had a patchset that made some iomap changes
> > ahead of porting f2fs to use directio.  I /think/ those changes were
> > dropped in the latest submission because the intended use of those
> > changes (counters of the number of pages undergoing reads or writes,
> > iirc?) has been replaced with something simpler.  IOWs, f2fs doesn't
> > need any iomap changes for 5.15, right?
> 
> Converting f2fs to use iomap for direct I/O doesn't require any iomap changes.
> You might be referring to
> https://lkml.kernel.org/r/20210604210908.2105870-7-satyat@google.com
> ("iomap: support direct I/O with fscrypt using blk-crypto"), which will be
> needed to support direct I/O on encrypted files.  Direct I/O support on
> encrypted files will be a new feature, and it's being held up for other reasons.
> So there's nothing for you to do for 5.15.  (And separately, using iomap for
> direct I/O in f2fs is being held up by existing f2fs direct I/O bugs.)

Ok, thank you for the update!

--D

> 
> - Eric

Re: iomap 5.15 branch construction ...

[Gao Xiang]

On Mon, Aug 02, 2021 at 03:11:14PM -0700, Darrick J. Wong wrote:
> Hi everyone!
> 
> iomap has become very popular for this cycle, with seemingly a lot of
> overlapping patches and whatnot.  Does this accurately reflect all the
> stuff that people are trying to send for 5.15?
> 
> 1. So far, I think these v2 patches from Christoph are ready to go:
> 
> 	iomap: simplify iomap_readpage_actor
> 	iomap: simplify iomap_add_to_ioend
> 
> 2. This is the v9 "iomap: Support file tail packing" patch from Gao,
> with a rather heavily edited commit:
> 
> 	iomap: support reading inline data from non-zero pos
> 
> Should I wait for a v10 patch with spelling fixes as requested by
> Andreas?  And if there is a v10 submission, please update the commit
> message.

I've already sent out v10 with these changes:
https://lore.kernel.org/r/20210803001727.50281-1-hsiangkao@linux.alibaba.com

Thanks,
Gao Xiang

Re: iomap 5.15 branch construction ...

[Darrick J. Wong]

On Tue, Aug 03, 2021 at 08:21:42AM +0800, Gao Xiang wrote:
> On Mon, Aug 02, 2021 at 03:11:14PM -0700, Darrick J. Wong wrote:
> > Hi everyone!
> > 
> > iomap has become very popular for this cycle, with seemingly a lot of
> > overlapping patches and whatnot.  Does this accurately reflect all the
> > stuff that people are trying to send for 5.15?
> > 
> > 1. So far, I think these v2 patches from Christoph are ready to go:
> > 
> > 	iomap: simplify iomap_readpage_actor
> > 	iomap: simplify iomap_add_to_ioend
> > 
> > 2. This is the v9 "iomap: Support file tail packing" patch from Gao,
> > with a rather heavily edited commit:
> > 
> > 	iomap: support reading inline data from non-zero pos
> > 
> > Should I wait for a v10 patch with spelling fixes as requested by
> > Andreas?  And if there is a v10 submission, please update the commit
> > message.
> 
> I've already sent out v10 with these changes:
> https://lore.kernel.org/r/20210803001727.50281-1-hsiangkao@linux.alibaba.com

Applied, thanks.

--D

> 
> Thanks,
> Gao Xiang

Re: iomap 5.15 branch construction ...

[Matthew Wilcox]

On Mon, Aug 02, 2021 at 03:11:14PM -0700, Darrick J. Wong wrote:
> Hi everyone!
> 
> iomap has become very popular for this cycle, with seemingly a lot of
> overlapping patches and whatnot.  Does this accurately reflect all the
> stuff that people are trying to send for 5.15?
> 
> 1. So far, I think these v2 patches from Christoph are ready to go:
> 
> 	iomap: simplify iomap_readpage_actor
> 	iomap: simplify iomap_add_to_ioend
> 
> 2. This is the v9 "iomap: Support file tail packing" patch from Gao,
> with a rather heavily edited commit:
> 
> 	iomap: support reading inline data from non-zero pos
> 
> Should I wait for a v10 patch with spelling fixes as requested by
> Andreas?  And if there is a v10 submission, please update the commit
> message.
> 
> 3. Matthew also threw in a patch:
> 
> 	iomap: Support inline data with block size < page size
> 
> for which Andreas also sent some suggestions, so I guess I'm waiting for
> a v2 of that patch?  It looks to me like the last time he sent that
> series (on 24 July) he incorporated Gao's patch as patch 1 of the
> series?

These four patches are at the base of my 'devel' branch of folios, ie
they're basically the next in the series after for-next.  So I've built
the rest of the iomap-folios patches on top of them.  I'll pull in Gao's
v10 tomorrow, retest and send you a git pull for those four?

> So, I /think/ that's all I've received for this next cycle.  Did I miss
> anything?  Matthew said he might roll some of these up and send me a
> pull request, which would be nice... :)

I ran out of time on Friday, and I took today (+ the weekend) off.
I'll catch up tomorrow.

Re: iomap 5.15 branch construction ...

[Christoph Hellwig]

I'm on vacation this week, so just a quick note:

I'd love to see 1. and 2. from your list in a public branch ASAP,
maybe also 3 and 4 if they get positive reviews so that I can
rebased the iter stuff ontop of that so that I can repost the iter
series with that as a baseline.

I still haven't succeeded getting a working DAX setup, though.

Re: iomap 5.15 branch construction ...

[Dave Chinner]

On Tue, Aug 03, 2021 at 09:17:37AM +0100, Christoph Hellwig wrote:
> I'm on vacation this week, so just a quick note:
> 
> I'd love to see 1. and 2. from your list in a public branch ASAP,
> maybe also 3 and 4 if they get positive reviews so that I can
> rebased the iter stuff ontop of that so that I can repost the iter
> series with that as a baseline.
> 
> I still haven't succeeded getting a working DAX setup, though.

Just set up a VM with a chunk of RAM and then use the memmap=
command line option to use some of that RAM as pmem. I use a VM with 32GB
of RAM (-m 32768) and then use this command line:

-append "console=ttyS0,115200 root=/dev/sda1 scsi_debug.add_host=0 memmap=8G!15G,8G!24G $1"

that gives me two 8GB pmem devices, one at a base address of 15GB
and the other at a base address of 24GB. This is the only way I've
been able to get "pmem" to work reliably with qemu. The persistence
lasts for the qemu process lifetime, so you can reboot the VM and
the devices still contain the data from the previous boot, but they
do not persist across restarting the qemu process.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com