linux-kernel - Re: linux-next: manual merge of the zonefs tree with the vfs-idmapping 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20230124083235.6fhvnjgl4bzuzwuq@wittgenstein>
Date:   Tue, 24 Jan 2023 09:32:35 +0100
From:   Christian Brauner <brauner@...nel.org>
To:     Damien Le Moal <damien.lemoal@...nsource.wdc.com>
Cc:     Stephen Rothwell <sfr@...hwell.id.au>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Damien Le Moal <Damien.LeMoal@....com>,
        Christian Brauner <christian@...uner.io>,
        Seth Forshee <sforshee@...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 zonefs tree with the
 vfs-idmapping tree

On Tue, Jan 24, 2023 at 09:11:47AM +0900, Damien Le Moal wrote:
> On 1/24/23 09:07, Stephen Rothwell wrote:
> > Hi Damien,
> > 
> > On Tue, 24 Jan 2023 08:30:29 +0900 Damien Le Moal <damien.lemoal@...nsource.wdc.com> wrote:
> >>
> >> OK. I think I will merge the 3 patches that create the conflict and rebase
> >> the patches. I need that for retesting at least. But given the size of the
> >> conflict resolution, I may push that as an update to my for-6.3/for-next
> >> branch. Let me see...
> >>
> >>> Alternatively, just leave the fix up to Linus (but mention it to him
> >>> when you send your pull requests).  
> >>
> >> Understood. Let me retest first :)
> > 
> > When I said "merge", I meant literally "git merge <some stable branch
> > from the vfs-mapping tree that contains the conflicting commit>" not
> > cherry pick the commits i.e. you would need to coordinate with
> > Christian about having a common branch (or making sure that the part of
> > his tree you pull in is immutable).
> 
> Yep, cherry picking did not work :)
> I did a merge test and came up with the same resolution as you did. It
> looks good. It looks big but is in fact fairly simple. I will keep it as
> is and signal it to Linus when I send my PR.

I don't rebase branches after they're in -next as soon as someone
wants to depend on them.

> 
> But retesting everything to be sure there are no issues.
> 
> Christian,
> 
> Next time, when you touch an fs, please cc the maintainer for acks. I had
> that zonefs series ready for a while and we could have coordinated for the
> conflict...

I understand merge conflicts aren't pleasant as I'm dealing with them on
a regular basis myself and I'm sorry that this is causing churn for you.

Similar to other large branches such as the initial folio conversion
that affected a lot of filesystems and other branches of mine it simply
becomes impractical to generate a massive recipients list.

All filesystems were touched in non-semantical ways and simply replace a
vfs type.

One of linux-next's tasks is to find generated merge conflicts so that
we can coordinate. As usual, I will send a list of merge conflicts
caused by one of our branches to Linus and point him to the relevant
threads that Steven reported with proposed resolutions as he prefers to
fix them up himself.

Sorry for the inconvenience.