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:   Tue, 30 Apr 2019 11:17:32 +1000
From:   Stephen Mallon <stephen.mallon@...ney.edu.au>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
CC:     Richard Cochran <richardcochran@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>,
        "Stephen Mallon" <stephen.mallon@...ney.edu.au>
Subject: Re: [PATCH net] ipv4: Fix updating SOF_TIMESTAMPING_OPT_ID when
 SKBTX_HW_TSTAMP is enabled

On Mon, Apr 29, 2019 at 11:32:08AM -0400, Willem de Bruijn wrote:
> On Mon, Apr 29, 2019 at 11:02 AM Richard Cochran
> <richardcochran@...il.com> wrote:
> >
> > On Sun, Apr 28, 2019 at 10:57:57PM -0400, Willem de Bruijn wrote:
> > > It is debatable whether this is a fix or a new feature. It extends
> > > SOF_TIMESTAMPING_OPT_ID to hardware timestamps. I don't think this
> > > would be a stable candidate.
> >
> > Was the original series advertised as SW timestamping only?
> 
> I did not intend to cover hardware timestamps at the time.
> 
> > If so, I missed that at the time.  After seeing it not work, I meant
> > to fix it, but never got around to it.  So to me this is a known
> > issue.
> 
> Understood. I certainly understand that view. I never use hw
> timestamps, so it is a bit of a blind spot for me. If this is a safe
> and predictable change, I don't care strongly about net vs net-next. I
> don't think it meets the bar for stable, but that is not my call.

I've found that SOF_TIMESTAMPING_OPT_ID already works with hardware timestamps
for TCP just not datagram sockets and so I though this was a fix.

> > > More importantly, note that __ip6_append_data has similar logic. For
> > > consistency the two should be updated at the same time.
> >
> > +1
> >
> > Thanks,
> > Richard

Thanks for the feedback, I'll update with __ip6_append_data.

Powered by blists - more mailing lists