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  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]
Date:	Fri, 07 Jun 2013 10:15:26 -0700
From:	John Fastabend <>
To:	Ben Hutchings <>
CC:	John Fastabend <>,,,,
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, wrote:
>>> On Thu, May 30, 2013 at 07:08:46PM +0530, Bjørn Mork wrote:
>>>> <> writes:
>>>>> From: Narendra K <>
>>>>> '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 Fastabend         Intel Corporation
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists