netdev - Re: [RFC PATCH] Initialize dev_id sysfs attribute to -1 by default

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51B2152E.5010105@gmail.com>
Date:	Fri, 07 Jun 2013 10:15:26 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	John Fastabend <john.r.fastabend@...el.com>, Narendra_K@...l.com,
	bjorn@...k.no, netdev@...r.kernel.org, yoshfuji@...ux-ipv6.org
Subject: Re: [RFC PATCH] Initialize dev_id sysfs attribute to -1 by default

On 06/07/2013 08:23 AM, Ben Hutchings wrote:
> On Fri, 2013-06-07 at 07:45 -0700, John Fastabend wrote:
>> On 5/31/2013 5:17 AM, Narendra_K@...l.com wrote:
>>> On Thu, May 30, 2013 at 07:08:46PM +0530, Bjørn Mork wrote:
>>>>
>>>> <Narendra_K@...l.com> writes:
>>>>
>>>>> From: Narendra K <narendra_k@...l.com>
>>>>>
>>>>> 'dev_id' sysfs attribute is initialized to zero by default.
>>>>> It is also zero based. This creates ambiguity in differentiating
>>>>> whether the driver set it to zero or it is the default value.
>>>>> Initialize 'dev_id' to -1 to make the scenario unambiguous.
>>>>
>>>> I understand your concern, but I don't think you can do this.  It
>>>> changes the userspace API, and has some very visible side effects.
>>>>
>>>> Please take a look at net/ipv6/addrconf.c
>>>
>>> Ok, thank you for pointing it. I missed it while looking for its
>>> possible use scenarios.
>>
>> Although I'm not sure how that check works with devices that are
>> setting dev_id and also provide their own mac addresses. From
>> inspection it looks like these devices end up with a local interface
>> identifier unnecessarily.
>>
>> Maybe Ben knows one of the drivers is the siena solorflare controller
>> apparently for the SFC9000 family? The other two 'grep' finds are
>> an mlx and chelsio device.
>>
>> Interestingly I didn't find any devices setting dev_id that also
>> didn't program unique mac addresses. Perhaps I'm missing something?
>
> I set this for Siena so that userland can tell which PF and port is
> which even if the PCIe topology is hidden by virtualisation.  In
> practice we haven't made use of that (and since virtualisation may also
> hide the VPD and serial number capabilities, it probably doesn't help
> much).
>
> Ben.
>

I guess then to make dev_id work like Narendra wants you would need
something in the management stack to come through and assign unique
dev_id values to functions (net_devices) that share a MAC. Or have some
unique 'unsigned short' value in the driver that it could be set to.
I guess I miss why initializing it to -1 helps.

Still best I can tell your ipv6 identifiers are not going to have
the 'u' bit inverted creating a somewhat strange side effect from
setting the dev_id.

.John



-- 
John Fastabend         Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html