linux-kernel - Re: [git pull] vfs.git sysv pile

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 2 Mar 2023 22:35:41 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     "Fabio M. De Francesco" <fmdefrancesco@...il.com>
Cc:     Jan Kara <jack@...e.cz>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [git pull] vfs.git sysv pile

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 interpreted 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.
> > 
> > Now I see that you are interpreting his message as an invite to use them to 
> > shorten the time... 
> > 
> > Furthermore I'm not sure about how I should credit him. Should I merely 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.
> 
> What, for sysv part?  It's already in mainline; for minixfs and ufs, if you want
> to do those - whatever you want, I'd probably go for "modelled after sysv
> series in 6.2" - "Suggested-by" in those would suffice...
> 
> > @Al,
> > 
> > Can I really proceed with *your* work? What should the better suited tag be to 
> > credit you for the patches?
> > 
> > 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 a 
> > QEMU/KVM x86_32 bit VM, with 6GB RAM, running an HIGHMEM64GB enabled kernel.
> 
> Frankly, ext2 patchset had been more along the lines of "here's what untangling
> the calling conventions in ext2 would probably look like" than 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...

PS: now we can actually turn
        kunmap_local((void *)((unsigned long)page_addr & PAGE_MASK));
into
	kunmap_local(page_addr);

provided that commit doing that includes something along the lines of

Do-Not-Backport-Without: 88d7b12068b9 "highmem: round down the address passed to kunmap_flush_on_unmap()"

in commit message.