linux-kernel - Re: [PATCH can-next v6] can: add tx/rx LED trigger support

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:	Mon, 3 Sep 2012 20:13:35 +0200
From:	Kurt Van Dijck <kurt.van.dijck@....be>
To:	Marc Kleine-Budde <mkl@...gutronix.de>
Cc:	Fabio Baltieri <fabio.baltieri@...il.com>,
	linux-can@...r.kernel.org, linux-kernel@...r.kernel.org,
	Oliver Hartkopp <socketcan@...tkopp.net>,
	Wolfgang Grandegger <wg@...ndegger.com>
Subject: Re: [PATCH can-next v6] can: add tx/rx LED trigger support

On Mon, Sep 03, 2012 at 02:40:39PM +0200, Marc Kleine-Budde wrote:
> On 08/25/2012 12:01 AM, Fabio Baltieri wrote:
> > Hello Kurt,
> > 
> > On Fri, Aug 24, 2012 at 02:42:48PM +0200, Kurt Van Dijck wrote:
> >> On Fri, Aug 24, 2012 at 01:28:16PM +0200, Marc Kleine-Budde wrote:
> >>> On 08/24/2012 07:10 AM, Kurt Van Dijck wrote:
> >>>> Hello,
> >>>>
> >>>> I find the CAN led triggers an interesting thing.
> >>>>
> >>>> And then, this scenario fell crossed my mind:
> >>>> Imagine I do:
> >>>> [insert CAN device: can0]
> >>>> $ ip link set can0 name helga
> >>>> [insert another CAN device: again 'can0']
> >>>>
> >>>> Registering 'can0-tx' led trigger will fail for the second CAN device,
> >>>> since that led trigger name is already reserved for CAN device 'helga'.
> >>> Good point.
> > 
> > Yep, thanks for pointing that out!
> > 
> > Interface renaming was something I considered when I first wrote the
> > code and I had the mac80211-led driver in mind, as that driver uses the
> > phy name and not the netdev one for its triggers.
> > 
> > The reason why I did not care that much in the end is that on SoC based
> > systems trigger-led association is made at probe time, based on data
> > either from platform_data or devicetree, so I imagined that once the
> > kernel is ported to the board and default triggers are set correctly at
> > boot time, the userspace is free to rename CAN interfaces and nobody
> > should notice... :^)
> > 
> > The thing I did not consider are hot-plug interfaces mixed with
> > renaming, such as in the case you pointed out - it's probably not really
> > common but still possible.
> > 
> >>>> I'm not sure how to fix such.
> >>>> If 'rx' & 'tx' may be combined, reusing the netdev name may be possible?
> >>>> Just wild thinking ...
> >>>
> >>> I think the device's name (not netdev) is unique in the system and
> >>> cannot be changed.
> >>
> >> but may contain several netdev's ...
> > 
> > Ouch.
> 
> The net->ifindex is unique. But it's only an integer. Usually can0 has a
> ifindex != 0, so a simple can%d is contra productive here.
> 
> Some pointers to related code:
> http://lxr.free-electrons.com/source/drivers/base/core.c#L1847
> http://lxr.free-electrons.com/source/drivers/base/core.c#L73
> http://lxr.free-electrons.com/source/include/linux/device.h#L695
> 
> comments?

a very recent idea: something with netdevice notifiers and NETDEV_CHANGENAME ...
http://lxr.free-electrons.com/source/net/core/dev.c#L1030

you could: rename the trigger, or if we think it's usefull,
block the netdev rename when its triggers are in use.

Kurt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/