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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8885EB64DC for ; Mon, 10 Jul 2023 23:13:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60C848E0001; Mon, 10 Jul 2023 19:13:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BC4A8D0001; Mon, 10 Jul 2023 19:13:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AB408E0001; Mon, 10 Jul 2023 19:13:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 387D58D0001 for ; Mon, 10 Jul 2023 19:13:47 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 04E1E1C804F for ; Mon, 10 Jul 2023 23:13:46 +0000 (UTC) X-FDA: 80997256494.30.D00928D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf02.hostedemail.com (Postfix) with ESMTP id 4DC008000A for ; Mon, 10 Jul 2023 23:13:45 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=O0dtsCUq; spf=pass (imf02.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689030825; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=X1FPedXWst/FcrGrjev49MQRUBUchZbG+BwSAR3DBJE=; b=WU0iQ4Y9WXOd21zP8IT57m2hOdQ62pt+N4E9oEzy7GByPD1ZfWyjlMBp/ALbIICMncUIZe v0Tm+IqvTneKnhAGo66vTwe7Nip72z0Xlo4HUiv+vme7Bs1HcamfdJN0Nu+RvYNKrGX2Qm n8zP5tN62RO28dKsX8A3UBmOD3YxYJM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689030825; a=rsa-sha256; cv=none; b=yGqcdeaPnSExsOXuoFsxQj4XXX0ITWbU4NEQyzmgm+gI0AK9ztnHzTxuR2Hl1SVs7akAAR D9jDfCIKPSHFEDpx7qLEQd5XMSDlOJ/tWsxXRRI/VWvU4Z9dUVu825tiQ8MoQkqdcR0pGO g86Eeo1VZ5Fzg8CzuJ1oFoElQXytAsY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=O0dtsCUq; spf=pass (imf02.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6674B6125B; Mon, 10 Jul 2023 23:13:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A48FAC433C7; Mon, 10 Jul 2023 23:13:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1689030823; bh=fHPnsvbmHoDax2JcKJLoPjo5k2CknkN7L6jw/9rSA4w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=O0dtsCUqqxh2E48pOsfcrz2eZeXmdjOp00Zk6jVReJI5GrDZqLL7FjY7BrEshu/p5 slD/g3Fa5uEiXtcnwB5ZlNreYjQhnGvzG/CqvGSc0lZYOHtsjbY9pElz4CGWNHdo/Z rAW9MKjVNY1aI+QBeJq05SUOTjzWNkFPmIQS21pE= Date: Mon, 10 Jul 2023 16:13:41 -0700 From: Andrew Morton To: "Matthew Wilcox (Oracle)" 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 Message-Id: <20230710161341.c8d6a8b2cbf57013bf6e0140@linux-foundation.org> In-Reply-To: <20230710204339.3554919-2-willy@infradead.org> References: <20230710204339.3554919-1-willy@infradead.org> <20230710204339.3554919-2-willy@infradead.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: g1k17izxmmr7it9xxngp6wfazu766oo3 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 4DC008000A X-Rspam-User: X-HE-Tag: 1689030825-13384 X-HE-Meta: U2FsdGVkX1+JGYURss0bsQLeWiVu2yy7SH4IKbNHTriwp7nXhr1FcXOpfYREO4DWGfbiG4Z5Vgdm2vG7jILF2C27uElg4uRijp6F5/ddm5BO3khjJewZjWqrf8lBER2qbVqtdUPzA00oVUiAb7IDVEhBMszG2CdgAXPOjlCrc2hA3T2I0XHDRyLA+t4BSnDLvy+KfuRHE0UcsFOJyRqjjgC5jxx8x5oDgc7Muv7mZWOFA3W2i7V/fGmt0OHRi2OlmSl8yzlUHLJm2X59okNdMOYkUuPOe8yrrSN9tSoqlIvi+NuKGoDoSt+QygmECzZhrIsysPoybTXQKUldCQVH2Oy4gSDYkN8FM2v99VejbwyceV7yK4dqGbT3hDxSnXwiKhz2b2Q29I0SYkg3PBosG64noLLzfWCadHypuHgL3Y/fKu3j8c1gc2Vq5v4avZ6S30vG0Ur22Q39FuIgKQS1pumah1PsX1sFoXSK9Uk2vYQZnGZrrd610GjUQ0oe5pef3JtN48qminDUQbozUy70mWtvyDqLDRleZLxkh6YvwgCZtmAOZcxj98NTcJScVCYmYrFEXYkjHkhHd8A+fKCId/p5TsACzi25oFW/4/z2KIHOzA22gunODNHP2/EqdgL7tJurHBnT/WCXII7ICttOOdqtLlfnVSjx5BqSXUJeOHzZ57J6pQ09Yhl0mfrxGikPp58IcWNfgML2ZPJxPuuP6EIb/8AfUn8K7V3gOOHYdJaro9qJwPPfCPoM1IME/bnXGLjtxDnqJ9o+wPfD8e/20MPXWhI7vDwl/OkXU+X9EoX6Ns5yrHtwJGXU3yL//DiNBBa6rcXuLYrLokSHir0iSgGkR5B0IV0NvoSvuiOWd3Aut6i4cxFUT36Yfcoqof1a65gVNOdy3XvyPqHrVJx+5QTgpcNuDq8Qa1oJ+SPcO3wTz3MYJkrx4Chhy0///wf41e4Yy+g5x302GhO21po anQoEgDj bK7aqy0K41grlux7ZKMz9dCYkilwfmWSENv7eyQTAo6u9+odQ/bSJ9mie/RGxakPTZb5P9i/i4TpH5tluNS6HbI6BwVsMkQUnCijq0Qh4Gw21sXuoXSP2Hn8id0lqFT6+AZcQaBGSf+/D2SFuLz9rREH9AHMixePRqkX5ycQlXfl6SKdKD7gMRQ95h7oRXXweLts9cEFXWQbfPFES28O3KlL6GtaFz8El83BsIpwTUR1NfB9O3DRsnKpkw8UeyDmm1mQ77/kLrgcwmtv1EKwKMwYQ8KuxfwK9wmBqgnIHzK2cUNWiV3DgZpYmHhypgde644KifIFyVQ4/S4Kb6LfOEctfcKV/jNcBAcDGVKi0uQJtPRZ/ycmRV8PjfxCV5yr8ejGmJQ/KMExRACYzmrCKEne1tbDxE3wuEHu0tV771c1l1KzIHjmVa5HM9A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 10 Jul 2023 21:43:02 +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. > > Signed-off-by: Matthew Wilcox (Oracle) > --- 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?