From: <gregkh@linuxfoundation.org>
To: 20230206140639.538867-5-fengwei.yin@intel.com,
David.Laight@ACULAB.COM, Jason@zx2c4.com,
adilger.kernel@dilger.ca, agk@redhat.com, airlied@linux.ie,
akpm@linux-foundation.org, alexander.deucher@amd.com,
alexandre.torgue@st.com, amd-gfx@lists.freedesktop.org,
andriy.shevchenko@linux.intel.com,
anton.ivanov@cambridgegreys.com, artur.paszkiewicz@intel.com,
bp@alien8.de, brian.starkey@arm.com, bvanassche@acm.org,
chao@kernel.org, christian.koenig@amd.com, clm@fb.com,
coreteam@netfilter.org, daniel@ffwll.ch,
dave.hansen@linux.intel.com, davem@davemloft.net,
dm-devel@redhat.com, dmitry.torokhov@gmail.com,
dri-devel@lists.freedesktop.org, dsterba@suse.com,
dushistov@mail.ru, evan.quan@amd.com, farbere@amazon.com,
fery@cypress.com, freedreno@lists.freedesktop.org, fw@strlen.de,
gregkh@linuxfoundation.org, harry.wentland@amd.com,
hdegoede@redhat.com, herve.codina@bootlin.com, hpa@zytor.com,
intel-linux-scu@intel.com, jack@suse.com, james.morse@arm.com,
james.qian.wang@arm.com, jdelvare@suse.com, jdike@addtoit.com,
jejb@linux.ibm.co, m@kvack.org, jmaloy@redhat.com,
joabreu@synopsys.com, josef@toxicpanda.com, kadlec@netfilter.org,
kbusch@kernel.org, keescook@chromium.org, kuba@kernel.org,
kuznet@ms2.inr.ac.ru, linux-arm-kernel@lists.infradead.org,
linux-erofs@lists.ozlabs.org, linux-mm@kvack.org,
linux-staging@lists.linux.dev,
linux-stm32@st-md-mailman.stormreply.com,
linux-um@lists.infradead.org, linux@armlinux.org.uk,
linux@rasmusvillemoes.dk, linux@roeck-us.net,
liviu.dudau@arm.com, luc.vanoostenryck@gmail.com,
luto@kernel.org, maarten.lankhorst@linux.intel.com,
malattia@linux.it, martin.petersen@oracle.com,
mchehab@kernel.org, mcoquelin.stm32@gmail.com,
mgross@linux.intel.com, mihail.atanassov@arm.com,
minchan@kernel.org, mingo@redhat.com, mripard@kernel.org,
nathan@kernel.org, ndesaulniers@google.com, ngupta@vflare.org,
pablo@netfilter.org, peppe.cavallaro@st.com,
peterz@infradead.org, pmladek@suse.com, qiuxu.zhuo@intel.com,
rajur@chelsio.com, richard@nod.at, robdclark@gmail.com,
rostedt@goodmis.org, rric@kernel.org, ruanjinjie@huawei.com,
sakari.ailus@linux.int, el.com@kvack.org, sashal@kernel.org,
sean@poorly.run, sergey.senozhatsky@gmail.com,
snitzer@redhat.com, sunpeng.li@amd.com, tglx@linutronix.de,
tipc-discussion@lists.sourceforge.net, tony.luck@intel.com,
tytso@mit.edu, tzimmermann@suse.de, willy@infradead.org,
x86@kernel.org, xiang@kernel.org, ying.xue@windriver.com,
yoshfuji@linux-ipv6.org
Cc: <stable-commits@vger.kernel.org>
Subject: Patch "minmax: add in_range() macro" has been added to the 5.10-stable tree
Date: Fri, 17 Oct 2025 15:48:28 +0200 [thread overview]
Message-ID: <2025101727-agile-tinwork-5c96@gregkh> (raw)
In-Reply-To: <20251017090519.46992-6-farbere@amazon.com>
This is a note to let you know that I've just added the patch titled
minmax: add in_range() macro
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
minmax-add-in_range-macro.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From prvs=378230090=farbere@amazon.com Fri Oct 17 11:07:27 2025
From: Eliav Farber <farbere@amazon.com>
Date: Fri, 17 Oct 2025 09:04:57 +0000
Subject: minmax: add in_range() macro
To: <gregkh@linuxfoundation.org>, <stable@vger.kernel.org>, <linux@armlinux.org.uk>, <jdike@addtoit.com>, <richard@nod.at>, <anton.ivanov@cambridgegreys.com>, <dave.hansen@linux.intel.com>, <luto@kernel.org>, <peterz@infradead.org>, <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>, <x86@kernel.org>, <hpa@zytor.com>, <tony.luck@intel.com>, <qiuxu.zhuo@intel.com>, <mchehab@kernel.org>, <james.morse@arm.com>, <rric@kernel.org>, <harry.wentland@amd.com>, <sunpeng.li@amd.com>, <alexander.deucher@amd.com>, <christian.koenig@amd.com>, <airlied@linux.ie>, <daniel@ffwll.ch>, <evan.quan@amd.com>, <james.qian.wang@arm.com>, <liviu.dudau@arm.com>, <mihail.atanassov@arm.com>, <brian.starkey@arm.com>, <maarten.lankhorst@linux.intel.com>, <mripard@kernel.org>, <tzimmermann@suse.de>, <robdclark@gmail.com>, <sean@poorly.run>, <jdelvare@suse.com>, <linux@roeck-us.net>, <fery@cypress.com>, <dmitry.torokhov@gmail.com>, <agk@redhat.com>, <snitzer@redhat.com>, <dm-devel@redhat.com>, <rajur
@chelsio
.com>, <davem@davemloft.net>, <kuba@kernel.org>, <peppe.cavallaro@st.com>, <alexandre.torgue@st.com>, <joabreu@synopsys.com>, <mcoquelin.stm32@gmail.com>, <malattia@linux.it>, <hdegoede@redhat.com>, <mgross@linux.intel.com>, <intel-linux-scu@intel.com>, <artur.paszkiewicz@intel.com>, <jejb@linux.ibm.com>, <martin.petersen@oracle.com>, <sakari.ailus@linux.intel.com>, <clm@fb.com>, <josef@toxicpanda.com>, <dsterba@suse.com>, <xiang@kernel.org>, <chao@kernel.org>, <jack@suse.com>, <tytso@mit.edu>, <adilger.kernel@dilger.ca>, <dushistov@mail.ru>, <luc.vanoostenryck@gmail.com>, <rostedt@goodmis.org>, <pmladek@suse.com>, <sergey.senozhatsky@gmail.com>, <andriy.shevchenko@linux.intel.com>, <linux@rasmusvillemoes.dk>, <minchan@kernel.org>, <ngupta@vflare.org>, <akpm@linux-foundation.org>, <kuznet@ms2.inr.ac.ru>, <yoshfuji@linux-ipv6.org>, <pablo@netfilter.org>, <kadlec@netfilter.org>, <fw@strlen.de>, <jmaloy@redhat.com>, <ying.xue@windriver.com>, <willy@infradead.org>, <farbere@amaz
on.com>,
<sashal@kernel.org>, <ruanjinjie@huawei.com>, <David.Laight@ACULAB.COM>, <herve.codina@bootlin.com>, <Jason@zx2c4.com>, <keescook@chromium.org>, <kbusch@kernel.org>, <nathan@kernel.org>, <bvanassche@acm.org>, <ndesaulniers@google.com>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linux-um@lists.infradead.org>, <linux-edac@vger.kernel.org>, <amd-gfx@lists.freedesktop.org>, <dri-devel@lists.freedesktop.org>, <linux-arm-msm@vger.kernel.org>, <freedreno@lists.freedesktop.org>, <linux-hwmon@vger.kernel.org>, <linux-input@vger.kernel.org>, <linux-media@vger.kernel.org>, <netdev@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com>, <platform-driver-x86@vger.kernel.org>, <linux-scsi@vger.kernel.org>, <linux-staging@lists.linux.dev>, <linux-btrfs@vger.kernel.org>, <linux-erofs@lists.ozlabs.org>, <linux-ext4@vger.kernel.org>, <linux-sparse@vger.kernel.org>, <linux-mm@kvack.org>, <netfilter-devel@vger.kernel.org>, <coreteam@netfilter.org>, <tipc-dis
cussion@
lists.sourceforge.net>
Message-ID: <20251017090519.46992-6-farbere@amazon.com>
From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
[ Upstream commit f9bff0e31881d03badf191d3b0005839391f5f2b ]
Patch series "New page table range API", v6.
This patchset changes the API used by the MM to set up page table entries.
The four APIs are:
set_ptes(mm, addr, ptep, pte, nr)
update_mmu_cache_range(vma, addr, ptep, nr)
flush_dcache_folio(folio)
flush_icache_pages(vma, page, nr)
flush_dcache_folio() isn't technically new, but no architecture
implemented it, so I've done that for them. The old APIs remain around
but are mostly implemented by calling the new interfaces.
The new APIs are based around setting up N page table entries at once.
The N entries belong to the same PMD, the same folio and the same VMA, so
ptep++ is a legitimate operation, and locking is taken care of for you.
Some architectures can do a better job of it than just a loop, but I have
hesitated to make too deep a change to architectures I don't understand
well.
One thing I have changed in every architecture is that PG_arch_1 is now a
per-folio bit instead of a per-page bit when used for dcache clean/dirty
tracking. This was something that would have to happen eventually, and it
makes sense to do it now rather than iterate over every page involved in a
cache flush and figure out if it needs to happen.
The point of all this is better performance, and Fengwei Yin has measured
improvement on x86. I suspect you'll see improvement on your architecture
too. Try the new will-it-scale test mentioned here:
https://lore.kernel.org/linux-mm/20230206140639.538867-5-fengwei.yin@intel.com/
You'll need to run it on an XFS filesystem and have
CONFIG_TRANSPARENT_HUGEPAGE set.
This patchset is the basis for much of the anonymous large folio work
being done by Ryan, so it's received quite a lot of testing over the last
few months.
This patch (of 38):
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. Convert all the conflicting definitions of in_range() within the
kernel; some can use the generic definition while others need their own
definition.
Link: https://lkml.kernel.org/r/20230802151406.3735276-1-willy@infradead.org
Link: https://lkml.kernel.org/r/20230802151406.3735276-2-willy@infradead.org
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Eliav Farber <farbere@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mm/pageattr.c | 6 +-
drivers/gpu/drm/arm/display/include/malidp_utils.h | 2
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 24 +++++------
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 --
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 18 ++++----
fs/btrfs/misc.h | 2
fs/ext2/balloc.c | 2
fs/ext4/ext4.h | 2
fs/ufs/util.h | 6 --
include/linux/minmax.h | 27 +++++++++++++
lib/logic_pio.c | 3 -
net/netfilter/nf_nat_core.c | 6 +-
net/tipc/core.h | 2
net/tipc/link.c | 10 ++--
14 files changed, 61 insertions(+), 55 deletions(-)
--- a/arch/arm/mm/pageattr.c
+++ b/arch/arm/mm/pageattr.c
@@ -25,7 +25,7 @@ static int change_page_range(pte_t *ptep
return 0;
}
-static bool in_range(unsigned long start, unsigned long size,
+static bool range_in_range(unsigned long start, unsigned long size,
unsigned long range_start, unsigned long range_end)
{
return start >= range_start && start < range_end &&
@@ -46,8 +46,8 @@ static int change_memory_common(unsigned
if (!size)
return 0;
- if (!in_range(start, size, MODULES_VADDR, MODULES_END) &&
- !in_range(start, size, VMALLOC_START, VMALLOC_END))
+ if (!range_in_range(start, size, MODULES_VADDR, MODULES_END) &&
+ !range_in_range(start, size, VMALLOC_START, VMALLOC_END))
return -EINVAL;
data.set_mask = set_mask;
--- a/drivers/gpu/drm/arm/display/include/malidp_utils.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_utils.h
@@ -35,7 +35,7 @@ static inline void set_range(struct mali
rg->end = end;
}
-static inline bool in_range(struct malidp_range *rg, u32 v)
+static inline bool malidp_in_range(struct malidp_range *rg, u32 v)
{
return (v >= rg->start) && (v <= rg->end);
}
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -305,12 +305,12 @@ komeda_layer_check_cfg(struct komeda_lay
if (komeda_fb_check_src_coords(kfb, src_x, src_y, src_w, src_h))
return -EINVAL;
- if (!in_range(&layer->hsize_in, src_w)) {
+ if (!malidp_in_range(&layer->hsize_in, src_w)) {
DRM_DEBUG_ATOMIC("invalidate src_w %d.\n", src_w);
return -EINVAL;
}
- if (!in_range(&layer->vsize_in, src_h)) {
+ if (!malidp_in_range(&layer->vsize_in, src_h)) {
DRM_DEBUG_ATOMIC("invalidate src_h %d.\n", src_h);
return -EINVAL;
}
@@ -452,14 +452,14 @@ komeda_scaler_check_cfg(struct komeda_sc
hsize_out = dflow->out_w;
vsize_out = dflow->out_h;
- if (!in_range(&scaler->hsize, hsize_in) ||
- !in_range(&scaler->hsize, hsize_out)) {
+ if (!malidp_in_range(&scaler->hsize, hsize_in) ||
+ !malidp_in_range(&scaler->hsize, hsize_out)) {
DRM_DEBUG_ATOMIC("Invalid horizontal sizes");
return -EINVAL;
}
- if (!in_range(&scaler->vsize, vsize_in) ||
- !in_range(&scaler->vsize, vsize_out)) {
+ if (!malidp_in_range(&scaler->vsize, vsize_in) ||
+ !malidp_in_range(&scaler->vsize, vsize_out)) {
DRM_DEBUG_ATOMIC("Invalid vertical sizes");
return -EINVAL;
}
@@ -574,13 +574,13 @@ komeda_splitter_validate(struct komeda_s
return -EINVAL;
}
- if (!in_range(&splitter->hsize, dflow->in_w)) {
+ if (!malidp_in_range(&splitter->hsize, dflow->in_w)) {
DRM_DEBUG_ATOMIC("split in_w:%d is out of the acceptable range.\n",
dflow->in_w);
return -EINVAL;
}
- if (!in_range(&splitter->vsize, dflow->in_h)) {
+ if (!malidp_in_range(&splitter->vsize, dflow->in_h)) {
DRM_DEBUG_ATOMIC("split in_h: %d exceeds the acceptable range.\n",
dflow->in_h);
return -EINVAL;
@@ -624,13 +624,13 @@ komeda_merger_validate(struct komeda_mer
return -EINVAL;
}
- if (!in_range(&merger->hsize_merged, output->out_w)) {
+ if (!malidp_in_range(&merger->hsize_merged, output->out_w)) {
DRM_DEBUG_ATOMIC("merged_w: %d is out of the accepted range.\n",
output->out_w);
return -EINVAL;
}
- if (!in_range(&merger->vsize_merged, output->out_h)) {
+ if (!malidp_in_range(&merger->vsize_merged, output->out_h)) {
DRM_DEBUG_ATOMIC("merged_h: %d is out of the accepted range.\n",
output->out_h);
return -EINVAL;
@@ -866,8 +866,8 @@ void komeda_complete_data_flow_cfg(struc
* input/output range.
*/
if (dflow->en_scaling && scaler)
- dflow->en_split = !in_range(&scaler->hsize, dflow->in_w) ||
- !in_range(&scaler->hsize, dflow->out_w);
+ dflow->en_split = !malidp_in_range(&scaler->hsize, dflow->in_w) ||
+ !malidp_in_range(&scaler->hsize, dflow->out_w);
}
static bool merger_is_available(struct komeda_pipeline *pipe,
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -657,12 +657,6 @@ struct block_header {
u32 data[];
};
-/* this should be a general kernel helper */
-static int in_range(u32 addr, u32 start, u32 size)
-{
- return addr >= start && addr < start + size;
-}
-
static bool fw_block_mem(struct a6xx_gmu_bo *bo, const struct block_header *blk)
{
if (!in_range(blk->addr, bo->iova, bo->size))
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -2131,7 +2131,7 @@ static const struct ethtool_ops cxgb_eth
.set_link_ksettings = set_link_ksettings,
};
-static int in_range(int val, int lo, int hi)
+static int cxgb_in_range(int val, int lo, int hi)
{
return val < 0 || (val <= hi && val >= lo);
}
@@ -2162,19 +2162,19 @@ static int cxgb_extension_ioctl(struct n
return -EINVAL;
if (t.qset_idx >= SGE_QSETS)
return -EINVAL;
- if (!in_range(t.intr_lat, 0, M_NEWTIMER) ||
- !in_range(t.cong_thres, 0, 255) ||
- !in_range(t.txq_size[0], MIN_TXQ_ENTRIES,
+ if (!cxgb_in_range(t.intr_lat, 0, M_NEWTIMER) ||
+ !cxgb_in_range(t.cong_thres, 0, 255) ||
+ !cxgb_in_range(t.txq_size[0], MIN_TXQ_ENTRIES,
MAX_TXQ_ENTRIES) ||
- !in_range(t.txq_size[1], MIN_TXQ_ENTRIES,
+ !cxgb_in_range(t.txq_size[1], MIN_TXQ_ENTRIES,
MAX_TXQ_ENTRIES) ||
- !in_range(t.txq_size[2], MIN_CTRL_TXQ_ENTRIES,
+ !cxgb_in_range(t.txq_size[2], MIN_CTRL_TXQ_ENTRIES,
MAX_CTRL_TXQ_ENTRIES) ||
- !in_range(t.fl_size[0], MIN_FL_ENTRIES,
+ !cxgb_in_range(t.fl_size[0], MIN_FL_ENTRIES,
MAX_RX_BUFFERS) ||
- !in_range(t.fl_size[1], MIN_FL_ENTRIES,
+ !cxgb_in_range(t.fl_size[1], MIN_FL_ENTRIES,
MAX_RX_JUMBO_BUFFERS) ||
- !in_range(t.rspq_size, MIN_RSPQ_ENTRIES,
+ !cxgb_in_range(t.rspq_size, MIN_RSPQ_ENTRIES,
MAX_RSPQ_ENTRIES))
return -EINVAL;
--- a/fs/btrfs/misc.h
+++ b/fs/btrfs/misc.h
@@ -8,8 +8,6 @@
#include <asm/div64.h>
#include <linux/rbtree.h>
-#define in_range(b, first, len) ((b) >= (first) && (b) < (first) + (len))
-
static inline void cond_wake_up(struct wait_queue_head *wq)
{
/*
--- a/fs/ext2/balloc.c
+++ b/fs/ext2/balloc.c
@@ -36,8 +36,6 @@
*/
-#define in_range(b, first, len) ((b) >= (first) && (b) <= (first) + (len) - 1)
-
struct ext2_group_desc * ext2_get_group_desc(struct super_block * sb,
unsigned int block_group,
struct buffer_head ** bh)
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -3659,8 +3659,6 @@ static inline void set_bitmap_uptodate(s
set_bit(BH_BITMAP_UPTODATE, &(bh)->b_state);
}
-#define in_range(b, first, len) ((b) >= (first) && (b) <= (first) + (len) - 1)
-
/* For ioend & aio unwritten conversion wait queues */
#define EXT4_WQ_HASH_SZ 37
#define ext4_ioend_wq(v) (&ext4__ioend_wq[((unsigned long)(v)) %\
--- a/fs/ufs/util.h
+++ b/fs/ufs/util.h
@@ -11,12 +11,6 @@
#include <linux/fs.h>
#include "swab.h"
-
-/*
- * some useful macros
- */
-#define in_range(b,first,len) ((b)>=(first)&&(b)<(first)+(len))
-
/*
* functions used for retyping
*/
--- a/include/linux/minmax.h
+++ b/include/linux/minmax.h
@@ -3,6 +3,7 @@
#define _LINUX_MINMAX_H
#include <linux/const.h>
+#include <linux/types.h>
/*
* min()/max()/clamp() macros must accomplish three things:
@@ -175,6 +176,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(len) | sizeof(val)) <= sizeof(u32) ? \
+ in_range32(val, start, len) : in_range64(val, start, len))
+
/**
* swap - swap values of @a and @b
* @a: first value
--- a/lib/logic_pio.c
+++ b/lib/logic_pio.c
@@ -20,9 +20,6 @@
static LIST_HEAD(io_range_list);
static DEFINE_MUTEX(io_range_mutex);
-/* Consider a kernel general helper for this */
-#define in_range(b, first, len) ((b) >= (first) && (b) < (first) + (len))
-
/**
* logic_pio_register_range - register logical PIO range for a host
* @new_range: pointer to the IO range to be registered.
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -262,7 +262,7 @@ static bool l4proto_in_range(const struc
/* If we source map this tuple so reply looks like reply_tuple, will
* that meet the constraints of range.
*/
-static int in_range(const struct nf_conntrack_tuple *tuple,
+static int nf_in_range(const struct nf_conntrack_tuple *tuple,
const struct nf_nat_range2 *range)
{
/* If we are supposed to map IPs, then we must be in the
@@ -311,7 +311,7 @@ find_appropriate_src(struct net *net,
&ct->tuplehash[IP_CT_DIR_REPLY].tuple);
result->dst = tuple->dst;
- if (in_range(result, range))
+ if (nf_in_range(result, range))
return 1;
}
}
@@ -543,7 +543,7 @@ get_unique_tuple(struct nf_conntrack_tup
if (maniptype == NF_NAT_MANIP_SRC &&
!(range->flags & NF_NAT_RANGE_PROTO_RANDOM_ALL)) {
/* try the original tuple first */
- if (in_range(orig_tuple, range)) {
+ if (nf_in_range(orig_tuple, range)) {
if (!nf_nat_used_tuple(orig_tuple, ct)) {
*tuple = *orig_tuple;
return;
--- a/net/tipc/core.h
+++ b/net/tipc/core.h
@@ -199,7 +199,7 @@ static inline int less(u16 left, u16 rig
return less_eq(left, right) && (mod(right) != mod(left));
}
-static inline int in_range(u16 val, u16 min, u16 max)
+static inline int tipc_in_range(u16 val, u16 min, u16 max)
{
return !less(val, min) && !more(val, max);
}
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1588,7 +1588,7 @@ next_gap_ack:
last_ga->bgack_cnt);
}
/* Check against the last Gap ACK block */
- if (in_range(seqno, start, end))
+ if (tipc_in_range(seqno, start, end))
continue;
/* Update/release the packet peer is acking */
bc_has_acked = true;
@@ -2216,12 +2216,12 @@ static int tipc_link_proto_rcv(struct ti
strncpy(if_name, data, TIPC_MAX_IF_NAME);
/* Update own tolerance if peer indicates a non-zero value */
- if (in_range(peers_tol, TIPC_MIN_LINK_TOL, TIPC_MAX_LINK_TOL)) {
+ if (tipc_in_range(peers_tol, TIPC_MIN_LINK_TOL, TIPC_MAX_LINK_TOL)) {
l->tolerance = peers_tol;
l->bc_rcvlink->tolerance = peers_tol;
}
/* Update own priority if peer's priority is higher */
- if (in_range(peers_prio, l->priority + 1, TIPC_MAX_LINK_PRI))
+ if (tipc_in_range(peers_prio, l->priority + 1, TIPC_MAX_LINK_PRI))
l->priority = peers_prio;
/* If peer is going down we want full re-establish cycle */
@@ -2264,13 +2264,13 @@ static int tipc_link_proto_rcv(struct ti
l->rcv_nxt_state = msg_seqno(hdr) + 1;
/* Update own tolerance if peer indicates a non-zero value */
- if (in_range(peers_tol, TIPC_MIN_LINK_TOL, TIPC_MAX_LINK_TOL)) {
+ if (tipc_in_range(peers_tol, TIPC_MIN_LINK_TOL, TIPC_MAX_LINK_TOL)) {
l->tolerance = peers_tol;
l->bc_rcvlink->tolerance = peers_tol;
}
/* Update own prio if peer indicates a different value */
if ((peers_prio != l->priority) &&
- in_range(peers_prio, 1, TIPC_MAX_LINK_PRI)) {
+ tipc_in_range(peers_prio, 1, TIPC_MAX_LINK_PRI)) {
l->priority = peers_prio;
rc = tipc_link_fsm_evt(l, LINK_FAILURE_EVT);
}
Patches currently in stable-queue which might be from farbere@amazon.com are
queue-5.10/minmax-allow-comparisons-of-int-against-unsigned-char-short.patch
queue-5.10/minmax-add-a-few-more-min_t-max_t-users.patch
queue-5.10/minmax-improve-macro-expansion-and-type-checking.patch
queue-5.10/minmax-fix-indentation-of-__cmp_once-and-__clamp_once.patch
queue-5.10/minmax.h-simplify-the-variants-of-clamp.patch
queue-5.10/minmax-add-in_range-macro.patch
queue-5.10/minmax.h-move-all-the-clamp-definitions-after-the-min-max-ones.patch
queue-5.10/minmax-allow-min-max-clamp-if-the-arguments-have-the-same-signedness.patch
queue-5.10/minmax-don-t-use-max-in-situations-that-want-a-c-constant-expression.patch
queue-5.10/minmax.h-remove-some-defines-that-are-only-expanded-once.patch
queue-5.10/minmax.h-use-build_bug_on_msg-for-the-lo-hi-test-in-clamp.patch
queue-5.10/minmax-simplify-min-max-clamp-implementation.patch
queue-5.10/minmax-deduplicate-__unconst_integer_typeof.patch
queue-5.10/minmax-simplify-and-clarify-min_t-max_t-implementation.patch
queue-5.10/minmax.h-add-whitespace-around-operators-and-after-commas.patch
queue-5.10/minmax-sanity-check-constant-bounds-when-clamping.patch
queue-5.10/minmax-avoid-overly-complicated-constant-expressions-in-vm-code.patch
queue-5.10/minmax-make-generic-min-and-max-macros-available-everywhere.patch
queue-5.10/minmax-fix-up-min3-and-max3-too.patch
queue-5.10/minmax.h-reduce-the-define-expansion-of-min-max-and-clamp.patch
queue-5.10/minmax-fix-header-inclusions.patch
queue-5.10/minmax-introduce-min-max-_array.patch
queue-5.10/btrfs-remove-duplicated-in_range-macro.patch
queue-5.10/overflow-tracing-define-the-is_signed_type-macro-once.patch
queue-5.10/minmax-relax-check-to-allow-comparison-between-unsigned-arguments-and-signed-constants.patch
queue-5.10/minmax-clamp-more-efficiently-by-avoiding-extra-comparison.patch
queue-5.10/minmax.h-update-some-comments.patch
next prev parent reply other threads:[~2025-10-17 13:48 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 9:04 [PATCH v2 00/27 5.10.y] Backport minmax.h updates from v6.17-rc7 Eliav Farber
2025-10-17 9:04 ` [PATCH v2 01/27 5.10.y] overflow, tracing: Define the is_signed_type() macro once Eliav Farber
2025-10-17 11:59 ` Greg KH
2025-10-17 12:16 ` Farber, Eliav
2025-10-17 13:21 ` Greg KH
2025-10-17 13:48 ` Patch "overflow, tracing: Define the is_signed_type() macro once" has been added to the 5.10-stable tree gregkh
2025-10-17 9:04 ` [PATCH v2 02/27 5.10.y] btrfs: remove duplicated in_range() macro Eliav Farber
2025-10-17 13:48 ` Patch "btrfs: remove duplicated in_range() macro" has been added to the 5.10-stable tree gregkh
2025-10-17 9:04 ` [PATCH v2 03/27 5.10.y] minmax: sanity check constant bounds when clamping Eliav Farber
2025-10-17 13:48 ` Patch "minmax: sanity check constant bounds when clamping" has been added to the 5.10-stable tree gregkh
2025-10-17 9:04 ` [PATCH v2 04/27 5.10.y] minmax: clamp more efficiently by avoiding extra comparison Eliav Farber
2025-10-17 13:48 ` Patch "minmax: clamp more efficiently by avoiding extra comparison" has been added to the 5.10-stable tree gregkh
2025-10-17 9:04 ` [PATCH v2 05/27 5.10.y] minmax: add in_range() macro Eliav Farber
2025-10-17 13:48 ` gregkh [this message]
2025-10-17 9:04 ` [PATCH v2 06/27 5.10.y] minmax: Introduce {min,max}_array() Eliav Farber
2025-10-17 13:48 ` Patch "minmax: Introduce {min,max}_array()" has been added to the 5.10-stable tree gregkh
2025-10-17 9:04 ` [PATCH v2 07/27 5.10.y] minmax: deduplicate __unconst_integer_typeof() Eliav Farber
2025-10-17 13:48 ` Patch "minmax: deduplicate __unconst_integer_typeof()" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 08/27 5.10.y] minmax: fix header inclusions Eliav Farber
2025-10-17 13:48 ` Patch "minmax: fix header inclusions" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 09/27 5.10.y] minmax: allow min()/max()/clamp() if the arguments have the same signedness Eliav Farber
2025-10-17 13:48 ` Patch "minmax: allow min()/max()/clamp() if the arguments have the same signedness." has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 10/27 5.10.y] minmax: fix indentation of __cmp_once() and __clamp_once() Eliav Farber
2025-10-17 13:48 ` Patch "minmax: fix indentation of __cmp_once() and __clamp_once()" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 11/27 5.10.y] minmax: allow comparisons of 'int' against 'unsigned char/short' Eliav Farber
2025-10-17 13:48 ` Patch "minmax: allow comparisons of 'int' against 'unsigned char/short'" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 12/27 5.10.y] minmax: relax check to allow comparison between unsigned arguments and signed constants Eliav Farber
2025-10-17 13:48 ` Patch "minmax: relax check to allow comparison between unsigned arguments and signed constants" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 13/27 5.10.y] minmax: avoid overly complicated constant expressions in VM code Eliav Farber
2025-10-17 13:48 ` Patch "minmax: avoid overly complicated constant expressions in VM code" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 14/27 5.10.y] minmax: add a few more MIN_T/MAX_T users Eliav Farber
2025-10-17 13:48 ` Patch "minmax: add a few more MIN_T/MAX_T users" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 15/27 5.10.y] minmax: simplify and clarify min_t()/max_t() implementation Eliav Farber
2025-10-17 13:48 ` Patch "minmax: simplify and clarify min_t()/max_t() implementation" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 16/27 5.10.y] minmax: make generic MIN() and MAX() macros available everywhere Eliav Farber
2025-10-17 13:48 ` Patch "minmax: make generic MIN() and MAX() macros available everywhere" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 17/27 5.10.y] minmax: don't use max() in situations that want a C constant expression Eliav Farber
2025-10-17 13:48 ` Patch "minmax: don't use max() in situations that want a C constant expression" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 18/27 5.10.y] minmax: simplify min()/max()/clamp() implementation Eliav Farber
2025-10-17 13:48 ` Patch "minmax: simplify min()/max()/clamp() implementation" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 19/27 5.10.y] minmax: improve macro expansion and type checking Eliav Farber
2025-10-17 13:48 ` Patch "minmax: improve macro expansion and type checking" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 20/27 5.10.y] minmax: fix up min3() and max3() too Eliav Farber
2025-10-17 13:48 ` Patch "minmax: fix up min3() and max3() too" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 21/27 5.10.y] minmax.h: add whitespace around operators and after commas Eliav Farber
2025-10-17 13:48 ` Patch "minmax.h: add whitespace around operators and after commas" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 22/27 5.10.y] minmax.h: update some comments Eliav Farber
2025-10-17 13:48 ` Patch "minmax.h: update some comments" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 23/27 5.10.y] minmax.h: reduce the #define expansion of min(), max() and clamp() Eliav Farber
2025-10-17 13:48 ` Patch "minmax.h: reduce the #define expansion of min(), max() and clamp()" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 24/27 5.10.y] minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp() Eliav Farber
2025-10-17 13:48 ` Patch "minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 25/27 5.10.y] minmax.h: move all the clamp() definitions after the min/max() ones Eliav Farber
2025-10-17 13:48 ` Patch "minmax.h: move all the clamp() definitions after the min/max() ones" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 26/27 5.10.y] minmax.h: simplify the variants of clamp() Eliav Farber
2025-10-17 13:48 ` Patch "minmax.h: simplify the variants of clamp()" has been added to the 5.10-stable tree gregkh
2025-10-17 9:05 ` [PATCH v2 27/27 5.10.y] minmax.h: remove some #defines that are only expanded once Eliav Farber
2025-10-17 13:48 ` Patch "minmax.h: remove some #defines that are only expanded once" has been added to the 5.10-stable tree gregkh
2025-10-17 15:03 ` [PATCH v2 00/27 5.10.y] Backport minmax.h updates from v6.17-rc7 Greg KH
2025-10-17 16:09 ` Nathan Chancellor
2025-10-19 12:38 ` Greg KH
2025-10-18 20:07 ` Farber, Eliav
2025-10-19 12:37 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025101727-agile-tinwork-5c96@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=20230206140639.538867-5-fengwei.yin@intel.com \
--cc=David.Laight@ACULAB.COM \
--cc=Jason@zx2c4.com \
--cc=adilger.kernel@dilger.ca \
--cc=agk@redhat.com \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=alexander.deucher@amd.com \
--cc=alexandre.torgue@st.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=artur.paszkiewicz@intel.com \
--cc=bp@alien8.de \
--cc=brian.starkey@arm.com \
--cc=bvanassche@acm.org \
--cc=chao@kernel.org \
--cc=christian.koenig@amd.com \
--cc=clm@fb.com \
--cc=coreteam@netfilter.org \
--cc=daniel@ffwll.ch \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dm-devel@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsterba@suse.com \
--cc=dushistov@mail.ru \
--cc=el.com@kvack.org \
--cc=evan.quan@amd.com \
--cc=farbere@amazon.com \
--cc=fery@cypress.com \
--cc=freedreno@lists.freedesktop.org \
--cc=fw@strlen.de \
--cc=harry.wentland@amd.com \
--cc=hdegoede@redhat.com \
--cc=herve.codina@bootlin.com \
--cc=hpa@zytor.com \
--cc=intel-linux-scu@intel.com \
--cc=jack@suse.com \
--cc=james.morse@arm.com \
--cc=james.qian.wang@arm.com \
--cc=jdelvare@suse.com \
--cc=jdike@addtoit.com \
--cc=jejb@linux.ibm.co \
--cc=jmaloy@redhat.com \
--cc=joabreu@synopsys.com \
--cc=josef@toxicpanda.com \
--cc=kadlec@netfilter.org \
--cc=kbusch@kernel.org \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-mm@kvack.org \
--cc=linux-staging@lists.linux.dev \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-um@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linux@rasmusvillemoes.dk \
--cc=linux@roeck-us.net \
--cc=liviu.dudau@arm.com \
--cc=luc.vanoostenryck@gmail.com \
--cc=luto@kernel.org \
--cc=m@kvack.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=malattia@linux.it \
--cc=martin.petersen@oracle.com \
--cc=mchehab@kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=mgross@linux.intel.com \
--cc=mihail.atanassov@arm.com \
--cc=minchan@kernel.org \
--cc=mingo@redhat.com \
--cc=mripard@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ngupta@vflare.org \
--cc=pablo@netfilter.org \
--cc=peppe.cavallaro@st.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=qiuxu.zhuo@intel.com \
--cc=rajur@chelsio.com \
--cc=richard@nod.at \
--cc=robdclark@gmail.com \
--cc=rostedt@goodmis.org \
--cc=rric@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=sakari.ailus@linux.int \
--cc=sashal@kernel.org \
--cc=sean@poorly.run \
--cc=sergey.senozhatsky@gmail.com \
--cc=snitzer@redhat.com \
--cc=stable-commits@vger.kernel.org \
--cc=sunpeng.li@amd.com \
--cc=tglx@linutronix.de \
--cc=tipc-discussion@lists.sourceforge.net \
--cc=tony.luck@intel.com \
--cc=tytso@mit.edu \
--cc=tzimmermann@suse.de \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=xiang@kernel.org \
--cc=ying.xue@windriver.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox