linux-kernel - Re: [PATCH] exfat: update file system parameter handling

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]

Message-ID: <20200206065423.GZ23230@ZenIV.linux.org.uk>
Date:   Thu, 6 Feb 2020 06:54:23 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Valdis Klētnieks <valdis.kletnieks@...edu>
Cc:     Namjae Jeon <namjae.jeon@...sung.com>,
        'Namjae Jeon' <linkinjeon@...il.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        gregkh@...uxfoundation.org, sj1557.seo@...sung.com,
        pali.rohar@...il.com, arnd@...db.de,
        'Christoph Hellwig' <hch@....de>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] exfat: update file system parameter handling

On Wed, Feb 05, 2020 at 11:26:42PM -0500, Valdis Klētnieks wrote:
> On Tue, 04 Feb 2020 15:53:38 +0900, "Namjae Jeon" said:
> > > > Al Viro recently reworked the way file system parameters are handled
> > > > Update super.c to work with it in linux-next 20200203.
> 
> > Acked-by: Namjae Jeon <namjae.jeon@...sung.com>
> >
> > If I need to make v14 patch series for this, Let me know it.
> 
> Hmm... That's a process/git question that somebody else (probably Al Viro) will
> have to answer.
> 
> fs/exfat/super.c won't compile on next-20200203 or later without the patch, and
> as a practical matter the version that finally goes into the main tree will need the patch.
> 
> On the one hand, the proper way to track the history of that patch would be to
> cherry-pick it into the proper spot in your patch series, right after the
> commit that adds super.c.  Then the git history reflects what code came from
> where.
> 
> On the other hand, it leaves a really small window where a git bisect can land
> exactly on the commit that adds the unpatched version of super.c and fail to
> buiild.  If all the Signed-off-by's were from one person, the obvious answer is
> to fold the fix into the commit that adds super.c - but that loses the git
> history.
> 
> So I'm going to dodge the question by saying "What would Al Viro do?" :)

	The situation with #work.fs_parse is simple: I'm waiting for NFS series
to get in (git://git.linux-nfs.org/projects/anna/linux-nfs.git, that is).
 As soon as it happens, I'm sending #work.fs_parse + merge with nfs stuff +
fixups for said nfs stuff (as in
https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/commit/?id=c354ed1)
to Linus.  In case Anna decides to skip this cycle (and I've seen nothing that
might indicates that), I will just send #work.fs_parse as-is.

	I *can* rebase #work.fs_parse on top of NFS series (and vboxsf, and
exfat, etc.) and send it to Linus right before -rc1, with obviously identical
final state.  That would avoid all issues with bisect hazards, but Linus is
usually unhappy about rebases.  And bisect hazard window is narrow...

	Again, I've no problem with such rebase (hell, with additional
branch ending in the same tree as #merge.nfs-fs_parse, verifiable by
simple git diff - compare vfs.git merge.nfs-fs_parse.0 and
merge.nfs-fs_parse.1, the latter being a rebase on top of #nfs-next).
Linus, up to you...