From:   "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     Jan Kara <jack@suse.cz>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [git pull] vfs.git sysv pile
Date:   Fri, 03 Mar 2023 06:10:40 +0100
Message-ID: <2187011.72vocr9iq0@suse>
In-Reply-To: <ZAEkveTgVqKau+ab@ZenIV>
References: <Y/gugbqq858QXJBY@ZenIV> <ZAD6n+mH/P8LDcOw@ZenIV> <ZAEkveTgVqKau+ab@ZenIV>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk

On gioved=EC 2 marzo 2023 23:35:41 CET Al Viro wrote:
> On Thu, Mar 02, 2023 at 07:35:59PM +0000, Al Viro wrote:
> > On Thu, Mar 02, 2023 at 12:31:46PM +0100, Fabio M. De Francesco wrote:
> > > But... when yesterday Al showed his demo patchset I probably interpre=
ted
> > > his
> > > reply the wrong way and thought that since he spent time for the demo=
 he
> > > wanted to put this to completion on his own.
> > >=20
> > > Now I see that you are interpreting his message as an invite to use t=
hem
> > > to
> > > shorten the time...
> > >=20
> > > Furthermore I'm not sure about how I should credit him. Should I mere=
ly
> > > add a
> > > "Suggested-by:" tag or more consistent "Co-authored-by: Al Viro <...>=
"?
> > > Since
> > > he did so much I'd rather the second but I need his permission.
> >=20
> > What, for sysv part?  It's already in mainline; for minixfs and ufs, if=
=20
you
> > want to do those - whatever you want, I'd probably go for "modeled after
> > sysv series in 6.2" - "Suggested-by" in those would suffice...
> >=20
> > > @Al,
> > >=20
> > > Can I really proceed with *your* work? What should the better suited =
tag
> > > be to credit you for the patches?
> > >=20
> > > If you can reply today or at least by Friday, I'll pick your demo
> > > patchset,
> > > put it to completion, make the patches and test them with (x)fstests =
on=20
a
> > > QEMU/KVM x86_32 bit VM, with 6GB RAM, running an HIGHMEM64GB enabled
> > > kernel.
> >=20
> > Frankly, ext2 patchset had been more along the lines of "here's what
> > untangling the calling conventions in ext2 would probably look like" th=
an
> > anything else. If you are willing to test (and review) that sucker and =
it
> > turns out to be OK, I'll be happy to slap your tested-by on those during
> > rebase and feed them to Jan...
>=20
> PS: now we can actually turn
>         kunmap_local((void *)((unsigned long)page_addr & PAGE_MASK));
> into
> 	kunmap_local(page_addr);
>=20
> provided that commit doing that includes something along the lines of
>=20
> Do-Not-Backport-Without: 88d7b12068b9 "highmem: round down the address=20
passed
> to kunmap_flush_on_unmap()"
>=20
> in commit message.

I'll do it for fs/sysv.

Instead there is no need to change anything in my series for fs/ufs (it was=
 =20
made as if we already had 88d7b12068b9 "highmem: round down the address pas=
sed=20
to kunmap_flush_on_unmap()" in place).

Thanks,

=46abio