Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Mon, 2 Oct 2023 11:30:42 -0400
From:   Gregory Price <gregory.price@memverge.com>
To:     Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc:     Gregory Price <gourry.memverge@gmail.com>,
        linux-mm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arch@vger.kernel.org, linux-api@vger.kernel.org,
        linux-cxl@vger.kernel.org, luto@kernel.org, tglx@linutronix.de,
        mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
        hpa@zytor.com, arnd@arndb.de, akpm@linux-foundation.org,
        x86@kernel.org
Subject: Re: [RFC PATCH 2/3] mm/mempolicy: Implement set_mempolicy2 and
 get_mempolicy2 syscalls
Message-ID: <ZRriIpYETsRdWZet@memverge.com>
References: <20230914235457.482710-1-gregory.price@memverge.com>
 <20230914235457.482710-3-gregory.price@memverge.com>
 <20231002143008.000038ac@Huawei.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231002143008.000038ac@Huawei.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?w9k70vMeDI6pRh0gtk8C4d9eW5IFcwXJYW65r+XfUpBpPxoU7z9YIXVa3kiL?=
 =?us-ascii?Q?vPYnVjHS/4aD1SdR88Ifd2T3zmdhJ6cIB+Snzv1Eig5nQoDV6kNrqrHpZMNf?=
 =?us-ascii?Q?gaAfnu2FRfd4N80sNPgoQ+SVr2zl0VEcyAg1LSUjvMiRO+sDAKGaJ2+4Vx9Y?=
 =?us-ascii?Q?r0KHWZIDYJT8xtOcoFMGNvjK+0EKlLbOtb9PuEDhB2P8ix5LsElph1o+yiVX?=
 =?us-ascii?Q?7fIVpbMotf1dPTbcdSzER1Xijj3rC9ZbVWRlepQAfr9EOCfNXj6mX9Qc4RVd?=
 =?us-ascii?Q?lOWVN7qyYyr1wVmXqbdg4QEv9jYCU16HtH81Flc98lvoU2Wjf6zKXLNSY/oA?=
 =?us-ascii?Q?zcX/5bdRuG5XE9JFcLPwvLozNnFe8FuonwCE0CylHBKtd2vXW/upJxJyDnwU?=
 =?us-ascii?Q?b49/h9bdul9nrkU1vUfNz8gMoTG+eWmRN3BrY47DIT5ipCpuj4QuB34BTqDH?=
 =?us-ascii?Q?AYPsp2SmCzwq7L+o9STKCpMgjUlJdvsr4gyZYgeNLzZIGORuA3t+xVPlCBA1?=
 =?us-ascii?Q?2ka/BJVlWpd6nDDCJkVq7rEDkq5deu6Ac54CzIY3W4Z4tnrxyplm0X7ImiXl?=
 =?us-ascii?Q?Fs0uQVNsFconRHBuG3Zr/hSR7vPzyqpF8xWVy4WFv/MbylsPxUU0gxnBQ++F?=
 =?us-ascii?Q?/PpOZUJlA/PUrpbpGFIRogfAvO+8SKJ2PnSacD37c9BQn7aHhMqcSuaGfRis?=
 =?us-ascii?Q?sK1MkcvvbiM7lMov9b3KA8nLqAIPS1betllNsbmPixgJLZZ4ldLXlbDMQmh0?=
 =?us-ascii?Q?DdHEVzjHiU7x/YGVni8ilvdd0tzzX1Xn+wDkNWdOOlfGqwFdmGF2f9Pculym?=
 =?us-ascii?Q?9fo0mRmr1M0YXo8oGl7Ds6wbOdltT3xQ5gY6rflHxONCbKmIxvA69A88L2JU?=
 =?us-ascii?Q?Dk17cBTbNh5V78hYG8xBDh80I9s/bLx/Lk+qcfnurJXDgMsVqkqDMseYWq9g?=
 =?us-ascii?Q?hZhWSzwKXlyEiC+uuTc2KaGSjo7PHGD3J+8sSS9JXC/rY5ubL4ecXWdqfomr?=
 =?us-ascii?Q?JEHxGlQHRfK4mi0HxFZV1B/525P8pb03px1PQGWpwFlooPT8+mCryKs6amrl?=
 =?us-ascii?Q?gXd6IqJtxsiaLdRb1VeUes6bztVyPwV819e02WIpjAA4aAdPO0jNFvf9wB23?=
 =?us-ascii?Q?DWgUmshcJdZ652BGz/iRUWWJj4NIvl56ajA9IP4yPDyUlzW9hFLMQUEAeyac?=
 =?us-ascii?Q?MrYi1zFaI/5zy+Lwl/iKgpNVyk4yl6CzVg3Rcv9s8lxsJq2ZWh2v5Hc3iAb2?=
 =?us-ascii?Q?6AhUQhPy8Pe4x/hvyK7GC3b60vlhh+Acyz8sLQ+5V0zR4WmoXi4NIyyXfXxu?=
 =?us-ascii?Q?AmGte7hNj1g37o2LLYQljXhsj/B3GIKkvWy2XNcF8piWe1ESb4yds5YUH5Ng?=
 =?us-ascii?Q?vEDaIPJRuU0kx5I0JTytHBhD1EL4Yd9fHCGiyxecscVKiPMKEIsqJ5F62dGQ?=
 =?us-ascii?Q?MzDEmdIW1+lVZUyOM8Oy3oxNFxObS8ylEdSR1zVgSElni08ME6IDjFi/uJMy?=
 =?us-ascii?Q?8mrhR2X0p8RyEEYrmr+uuNA2h6d0HmLbRJr9xko3D0zlA8OaBrSLqCzdUcmV?=
 =?us-ascii?Q?LVYO3hc3ZoLQJdmHYQcK9U+MQFYX+YDy0NBASrUOFtzGUmvUgBupFTMAV1Fv?=
 =?us-ascii?Q?NQ=3D=3D?=
