netdev - Re: [RFC][PATCH 1/3] net: per skb control messages

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:	Thu, 24 Jul 2008 19:22:57 +0300
From:	Octavian Purdila <opurdila@...acom.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC][PATCH 1/3] net: per skb control messages

On Thursday 24 July 2008, Herbert Xu wrote:

> > From what I understand, the shinfo remains shared, thus there is no need
> > to do the copy here.
>
> No pskb_copy does a full copy on the head portion of the packet
> which is where your cmsg is.
>
> > > Also what about pskb_expand_head?
> >
> > I think this is only touching the skb header, not the shinfo. Thus we
> > should be safe?
>
> But you're freeing the cmsg in skb_release_data which is called
> by pskb_expand_head.  This can't possibly work.

Right, I've missed the fact that skb_shinfo is stored in the header part. 

> Do we need to make it so generic? If we do then can you please
> come up with other uses for it too.  For example, find out what
> existing fields can be better suited by storing them as a cmsg.
> Only then can we design this properly.

It looks like we can switch a few members from the skb to cmsg: secmark, 
priority, tstamp, thus saving some space in the skb, but we will have a 
performance overhead for accessing these since we now have to search for them 
in the cmesg list.

So, the more I think about this the more I am inclined to think that we don't 
really need it. For our hw timestamp usecases, the reason of this patch, we 
can get away by adding these new fields in the skb:

u16 flags; /* request / signal presence of RX/TX hw stamps, TX scheduling, TX 	
		    embed hw timestamp in packet */
u8 hwstamp[6];

and of course the mechanism of enabling hw stamps requests on per skb, with 
msghdr.msg_control stuff. 

Would that be acceptable (with proper CONFIG_HW_TSTAMPS of course)?

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