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=-3.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 3D8F2C48BE8 for ; Sat, 19 Jun 2021 02:53:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 132DD61248 for ; Sat, 19 Jun 2021 02:53:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235256AbhFSCzK (ORCPT ); Fri, 18 Jun 2021 22:55:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234645AbhFSCzK (ORCPT ); Fri, 18 Jun 2021 22:55:10 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20E75C06175F for ; Fri, 18 Jun 2021 19:52:59 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id o88-20020a17090a0a61b029016eeb2adf66so9065070pjo.4 for ; Fri, 18 Jun 2021 19:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=8ig2KbLkNfZB9qEEyBrZcLTjZ1+b1zPHZ1SGxRMAjQc=; b=n6m29m6b5dCAFgH3xm7od+G0GMX4GLnWpm106q5u6knyCK2JpHr8Yj3ZVktqDlkoiZ ULXOedDjaoOWvo1z3vRlMuwWThkCvF8MIU9VnpA6cSuixdxqwhuuhXHahCjFg9ucZ+bH tWPs02z9AsRcrlLxgzLFoAgdXAKCtsY7jd4g/n+ZhMv53WXz0NcfQMbXdkdXfNWPdte7 M1PT2g0NkBxNmPbHLiHwymBJ/g2x6u3lvsNe2vMIc6NVd06ZPwzcDWM1aKqLrAvc6q0f VN6AH5r4rF+ohmPluXTzwtDrd0PmJMsEuUiukbY1iMQQJIflsHTQpLLHQM1+NmOKVRy2 r73w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8ig2KbLkNfZB9qEEyBrZcLTjZ1+b1zPHZ1SGxRMAjQc=; b=CyLlwYwpIc0oeJ210aA/XfdUwka7OfSapV80YKXBTP2q479Xeccx0d1gTHgRlSeGAl eZwLYHlpgeIVLNdtbtfHjyLHE/bg3xTizSBXFbzdjrhibqz+FbLkGjfLGluO58MUzr0M QHUq1nkl5cQHsMY3J5YZsCCGjwTwVm09oxMrFZrNAnttnz7dO2fN8cs+sOGDHZ1x6iKx lNu5OPXzsex29X3D1rE2NzeXW3UE02+atv/Okwhc+FCwNcyn4Lu1XJguMILPs9qicGBS BuDzoLJLUgstqSCuXEU24SGXVBIJefaa2ElxuyE5KqCXxqVo3z+KoFhn6nFXfvJ5lPlx OyzQ== X-Gm-Message-State: AOAM533N21V06Qev386W9row6J6xBx+uVA4PEBgGVsBw/hJzOEanCiPu 5w8HiiecHuYrhrWLLKQ6uK0= X-Google-Smtp-Source: ABdhPJxABOGPSB9I/bbJnveSi6g0bKjSjC49IqGgcmQxnyaj9/UyMkv5F16NZY+hJp6pDFY2WbWHMg== X-Received: by 2002:a17:90a:4490:: with SMTP id t16mr14563959pjg.193.1624071178679; Fri, 18 Jun 2021 19:52:58 -0700 (PDT) Received: from [10.1.1.25] (222-152-189-137-fibre.sparkbb.co.nz. [222.152.189.137]) by smtp.gmail.com with ESMTPSA id gd3sm11820342pjb.39.2021.06.18.19.52.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Jun 2021 19:52:58 -0700 (PDT) Subject: Re: [PATCH v2] m68k: save extra registers on more syscall entry points To: Linus Torvalds References: <1623979642-14983-1-git-send-email-schmitzmic@gmail.com> <91865b90-c597-6119-5e14-dfe521a33489@gmail.com> <2b2ba866-104c-afea-9c29-145e9d80c2d5@gmail.com> Cc: Geert Uytterhoeven , linux-arch , linux-m68k , "Eric W. Biederman" , Andreas Schwab From: Michael Schmitz Message-ID: Date: Sat, 19 Jun 2021 14:52:49 +1200 User-Agent: Mozilla/5.0 (X11; Linux ppc; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-m68k@vger.kernel.org Hi Linus, that one boots OK now, thanks (applied on top of mine but that should not matter). I'll run a test on the actual hardware once the previous one is done. Cheers, Michael Am 19.06.2021 um 14:13 schrieb Linus Torvalds: > On Fri, Jun 18, 2021 at 6:54 PM Linus Torvalds > wrote: >> >> The registers being zero at that point is actually expected, so that's >> not much of a hint. But yeah, clearly I got some stack initialization >> offset or something wrong there, and I don't know modern m68k nearly >> well enough to even guess where I screwed up. > > Oh. I think I might have an idea. > > In that ret_from_kernel_thread code, after it returns from thge kernel > thread, I did > > addql #4,%sp > RESTORE_SWITCH_STACK > jra ret_from_exception > > where that "RESTORE_SWITCH_STACK" loads the user space registers from > the user-space switch stack. > > BUT. > > The switch stack also has that "retpc", and that one should just be popped. > > So I think that code should read > > addql #4,%sp > RESTORE_SWITCH_STACK > addql #4,%sp > jra ret_from_exception > > because we want to restore the switch stack registers (they'll all be > 0) but we then want to get rid of retpc too before we jump to > ret_from_exception, which will do the RESTORE_ALL. > > (The first 'addql' is to remove the argument we've pushed on the stack > earlier in ret_from_kernel_thread, the second addql is to remove > retpc). > > All the *normal* uses of RESTORE_SWITCH_STACK will just do "rts", but > that's because they were called from the shallower stack. The > ret_from_kernel_thread case is kind of special, because it had that > stack frame layout built up manually, rather than have a call to it. > > In that sense, it's a bit more like the 'do_trace_entry/exit' code, > which builds that switch stack using > > subql #4,%sp > SAVE_SWITCH_STACK > > and then undoes it using that same > > RESTORE_SWITCH_STACK > addql #4,%sp > > sequence that I _should_ have done in ret_from_kernel_thread. (Also, > see ret_from_signal) > > I've attached an updated patch just in case my incoherent ramblings > above didn't explain what I meant. It's the same as the previous > patch, it just has that one extra stack update there. > > Does _this_ one perhaps work? > > Linus >