netdev - Re: [EXT] [PATCH V2] bnx2x: Prevent ptp_task to be rescheduled indefinitely

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: <CAHD1Q_wzNDnzStrbjng8CFx3jHhjAYqyr04OGzZGJ2SisY2VCQ@mail.gmail.com>
Date:   Wed, 26 Jun 2019 17:24:08 -0300
From:   Guilherme Piccoli <gpiccoli@...onical.com>
To:     Sudarsana Reddy Kalluru <skalluru@...vell.com>
Cc:     "jay.vosburgh@...onical.com" <jay.vosburgh@...onical.com>,
        GR-everest-linux-l2 <GR-everest-linux-l2@...vell.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Ariel Elior <aelior@...vell.com>
Subject: Re: [EXT] [PATCH V2] bnx2x: Prevent ptp_task to be rescheduled indefinitely

On Wed, Jun 26, 2019 at 5:25 AM Sudarsana Reddy Kalluru
<skalluru@...vell.com> wrote:
> > Sudarsana, let me ask you something: why does the register is reading value
> > 0x0 always in the TX timestamp routine if the RX filter is set to None? This is
> > the main cause of the thread reschedule thing.
>
> The register value of zero indicates there is no pending Tx timestamp to be read by the driver.
> FW writes/latches the Tx timestamp for PTP event packet in this register. And it does the latching only if the register is free.
> In this case user/app look to be requesting  the Timestamp (via skb->tx_flags) for non-ptp Tx packet. In the Tx path, driver schedules a thread for reading the Tx timestamp,
>    bnx2x_start_xmit()
>    {
>         if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP))
>                         schedule_work(&bp->ptp_task);
>    }
> FW seem to be not timestamping the packet at all and driver is indefinitely waiting for it.
>

Thanks Sudarsana! I've tried to implement the qede-like approach
again, with the 2s timeout before
bailing-out the thread reschedule. This time, I've remove _all_log
messages, including the DP() ones...
Unfortunately kthread is still consuming 100% of CPU, which makes
sense, since it reschedules itself
the most times it can in this 2s window...I think we really should
have small pauses before retrying to
read the registers. I've worked a V3, implementing 1ms-starting
pauses, which worked well:
https://marc.info/?l=linux-netdev&m=156158032618932

I hope this way we don't harm the PTP applications, nor introduce
delays in the FW wait-queue,
and at same time we can fix the indefinitely reschedule in bnx2x.
Thanks again for your support,

Guilherme