netdev - Re: [PATCH net-next 1/3] cxgb4: add mirror action to TC-MATCHALL offload

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: <20200627064855.GB24993@chelsio.com>
Date:   Sat, 27 Jun 2020 12:18:56 +0530
From:   Rahul Lakkireddy <rahul.lakkireddy@...lsio.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, nirranjan@...lsio.com,
        vishal@...lsio.com, dt@...lsio.com
Subject: Re: [PATCH net-next 1/3] cxgb4: add mirror action to TC-MATCHALL
 offload

On Friday, June 06/26/20, 2020 at 21:18:44 -0700, Jakub Kicinski wrote:
> On Thu, 25 Jun 2020 17:28:41 +0530 Rahul Lakkireddy wrote:
> > +	if (refcount_read(&pi->vi_mirror_refcnt) > 1) {
> > +		refcount_dec(&pi->vi_mirror_refcnt);
> > +		return;
> > +	}
> 
> FWIW this looks very dodgy. If you know nothing changes the count
> between the read and the dec here, you probably don't need atomic
> refcounts at all..

Currently, all the callers accessing this refcount and its related
data is having the RTNL lock held by the stack. Perhaps this is a
false sense of security, especially if the stack API may change in
the future.

I'll add a proper lock to protect this data in v2 to be on the safer
side.

Thanks,
Rahul