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.8 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 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 02FB7C48BDF for ; Fri, 18 Jun 2021 17:18:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D94A9613E9 for ; Fri, 18 Jun 2021 17:18:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233869AbhFRRU1 (ORCPT ); Fri, 18 Jun 2021 13:20:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233680AbhFRRU1 (ORCPT ); Fri, 18 Jun 2021 13:20:27 -0400 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9458C061574 for ; Fri, 18 Jun 2021 10:18:16 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id a21so10026142ljj.1 for ; Fri, 18 Jun 2021 10:18:16 -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=nBnuJCjQE+aAZPwJSd9bJXr2Ds6ZThaAzMpjQA51kUI=; b=F1P+lKociosdfPcWBId6Ys43KUatGPrylEYc2ZkgaQSaIwYVTH2vl+FTSZsWUNtS2S xCB0wytuIkmaIt/KIgw7pVq9/rGNTKHWukrdulsisjI9kiH2RhIFD/Maq8/t/3Zc/+yP OBhR+UrWjvPrDLgpXfflpIry4l57W+y+y6Jd0= 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=nBnuJCjQE+aAZPwJSd9bJXr2Ds6ZThaAzMpjQA51kUI=; b=jD6P5dnzzg1kkZDAjq8jvQe4IIr4alSmWimiW2onB7qoHYGMvMYTkJoM1vYfAoJuWU YdBCNNB2/O1zAt4I7kJG6kNzjGkSvAG1KCdl+xNGp4kdyQ2eByy1rA4reGKHQpl3i5NS rWXpF2c2M+MmoEfbPrgTnryQU5QHiNs0wbvsehhCocgtlRSa/ehqhQwKFKA5uzZ+RFsz U4cUPjoj58VUJmV6UGxkonN+p+IVf8jPa3kjjCkudQgE6K8WomTN+lFxxE70DDm7oSAg ve/OwffeyHvvIUxsIrn/9xNUaPc0Unifa9bwSTA1pluOKSBk9A8QRqTbk6TOxQTQnXfk Vvhw== X-Gm-Message-State: AOAM530c3dK+RdhK9kGp6Uyh3pd6AAOUZIaBsINPg/JJ8uVGR0AMecd5 lR06qrtt14S+kVr8J7WOfnYVatsTqjUzmbq4 X-Google-Smtp-Source: ABdhPJwHfYKjCUQxqGkSXNBmGpK51x7FHLGlsptGRheCIXglXqMvDc70yUHywuNbH2hCuexZCNUUbg== X-Received: by 2002:a2e:b163:: with SMTP id a3mr7303226ljm.147.1624036694510; Fri, 18 Jun 2021 10:18:14 -0700 (PDT) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com. [209.85.208.178]) by smtp.gmail.com with ESMTPSA id c5sm963353lfv.117.2021.06.18.10.18.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Jun 2021 10:18:14 -0700 (PDT) Received: by mail-lj1-f178.google.com with SMTP id d13so14934686ljg.12 for ; Fri, 18 Jun 2021 10:18:13 -0700 (PDT) X-Received: by 2002:a2e:2ac6:: with SMTP id q189mr10211514ljq.61.1624036693648; Fri, 18 Jun 2021 10:18:13 -0700 (PDT) MIME-Version: 1.0 References: <1623979642-14983-1-git-send-email-schmitzmic@gmail.com> In-Reply-To: <1623979642-14983-1-git-send-email-schmitzmic@gmail.com> From: Linus Torvalds Date: Fri, 18 Jun 2021 10:17:57 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] m68k: save extra registers on more syscall entry points To: Michael Schmitz Cc: Geert Uytterhoeven , linux-arch , linux-m68k , "Eric W. Biederman" , Andreas Schwab Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-m68k@vger.kernel.org On Thu, Jun 17, 2021 at 6:27 PM Michael Schmitz wrote: > > I'd need specific test cases to exercise io_uring_setup in > particular, to see whether stack offsets for pt_regs and the > switch stack have been messed up. I don't think doing this for io_uring_setup() will help any - the problem is not in that system call thread itself, it's purely in the kernel thread that it then starts. And the fact that io_uring_setup() has the full stack frame won't then help that kernel thread, for exactly the same reason that was true on alpha: copy_thread() will actually _create_ the full stack, but when we switch to it (through switch_to() -> resume()), the resume code in arch/m68k/kernel/entry.S will switch to that stack, and then do RESTORE_SWITCH_STACK which will consume it again. So I think m68k should do the same thing as Eric's patch for alpha: do the full stack for exit and exit_group, and for kernel thread creation - or at least PF_IO_WORKER), do an extra stack frame on the kernel stack, so that even after resume() we'll still have another copy of the frame. The alternative would be to do what x86 does: see __switch_to_asm(). Instead of doing that normal kernel entry/exit stack (with SAVE_SWITCH_STACK and RESTORE_SWITCH_STACK), x86 has it's own very special "only for task switching" stack frame thing, and leaves the pt_regs etc entirely alone. Of course, that "only for task switching" is _kind_of_ what the whole SAVE_SWITCH_STACK is for - it's part of the name after all - but the difference is that on alpha and m68k, it's also (and primarily) the "full state" stack frame, used not just for task switching, but for signal handling state and for ptrace too. So in theory, it would be good to split this up: (a) have the signal handling and ptrace stack be one thing (maybe rename the "SWITCH" part of the operations to something else, like "EXTRA" or "SIGNAL" or whatever) (b) make a separate "for task switching only" stack frame, which is used by that switch_to() -> resume() sequence, and that copy_thread() has a "struct inactive_task_frame" thing for.. That way, the pt_regs/extra_regs stack frame that copy_thread() creates wouldn't then be eaten up by the task switch. But while that sounds like the right thing to do, it would be a rather bigger change. I'm not entirely sure it's worth it. Eric, comments? Linus