netdev - Re: [PATCH v3 net 4/4] pds_core: make wait_context part of q

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: <917a9476-b499-48da-8702-8b2415bae00a@amd.com>
Date: Fri, 18 Apr 2025 15:31:25 -0700
From: "Nelson, Shannon" <shannon.nelson@....com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: andrew+netdev@...n.ch, brett.creeley@....com, davem@...emloft.net,
 edumazet@...gle.com, pabeni@...hat.com, michal.swiatkowski@...ux.intel.com,
 horms@...nel.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v3 net 4/4] pds_core: make wait_context part of q_info

On 4/17/2025 8:21 AM, Jakub Kicinski wrote:
> 
> On Tue, 15 Apr 2025 16:29:31 -0700 Shannon Nelson wrote:
>> Make the wait_context a full part of the q_info struct rather
>> than a stack variable that goes away after pdsc_adminq_post()
>> is done so that the context is still available after the wait
>> loop has given up.
>>
>> There was a case where a slow development firmware caused
>> the adminq request to time out, but then later the FW finally
>> finished the request and sent the interrupt.  The handler tried
>> to complete_all() the completion context that had been created
>> on the stack in pdsc_adminq_post() but no longer existed.
>> This caused bad pointer usage, kernel crashes, and much wailing
>> and gnashing of teeth.
> 
> The patch will certainly redirect the access from the stack.
> But since you're already processing the completions under a spin
> lock, is it not possible to safely invalidate the completion
> under the same lock on timeout?
> 
> Perhaps not I haven't looked very closely.

We have another patch under consideration that does something like this, 
but we're not sure we're happy with that patch yet, so haven't pushed it 
out yet.

> 
>> +     wc = &pdsc->adminqcq.q.info[index].wc;
>> +     wc->wait_completion = COMPLETION_INITIALIZER_ONSTACK(wc->wait_completion);
> 
> _ONSTACK you say? I don't think it's on the stack any more.

This worked, but digging a little further through other examples I see 
how we can more correctly use init_completion() and reinit_completion().

sln