netdev - Re: IPv6 over Firewire

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]

Date:	Sun, 23 Dec 2012 17:23:11 +0900
From:	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
To:	stephan.gatzka@...il.com
CC:	netdev@...r.kernel.org, linux1394-devel@...ts.sourceforge.net,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Subject: Re: IPv6 over Firewire

(2012年12月22日 15:10), Stephan Gatzka wrote:
> 
>> Something like this:
>>
>>   static inline int ndisc_opt_addr_space(struct net_device *dev)
>>   {
>> -       return NDISC_OPT_SPACE(dev->addr_len + ndisc_addr_option_pad(dev->type));
>> +       switch (dev->type) {
>> +       case ARPHRD_IEEE1394:
>> +               return sizeof(struct ndisc_opt_ieee1394_llinfo);
>> +       default:
>> +               return NDISC_OPT_SPACE(dev->addr_len + ndisc_addr_option_pad(dev->type));
>> +       }
>>   }
>>
>> --yoshfuji
>>
> 
> O.k., this has the advantage that only ndisc packets get some more memory, but the question is if we are under such a hard memory pressure that we don't allow that.
> 
> Your solution has the disadvantage that now I have to publish struct ndisc_opt_ieee1394_llinfo to the ndisc stuff. Nobody in ndisc.c really wants to deal with that structure, only the size is of interest. So keeping this struct private is less invasive to the rest of linux. Just my two cents.

net/ipv6/ndisc.c SHOULD build full NDP messages for IPv6
over IEEE1394 as we do it for Infiniband.

Please, please do not try to mangle them in the driver.

--yoshfuji

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