linux-kernel - Re: Splat in kernel RT while processing incoming network 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] [day] [month] [year] [list]

Date:   Wed, 9 Aug 2023 12:56:23 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Wander Lairson Costa <wander@...hat.com>
Cc:     Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org,
        linux-rt-users@...r.kernel.org, juri.lelli@...hat.com
Subject: Re: Splat in kernel RT while processing incoming network packets

On 2023-07-05 12:59:28 [-0300], Wander Lairson Costa wrote:
> Maybe, under RT, some softirq should run in the context of the "target"
> process. For NET_RX, for example, the softirq's would run in the context
> of the packet recipient process. Each task_struct would have a list of
> pending softirq, which would be checked in a few points, like on scheduling,
> when the process enters in the kernel, softirq raise, etc. The default
> target process would be ksoftirqd. Does this idea make sense?

We had something similar. The softirq runs in the context of the task
that raised it. So the networking driver raised NET_RX and it was
processed in its context (and still is). The only difference now is that
we no longer have a task based "raised bit" but a per-CPU.

For RPS you already pulled the skb from the NIC, you need to process it
and this isn't handled in the task's context but on a specific CPU.

Let me look at per-CPU backlog thread or ripping the warning out…

Sebastian