Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1079262pxb; Wed, 15 Sep 2021 22:05:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydwRvis6Uq/CmAVsWs1hUXj8UrqNc659epHaTj64g82Z6d7wI4xVdeQRiRzPbA3zNP7c0p X-Received: by 2002:a92:d18c:: with SMTP id z12mr2699673ilz.59.1631768748652; Wed, 15 Sep 2021 22:05:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631768748; cv=none; d=google.com; s=arc-20160816; b=iyw8R1hCR/lsrEzgLGIGTxKD0mFAzCc1aGSc9/8bhjPtHgHABhZ4FahKAnfBX0WbHx fp8PonB5YjLoWkvG2Ez5ffNaf15GhLYgATcRCC2Zfzy4fAkKyg9hrwEPfiZTQPW4pmjr xgM3O8Ua3KiQfD9R+7WvVXvv5I9YirdmCFzVnuQDVkV2yhzerWEEw6xeVHeA2EPMyaiR pcK2LwJgsVe2W68Srr3rVdcFMmchG7L799loieep7FdeX83/UPjNBNC5STgR0GRWUuEf JxjoKvfNsjE1T4hg21TzAcf/TSwSruZBbyFumv5+KsAl3HXnddViaG0m3QoNmnTX7aLU MB9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:dkim-signature; bh=bNiWf9Qx2imX/YcNH8RlmyCW0vUQMoavZKqD+Jf5RmY=; b=lbQPolrFmrIMhFzcx35L/mvqzR51+i+lwrdr4KLhb3JRZnVLGO9KVB8OH1xuZ7dDwV /snlRx0nbFA50fqnSDz38d/Tk2dW4eaMJMbqzdGrxUCMZAW9sM0GlzVm3w9ioADJwGK+ gTrWUKEB9Ya+NDO7sixdhNycSt3RCqunWOH8ZJ23rPz0rExU+DO/ycKv4zDg6xebLGfY W926SNNyVpYlgWmuSfT3BF589AB/Q6JbfLsIAfwSG1II8QXsAG4uzY5LOVCoaBLKQKFj kNn7UeK6x4p1XBpjhMbqyz8KdCA43Etfhqh8MJZZiGFjb9qdjOMYXwPjdqPGsgSOrY2C dYMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=GDVTW6Cs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a7si1965793ila.148.2021.09.15.22.05.24; Wed, 15 Sep 2021 22:05:48 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=GDVTW6Cs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230081AbhIPFFa (ORCPT + 99 others); Thu, 16 Sep 2021 01:05:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234176AbhIPFF3 (ORCPT ); Thu, 16 Sep 2021 01:05:29 -0400 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E38AC061764 for ; Wed, 15 Sep 2021 22:04:09 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id on12-20020a17090b1d0c00b001997c60aa29so5432118pjb.1 for ; Wed, 15 Sep 2021 22:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=bNiWf9Qx2imX/YcNH8RlmyCW0vUQMoavZKqD+Jf5RmY=; b=GDVTW6CsD48MbgHnM3bpwPe+iOpZM1SWdd3GYBRRL4mAplEpWcA4JVZ2oCfY1r4sCH 8sCe/fdEiVzz7SCKtZ1PJGq3DW4O8suiVbPc05v0CdOZhx7Blq+mJaRGaN8OrjDVhwWA XuBQU0kRgBMhurRdEAwTqXrJ+dWKIJ1fKeSU/S7gAFpL/IGCQYuuImy/g3W8W/dAxT/9 yU6c82787OZYlp6b7eDdVQTO2lABAg+r3Q4KDsXxGd142ZW37FkJS/HO7WRcD3z6uEWb mxduj+AqOHIolzyOJ/NGYJRmUKxUvnZ7f6yVTpNmJn3cHSDOMWNu63DUUK9QvWC37S+M tLSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bNiWf9Qx2imX/YcNH8RlmyCW0vUQMoavZKqD+Jf5RmY=; b=xrAWhKYfaDW1xO49nqGhlFGyA9YbJ+bajKmSbc0oGF5+2t+0y8QDxg2Gs4UpUFYLTQ ZfZxP1YQJQdn+0LKxiYEcAMLCGqmaJzGlUC7Y4kp1HDVaYJlN577ci5IAi1uo/g7BwG/ c2a//yKwolxExWPIyz1sZBMTLRrzbbAvVwZWyqy5JbE7Grl5DSPlmVyVCNg7xo88jeXY C6X3mEDDc+c51SdOvyRF/HXcCZG3PQYF5kyVPla4m6X/ZtKYyXfjTwA3Ny+jCyOcFDY+ 7bxKmgAT8dZYR5MNKTCkx6/5Ht8o+RBtZFSvXagkal3m6rp/KTECd7XqrJCkL5qtwCoB 5pUA== X-Gm-Message-State: AOAM531N4x5yb+fvUESTOoyThPS1hTXPlq4ljidADIO8P/TIpktH2c+4 EUDGzhllhMcNotFCSAs3AxyFQKYEER4= X-Received: by 2002:a17:902:ab0a:b0:13c:9801:a33b with SMTP id ik10-20020a170902ab0a00b0013c9801a33bmr2929998plb.54.1631768648261; Wed, 15 Sep 2021 22:04:08 -0700 (PDT) Received: from [10.1.1.26] (222-155-4-20-adsl.sparkbb.co.nz. [222.155.4.20]) by smtp.gmail.com with ESMTPSA id n41sm1476030pfv.108.2021.09.15.22.04.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Sep 2021 22:04:07 -0700 (PDT) Subject: Re: [PATCH 3/3] m68k: leave stack mangling to asm wrapper of sigreturn() To: Al Viro References: <08183665-f846-0c5e-a8c7-d0a65e78a3da@gmail.com> <48dafad1-4f0c-4ab7-792c-b34a81d26799@gmail.com> Cc: linux-m68k@lists.linux-m68k.org, Geert Uytterhoeven , Greg Ungerer , linux-kernel@vger.kernel.org From: Michael Schmitz Message-ID: <59a44e17-bff8-041e-b704-2b1d97601ce7@gmail.com> Date: Thu, 16 Sep 2021 17:02:22 +1200 User-Agent: Mozilla/5.0 (X11; Linux ppc64; rv:45.0) Gecko/20100101 Thunderbird/45.8.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-kernel@vger.kernel.org Hi Al, On 16/09/21 15:21, Al Viro wrote: > On Thu, Sep 16, 2021 at 12:53:53PM +1200, Michael Schmitz wrote: >>> IOW, what would be the benefit of trying to avoid unconditional gap there? >> >> Avoiding a kernel stack overflow - there are comments in the code that warn >> against that, but those may be largely historic... > > This is syscall entry; moreover, it critically relies upon the fixed stack > layout - type 0 exception frame + pt_regs + switch_stack + (now) gap. AFAIR, the concerns in the comments I saw were about interrupts - come to think of it, back in the early days, we used to have 'fast' and 'slow' interrupt handlers, with much of the heavy lifting done in the handler, and slow interrupts allowed to lower the IPL. Probably no longer relevant. > Followed by fairly shallow C call chain. I suspect that the deepest you > can get there is when you get an unmapped page when reading the sigframe > and go into page fault handling, with call chain going into some filesystem's > ->readpage(). If it was that close to stack overflow, we'd see them all > the time in e.g. random net ioctl doing copy_from_user() - that's going > to be deeper. Or in stat(2), for that matter. Your points are well taken - I can see now that my concerns are without merit. The only question that remains is whether the third patch can also go to -stable. Most of my testing was with all three patches applied, I can drop the third one and retest if you're worries the third one is not appropriate for -stable. Cheers, Michael