Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date:   Mon, 16 Oct 2023 13:53:13 +0200
From:   Ingo Molnar <mingo@kernel.org>
To:     Jens Axboe <axboe@kernel.dk>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-next <linux-next@vger.kernel.org>,
        Sohil Mehta <sohil.mehta@intel.com>
Subject: Re: linux-next: manual merge of the block tree with the asm-generic
 tree
Message-ID: <ZS0kKWsCaYHhKeHa@gmail.com>
References: <20231009123118.4487a0e1@canb.auug.org.au>
 <20231009084812.GB14330@noisy.programming.kicks-ass.net>
 <cb4bb8e2-7dfe-4ca4-aa70-060f7b2f8f95@app.fastmail.com>
 <20231009141351.GD14330@noisy.programming.kicks-ass.net>
 <b7c57f03-4606-4190-98c5-344c49656f9c@kernel.dk>
 <66e09ad5-2dcf-4159-9c98-f37ac739a445@kernel.dk>
 <20231011175407.GG6307@noisy.programming.kicks-ass.net>
 <ZScUhud9eqKIQJjC@gmail.com>
 <bf5ecd2d-06a7-4c51-a762-6fe3753044b6@kernel.dk>
 <ZScbKPQur2qao5Gf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZScbKPQur2qao5Gf@gmail.com>
Precedence: bulk


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

> 
> * Jens Axboe <axboe@kernel.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