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=-2.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 C30B2C433DF for ; Wed, 13 May 2020 21:12:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BCC2B20659 for ; Wed, 13 May 2020 21:12:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589404320; bh=NB238MLfyhbZzQnDf+p0MJLkeyGVTyJL/894A4j8O3Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=KI3/LjoYmKxk7QDOtzrqCWh4c1WzPlUDq+J4F8m215CU0Dsh+QVUBN4t2SJL4Oy/k X5/2bD4NWSOFPyd9qqQGjpTASIJ1Ftq6JKv0G+RCNUKQBNWi0B0Y5Jgba2lTDdA8ex BL5LC0IILdkIFoI0VPyKJvXJk2ySbUxISQ9WIjW0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726070AbgEMVMA (ORCPT ); Wed, 13 May 2020 17:12:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:33522 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725943AbgEMVMA (ORCPT ); Wed, 13 May 2020 17:12:00 -0400 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 43F7020575; Wed, 13 May 2020 21:11:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589404319; bh=NB238MLfyhbZzQnDf+p0MJLkeyGVTyJL/894A4j8O3Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=usjBTM53z14/XldTXUHg1fDyfhm3RaLqPkhQietnIClnGrdlv3YHpe7sb0QQoNL0q 1ZhqQg/sYfEhdvxlcq8wt98mmsHQmgtb8ZplpJMHDM51HNzS1/+uMOrkp0t7lTfSz7 nGYbxkpB0EXjt5khIcLOcFXf+YwH65zW9aLRgFvk= Date: Wed, 13 May 2020 22:11:54 +0100 From: Will Deacon To: Dave Martin Cc: "Michael Kerrisk (man-pages)" , linux-man@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Catalin Marinas Subject: Re: [PATCH 13/14] prctl.2: Add SVE prctls (arm64) Message-ID: <20200513211153.GB28594@willie-the-truck> References: <1589301419-24459-1-git-send-email-Dave.Martin@arm.com> <1589301419-24459-14-git-send-email-Dave.Martin@arm.com> <20200513084351.GB18196@willie-the-truck> <20200513104635.GD21779@arm.com> <20200513140200.GP21779@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200513140200.GP21779@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-man-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org On Wed, May 13, 2020 at 03:02:00PM +0100, Dave Martin wrote: > On Wed, May 13, 2020 at 01:01:12PM +0200, Michael Kerrisk (man-pages) wrote: > > On 5/13/20 12:46 PM, Dave Martin wrote: > > > On Wed, May 13, 2020 at 09:43:52AM +0100, Will Deacon wrote: > > >> On Tue, May 12, 2020 at 05:36:58PM +0100, Dave Martin wrote: > > > glibc explicitly has > > > > > > extern int prctl (int __option, ...); > > > > > > (and nobody has to write _exit(0, 0, 0, 0, 0, 0) after all.) > > > > > > Is there some agreed rationale for requiring redundant arguments to be > > > supplied explicitly as zero? For now there are likely to be few users > > > of this, so we _might_ get away with changing the behaviour here if it's > > > considered important enough. > > > > See above. > > So there is no bulletproof rationale for either approach, but the main > concern is inconsistency? Have I understood that right? I think it's all just an extension of "make sure unused parameters are 0" idiom which allows those bits to be safely repurposed for flags and things later on without the worry of existing applications getting away with passing junk. > I'll propose to get that written down in the kernel source somewhere > if so. That would be a really good idea, actually! > (From my end, the pros and cons of the two approaches seem superficial > but the inconsistency is indeed annoying. For PR_SVE_SET_VL, I think > the first example I looked at didn't zero the trailing arguments, so I > didn't either... but it's been upstream for several releases, so most > likely we're stuck with it.) FWIW, I wasn't blaming you for this. Just that these oversights aren't always apparent when reviewing patches, but become more clear when reviewing the documentation. > > > There is no forwards compatibility problem with this prctl though, > > > because there are spare bits in arg2 which can "turn on" additional > > > args if needed. > > > > > > Also, it's implausible that PR_SVE_GET_VL will ever want an argument. > > > > > > There are still 2 billion unallocated prctl numbers, so new prctls can > > > always be added if there's ever a need to work around these limitations, > > > but it seems extremely unlikely. Oh, there are ways out, but had I noticed this during code review it would've been very easy just to enforce zero for the other args and be done with it. > > >>> +If > > >>> +.B PR_SVE_VL_INHERIT > > >>> +is also included in > > >>> +.IR arg2 , > > >>> +it takes effect > > >>> +.I after > > >>> +this deferred change. > > >> > > >> I find this a bit hard to follow, since it's not clear to me whether the > > >> INHERIT flag is effectively set before or after the next execve(). In other > > >> words, if both PR_SVE_SET_VL_ONEXEC and PR_SVE_VL_INHERIT are specified, > > >> is the vector length preserved or reset on the next execve()? > > > > > > It makes no difference, because the ONEXEC handling takes priority over > > > the INHERIT handling. But either way INHERIT is never cleared by execve() > > > and will apply at subsequent execs(). > > > > > > Explaining all this properly seems out of scope here. Maybe this should > > > be trimmed down rather than elaborated? Or perhaps just explain it in > > > terms of what the kernel does instead of futile attempts to make it > > > intuitive? Hmm, if we don't explain it in the man page then we should at least point people to somewhere where they can get the gory details, because I think they're necessary in order to use the prctl() request correctly. I'm still not confident that I understand the semantics of setting both PR_SVE_SET_VL_ONEXEC and PR_SVE_VL_INHERIT without reading the code, which may change. (I concede on all the spelling/grammar discussions ;) Will From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH 13/14] prctl.2: Add SVE prctls (arm64) Date: Wed, 13 May 2020 22:11:54 +0100 Message-ID: <20200513211153.GB28594@willie-the-truck> References: <1589301419-24459-1-git-send-email-Dave.Martin@arm.com> <1589301419-24459-14-git-send-email-Dave.Martin@arm.com> <20200513084351.GB18196@willie-the-truck> <20200513104635.GD21779@arm.com> <20200513140200.GP21779@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20200513140200.GP21779-5wv7dgnIgG8@public.gmane.org> Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Dave Martin Cc: "Michael Kerrisk (man-pages)" , linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Catalin Marinas List-Id: linux-arch.vger.kernel.org On Wed, May 13, 2020 at 03:02:00PM +0100, Dave Martin wrote: > On Wed, May 13, 2020 at 01:01:12PM +0200, Michael Kerrisk (man-pages) wrote: > > On 5/13/20 12:46 PM, Dave Martin wrote: > > > On Wed, May 13, 2020 at 09:43:52AM +0100, Will Deacon wrote: > > >> On Tue, May 12, 2020 at 05:36:58PM +0100, Dave Martin wrote: > > > glibc explicitly has > > > > > > extern int prctl (int __option, ...); > > > > > > (and nobody has to write _exit(0, 0, 0, 0, 0, 0) after all.) > > > > > > Is there some agreed rationale for requiring redundant arguments to be > > > supplied explicitly as zero? For now there are likely to be few users > > > of this, so we _might_ get away with changing the behaviour here if it's > > > considered important enough. > > > > See above. > > So there is no bulletproof rationale for either approach, but the main > concern is inconsistency? Have I understood that right? I think it's all just an extension of "make sure unused parameters are 0" idiom which allows those bits to be safely repurposed for flags and things later on without the worry of existing applications getting away with passing junk. > I'll propose to get that written down in the kernel source somewhere > if so. That would be a really good idea, actually! > (From my end, the pros and cons of the two approaches seem superficial > but the inconsistency is indeed annoying. For PR_SVE_SET_VL, I think > the first example I looked at didn't zero the trailing arguments, so I > didn't either... but it's been upstream for several releases, so most > likely we're stuck with it.) FWIW, I wasn't blaming you for this. Just that these oversights aren't always apparent when reviewing patches, but become more clear when reviewing the documentation. > > > There is no forwards compatibility problem with this prctl though, > > > because there are spare bits in arg2 which can "turn on" additional > > > args if needed. > > > > > > Also, it's implausible that PR_SVE_GET_VL will ever want an argument. > > > > > > There are still 2 billion unallocated prctl numbers, so new prctls can > > > always be added if there's ever a need to work around these limitations, > > > but it seems extremely unlikely. Oh, there are ways out, but had I noticed this during code review it would've been very easy just to enforce zero for the other args and be done with it. > > >>> +If > > >>> +.B PR_SVE_VL_INHERIT > > >>> +is also included in > > >>> +.IR arg2 , > > >>> +it takes effect > > >>> +.I after > > >>> +this deferred change. > > >> > > >> I find this a bit hard to follow, since it's not clear to me whether the > > >> INHERIT flag is effectively set before or after the next execve(). In other > > >> words, if both PR_SVE_SET_VL_ONEXEC and PR_SVE_VL_INHERIT are specified, > > >> is the vector length preserved or reset on the next execve()? > > > > > > It makes no difference, because the ONEXEC handling takes priority over > > > the INHERIT handling. But either way INHERIT is never cleared by execve() > > > and will apply at subsequent execs(). > > > > > > Explaining all this properly seems out of scope here. Maybe this should > > > be trimmed down rather than elaborated? Or perhaps just explain it in > > > terms of what the kernel does instead of futile attempts to make it > > > intuitive? Hmm, if we don't explain it in the man page then we should at least point people to somewhere where they can get the gory details, because I think they're necessary in order to use the prctl() request correctly. I'm still not confident that I understand the semantics of setting both PR_SVE_SET_VL_ONEXEC and PR_SVE_VL_INHERIT without reading the code, which may change. (I concede on all the spelling/grammar discussions ;) Will 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=-2.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no 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 751F3C433E0 for ; Wed, 13 May 2020 21:12:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6714120575 for ; Wed, 13 May 2020 21:12:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZlzGfBtE"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="usjBTM53" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6714120575 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=yreJ7fHkWQjq13lbaorhGD9z9ie0cTDnlKpkHFndnKk=; b=ZlzGfBtEfXNcOV j4s+fLPGVmbzJ50n2eJkPIWuTg/W0ty5+ZN9xvQ+Hv80fIdj50+n8gucfmWLHtJ+fOcFFYA6aG6Ki 2pLUQ5RV5KbWTVfdzzmdts6REo5wPQcgZo2MfOopmJi7YW4fTFZtUDwRJxr0XUgUSuazZGa/8x85H cKJRqN+fhwpkBcnt512SkBqRvg30CdgNsCxAP4xbiK9dDgdo2p90ECgvJuw3FBB+zNjrxcDGl13EK N8j/Vhpn+qLQN2apbrY7+YMUMQUftk4+W2TfCampZvzlmskd9G+eKezYxoC0Q1bCL+ZvIOYrcRlOH ZY6lAYZ1ud4gjeJqsbxA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jYyfa-00062o-Bf; Wed, 13 May 2020 21:12:02 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jYyfX-00062S-PH for linux-arm-kernel@lists.infradead.org; Wed, 13 May 2020 21:12:01 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 43F7020575; Wed, 13 May 2020 21:11:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589404319; bh=NB238MLfyhbZzQnDf+p0MJLkeyGVTyJL/894A4j8O3Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=usjBTM53z14/XldTXUHg1fDyfhm3RaLqPkhQietnIClnGrdlv3YHpe7sb0QQoNL0q 1ZhqQg/sYfEhdvxlcq8wt98mmsHQmgtb8ZplpJMHDM51HNzS1/+uMOrkp0t7lTfSz7 nGYbxkpB0EXjt5khIcLOcFXf+YwH65zW9aLRgFvk= Date: Wed, 13 May 2020 22:11:54 +0100 From: Will Deacon To: Dave Martin Subject: Re: [PATCH 13/14] prctl.2: Add SVE prctls (arm64) Message-ID: <20200513211153.GB28594@willie-the-truck> References: <1589301419-24459-1-git-send-email-Dave.Martin@arm.com> <1589301419-24459-14-git-send-email-Dave.Martin@arm.com> <20200513084351.GB18196@willie-the-truck> <20200513104635.GD21779@arm.com> <20200513140200.GP21779@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200513140200.GP21779@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200513_141159_861088_58C7D074 X-CRM114-Status: GOOD ( 27.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, linux-man@vger.kernel.org, "Michael Kerrisk \(man-pages\)" , linux-arm-kernel@lists.infradead.org, Catalin Marinas Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, May 13, 2020 at 03:02:00PM +0100, Dave Martin wrote: > On Wed, May 13, 2020 at 01:01:12PM +0200, Michael Kerrisk (man-pages) wrote: > > On 5/13/20 12:46 PM, Dave Martin wrote: > > > On Wed, May 13, 2020 at 09:43:52AM +0100, Will Deacon wrote: > > >> On Tue, May 12, 2020 at 05:36:58PM +0100, Dave Martin wrote: > > > glibc explicitly has > > > > > > extern int prctl (int __option, ...); > > > > > > (and nobody has to write _exit(0, 0, 0, 0, 0, 0) after all.) > > > > > > Is there some agreed rationale for requiring redundant arguments to be > > > supplied explicitly as zero? For now there are likely to be few users > > > of this, so we _might_ get away with changing the behaviour here if it's > > > considered important enough. > > > > See above. > > So there is no bulletproof rationale for either approach, but the main > concern is inconsistency? Have I understood that right? I think it's all just an extension of "make sure unused parameters are 0" idiom which allows those bits to be safely repurposed for flags and things later on without the worry of existing applications getting away with passing junk. > I'll propose to get that written down in the kernel source somewhere > if so. That would be a really good idea, actually! > (From my end, the pros and cons of the two approaches seem superficial > but the inconsistency is indeed annoying. For PR_SVE_SET_VL, I think > the first example I looked at didn't zero the trailing arguments, so I > didn't either... but it's been upstream for several releases, so most > likely we're stuck with it.) FWIW, I wasn't blaming you for this. Just that these oversights aren't always apparent when reviewing patches, but become more clear when reviewing the documentation. > > > There is no forwards compatibility problem with this prctl though, > > > because there are spare bits in arg2 which can "turn on" additional > > > args if needed. > > > > > > Also, it's implausible that PR_SVE_GET_VL will ever want an argument. > > > > > > There are still 2 billion unallocated prctl numbers, so new prctls can > > > always be added if there's ever a need to work around these limitations, > > > but it seems extremely unlikely. Oh, there are ways out, but had I noticed this during code review it would've been very easy just to enforce zero for the other args and be done with it. > > >>> +If > > >>> +.B PR_SVE_VL_INHERIT > > >>> +is also included in > > >>> +.IR arg2 , > > >>> +it takes effect > > >>> +.I after > > >>> +this deferred change. > > >> > > >> I find this a bit hard to follow, since it's not clear to me whether the > > >> INHERIT flag is effectively set before or after the next execve(). In other > > >> words, if both PR_SVE_SET_VL_ONEXEC and PR_SVE_VL_INHERIT are specified, > > >> is the vector length preserved or reset on the next execve()? > > > > > > It makes no difference, because the ONEXEC handling takes priority over > > > the INHERIT handling. But either way INHERIT is never cleared by execve() > > > and will apply at subsequent execs(). > > > > > > Explaining all this properly seems out of scope here. Maybe this should > > > be trimmed down rather than elaborated? Or perhaps just explain it in > > > terms of what the kernel does instead of futile attempts to make it > > > intuitive? Hmm, if we don't explain it in the man page then we should at least point people to somewhere where they can get the gory details, because I think they're necessary in order to use the prctl() request correctly. I'm still not confident that I understand the semantics of setting both PR_SVE_SET_VL_ONEXEC and PR_SVE_VL_INHERIT without reading the code, which may change. (I concede on all the spelling/grammar discussions ;) Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel