From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.127 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793586224; b=OHmbiuvsMNPMXeWOEOH6nEtLqU2jw6eVKhaU82qMKq9l6VeZUL/azv26whau+u3+iXqI tmpeLFMV2q7TiXUi/9sR9v8z+T9/W3kIJWbyO2ZD3I3ZuZzFZGJYrL77Ev7JS3A+rQLWO ACYe0KdWzvE5fNBt1n7qJ3jGgBvx9YAq4cCqKwhuwH9Hv7UEoHtiiERIvE4L3QALFrwHH +eGlBT0qB2/eUUUTMQj5SJZEtYIqfJY7jZq2QcNDKmGdnS/K8p6ay1GufHlu8tL4mgwQg O1qWm3/amGsQoCZJ79agOmUxja2yMAGZCE8Ko/EssunXa9k3W5IE4xs7NkAm2wHW0cw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793586224; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Message-ID:Date:MIME-Version:User-Agent: Subject:To:Cc:References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding; bh=o4fSDnmtmbZ30jH6553LXpXrsXHng0trnMhwaBC+PZs=; b=QMpbkezbZBzq+0uI6uf1l+dYtzV0YYVusfteUa8iu2lwfTxEOQe+Slwf26Cnu77FJzpK gKFb1Asi+Ydmx2/Ah1EYj+oUVIye7oRo0sZFZ9JANeqzeGEF+ZcpkLrBHD10m91EvJ71B nS8uIlRSOhax90btfCaGP2ZAXwVH4/DM9zhVgkc2zCKmmxsSOKd7z4iFT/wNuN+aCQFJT i2qRaeTj1Egkr46pZvolmZP50FYn7r2MvIWEI/N7YoNMmK8iXE/XjyAwlNJasNgwazCj9 B02ls2JxtMtLf9OLL/5DLs/ODamo6suGcwLuwk2C0p+L0vYJf/NT9by0zkhiA4gtfXA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=SRqinuuM; arc=none smtp.remote-ip=95.215.58.127 Received: from mta1.migadu.com (out-127.mta1.migadu.com [95.215.58.127]) (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 D9EEB606A32C for ; Mon, 2 Nov 2026 02:23:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org D9EEB606A32C 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=SRqinuuM X-Envelope-To: netdev@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=ALr5TsAEjuwt2pIJ/IP8K7713x8kUZX1icwbiFIInMI=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793586220; v=1; x=1794191020; b=SRqinuuMl6gdOXtp9TRbNPvcgF5WtOOqzaWiXWuBanFkmJV9xWmUIEICQ54IcO1dfYLdl/ue PBol2C63lhz91+GDFk7CfJhlOz3rzvVlyg07YN9TBKCWvNhCXfAw4f5el0RhCoZZBWuwu2sgdXc 3mzifa34+JRcDNllCvqsNviU= X-Envelope-To: netdev@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 74277f5059ada402; Mon, 02 Nov 2026 02:23:40 +0000 X-Mizu-Trace-ID: 74277f5059ada402 X-Migadu-Flow: FLOW_OUT Message-ID: <2fd1dc53-ae46-4163-90a4-f916c9dce29b@linux.dev> Date: Mon, 2 Nov 2026 10:23:30 +0800 X-Mailing-List: netdev@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net v3 5/5] net: restrict message_cost and message_burst to non-negative values To: Hangbin Liu 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 References: <20261101061331.286404-1-jiayuan.chen@linux.dev> <20261101061331.286404-6-jiayuan.chen@linux.dev> From: Jiayuan Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 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(). > 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. > 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. > Thanks > Hangbin