netdev - Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if

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:   Wed, 7 Mar 2018 13:52:00 -0800
From:   Jesus Sanchez-Palencia <jesus.sanchez-palencia@...el.com>
To:     Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Cc:     jhs@...atatu.com, xiyou.wangcong@...il.com, jiri@...nulli.us,
        vinicius.gomes@...el.com, richardcochran@...il.com,
        intel-wired-lan@...ts.osuosl.org, anna-maria@...utronix.de,
        henrik@...tad.us, tglx@...utronix.de, john.stultz@...aro.org,
        levi.pearson@...man.com, edumazet@...gle.com, willemb@...gle.com,
        mlichvar@...hat.com
Subject: Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and
 drop_if_late params

Hi,


On 03/06/2018 06:53 PM, Eric Dumazet wrote:
> On Tue, 2018-03-06 at 17:12 -0800, Jesus Sanchez-Palencia wrote:
>> Extend SO_TXTIME APIs with new per-packet parameters: a clockid_t and
>> a drop_if_late flag. With this commit the API becomes:
>>
>>
> 
>  * diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>  * index d8340e6e8814..951969ceaf65 100644
>  * --- a/include/linux/skbuff.h
>  * +++ b/include/linux/skbuff.h
>  * @@ -788,6 +788,9 @@ struct sk_buff {
>  *  	__u8			tc_redirected:1;
>  *  	__u8			tc_from_ingress:1;
>  *  #endif
>  * +	__u8			tc_drop_if_late:1;
>  * +
>  * +	clockid_t		txtime_clockid;
>  *  
>  *  #ifdef CONFIG_NET_SCHED
>  *  	__u16			tc_index;	/* traffic
>    control index */
> 
> 
> This is adding 32+1 bits to sk_buff, and possibly holes in this very
> very hot (and already too fat) structure.

I should have mentioned on the commit msg, but the tc_drop_if_late is actually
filling a 1 bit hole that was already there.


> 
> Do we really need 32 bits for a clockid_t ?

There is a 2 bytes hole just after tc_index, so a u16 clockid would fit
perfectly without increasing the skbuffs size / cachelines any further.

>From Richard's reply, it seems safe to just change the definition here if we
make it explicit on the SCM_CLOCKID documentation the caveat about the max
possible fd count for dynamic clocks.

How does that sound?

Thanks,
Jesus