Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v2] io_thread/x86: setup io_threads more like normal user
 space threads
To:     Stefan Metzmacher <metze@samba.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@kernel.org>,
        linux-kernel@vger.kernel.org, io-uring@vger.kernel.org,
        x86@kernel.org
References: <20210411152705.2448053-1-metze@samba.org>
 <20210505110310.237537-1-metze@samba.org>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <df4b116a-3324-87b7-ff40-67d134b4e55c@kernel.dk>
Date:   Wed, 5 May 2021 15:24:18 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20210505110310.237537-1-metze@samba.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/5/21 5:03 AM, Stefan Metzmacher wrote:
> As io_threads are fully set up USER threads it's clearer to
> separate the code path from the KTHREAD logic.
> 
> The only remaining difference to user space threads is that
> io_threads never return to user space again.
> Instead they loop within the given worker function.
> 
> The fact that they never return to user space means they
> don't have an user space thread stack. In order to
> indicate that to tools like gdb we reset the stack and instruction
> pointers to 0.
> 
> This allows gdb attach to user space processes using io-uring,
> which like means that they have io_threads, without printing worrying
> message like this:
> 
>   warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386
> 
>   warning: Architecture rejected target-supplied description
> 
> The output will be something like this:
> 
>   (gdb) info threads
>     Id   Target Id                  Frame
>   * 1    LWP 4863 "io_uring-cp-for" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
>     2    LWP 4864 "iou-mgr-4863"    0x0000000000000000 in ?? ()
>     3    LWP 4865 "iou-wrk-4863"    0x0000000000000000 in ?? ()
>   (gdb) thread 3
>   [Switching to thread 3 (LWP 4865)]
>   #0  0x0000000000000000 in ?? ()
>   (gdb) bt
>   #0  0x0000000000000000 in ?? ()
>   Backtrace stopped: Cannot access memory at address 0x0

I have queued this one up in the io_uring branch, also happy to drop it if
the x86 folks want to take it instead. Let me know!

-- 
Jens Axboe