netdev - Re: [RFC] Exempt multicast address from five-second neighbor lifetime

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]

Message-ID: <357ad409-5e3c-d47c-e7f1-8a11a307ee5e@akamai.com>
Date:   Mon, 19 Oct 2020 10:41:51 -0400
From:   Jeff Dike <jdike@...mai.com>
To:     Jesse Brandeburg <jesse.brandeburg@...el.com>,
        netdev@...r.kernel.org
Subject: Re: [RFC] Exempt multicast address from five-second neighbor lifetime

Hi Jesse,

> Your subject should indicate net or net-next as the tree, please see:

I was intending more to see if this is an intrinsically bad idea than for it to go directly into a tree right now.

> Not sure how many patches you've submitted, but your commit message
> should be wrapped at 68 or 72 characters or so.

Not my first patch, but the first sent through Thunderbird and Outlook.

> your triple-dash and a diffstat should be right here, did you hand edit
> this mail instead of using git format-patch to generate it?

Yup, the log message on my internal commit wouldn't make too much sense outside of Akamai, so I wrote this changelog in my MUA.

> Why is this added in the middle of the includes?

I needed to get IN_MULTICAST defined - this is one reason I don't expect this patch as it stands to go anywhere.  IN_MULTICAST seems intended just for userspace use, but there isn't any way to ask the same question in the kernel.  The same seems to be true of IPv6 multicast addresses.

>> +static int arp_is_multicast(const void *pkey)
>> +{
>> +	return IN_MULTICAST(htonl(*((u32 *) pkey)));
>> +}
> 
> Why not just move this function up and skip the declaration above?

Following existing practice in this file.  Similar functions are declared above the structure and defined below it.

>>  
>> +static int ndisc_is_multicast(const void *pkey)
>> +{
>> +	return (((struct in6_addr *) pkey)->in6_u.u6_addr8[0] & 0xf0) == 0xf0;
>> +}
>> +
> 
> Again, just move this up above the first usage?

Following existing practice again.
> 
> Does the above work on big and little endian, just seems suspicious
> even though you're using a byte offset? Also I suspect this will
> trigger a warning with sparse or with W=2 about pointer alignment.

I used the byte offsets on purpose for this reason.  Didn't check if sparse had any problems with it.

Jeff