netdev - Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set

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:	Mon, 21 Apr 2008 13:45:20 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
CC:	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Gerrit Renker <gerrit@....abdn.ac.uk>, dccp@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version
 of Tomasz's patch set

Tomasz Grobelny wrote:
> Dnia Sunday 20 of April 2008, Arnaldo Carvalho de Melo napisał:
>> Em Sat, Apr 19, 2008 at 10:42:32PM +0200, Tomasz Grobelny escreveu:
>>>> When the patch failed to compile I thought about those alternatives.
>>>> Trying to extend the dccp_skb_cb over and above what is in there will
>>>> be messy, since the IPv4/v6 parameters are required by other
>>>> subsystems.
>>> If inet{,6}_skb_parm is used only outside DCCP code then why at all
>>> should it be placed in struct dccp_skb_cb taking up quite a lot of
>>> valuable space? Why not put it directly in struct sk_buff? Especially
>>> that it is present in struct udp_skb_cb, struct tcp_skb_cb as well.
>> Because all this is used in skb->cb[], a scratchpad for protocols to
>> use, we can go back to what we had before, that is to not reserve use
>> for inet6?_skb_parm but be sure to zero it before passing it to IP, as
>> we don't want IP to be confused with things being non zero there. Then
>> we can use all its space.
>>
> Several questions regarding this case:
> 1. What about SCTP? It doesn't have inet6?_skb_parm in it's structure that is 
> stored in skb->cb. So does it contain a potential bug (that is to be fixed) 
> or is it not needed there or what?

Judging by a quick grep, SCTP only uses the CB on input and
appears to be fine.

> 2. If the sole purpose of this change was to keep skb->cb zeroed then it 
> doesn't seem to me like the right solution. Wasting about 20 bytes instead of 
> zeroing them when needed I would consider at least weird. I understand that 
> TCP and UDP may have enough space left but it just turned out that DCCP 
> doesn't.

It was the safest solution that late in a release. It also
avoids to memset the cb unnecessarily. If the room is not
enough anymore, its easy to go back to using memset.

> 3. If it's IP layer that needs zeroes then why not clear skb->cb in IP layer?

That would certainly work, but it adds unnecessary costs for
the other protocols that don't need this.
--
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