netdev - Re: net: openvswitch: incorrect usage in ovs_meters

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] [day] [month] [year] [list]

Message-Id: <71FB508D-5829-4237-9D8D-727235934971@163.com>
Date: Fri, 27 Jun 2025 11:10:12 +0800
From: lihuawei <lihuawei_zzu@....com>
To: Ilya Maximets <i.maximets@....org>
Cc: davem@...emloft.net,
 netdev@...r.kernel.org,
 edumazet@...gle.com,
 pabeni@...hat.com,
 kuba@...nel.org,
 xiangxia.m.yue@...il.com
Subject: Re: net: openvswitch: incorrect usage in ovs_meters_exit?

Okay，I got it, thank you Ilya Maximets.

> 2025年6月27日 01:16，Ilya Maximets <i.maximets@....org> 写道：
> 
> On 6/26/25 2:59 PM, lihuawei wrote:
>> hi, guys,
>> 
>> 	Recently, I am working on ovs meter.c, after reading the code, I have two questions about the ovs_meters_exit function as bellow :
>> 
>> void ovs_meters_exit(struct datapath *dp)
>> {
>> 	struct dp_meter_table *tbl = &dp->meter_tbl;
>> 	struct dp_meter_instance *ti = rcu_dereference_raw(tbl->ti);
>> 	int i;
>> 
>> 	for (i = 0; i < ti->n_meters; i++)
>> 		ovs_meter_free(rcu_dereference_raw(ti->dp_meters[i]));
>> 
>> 	dp_meter_instance_free(ti);
>> }
>> 
>>    1. why use rcu_dereference_raw here and not rcu_dereference_ovsl?
>>    2. why use dp_meter_instance_free here and not dp_meter_instance_free_rcu?
> 
> Hi.  AFAICT, the ovs_meters_exit() is called only from two places:
> 
> 1. As a cleanup for the datapath that we failed to fully allocate.
> 2. From the RCU-postponed destroy_dp_rcu() when the datapath is
>   being destroyed.
> 
> In both cases there should be no users of this datapath at the time
> this function is called, so it doesn't make a lot of sense to hold
> the lock or postpone the destruction of these internal fields again.
> Half of the datapath structure is already freed here.  So, unless
> I'm missing something, we can just free the meters directly as well.
> 
> Best regards, Ilya Maximets.