netdev - Re: [RFC][PATCH 00/50] set addr_assign_type to NET_ADDR_RANDOM if a random mac address get assigned to a netdevice

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]

Message-Id: <201202091318.36264.danny.kukawka@bisect.de>
Date:	Thu, 9 Feb 2012 13:18:35 +0100
From:	Danny Kukawka <danny.kukawka@...ect.de>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 00/50] set addr_assign_type to NET_ADDR_RANDOM if a random mac address get assigned to a netdevice

On Donnerstag, 9. Februar 2012, David Miller wrote:
> 50 patches is way too many patches to submit and expect people
> to review at one time.
>
> You must do one of two things:
>
> 1) Condense the series down to a smaller number of more managable
>    patches.  Perhaps combine all the completely trivial conversion
>    cases into one single patch, and post the non-trivial cases
>    seperately.
>
> 2) Only submit a few of these changes at a time, not all at once.
>
> It's your choice, but what you did here is unacceptable.

Could you at least comment on these points from the cover letter, before I 
change/update the patches?

- Should NET_ADDR_RANDOM get reset (to NET_ADDR_PERM) if the MAC address
  get changed via SIOCSIFHWADDR/.ndo_set_mac_address and was random before?
- Would it make sense to add a new state (e.g. NET_ADDR_USERSPACE)
  if the net address get changed via SIOCSIFHWADDR/.ndo_set_mac_address 
  from userspace?

Thanks,

Danny
--
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