netdev - Re: [PATCH net-next] neighbor: Add protocol attribute

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: <c6702406-dfb6-462f-7664-c96af4fc811b@gmail.com>
Date:   Fri, 7 Dec 2018 15:03:04 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     David Ahern <dsahern@...il.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, roopa@...ulusnetworks.com
Subject: Re: [PATCH net-next] neighbor: Add protocol attribute



On 12/07/2018 02:24 PM, David Ahern wrote:
> On 12/7/18 3:20 PM, Eric Dumazet wrote:
>>
>>
>> On 12/07/2018 01:49 PM, David Ahern wrote:
>>> From: David Ahern <dsahern@...il.com>
>>>
>>> Similar to routes and rules, add protocol attribute to neighbor entries
>>> for easier tracking of how each was created.
>>>
>>> Signed-off-by: David Ahern <dsahern@...il.com>
>>> ---
>>>  include/net/neighbour.h        |  2 ++
>>>  include/uapi/linux/neighbour.h |  1 +
>>>  net/core/neighbour.c           | 24 +++++++++++++++++++++++-
>>>  3 files changed, 26 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/net/neighbour.h b/include/net/neighbour.h
>>> index 6c13072910ab..e93c59df9501 100644
>>> --- a/include/net/neighbour.h
>>> +++ b/include/net/neighbour.h
>>> @@ -149,6 +149,7 @@ struct neighbour {
>>>  	__u8			nud_state;
>>>  	__u8			type;
>>>  	__u8			dead;
>>> +	u8			protocol;
>>>  	seqlock_t		ha_lock;
>>>  	unsigned char		ha[ALIGN(MAX_ADDR_LEN, sizeof(unsigned long))];
>>
>> This looks like ha[] alignment would change, I am not sure how critical it is.
> 
> Just adds 4 bytes to neighbour:
> 
> ...
> /* --- cacheline 2 boundary (128 bytes) --- */
> long unsigned int          used;                 /*   128     8 */
> atomic_t                   probes;               /*   136     4 */
> __u8                       flags;                /*   140     1 */
> __u8                       nud_state;            /*   141     1 */
> __u8                       type;                 /*   142     1 */
> __u8                       dead;                 /*   143     1 */
> u8                         protocol;             /*   144     1 */
> 
> /* XXX 3 bytes hole, try to pack */
> seqlock_t                  ha_lock;              /*   148     8 */
> unsigned char              ha[32];               /*   156    32 */
> /* XXX 4 bytes hole, try to pack */
> 
> /* --- cacheline 3 boundary (192 bytes) --- */
> struct hh_cache            hh;                   /*   192    48 */
> 
> ...
> 
> but does not change the actual allocation size which is rounded to 512.
> 

I have not talked about the allocation size, but alignment of ->ha field,
which is kind of assuming long alignment, in a strange way.

As I said, I do not know how performance critical this might be.