netdev - Re: [net-next 5/7] ixgbe: protect TX timestamping from API misuse

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] [day] [month] [year] [list]

Message-ID: <1d1008bf581260ef00704f45ad062681b9736ddc.camel@intel.com>
Date:   Mon, 04 Nov 2019 13:15:07 -0800
From:   Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     davem@...emloft.net,
        Manjunath Patil <manjunath.b.patil@...cle.com>,
        netdev@...r.kernel.org, nhorman@...hat.com, sassmann@...hat.com,
        Andrew Bowers <andrewx.bowers@...el.com>
Subject: Re: [net-next 5/7] ixgbe: protect TX timestamping from API misuse

On Mon, 2019-11-04 at 11:53 -0800, Jakub Kicinski wrote:
> On Sat,  2 Nov 2019 05:14:15 -0700, Jeff Kirsher wrote:
> > From: Manjunath Patil <manjunath.b.patil@...cle.com>
> > 
> > HW timestamping can only be requested for a packet if the NIC is
> > first
> > setup via ioctl(SIOCSHWTSTAMP). If this step was skipped, then the
> > ixgbe
> > driver still allowed TX packets to request HW timestamping. In this
> > situation, we see 'clearing Tx Timestamp hang' noise in the log.
> > 
> > Fix this by checking that the NIC is configured for HW TX
> > timestamping
> > before accepting a HW TX timestamping request.
> > 
> > similar-to:
> >        (26bd4e2 igb: protect TX timestamping from API misuse)
> >        (0a6f2f0 igb: Fix a test with HWTSTAMP_TX_ON)
> 
> This is not a correct way to quote a commit. Please use checkpatch.

Just an FYI, checkpatch.pl does not complain about the above commit id
references.

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)