Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934560AbdC3P3H (ORCPT ); Thu, 30 Mar 2017 11:29:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41434 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934493AbdC3P26 (ORCPT ); Thu, 30 Mar 2017 11:28:58 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D71A380508 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=oleg@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D71A380508 Date: Thu, 30 Mar 2017 17:28:48 +0200 From: Oleg Nesterov To: Andy Lutomirski Cc: Andy Lutomirski , Andrew Morton , Linus Torvalds , Denys Vlasenko , "H. Peter Anvin" , Ingo Molnar , Jan Kratochvil , Pedro Alves , Thomas Gleixner , X86 ML , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 1/1] get_nr_restart_syscall() should return __NR_ia32_restart_syscall if __USER32_CS Message-ID: <20170330152848.GA27171@redhat.com> References: <20170328145413.GA3164@redhat.com> <20170328145432.GA3163@redhat.com> <20170328162736.GA3983@redhat.com> <20170329150535.GA22925@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 30 Mar 2017 15:28:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1735 Lines: 55 On 03/29, Andy Lutomirski wrote: > > On Wed, Mar 29, 2017 at 8:05 AM, Oleg Nesterov wrote: > > On 03/28, Oleg Nesterov wrote: > >> > >> On 03/28, Andy Lutomirski wrote: > >> > > >> > How about we store the syscall arch to be restored in task_struct > >> > along with restart_block? > >> > >> Yes, perhaps we will have to finally do this. Not really nice too. > > > > OK, how about the hack below? > > > > I do not want to a new member into task_struct/restart_block, so the > > patch below adds a sticky TS_COMPAT bit which logically is a member > > of "struct restart_block". > > Okay, but I'd much rather we just added a helper that's called in the > few places that actually write to restart_block. Oh, yes, I thought about this too. This obviously needs more changes, and every arch needs a dummy definition... I was thinking about static inline long setup_restart_block(void) { if (TS_COMPAT) set TS_COMPAT_XXX; else clear TS_COMPAT_XXX; return -ERESTART_RESTARTBLOCK; } so that we can do - ret = -ERESTART_RESTARTBLOCK; + ret = setup_restart_block(); but I don't really like this... Do you strongly prefer it over the -ERESTART_RESTARTBLOCK check in syscall_return_slowpath? I agree it doesn't look nice too but it connects to other TS_ magic we do in arch/x86/entry/, perhaps it is not that bad... > Or we just add the new syscall nr and see what breaks. The answer > could well be nothing at all. Well, strace knows about __NR_restart_syscall. It won't be really broken, but I guess it will report something like "unknown syscall" rather than restart_syscall(...). However, this still looks like a best solution to me, just I have no idea how much we can confuse user-space. Oleg.