linux-kernel - RE: [EXT] Re: [net-next PATCH v6 1/2] octeontx2-af: Add new mbox to support multicast/mirror 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] [day] [month] [year] [list]

Message-ID: <SJ0PR18MB5216723A36FC17056845139CDB8BA@SJ0PR18MB5216.namprd18.prod.outlook.com>
Date:   Thu, 7 Dec 2023 04:51:33 +0000
From:   Suman Ghosh <sumang@...vell.com>
To:     Paolo Abeni <pabeni@...hat.com>,
        Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        Geethasowjanya Akula <gakula@...vell.com>,
        Subbaraya Sundeep Bhatta <sbhatta@...vell.com>,
        Hariprasad Kelam <hkelam@...vell.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linu Cherian <lcherian@...vell.com>,
        Jerin Jacob Kollanukkaran <jerinj@...vell.com>,
        "horms@...nel.org" <horms@...nel.org>,
        "wojciech.drewek@...el.com" <wojciech.drewek@...el.com>
Subject: RE: [EXT] Re: [net-next PATCH v6 1/2] octeontx2-af: Add new mbox to
 support multicast/mirror offload

>> > > +
>> > > u32 mcast_grp_idx)
>> > > +{
>> > > +	struct nix_mcast_grp_elem *iter;
>> > > +	bool is_found = false;
>> > > +
>> > > +	mutex_lock(&mcast_grp->mcast_grp_lock);
>> > > +	list_for_each_entry(iter, &mcast_grp->mcast_grp_head,
>> > > list) {
>> > > +		if (iter->mcast_grp_idx == mcast_grp_idx) {
>> > > +			is_found = true;
>> > > +			break;
>> > > +		}
>> > > +	}
>> > > +	mutex_unlock(&mcast_grp->mcast_grp_lock);
>> >
>> > AFAICS, at this point another thread/CPU could kick-in and run
>> > rvu_mbox_handler_nix_mcast_grp_destroy() up to completion, freeing
>> > 'iter' before it's later used by the current thread.
>> >
>> > What prevents such scenario?
>> >
>> > _If_ every mcast group manipulation happens under the rtnl lock,
>> > then you could as well completely remove the confusing
>> > mcast_grp_lock.
>> >
>> > Cheers,
>> >
>> > Paolo
>> [Suman] I added this lock because, these requests can come from some
>> user-space application also. In that case, application will send a
>> mailbox to kernel toad/del Multicast nodes. But I got your point and
>> there is indeed chances of race. Let me think through it and push a
>> fix. So, what process should be followed here? Are you going to revert
>> the change? Or I can push a separate fix on net tree?
>
>You can push a follow-up fix.
>
>We could end-up reverting the patch only if the fix will take too long
>to land here, and the issue will start hitting people.
>
>Cheers,
>
>Paolo
[Suman] Sure Paolo, I will push the follow-up fix ASAP.
>