From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5700C2D0A3 for ; Wed, 4 Nov 2020 18:00:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5166720825 for ; Wed, 4 Nov 2020 18:00:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726779AbgKDSAd (ORCPT ); Wed, 4 Nov 2020 13:00:33 -0500 Received: from foss.arm.com ([217.140.110.172]:41310 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726608AbgKDSAd (ORCPT ); Wed, 4 Nov 2020 13:00:33 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6807A139F; Wed, 4 Nov 2020 10:00:32 -0800 (PST) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6AE643F718; Wed, 4 Nov 2020 10:00:30 -0800 (PST) Date: Wed, 4 Nov 2020 18:00:26 +0000 From: Dave Martin To: Catalin Marinas Cc: "Eric W. Biederman" , Peter Collingbourne , Evgenii Stepanov , Kostya Serebryany , Vincenzo Frascino , Will Deacon , Oleg Nesterov , "James E.J. Bottomley" , Linux ARM , Kevin Brodsky , Andrey Konovalov , Richard Henderson , linux-api@vger.kernel.org, Helge Deller , David Spickett Subject: Re: [PATCH v13 1/8] parisc: Drop parisc special case for __sighandler_t Message-ID: <20201104180026.GF6882@arm.com> References: <7e26600459cb08c5016611b37fe88c23098b40eb.1604376407.git.pcc@google.com> <87a6vx6p11.fsf@x220.int.ebiederm.org> <20201104172447.GF28902@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201104172447.GF28902@gaia> User-Agent: Mutt/1.5.23 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Wed, Nov 04, 2020 at 05:24:48PM +0000, Catalin Marinas wrote: > On Wed, Nov 04, 2020 at 10:54:34AM -0600, Eric W. Biederman wrote: > > Peter Collingbourne writes: > > > From: Helge Deller > > > > > > I believe we can and *should* drop this parisc-specific typedef for > > > __sighandler_t when compiling a 64-bit kernel. The reasons: > > > > > > 1. We don't have a 64-bit userspace yet, so nothing (on userspace side) > > > can break. > > > > > > 2. Inside the Linux kernel, this is only used in kernel/signal.c, in > > > function kernel_sigaction() where the signal handler is compared against > > > SIG_IGN. SIG_IGN is defined as (__sighandler_t)1), so only the pointers > > > are compared. > > > > > > 3. Even when a 64-bit userspace gets added at some point, I think > > > __sighandler_t should be defined what it is: a function pointer struct. > > > > > > I compiled kernel/signal.c with and without the patch, and the produced code > > > is identical in both cases. > > > > > > Signed-off-by: Helge Deller > > > Reviewed-by: Peter Collingbourne > > > Link: > > > https://linux-review.googlesource.com/id/I21c43f21b264f339e3aa395626af838646f62d97 > > > > Peter as you have sent this, this also needs your Signed-off-by. > > > > Otherwise this looks reasonable to me. > > Acked-by: "Eric W. Biederman" > > > > While the final bits look like they are still under discussion it looks > > like the preceding cleanups are pretty solid at this point. > > Minor nits, unless you nak the whole approach of SA_FAULTFLAGS and > SA_UNSUPPORTED ;) (it looks a bit complicated to me but I don't have a > better idea for a generic implementation). It is a bit complicated, but we didn't come up with anything better so far that can cope with the various historical quirks in the signal API. A bigger overhaul of the whole interface might be a good idea at some point, but it would probably be a mistake to rush that. It may be possible to make the SA_UNSUPPORTED stuff a bit more digestible via libc. I'll try to get a discussion started on that. [...] Cheers ---Dave