netdev - Re: [PATCH next 2/3] ipvlan: mode is u16

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] [day] [month] [year] [list]

Date:	Mon, 8 Feb 2016 14:14:54 -0800
From:	Mahesh Bandewar <maheshb@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	mahesh@...dewar.net, Eric Dumazet <edumazet@...gle.com>,
	linux-netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH next 2/3] ipvlan: mode is u16

On Sun, Feb 7, 2016 at 11:19 AM, David Miller <davem@...emloft.net> wrote:
> From: Mahesh Bandewar <mahesh@...dewar.net>
> Date: Tue,  2 Feb 2016 11:20:30 -0800
>
>> From: Mahesh Bandewar <maheshb@...gle.com>
>>
>> The mode argument was erronusly defined as u32 but it has always
>> been u16.
>>
>> Signed-off-by: Mahesh Bandewar <maheshb@...gle.com>
>
> This patch is changing more than this.
>
> Specifically it is invoking ipvlan_set_port_mode() instead of assigning
> port->mode directly in ipvlan_link_new().
>
> That minimally needs to be documented in the commit log message.
>
> But I also wonder if for some reason in this conect the direct
> assignment happens to be fine.  That's pretty much why you should
> explain things.

Directly assigning does serve the same purpose, however when there is
a helper to do just that (and other things in future) it would help
keep all related things at one place avoiding errors in future. Since
it's a minor improvement I did not mention that into the commit log.

I'll update the commit log and resend.