netdev - Re: [net-next,V5,06/15] devlink: Decouple rate storage from associated devlink object

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <91e5ed31316e27d0c60dc392858f3cae02cee43a.camel@nvidia.com>
Date: Thu, 22 Jan 2026 11:18:33 +0000
From: Cosmin Ratiu <cratiu@...dia.com>
To: Tariq Toukan <tariqt@...dia.com>, "kuba@...nel.org" <kuba@...nel.org>
CC: "corbet@....net" <corbet@....net>, "rdunlap@...radead.org"
	<rdunlap@...radead.org>, "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"donald.hunter@...il.com" <donald.hunter@...il.com>, "davem@...emloft.net"
	<davem@...emloft.net>, "leon@...nel.org" <leon@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "jiri@...nulli.us" <jiri@...nulli.us>, Jiri Pirko
	<jiri@...dia.com>, Carolina Jubran <cjubran@...dia.com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, "horms@...nel.org"
	<horms@...nel.org>, Mark Bloch <mbloch@...dia.com>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>, "krzk@...nel.org"
	<krzk@...nel.org>, Saeed Mahameed <saeedm@...dia.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>, Gal Pressman
	<gal@...dia.com>, Moshe Shemesh <moshe@...dia.com>
Subject: Re: [net-next,V5,06/15] devlink: Decouple rate storage from
 associated devlink object

On Wed, 2026-01-21 at 19:39 -0800, Jakub Kicinski wrote:
> > @@ -220,6 +248,9 @@ devlink_nl_rate_get_dump_one(struct sk_buff
> > *msg, struct devlink *devlink,
> >  			idx++;
> >  			continue;
> >  		}
> > +		if (devlink_rate->devlink != devlink)
> > +			continue;
> 
> When this filter skips a non-matching entry, idx is not incremented.
> However, state->idx is used to track position across netlink dump
> resumptions and expects idx to reflect the actual position in the
> list.
> 
> Once cross-device rate nodes are enabled (later in this series), the
> list
> can contain entries from multiple devlinks. If the dump requires
> multiple
> netlink messages and non-matching entries exist between matching
> ones,
> the idx tracking becomes inconsistent with the list position. This
> can
> cause entries to be reported multiple times on dump resumption.
> 
> Should this continue statement also increment idx to maintain correct
> position tracking?

Another useful finding. I suspect the code might work as-is, since
state->idx tracks "the next pending item for 'devlink'" from the list,
but it's quite hard to reason about that and it's probably better to do
as the tool suggests, and track the list position as now. Will do so in
the next version.

Cosmin.