netdev - RE: [PATCH net-next] net: Add phys_port identifier to struct net

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]

Date:	Thu, 20 Jun 2013 00:23:47 +0530
From:	<Narendra_K@...l.com>
To:	<bhutchings@...arflare.com>
CC:	<john.fastabend@...il.com>, <netdev@...r.kernel.org>,
	<john.r.fastabend@...el.com>
Subject: RE: [PATCH net-next] net: Add phys_port identifier to struct
 net_device and export it to sysfs

> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@...arflare.com]
> Sent: Wednesday, June 19, 2013 9:07 PM
> To: K, Narendra
> Cc: john.fastabend@...il.com; netdev@...r.kernel.org;
> john.r.fastabend@...el.com
> Subject: Re: [PATCH net-next] net: Add phys_port identifier to struct
> net_device and export it to sysfs
> 
> On Wed, 2013-06-19 at 07:29 -0700, Narendra_K@...l.com wrote:
> [...]
> > 2. show_phys_port  function sees a consistent value of
> > 'netdev->phys_port.port_id and netdev->phys_port.port_id_len '  if
> > another execution path changes the value of 'netdev->phys_port.port_id
> > and netdev->phys_port.port_id_len '  with write_lock(&dev_base_lock)
> > held (similar to how dev->operstate is being changed).
> [...]
> 
> If the physical port ID can change dynamically (I hadn't thought of that, but an
> embedded switch could support such reconfiguration) then any such change
> also needs to be announced through rtnetlink.  Actually, I think the value
> needs to be included in rtnetlink information anyway.
> 

Ok. Thank you Ben. I had not thought about this scenario.  I was thinking about the reason to hold the dev_base_lock.  Do you think points 1 and 2 are correct reason to hold the dev_base_lock ? If correct,  I think the 'show_broadcast' function also needs to be fixed as it is not holding the lock.

With regards,
Narendra K
Linux Engineering
Dell Inc.