From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3674AC433B4 for ; Mon, 3 May 2021 23:48:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0297961244 for ; Mon, 3 May 2021 23:48:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229570AbhECXtW (ORCPT ); Mon, 3 May 2021 19:49:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229497AbhECXtV (ORCPT ); Mon, 3 May 2021 19:49:21 -0400 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6F77C06174A for ; Mon, 3 May 2021 16:48:26 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id c3so6574692lfs.7 for ; Mon, 03 May 2021 16:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8cxTD+RC9r0CXS9dr55V7a29XytNEKtivWFE6svy/UU=; b=KrSrP6H1kg0Ou7qIlA2hC/fEOBjjQfOdxSm1qFRBv7hG/LVf94xY1oTR/3v8qlxSNU Y5cJkh+yGLgafUhxEeFCJZpZ0CpYr0JoegHkOpGzvdxEaFsNlt8k0Dih/m8mzHTSjesG XgRhnzhg3g7Qy7Lf0CH85Q//wk+LxtHK1uwqw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8cxTD+RC9r0CXS9dr55V7a29XytNEKtivWFE6svy/UU=; b=JLdxxGM2nWhPr+CIlImGDxVwmRo4rk+dRySjQdVUt5lHPUISFFAqkiAtR7dw/oi/l6 tzJPmPpr0ucGQzajqnxR5Bs0nTkpNoo9jgWpZKkNEQW+NWcPjt8THYBlYvc4wZe0MiQz cW3R6+rX5wDFJVriyiaNqUHMasTLJWs5H1DRxhaYIi6DnWJbvmYNMvt1ykr0XXma3Aqb 1W+JFddGQsrE7m1TEDfbgb2flvqEuHCx9cEIkREhwgA4lL7UA4IokSLye04eSGpF6IWG pUGQNRZ+kezbv02ITrBb+TrXRZMjAU83n4Z6uDvswM+AkexNQjbSG9bRC/VzvfjXs8hV HZrg== X-Gm-Message-State: AOAM532MDGAYrkkzNB/oV6EQdFkR+7m/gq9SvzY1uyAZXqC7cBHZK5Vg SnsDTXiJCKVWtjQ/z4d49An396AScEuiY0LC X-Google-Smtp-Source: ABdhPJx/wlGjDXxXWjC4oqlahdm0Ctn9aAw3tWNXk2tMkulRWzM99hqHJJBcGGJcIOTFjqXBS8m3wQ== X-Received: by 2002:ac2:5a01:: with SMTP id q1mr10897359lfn.148.1620085705084; Mon, 03 May 2021 16:48:25 -0700 (PDT) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com. [209.85.208.170]) by smtp.gmail.com with ESMTPSA id r1sm46639ljj.21.2021.05.03.16.48.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 May 2021 16:48:23 -0700 (PDT) Received: by mail-lj1-f170.google.com with SMTP id b21so8913991ljf.11 for ; Mon, 03 May 2021 16:48:23 -0700 (PDT) X-Received: by 2002:a05:651c:3de:: with SMTP id f30mr344166ljp.251.1620085703543; Mon, 03 May 2021 16:48:23 -0700 (PDT) MIME-Version: 1.0 References: <8735v3ex3h.ffs@nanos.tec.linutronix.de> <3C41339D-29A2-4AB1-958F-19DB0A92D8D7@amacapital.net> <8735v3jujv.ffs@nanos.tec.linutronix.de> <12710fda-1732-ee55-9ac1-0df9882aa71b@samba.org> In-Reply-To: <12710fda-1732-ee55-9ac1-0df9882aa71b@samba.org> From: Linus Torvalds Date: Mon, 3 May 2021 16:48:07 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] io_thread/x86: don't reset 'cs', 'ss', 'ds' and 'es' registers for io_threads To: Stefan Metzmacher Cc: Thomas Gleixner , Andy Lutomirski , Jens Axboe , Linux Kernel Mailing List , io-uring , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Mon, May 3, 2021 at 4:27 PM Stefan Metzmacher wrote: > > If I remember correctly gdb showed bogus addresses for the backtraces of the io_threads, > as some regs where not cleared. Yeah, so that patch will make the IO thread have the user stack pointer point to the original user stack, but that stack will obviously be used by the original thread which means that it will contain random stuff on it. Doing a childregs->sp = 0; is probably a good idea for that PF_IO_WORKER case, since it really doesn't have - or need - a user stack. Of course, it doesn't really have - or need - any of the other user registers either, but once you fill in the segment stuff to make gdb happy, you might as well fill it all in using the same code that the regular case does. Linus