netdev - Re: hardware time stamping with extra skb->hwtstamp

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: <200811281800.09870.opurdila@ixiacom.com>
Date:	Fri, 28 Nov 2008 18:00:09 +0200
From:	Octavian Purdila <opurdila@...acom.com>
To:	Oliver Hartkopp <oliver@...tkopp.net>
Cc:	Patrick Ohly <patrick.ohly@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: hardware time stamping with extra skb->hwtstamp

From: Oliver Hartkopp <oliver@...tkopp.net>
Date: Fri, 28 Nov 2008 16:38:16 +0100


> Do you know what all the people are doing with skbuffs in the kernel?
> I'm not aware of it.
> So whenever we touch a vital data structure like the skbuff we must be
> sure that our handling is a wise approach for all.

I agree. But what in this approach do you think its not wise? :)

The skb is not touched at all, we just need to allocate a larger skb when 
using hw timestamps (or other extensions) and reserve some portion of it. 

> Btw. your answer brought me to a completely different approach:
>
> What about just creating a new pointer in the struct skbuff that points
> to a struct hwstamp when it is available OR the pointer is NULL when no
> hwstamps are available.
> This struct hwstamp may consist of 'everthing we really need for
> timestamping' and is added somewhere at the head or the tail of the
> skbuff data section by the device driver.
> And if the socket sees this pointer to be not NULL it knows where to
> look for our fancy struct hwstamp ...
>
> I don't know, where this hwstamp data could be pasted into the data
> section in the best way - but surely others know. Especially this
> approach meets the requirement that the additional hwstamp data is only
> allocated (per interface!), when it's really needed - and not for
> everyone by default.
>
> What do you thing about this idea?
>

That is still adding a member into the skb. For what I am proposing we don't 
have to touch the skb and it has all of your approach benefits. 

I would rather use this approach since it allows us to "extend" the skb in 
this manner int the future for other hardware features which requires passing 
per-skb information to userspace.

Thanks,
tavi




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