linux-kernel - Re: [PATCH] Document that PF_KTHREAD _is

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5992461c-1aad-3ba4-47d6-4dad10b6903a@samba.org>
Date:   Thu, 1 Apr 2021 17:05:20 +0200
From:   Stefan Metzmacher <metze@...ba.org>
To:     Alexey Dobriyan <adobriyan@...il.com>,
        Christoph Hellwig <hch@...radead.org>,
        Jens Axboe <axboe@...nel.dk>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>, fw@...eb.enyo.de,
        io-uring <io-uring@...r.kernel.org>
Subject: Re: [PATCH] Document that PF_KTHREAD _is_ ABI


Am 31.03.21 um 21:23 schrieb Alexey Dobriyan:
> On Mon, Mar 22, 2021 at 07:53:10AM +0000, Christoph Hellwig wrote:
>> On Sat, Mar 20, 2021 at 10:23:12AM -0700, Andy Lutomirski wrote:
>>>> https://github.com/systemd/systemd/blob/main/src/basic/process-util.c#L354
>>>> src/basic/process-util.c:is_kernel_thread()
>>>
>>> Eww.
>>>
>>> Could we fix it differently and more permanently by modifying the proc
>>> code to display the values systemd expects?
>>
>> Yes, do_task_stat needs a mapping from kernel flags to UABI flags.  And
>> we should already discard everything we think we can from the UABI
>> now, and only add the ones back that are required to not break
>> userspace.
> 
> Sure we do. Who is going to find all the flags? I found PF_KTHREAD. :^)
> 
> More seriously,
> 
> /proc/$pid/stat was expanded to include tsk->flags in 0.99.1 (!!!)
> 
> Developers kept adding and shuffling flags probably not even realising
> what's going on. The last incident happened at 5.10 when PF_IO_WORKER
> was exchanged with PF_VCPU for smaller codegen.

With the create_io_thread(), the impact of PF_IO_WORKER becomes more broadly
visible and userspace might start to look at it in order to find the difference
between userspace and kernel io threads. (I also think it should actually be renamed to
PF_IO_THREAD...)

Jens, what do you think about that?

metze