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]

Message-Id: <200807250214.11298.opurdila@ixiacom.com>
Date:	Fri, 25 Jul 2008 02:14:11 +0300
From:	Octavian Purdila <opurdila@...acom.com>
To:	David Miller <davem@...emloft.net>
Cc:	herbert@...dor.apana.org.au, netdev@...r.kernel.org
Subject: Re: [RFC][PATCH 1/3] net: per skb control messages

On Friday 25 July 2008, David Miller wrote:
> From: Octavian Purdila <opurdila@...acom.com>
> Date: Fri, 25 Jul 2008 01:12:03 +0300
>
> > On Friday 25 July 2008, David Miller wrote:
> > > We have a timestamp in the SKB already, why don't you simply override
> > > it when your feature is enable and set a single flag bit that
> > > indicates you used a HW timestamp to set that timestamp?
> >
> > I thought of something similar, but I am not sure if I can to so, as it
> > seems that the skb->tstamp requires current gettimeofday semantics at
> > least in netfilter's ipt_time module.
>
> Can your timestamp format at least be converted to
> gettimeofday() format?
>
> I thought we had a ton of accessor functions that code uses to access
> the timestamp?  You should be able to do your translation in those
> routines.

Sure but the problem is that the NIC hw timestamp is not synced with the CPU 
time. In that case I think that the netfilter rules which are looking at the 
timestamp will be messed up.

[ 
A bit of general context about this annoying hw timestamp thing I keep 
bringing up  here:) 

I know that this is a very specific thing and there is probably not a clean 
solution to this and we will probably have to go with an in internal patch 
approach. 

But the thing is that we accumulated a lot such internal patches to the point 
that makes it very hard to upgrade and track a recent Linux version. And I 
feel that we need to stop adding new stuff in this pile, otherwise we will 
not be able to keep up.

Thus my fixation with this very specific and not so significant thing in the 
great Linux ecosystem. Probably I just chosen the wrong patch to battle. 
]

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