From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.239 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793590384; b=GRy/t3j04FioGw1AqAYa9x2f03nZogoHIvrRPbwz35ufrwQ8TDExkwRh8b1hFwyFI/eH r7o8CB3CUQ3Ec6k690zTi8c7OeY//8q5rR1Zoh5T0LC9nw244AG/fIZmAgEg3iorZSlia H/E+oLFHpV3LMB8o3tQGc6gBWvxo4ChHrqi8eb0m0PEsUcmLqJiv3MX1jLmQOeOdrc8bD gESA3TyGEMW8u0dG+domquwS/QQyOGbjTeMcYbZwjZKNSIdo44bU01JqT690oRFMINvGg 0T8vMY9B4TBXzjZkYMu0JjtnlmsfoWVWJBLGG/g3MgETrS2gqex1cYgE/eD44W5qlQA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793590384; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=m/8uEgVZBiGs6GhX+EaixTcEV6WwGEnxdOq6kuEraE8=; b=2vtrLRXbmwAr5D39P9R9dug/aqVuu+seVl35t6OP2KlD2fmEq2VIToS6Ijsa68e0dbSB hM+QstD/QX5+ByA1CwecLyydPR0oT2i5ES5dlCRdeflvxTZpqTGz5i3e6DsF9tlO1rIRQ 5Ht7eos1PSH+zn/VFbaMl5yYVkhMitLTaZ0/GUdPL+MjekAAYHRMI6h9HZkK1hPGeT9Lp SwL5PK5P9Jo+xH0GUzhCG4+lTQ38YaXAffdH5XRkiPaae8hHz35XyEx2Hr+GZAU7U94e0 HJrn7rBWGNP/Y3tG5dw+lc8lc/iDFgK3aUSiL1XGmBfzMdZLaBRzRAk97hsbKKYAppA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; arc=none smtp.remote-ip=91.218.175.239 Received: from mta0.migadu.com (out-239.mta0.migadu.com [91.218.175.239]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD453606A324 for ; Mon, 2 Nov 2026 03:32:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org CD453606A324 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev X-Envelope-To: stable@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=nNlyAiB0N622Wf4HwaxQyqQjcvp12NITnvjasTRHZ0c=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793590371; v=1; x=1794195171; b=Jinjzi6X+J/HEXZSr2S+tfp0I3z7ZtTGk63EFv26nAh/wxu4Ml3RUoctD3BqbkkXroDZX9Sl IpnB5Vh7Ls+8sN32Me8WAELsWI5QMsIFLmsVA2NkTPEfHw3IhwLqvWnQ4ggfYQ7+xlsXWnThMvR 7dbldQzEJsaPqxRyIr3Y6Pi4= X-Envelope-To: stable@vger.kernel.org Received: by mta10.migadu.com with ESMTPS id d0263b54e1afad11; Mon, 02 Nov 2026 03:32:51 +0000 X-Mizu-Trace-ID: d0263b54e1afad11 X-Migadu-Flow: FLOW_OUT Date: Mon, 2 Nov 2026 11:32:36 +0800 From: Hangbin Liu To: Jiayuan Chen Cc: netdev@vger.kernel.org, stable@vger.kernel.org, Joel Granados , Fernando Fernandez Mancera , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Shuah Khan , Randy Dunlap , David Ahern , Ido Schimmel , Thomas Gleixner , Petr Pavlu , Kuniyuki Iwashima , Maoyi Xie , Zhan Xusheng , Oleg Nesterov , Neal Cardwell , Chia-Yu Chang , Yung Chih Su , Wyatt Feng , Hannes Frederic Sowa , Flavio Leitner , "Paul E. McKenney" , Petr Mladek , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net v3 5/5] net: restrict message_cost and message_burst to non-negative values Message-ID: References: <20261101061331.286404-1-jiayuan.chen@linux.dev> <20261101061331.286404-6-jiayuan.chen@linux.dev> <2fd1dc53-ae46-4163-90a4-f916c9dce29b@linux.dev> X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2fd1dc53-ae46-4163-90a4-f916c9dce29b@linux.dev> Hi Jiayuan, On Mon, Nov 02, 2026 at 10:23:30AM +0800, Jiayuan Chen wrote: > > On 11/2/26 9:55 AM, Hangbin Liu wrote: > > Hi Jiayuan, > > On Sun, Nov 01, 2026 at 02:12:03PM +0800, Jiayuan Chen wrote: > >> net.core.message_cost and net.core.message_burst feed the interval and > >> burst of net_ratelimit_state, but neither rejects negative values: > >> message_burst uses plain proc_dointvec, and message_cost uses > >> proc_dointvec_jiffies, which happily stores -1 second as -HZ jiffies. > >> > >> Since commit a940d145cc38 ("ratelimit: Warn if ->interval or ->burst are > >> negative"), ___ratelimit() splats on such values, so the next > >> net_ratelimit() caller warns, e.g. a martian source log: > >> > >> Negative interval (-250) or burst (10): Uninitialized ratelimit_state structure? > >> WARNING: lib/ratelimit.c:43 at ___ratelimit+0x56e/0x960, CPU#1: ping/3218 > >> RIP: 0010:___ratelimit+0x578/0x960 > >> Call Trace: > >> > >> net_ratelimit+0x1c/0x30 > >> ip_handle_martian_source+0x1bb/0x340 > >> ip_route_input_slow+0x1057/0x3650 > >> ip_route_input_noref+0x104/0x260 > >> arp_process+0x109b/0x2510 > >> arp_rcv+0x381/0x460 > >> __netif_receive_skb_one_core+0x173/0x1c0 > >> __netif_receive_skb+0x21/0x150 > >> process_backlog+0x37e/0x1200 > >> __napi_poll.constprop.0+0xa5/0x5e0 > >> net_rx_action+0x4c0/0xf70 > >> handle_softirqs+0x204/0x9b0 > >> __do_softirq+0x10/0x18 > >> do_softirq.part.0+0x49/0xd0 > >> > >> > >> Negative values never meant anything here: 0 already expresses both > >> "no limit" (interval) and "suppress everything" (burst). > > Will this limit breaks the UAPI on old kernels that supports negative values? > > All commits in this series restrict config values, and every one of them > changes the old behavior to some degree; the question is whether the The other patches fix shift-out-of-bounds or incorrect behaviors. > > change is reasonable. > > > For this one, negative values never did anything that 0 doesn't, and > since a940d145cc38 setting one already triggers the WARN_ONCE(). While this one doesn't improve anything other than the WARN_ONCE. The previous kernel works good with negative values. > > > > As the comment in ___ratelimit() says: > > > > /* > > * Zero interval says never limit, otherwise, non-positive burst > > * says always limit. > > */ > > > > If all others agree to set the limit in this patch. I think the comment > > > The comment and the WARN_ONCE() are about ratelimit_state in general, not > net only. There are still other ways to set a negative value, > printk_ratelimit for example, so updating them is not this net patch's > job. printk_ratelimit is not recommend anymore. /* * Please don't use printk_ratelimit(), because it shares ratelimiting state * with all other unrelated printk_ratelimit() callsites. Instead use * printk_ratelimited() or plain old __ratelimit(). */ extern int __printk_ratelimit(const char *func); #define printk_ratelimit() __printk_ratelimit(__func__) > > > and the WARN_ONCE() , and the admin-guide/sysctl/net.rst all need to be updated. > > > > net.rst never documented a range or even the unit for these two, which is > why I didn't touch it. No strong preference though. I think a doc need to be updated if you set a range limit. Thanks Hangbin