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=-9.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 519CAC636C8 for ; Tue, 20 Jul 2021 22:17:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2E6E66120A for ; Tue, 20 Jul 2021 22:17:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230233AbhGTVgj (ORCPT ); Tue, 20 Jul 2021 17:36:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234525AbhGTVge (ORCPT ); Tue, 20 Jul 2021 17:36:34 -0400 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C19A8C061768 for ; Tue, 20 Jul 2021 15:16:11 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id j3so12128955plx.7 for ; Tue, 20 Jul 2021 15:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=HMP4hOg3SpK+nsKtMUngLG5eW2U79IIKIlymfzgnAXs=; b=hXUjgTVkiGDcwRj0K05Ze1rB4fS2Tk8YOBWplqcHc/RigtxHWeA743PNhvx6dnYMnq ePnWoKM6/hjh5nXSS3yKHnFlNiJLuAE4xb8Htd8G9e+81G51Mjc4yqzSsIlpLz2puMfs CiUSQEsh4GELOi0RKKxG4HvBpzIZC6HC4D9Ozk+T7oJ3R9lVK9+z29LKinq9yhF2M1UE tHL6vkX40Xx2LPjW287pN5LNzoTHQ5KB0KrDi46QPn0J89XdTc7CxqXavBkDzKGMm0nR OYDWlh8tkedWHon/t845oVJx/81lHguh5HVyzz8ifyZnJgP9sutebEgpV4x2fkNlz/fU cQqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=HMP4hOg3SpK+nsKtMUngLG5eW2U79IIKIlymfzgnAXs=; b=uI5TIDDCLw68A0Js8ueVY/KcR8kpXWFHBXjDKqMBy92Yh9VtDIO1uldnveBgDnJAt3 q3g9YDXypSzUx49dwT0dVINWyrzOWD2pSt/oj7NECeCzzZZr/qbYD6JdUU16oCtrY//q AsyEsIh0DgS4fLBzubi+3ZgZb5abJs7iVV7dAZFW6iVvHVsTxrC5Vgvz7cV+uYRj08Q4 8L0LOZWGhe789i+piR/7i+WV5xABESLRZ+mtnBcND8jxyfC1rJLkBaPpymvgJsDWlg9u xLrs3A32wTWs15uZzj8z9nN99XZcaaYDLPHOyoJakZvnZ3vV9E1x7Qr1ZgsPlS5jzSXv Yc9g== X-Gm-Message-State: AOAM533dMP25a6oUfcp9ce83CvyVZOyUhqbhj2vcA6ZJAsLkPgxi0KEt FtfOgs/gG7IeXNId8pkmUyY= X-Google-Smtp-Source: ABdhPJwEPgQZE7JpUgmFjH+qkNOCJb48z+MSJu0/zjqro44n6IkH2fjA3vP8tuRIgejRIs6b0U8zqw== X-Received: by 2002:a17:90a:2906:: with SMTP id g6mr31523081pjd.100.1626819370838; Tue, 20 Jul 2021 15:16:10 -0700 (PDT) Received: from ?IPv6:2001:df0:0:200c:9497:db03:a72f:4a88? ([2001:df0:0:200c:9497:db03:a72f:4a88]) by smtp.gmail.com with ESMTPSA id s36sm12519531pgl.8.2021.07.20.15.16.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jul 2021 15:16:10 -0700 (PDT) Subject: Re: [PATCH v4 0/3] m68k: Improved switch stack handling To: "Eric W. Biederman" Cc: geert@linux-m68k.org, linux-arch@vger.kernel.org, linux-m68k@lists.linux-m68k.org, torvalds@linux-foundation.org, schwab@linux-m68k.org References: <1624407696-20180-1-git-send-email-schmitzmic@gmail.com> <87zgunzovm.fsf@disp2133> <3b4f287b-7be2-0e7b-ae5a-6c11972601fb@gmail.com> <1b656c02-925c-c4ba-03d3-f56075cdfac5@gmail.com> <8735scvklk.fsf@disp2133> <87h7gopvz2.fsf@disp2133> From: Michael Schmitz Message-ID: <328e59fb-3e8c-e4cd-06b4-1975ce98614a@gmail.com> Date: Wed, 21 Jul 2021 10:16:05 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87h7gopvz2.fsf@disp2133> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-m68k@vger.kernel.org Hi Eric, On 21/07/21 8:32 am, Eric W. Biederman wrote: > >> diff --git a/arch/m68k/fpsp040/skeleton.S b/arch/m68k/fpsp040/skeleton.S >> index a8f4161..6c92d38 100644 >> --- a/arch/m68k/fpsp040/skeleton.S >> +++ b/arch/m68k/fpsp040/skeleton.S >> @@ -502,7 +502,17 @@ in_ea: >> .section .fixup,#alloc,#execinstr >> .even >> 1: >> + >> + SAVE_ALL_INT >> + SAVE_SWITCH_STACK > ^^^^^^^^^^ > > I don't think this saves the registers in the well known fixed location > on the stack because some registers are saved at the exception entry > point. The FPU exception entry points are not using the exception entry code in head.S. These entry points are stored in the exception vector table directly. No saving of a syscall stack frame happens there. The FPU places its exception frame on the stack, and that is what the FPU exception handlers use. (If these have to call out to the generic exception handlers again, they will build a minimal stack frame, see code in skeleton.S.) Calling fpsp040_die() is no different from calling a syscall that may need to have access to the full stack frame. The 'fixed location' is just 'on the stack before calling  fpsp040_die()', again this is no different from calling e.g. sys_fork() which does not take a pointer to the begin of the stack frame as an argument. I must admit I never looked at how do_exit() figures out where the stack frame containing the saved registers is stored, I just assumed it unwinds the stack up to the point where the caller syscall was made, and works from there. The same strategy ought to work here. > > Without being saved at the well known fixed location if some process > stops in PTRACE_EVENT_EXIT in do_exit we likely get some complete > gibberish. > > That is probably safe. > >> jbra fpsp040_die >> + addql #8,%sp >> + addql #8,%sp >> + addql #8,%sp >> + addql #8,%sp >> + addql #8,%sp >> + addql #4,%sp >> + rts > Especially as everything after jumping to fpsp040_die does not execute. Unless we change fpsp040_die() to call force_sig(SIGSEGV). Cheers,     Michael > > Eric > > >> >> .section __ex_table,#alloc >> .align 4