linux-kernel - Re: linux-next: manual merge of the vfs tree with the vfs-brauner tree

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250708004550.GS1880847@ZenIV>
Date: Tue, 8 Jul 2025 01:45:50 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Christian Brauner <brauner@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the vfs tree with the vfs-brauner
 tree

On Tue, Jul 08, 2025 at 01:25:09AM +0100, Al Viro wrote:

> Umm...  Let's do it that way - fs/fhandle.c chunk of that commit is
> trivially split off and the rest should not conflict at all.
> 
> Christian, would you mind throwing this on top of your vfs.pidfs?  I'm dropping
> that part from my #work.misc commit...

Argh...  Sorry, no go - that chunk needs to go before the rest of conversion
commit.  Hmm...

See vfs/vfs.git #vfs-6.17.fs_struct; that branches off your "reflow" commit
and it merges clean with #vfs.all, AFAICS.

Are you OK with that variant?  I've no strong preferences re branchpoints,
but some folks do - no idea if you have any policies in that respect.

If you don't have any problems with it, just merge it into #vfs.all
and I'll drop that commit from #work.misc