netdev - Re: [PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp support

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]

Date:	Wed, 06 Aug 2014 08:26:06 -0700
From:	Alexander Duyck <alexander.h.duyck@...el.com>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	Koehrer Mathias <mathias.koehrer@...s.com>,
	Nick Krause <xerofoify@...il.com>
CC:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp
 support

On 08/06/2014 08:21 AM, Alexander Duyck wrote:
> On 08/06/2014 08:09 AM, Henrique de Moraes Holschuh wrote:
>> On Wed, Aug 6, 2014, at 11:30, Sergei Shtylyov wrote:
>>> On 8/6/2014 6:27 PM, Koehrer Mathias (ETAS/ESW5) wrote:
>>>
>>>> With the Intel 82527EI (driver: e1000e) there is an issue when running
>>>> the ptpd2 program, that leads to a kernel oops.
>>>> The reason is here that in e1000_xmit_frame() a work queue will be
>>>> scheduled that has not been initialized in this case.
>>>> The work queue "tx_hwstamp_work" will only be initialized if
>>>> adapter->flags & FLAG_HAS_HW_TIMESTAMP set.
>>>> This check is missing in e1000_xmit_frame().
>>>
>>>> The following patch adds the missing check.
>>>
>>>     OK, but this time you forgot your sign-off. :-)
>>
>> Also, shouldn't the added test be inside the unlikely() ?
>>
> 
> That shouldn't be necessary, but it might be better to place the new
> check after the unlikely.  So you do the unlikely check first, then the
> adapter check to see if we support Tx timestamping.  That way we can
> avoid any unnecessary checks in the adapter structure.
> 
> Thanks,
> 
> Alex
> 


Actually you might want to even take it one step further and break out
the test as follows (note this is only pseudo-code:
  unlikely(skb->tx_flags & HW_TSTAMP) &&
  (adapter->flags & HAS_HW_TSTAMP) &&
  !adapter->tx_hwtstamp_skb

There isn't much point in wrapping the entire statement in unlikely, by
wrapping just the first test the rest of the conditional checks can be
pushed into the branch which will likely require a jump to some remote
block of code and should streamline the hot-path.

Thanks,

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