netdev - Re: [PATCH net-next 2/4] tsnep: Fix rotten packets

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: <5fefbc3d-c83b-d628-e660-15abfa596b1b@engleder-embedded.com>
Date:   Fri, 18 Nov 2022 07:13:34 +0100
From:   Gerhard Engleder <gerhard@...leder-embedded.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        edumazet@...gle.com, pabeni@...hat.com
Subject: Re: [PATCH net-next 2/4] tsnep: Fix rotten packets

On 17.11.22 21:39, Andrew Lunn wrote:
> On Thu, Nov 17, 2022 at 09:14:38PM +0100, Gerhard Engleder wrote:
>> If PTP synchronisation is done every second, then sporadic the interval
>> is higher than one second:
>>
>> ptp4l[696.582]: master offset        -17 s2 freq   -1891 path delay 573
>> ptp4l[697.582]: master offset        -22 s2 freq   -1901 path delay 573
>> ptp4l[699.368]: master offset         -1 s2 freq   -1887 path delay 573
>>        ^^^^^^^ Should be 698.582!
>>
>> This problem is caused by rotten packets, which are received after
>> polling but before interrupts are enabled again.
> 
> Is this a hardware bug? At the end of the interrupt coalescence
> period, should it not check the queue and fire an interrupt?

In my case, the hardware is not signaled if a descriptor is processed by
the software. The hardware is only signaled if it gets new descriptors
assigned. So the hardware does not know if there are still descriptors
in the RX queue which need to be processed by the software. As a result,
it would only be possible to trigger an interrupt for descriptors which
may has been processed already anyway.

In the end I made the hardware stupid. If interrupts are disabled for
NAPI polling, then interrupts events in the hardware are ignored. If
interrupts are enabled again, then only new interrupt events will
trigger the interrupt. I was afraid that too intelligent hardware will
lead to hardware bugs in this case.

Gerhard