Re: PF_USER_WORKERs and shadow stack

[Dave Hansen <dave.hansen@intel.com>]

On 8/13/25 12:14, Oleg Nesterov wrote:
> On 08/13, Dave Hansen wrote:
>> On 8/13/25 09:28, Oleg Nesterov wrote:
>>> But it seems that if a features_enabled(ARCH_SHSTK_SHSTK) thread creates a
>>> PF_USER_WORKER thread, shstk_alloc_thread_stack() will allocate the shadow
>>> stack for no reason.
>> Is this costing us anything other than some CPU cycles and 160 bytes of
>> memory for a VMA?
> Well, I guess no, but I do have another reason for "something-like-this" cleanup.
> I am working on other changes which should eliminate x86_task_fpu(PF_USER_WORKER).
> Hopefully I'll send the patches tomorrow. To remind, see
> https://lore.kernel.org/all/20250812125700.GA11290@redhat.com/

Yep, I assumed the efforts were connected.

> So I'd like to ensure that ssp_active() can't return T in ssp_get().
> 
> And... Dave, I understand that it is very easy to criticize someone else's code 😉
> But - if I am right - the current logic doesn't look clean to me. Regardless.

Hey, I'm all for having "clean" code. But if we're going to add
complexity (aka. code) to the kernel, we should know what it's getting
us other than "cleanliness".

BTW, how many PF_USER_WORKER threads _are_ there out there? I wouldn't
have thought that they were prevalent enough to justify much of an
effort here.