From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754164AbbG2XIW (ORCPT ); Wed, 29 Jul 2015 19:08:22 -0400 Received: from www.linutronix.de ([62.245.132.108]:43144 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753434AbbG2XIV (ORCPT ); Wed, 29 Jul 2015 19:08:21 -0400 Date: Thu, 30 Jul 2015 01:07:46 +0200 (CEST) From: Thomas Gleixner To: Stephen Rothwell cc: Andrea Arcangeli , Andrew Morton , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Andy Lutomirski , Eric B Munson , "Dr. David Alan Gilbert" Subject: Re: linux-next: manual merge of the akpm-current tree with the tip tree In-Reply-To: <20150730090610.0922a2c6@canb.auug.org.au> Message-ID: References: <20150728160015.142f588f@canb.auug.org.au> <20150729171256.GA10863@redhat.com> <20150730090610.0922a2c6@canb.auug.org.au> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 30 Jul 2015, Stephen Rothwell wrote: > Hi Andrea, > > On Wed, 29 Jul 2015 19:12:56 +0200 Andrea Arcangeli wrote: > > > > On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote: > > > -359 i386 userfaultfd sys_userfaultfd > > > ++374 i386 userfaultfd sys_userfaultfd > > > > Do I understand correctly the syscall number of userfaultfd for x86 > > 32bit has just changed from 359 to 374? Appreciated that you CCed me > > on such a relevant change to be sure I didn't miss it. > > > > Then the below is needed as well. > > I have added the below patch to linux-next from today. > > > One related question: is it ok to ship kernels in production right now > > with the userfaultfd syscall number 374 for x86 32bit ABI (after the > > above change) and 323 for x86-64 64bit ABI, with these syscalls number > > registered in linux-next or it may keep changing like it has just > > happened? I refer only to userfaultfd syscalls of x86 32bit and x86-64 > > 64bit, not all other syscalls in linux-next. > > These numbers are certainly not in any way official, they are just the > result of my merge conflict fixup. So, yes, they could change again if > someone adds another new syscall to any tree but Andrew's. > > > Of course, I know full well that the standard answer is no, and in > > fact the above is an expected and fine change. In other words what I'm > > really asking is if I wonder if I could get an agreement here that > > from now on, the syscall number of userfaultfd for x86 32bit and > > x86-64 64bit won't change anymore in linux-next and it's already > > reserved just like if it was already upstream. > > Like Thomas said, send a patch to the x86 maintainers. I suspect (if > the rest of the implementation needs to stay in Andrew's tree) that it > could be a simple as a patch to the syscall tables using ni_syscall and > a comment. Thomas? Yes, that's all it takes to reserve a syscall number. Thanks, tglx