X-OriginatorOrg: memverge.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cc26fb84-4cf9-48e3-786a-08dbc35c8f26
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR17MB5512.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Oct 2023 15:30:51.1241
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5c90cb59-37e7-4c81-9c07-00473d5fb682
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: y3/A5cqQHETY8ZOIKkVI2+yXikaANhQqdMpH2kOrqIeWGidyOtzYMjIDMP9hPBQazy6KQyWA+Ihcg0kVxj4SxWv1c1Jkg4Ts53xDblyDD5s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3755
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Mon, 02 Oct 2023 08:31:20 -0700 (PDT)

On Mon, Oct 02, 2023 at 02:30:08PM +0100, Jonathan Cameron wrote:
> On Thu, 14 Sep 2023 19:54:56 -0400
> Gregory Price <gourry.memverge@gmail.com> wrote:
> 
> > diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
> > index abe087c53b4b..397dcf804941 100644
> > --- a/include/uapi/asm-generic/unistd.h
> > +++ b/include/uapi/asm-generic/unistd.h
> > ...
> >  #undef __NR_syscalls
> > -#define __NR_syscalls 453
> > +#define __NR_syscalls 456
> +3 for 2 additions?
> 

When i'd originally written this, there was a partially merged syscall
colliding with 453, and this hadn't been incremented yet.  Did a quick
grep and it seems like that might have been reverted, so yeah this would
drop down to 453/454 & __NR=455.

> > +	/* Legacy modes are routed through the legacy interface */
> > +	if (kargs->mode <= MPOL_LEGACY)
> > +		return false;
> > +
> > +	if (kargs->mode >= MPOL_MAX)
> > +		return false;
> > +
> > +	return true;
> 
> This is a range check, so I think equally clear (and shorter) as..
> 	/* Legacy modes are routed through the legacy interface */
> 	return kargs->mode > MPOL_LEGACY && kargs->mode < MPOL_MAX;
>

I'll combine the range, but i left the two true/false conditions
separate because it's intended that follow on patches will add logic
before true is returned.

> > +		kargs->get.allowed.err = err ? err : 0;
> > +		kargs->err |= err ? err : 1;
> 		if (err) {
> 			kargs->get.allowed.err = err;
> 			kargs->err |= err;
> 		} else {
> 			kargs->get.allowed.err = 0;
> 			kargs->err = 1;
> 	Not particularly obvious why 1 and if you get an error later it's going to be messy
>         as will 1 |= err_code

My original intent was to just allow each section to error separately,
but honestly this seems overly complicated and somewhat against the
design of almost every other syscall, so i'm going to rip all these
error code spaces out and instead just have everything return on error.

Thanks!
Gregory