netdev - Re: [RFC] usbnet: assign unique random MAC

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: <87il61g7fz.fsf@miraculix.mork.no>
Date: Thu, 16 Nov 2023 14:21:20 +0100
From: Bjørn Mork <bjorn@...k.no>
To: Oliver Neukum <oneukum@...e.com>
Cc: netdev@...r.kernel.org
Subject: Re: [RFC] usbnet: assign unique random MAC

Oliver Neukum <oneukum@...e.com> writes:

> On 16.11.23 13:39, Bjørn Mork wrote:
>> Oliver Neukum <oneukum@...e.com> writes:
>> 
>>> A module parameter to go back to the old behavior
>>> is included.
>> Is this really required?  If we add it now then we can never get rid
>> of
>> it.  Why not try without, and add this back if/when somebody complains
>> about the new behaviour?
>> I believe there's a fair chance no one will notice or complain.  And
>> we
>> have much cleaner code and one module param less.
>
> Isn't it a bit evil to change behavior?

Only if someone actually depend on the old behaviour.  And I think
there's a fair chance no one does.

I don't propose forcing this change on anyone.  Only to try and see if
we can apply if without any force involved.

Note that the module parameter solution also will be a breaking change
for anyone depending on the current behaviour.  If you want to avoid
that, then you need to invert the logic. And then you might as well drop
the whole change.

> Do you think I should make a different version for stable
> with the logic for retaining the old behavior inverted?

I assumed this was unsuitable for stable backports.  Is there any reason
to backport it?

Bjørn