[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <IA1PR11MB62668A4445C791151B657ACCE43B9@IA1PR11MB6266.namprd11.prod.outlook.com>
Date: Fri, 4 Nov 2022 23:27:03 +0000
From: "Mogilappagari, Sudheer" <sudheer.mogilappagari@...el.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"kuba@...nel.org" <kuba@...nel.org>,
"corbet@....net" <corbet@....net>,
"mkubecek@...e.cz" <mkubecek@...e.cz>,
"Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>
Subject: RE: [PATCH net-next] ethtool: add netlink based get rxfh support
> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Subject: Re: [PATCH net-next] ethtool: add netlink based get rxfh
> support
>
> > Got a question wrt rtnl_lock usage. I see lock is acquired for SET
> > operations and not for GET operations. Is rtnl_lock needed in this
> > case due to slightly different flow than rest of GET ops?
>
> The ioctl path takes the lock, so i don't see why the netlink code
> should not take the lock.
>
> Andrew
Hi Andrew,
Added locking changes but testing failed. Looks like locking is taken care of earlier in the flow for GET requests. ethnl_default_doit is acquiring rtnl_lock for GET.
Thanks
Sudheer
Powered by blists - more mailing lists