Message ID | 20230710204339.3554919-2-willy@infradead.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a6b2:0:b0:3e4:2afc:c1 with SMTP id c18csp65921vqm; Mon, 10 Jul 2023 13:53:36 -0700 (PDT) X-Google-Smtp-Source: APBJJlE8YDzuf3L166KMLtL6IaVsYKUGxFovJrJSql1awpbXSW1RH6R+ehEOb5L35vuOjHlGGodv X-Received: by 2002:a2e:80d6:0:b0:2b6:c790:150a with SMTP id r22-20020a2e80d6000000b002b6c790150amr12144888ljg.22.1689022415941; Mon, 10 Jul 2023 13:53:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689022415; cv=none; d=google.com; s=arc-20160816; b=K3H/ei1lldBvZGzY7Zn3k+5B2JRPU8lw1PeWpAh6cE2U6AmQn0FvMnfqZIMaMVb65T lPprvw6tVmeJyW1sTsn2mrWiEUEZ1VoW0gNRWkxOwh8VIwoNhH2I083MIJoTmo5Z76bo Z6Lxj80+TJCXePUeubpQ+5/Pe6gxkgFYt4oJqukA/Qk8LmkS3j5oa/eZqUQbKIS7QXgQ jkGrKSdJzFLAlaMk8xyQA80jvIJngyy+KdTMi+WQydQXmgnirVA8Ix7q8rou+E20BjXm E301qpzfscqcwFIMyhPEko586i22+iqP4PKeZmdhk8M64+VpXarV0g7NEnlp2bDTCoVI RXog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=A7RcetqmNW3btMImHl/BZfdcqRl9coUa9L9XZZv1508=; fh=XtKYrrV24qpJDEOQ96O/Lmd5LL6GP9mEWUOmxLG8cXI=; b=HDmxJnh2nxB4VrSFpPKVcu5oIWd/m6EMoMCvxjgeRjORnRofsO2aeKEi/AgHHyHsDY mABldx3Zqqo5uicsPrZaBnZoeo8gg05iYvcrQ9H8UcKPfyF2qv6JvtONm6oy27eSYKB5 zxUaV9ElHX6caisvgeuYhkDjs5AXsExiw5p6UiC62jqh97BO+5ejjO9Jl0ols5Kok7qS X5Z6zj5XBXT8/PjzM1YqcOwMVMEC1T66/JPZ1UGEWyWgl7HxYUIFPNjpocxY/tdFBeDc SZ7a1dIaaU9lSZpNo/iCiIIEV4s/ohAjOizwmMkjSnI7IJuWm7rpMnEc7n4Vc5Hz1OBC 1GFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=WgSSkXyo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p9-20020a170906140900b00993689daad1si441564ejc.116.2023.07.10.13.53.11; Mon, 10 Jul 2023 13:53:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=WgSSkXyo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233043AbjGJUqd (ORCPT <rfc822;gnulinuxfreebsd@gmail.com> + 99 others); Mon, 10 Jul 2023 16:46:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231656AbjGJUpA (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 10 Jul 2023 16:45:00 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C5A31BF; Mon, 10 Jul 2023 13:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Type:Content-ID:Content-Description; bh=A7RcetqmNW3btMImHl/BZfdcqRl9coUa9L9XZZv1508=; b=WgSSkXyo6wHIO77DHamsAtL5yS QPw+3CNlMjYUWUL/cmn1npceGfaf+29pfTh1AWihDxltm3qKIFPVy5zVYjvclsnFpXKYetM/YBD+t pDQiNiNl9LpEoGB8KmBRwWmkDxMJDuHj5GlmENIK0nNp8MTh/wrwhCI2z1kpRHwF5n0P8/2o0TOIw lnX0H/DLnXPWpzmVouo1J7c0g3n5+cegiGdOuSGV97zLi9NShKpz20OELw2TBUrUBocDgTJYn7oY0 d4t9+1dGZsxpyK/6oTDLRRXJ10U4eXy3U5L8PQIq7FLntXSPG6i3HPw2LOBx3gqBtNDv1YMvvQTgb wQnxk6dA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qIxjR-00EuoE-3L; Mon, 10 Jul 2023 20:43:41 +0000 From: "Matthew Wilcox (Oracle)" <willy@infradead.org> To: Andrew Morton <akpm@linux-foundation.org> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v5 01/38] minmax: Add in_range() macro Date: Mon, 10 Jul 2023 21:43:02 +0100 Message-Id: <20230710204339.3554919-2-willy@infradead.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20230710204339.3554919-1-willy@infradead.org> References: <20230710204339.3554919-1-willy@infradead.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771068369084429364 X-GMAIL-MSGID: 1771068369084429364 |
Series |
New page table range API
|
|
Commit Message
Matthew Wilcox
July 10, 2023, 8:43 p.m. UTC
Determine if a value lies within a range more efficiently (subtraction +
comparison vs two comparisons and an AND). It also has useful (under
some circumstances) behaviour if the range exceeds the maximum value of
the type.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
include/linux/minmax.h | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
Comments
On Mon, 10 Jul 2023 21:43:02 +0100 "Matthew Wilcox (Oracle)" <willy@infradead.org> wrote: > Determine if a value lies within a range more efficiently (subtraction + > comparison vs two comparisons and an AND). It also has useful (under > some circumstances) behaviour if the range exceeds the maximum value of > the type. > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> > --- a/include/linux/minmax.h > +++ b/include/linux/minmax.h > @@ -158,6 +158,32 @@ > */ > #define clamp_val(val, lo, hi) clamp_t(typeof(val), val, lo, hi) > > +static inline bool in_range64(u64 val, u64 start, u64 len) > +{ > + return (val - start) < len; > +} > + > +static inline bool in_range32(u32 val, u32 start, u32 len) > +{ > + return (val - start) < len; > +} > + > +/** > + * in_range - Determine if a value lies within a range. > + * @val: Value to test. > + * @start: First value in range. > + * @len: Number of values in range. > + * > + * This is more efficient than "if (start <= val && val < (start + len))". > + * It also gives a different answer if @start + @len overflows the size of > + * the type by a sufficient amount to encompass @val. Decide for yourself > + * which behaviour you want, or prove that start + len never overflow. > + * Do not blindly replace one form with the other. > + */ > +#define in_range(val, start, len) \ > + sizeof(start) <= sizeof(u32) ? in_range32(val, start, len) : \ > + in_range64(val, start, len) There's nothing here to prevent callers from passing a mixture of 32-bit and 64-bit values, possibly resulting in truncation of `val' or `len'. Obviously caller is being dumb, but I think it's cost-free to check all three of the arguments for 64-bitness? Or do a min()/max()-style check for consistently typed arguments?
On Mon, Jul 10, 2023 at 04:13:41PM -0700, Andrew Morton wrote: > > +/** > > + * in_range - Determine if a value lies within a range. > > + * @val: Value to test. > > + * @start: First value in range. > > + * @len: Number of values in range. > > + * > > + * This is more efficient than "if (start <= val && val < (start + len))". > > + * It also gives a different answer if @start + @len overflows the size of > > + * the type by a sufficient amount to encompass @val. Decide for yourself > > + * which behaviour you want, or prove that start + len never overflow. > > + * Do not blindly replace one form with the other. > > + */ > > +#define in_range(val, start, len) \ > > + sizeof(start) <= sizeof(u32) ? in_range32(val, start, len) : \ > > + in_range64(val, start, len) > > There's nothing here to prevent callers from passing a mixture of > 32-bit and 64-bit values, possibly resulting in truncation of `val' or > `len'. > > Obviously caller is being dumb, but I think it's cost-free to check all > three of the arguments for 64-bitness? > > Or do a min()/max()-style check for consistently typed arguments? How about #define in_range(val, start, len) \ (sizeof(val) | sizeof(start) | size(len)) <= sizeof(u32) ? \ in_range32(val, start, len) : in_range64(val, start, len)
On Mon, Jul 10, 2023 at 09:43:02PM +0100, Matthew Wilcox (Oracle) wrote: > Determine if a value lies within a range more efficiently (subtraction + > comparison vs two comparisons and an AND). It also has useful (under > some circumstances) behaviour if the range exceeds the maximum value of > the type. Should this also drop existing versions of in_range()? E.g. btrfs already has its own.
On Tue, 11 Jul 2023 03:14:44 +0100 Matthew Wilcox <willy@infradead.org> wrote: > On Mon, Jul 10, 2023 at 04:13:41PM -0700, Andrew Morton wrote: > > > +/** > > > + * in_range - Determine if a value lies within a range. > > > + * @val: Value to test. > > > + * @start: First value in range. > > > + * @len: Number of values in range. > > > + * > > > + * This is more efficient than "if (start <= val && val < (start + len))". > > > + * It also gives a different answer if @start + @len overflows the size of > > > + * the type by a sufficient amount to encompass @val. Decide for yourself > > > + * which behaviour you want, or prove that start + len never overflow. > > > + * Do not blindly replace one form with the other. > > > + */ > > > +#define in_range(val, start, len) \ > > > + sizeof(start) <= sizeof(u32) ? in_range32(val, start, len) : \ > > > + in_range64(val, start, len) > > > > There's nothing here to prevent callers from passing a mixture of > > 32-bit and 64-bit values, possibly resulting in truncation of `val' or > > `len'. > > > > Obviously caller is being dumb, but I think it's cost-free to check all > > three of the arguments for 64-bitness? > > > > Or do a min()/max()-style check for consistently typed arguments? > > How about > > #define in_range(val, start, len) \ > (sizeof(val) | sizeof(start) | size(len)) <= sizeof(u32) ? \ > in_range32(val, start, len) : in_range64(val, start, len) It saves some typing ;) sizeof(val+start+len)? <no>
On 10/07/2023 21:43, Matthew Wilcox (Oracle) wrote: > Determine if a value lies within a range more efficiently (subtraction + > comparison vs two comparisons and an AND). It also has useful (under > some circumstances) behaviour if the range exceeds the maximum value of > the type. Sorry it's taken me a while to looking at this. I'm getting a lot of warnings about in_range() being redefined when building arm64 (defconfig-ish) with this patch set on top of v6.5-rc2. Looks like there are multiple existing implementations. Thanks, Ryan
From: Andrew Morton > Sent: 11 July 2023 00:14 > To: Matthew Wilcox (Oracle) <willy@infradead.org> > Cc: linux-arch@vger.kernel.org; linux-mm@kvack.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v5 01/38] minmax: Add in_range() macro > > On Mon, 10 Jul 2023 21:43:02 +0100 "Matthew Wilcox (Oracle)" <willy@infradead.org> wrote: > > > Determine if a value lies within a range more efficiently (subtraction + > > comparison vs two comparisons and an AND). It also has useful (under > > some circumstances) behaviour if the range exceeds the maximum value of > > the type. > > > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> > > --- a/include/linux/minmax.h > > +++ b/include/linux/minmax.h > > @@ -158,6 +158,32 @@ > > */ > > #define clamp_val(val, lo, hi) clamp_t(typeof(val), val, lo, hi) > > > > +static inline bool in_range64(u64 val, u64 start, u64 len) > > +{ > > + return (val - start) < len; > > +} > > + > > +static inline bool in_range32(u32 val, u32 start, u32 len) > > +{ > > + return (val - start) < len; > > +} > > + > > +/** > > + * in_range - Determine if a value lies within a range. > > + * @val: Value to test. > > + * @start: First value in range. > > + * @len: Number of values in range. > > + * > > + * This is more efficient than "if (start <= val && val < (start + len))". > > + * It also gives a different answer if @start + @len overflows the size of > > + * the type by a sufficient amount to encompass @val. Decide for yourself > > + * which behaviour you want, or prove that start + len never overflow. > > + * Do not blindly replace one form with the other. > > + */ > > +#define in_range(val, start, len) \ > > + sizeof(start) <= sizeof(u32) ? in_range32(val, start, len) : \ > > + in_range64(val, start, len) > > There's nothing here to prevent callers from passing a mixture of > 32-bit and 64-bit values, possibly resulting in truncation of `val' or > `len'. > > Obviously caller is being dumb, but I think it's cost-free to check all > three of the arguments for 64-bitness? > > Or do a min()/max()-style check for consistently typed arguments? Just use integer promotions to extend everything to 'unsigned long long'. #define in_range(val, start, len) ((val) + 0ull - (start)) < (len)) If all the values are unsigned 32bit the compiler will discard all the zero extensions. If values might be signed types (with non-negative values) you might want to do explicit ((xxx) + 0u + 0ul + 0ull) to avoid any potentially expensive sign extensions. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
diff --git a/include/linux/minmax.h b/include/linux/minmax.h index 396df1121bff..028069a1f7ef 100644 --- a/include/linux/minmax.h +++ b/include/linux/minmax.h @@ -158,6 +158,32 @@ */ #define clamp_val(val, lo, hi) clamp_t(typeof(val), val, lo, hi) +static inline bool in_range64(u64 val, u64 start, u64 len) +{ + return (val - start) < len; +} + +static inline bool in_range32(u32 val, u32 start, u32 len) +{ + return (val - start) < len; +} + +/** + * in_range - Determine if a value lies within a range. + * @val: Value to test. + * @start: First value in range. + * @len: Number of values in range. + * + * This is more efficient than "if (start <= val && val < (start + len))". + * It also gives a different answer if @start + @len overflows the size of + * the type by a sufficient amount to encompass @val. Decide for yourself + * which behaviour you want, or prove that start + len never overflow. + * Do not blindly replace one form with the other. + */ +#define in_range(val, start, len) \ + sizeof(start) <= sizeof(u32) ? in_range32(val, start, len) : \ + in_range64(val, start, len) + /** * swap - swap values of @a and @b * @a: first value