linux-kernel - Re: linux-next: manual merge of the block tree with the asm-generic 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: <ZS0kKWsCaYHhKeHa@gmail.com>
Date:   Mon, 16 Oct 2023 13:53:13 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Arnd Bergmann <arnd@...db.de>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-next <linux-next@...r.kernel.org>,
        Sohil Mehta <sohil.mehta@...el.com>
Subject: Re: linux-next: manual merge of the block tree with the asm-generic
 tree


* Ingo Molnar <mingo@...nel.org> wrote:

> 
> * Jens Axboe <axboe@...nel.dk> wrote:
> 
> > >>> Peter, what's the verdict - do you want to rebase it, or leave it 
> > >>> as-is?
> > >>
> > >> Ah, I looked into doing this, but tip/locking/core has since grown a 
> > >> bunch of patches and has a merge commit -- I talked to Ingo yesterday 
> > >> and he proposed just queueing a fix on top instead of doing a full 
> > >> rebase.
> > >>
> > >> Ingo, that still your preferred solution?
> > > 
> > > Yeah, that would be the best solution IMO - it's not like there's any 
> > > real prospect of someone bisecting futex2 patch-enablement commits on 
> > > Alpha ... and the bisection distance isn't particularly large either in 
> > > any case.
> > 
> > OK, works for me. I'll keep my branch as-is, and just ensure it gets sent 
> > out after locking/core has been pulled by Linus.
> 
> Thank you!

Heads-up: the futex syscall numbers are now fixed on Alpha in the locking 
tree via:

  dcc134510eef ("alpha: Fix up new futex syscall numbers")

This would, I presume, trigger a new conflict in -next, which should be 
resolved in an identical fashion.

Jens, feel free to send your tree to Linus in any ordering with the
locking tree, there's no real dependency between them, and whoever
sends last should warn Linus about the known conflict.

Thanks,

	Ingo