linux-kernel - Re: fuse uring / wake

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: <1b3ca0e3-cabf-a783-7bde-5bc6d51890fc@ddn.com>
Date:   Mon, 27 Mar 2023 14:35:28 +0000
From:   Bernd Schubert <bschubert@....com>
To:     K Prateek Nayak <kprateek.nayak@....com>,
        Hillf Danton <hdanton@...a.com>
CC:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Miklos Szeredi <miklos@...redi.hu>,
        Amir Goldstein <amir73il@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrei Vagin <avagin@...gle.com>
Subject: Re: fuse uring / wake_up on the same core

On 3/25/23 08:08, K Prateek Nayak wrote:
> [You don't often get email from kprateek.nayak@....com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hello Hillf,
> 
> On 3/25/2023 5:58 AM, Hillf Danton wrote:
>> On 24 Mar 2023 22:44:16 +0000 Bernd Schubert <bschubert@....com>
>>> How much of hack is this patch?
>>
>> It adds a churn to my mind then another RFC [1] rises.
>>
>> Feel free to make it work for you and resend it.
>>
>> [1] Subject: [RFC PATCH 0/5] sched: Userspace Hinting for Task Placement
>>      https://lore.kernel.org/lkml/20220910105326.1797-1-kprateek.nayak@amd.com/
> 
> Thank you for pointing to my series.
> 
> Another possible way to tackle this is with a strategy Andrei is using in
> his "seccomp: add the synchronous mode for seccomp_unotify" series
> (https://lore.kernel.org/lkml/20230308073201.3102738-1-avagin@google.com/)
> 
> In patch 2, Andrei adds a WF_CURRENT_CPU that allows the task to always
> wake on the CPU where the waker is running.
> (https://lore.kernel.org/lkml/20230308073201.3102738-3-avagin@google.com/)
> 
> I believe Bernd's requirement calls for a a WF_PREV_CPU which always
> wakes up the task on the CPU where it previously ran. I believe you can
> modify fuse_request_end() (in fs/fuse/dev.c) to use the WF_PREV_CPU flag
> when waking the tasks on req->waitq
> 
> (P.S. I'm not familiar with the fuse subsystem but the comment
> "Wake up waiter sleeping in request_wait_answer()" in fuse_request_end()
> seems to suggest that is the right place to add this flag.)
> 
> Peter favored wake flag strategy of fixing wakeup target in a reply to an
> earlier version of Andrei's series
> (https://lore.kernel.org/lkml/Y8UgBnsaGDUJKH5A@hirez.programming.kicks-ass.net/)
> but I'll let Peter respond with what he thinks is the right way to tackle
> this.
> 

Thanks Hillf, Prateek and Peter! I'm going right now through Andrei's 
(will also check Prateek patches later). On the first glance 
WF_CURRENT_CPU is exactly what I need. At least for fuse/uring no need 
for another 'WF_PREV_CPU' flag - it goes and comes back to/from the ring 
on 'current' cpu and only switches on the final completion - staying on 
the current cpu is all we need. Will test these patches later today.


Thanks again,
Bernd