Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp640105pxb; Thu, 23 Sep 2021 07:44:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyXHs0luiAm/3uErjMGdDQhJrCo+EkQem4t0EC2Z/jvUammF3zMkGrH+2KUvfnNum+VT0Gh X-Received: by 2002:a02:2302:: with SMTP id u2mr4370785jau.32.1632408291450; Thu, 23 Sep 2021 07:44:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632408291; cv=none; d=google.com; s=arc-20160816; b=in7yvc7howLgwI0LkwJGn8JndGmvgWnme+TbY9FroTe/5XJ+DxQ6W9YkuLftGtscrE EwxLcvJ9w2si7TiiTj8YZeO5oAmxB7ZwaqvnG7sMQukAzx+EEufv/4tofMA/Gvfy+LT1 RjQ1lmAslp+/EZlH9zvQYeSLY2E2Rg0gKHxgAyUuClb5Gh398YXnDABJopvPhUGteEbp 8gfTX1YD24LK/PMn2lqT7vREGAwak3vhvPK4A5VCdxAEQf+HBypPa2WdAgiH4l8dk/We Lou2pGjKoQHrtdRUWIBsvgwf6vwBajn6rFUrH1qheT7ByDKo7f0PoUEuYYuGuaGNL9wa Z9SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=ocmWBy5EYqhzDku3sEqRq+XF89g3KCCaraUmmsxvZxA=; b=qQaHycHYUkixzObKtKzJbA/LTp+0g2Y+qZHcQKTlMUrzMHlHorxjJcKWpW5eF+733R QobTx2NjR5K663K04Ezt4t8CzeSuHVvzKET8OIQCm8RT7MvidVylU/oZK3AKpFh7O/f5 SMt81X2zsuSYb379Cjnk5Vy5oHIS7azPt0Uy33jn/R7mitCDVyhWbmMxJJaTwx1Z4MJK XFfVZzGVaVptCkt9DmtvX61UwOUOKtVdRtunXlYO89ehUbRkF1K/T0U/qirmzFsdtD/h 2LumN76IlNVPjhgS2QpN86lc1bcVfaAMY6sBr7gzKNaFITzPgr1n+ctKs8GtUeUepbco YrMQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c3si4006315ilq.163.2021.09.23.07.44.39; Thu, 23 Sep 2021 07:44:51 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241707AbhIWOpY (ORCPT + 99 others); Thu, 23 Sep 2021 10:45:24 -0400 Received: from mail-vs1-f53.google.com ([209.85.217.53]:44701 "EHLO mail-vs1-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241670AbhIWOpX (ORCPT ); Thu, 23 Sep 2021 10:45:23 -0400 Received: by mail-vs1-f53.google.com with SMTP id 66so2773340vsd.11 for ; Thu, 23 Sep 2021 07:43:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ocmWBy5EYqhzDku3sEqRq+XF89g3KCCaraUmmsxvZxA=; b=IofLwUGYraoFWiyrGxlSkGhI5sKr4tuHsWI0GvmabcMrosdNe6lsP0CrXDMAN5xZ/V fvvzi8D8m5jfyGwaBywsPDvCUdpbE2Mg8LeVSsKrwAiaXAJFTXhRMzBdL53Wt1Ia0BoH E+q076RfDm9dAUpOHTSNih3zQz5Em/T/Lk/VZPy1682tFzth40JFfLtK4pBbbhuGU9nX cgocwOHW5j1r3/sampKc2hdNKKrQYkTY8P/R/60s+CwwNGghwJO84qfhVmNBzXSR8OFX g7ynaGU7lrunNsSfk0xtqzw6LGdshXjhphfHDLagFznPYbSd4RyivuV08qJcziUulCgv zeEA== X-Gm-Message-State: AOAM531m6UcKQ+B5Sgvvb0+ryMkivqXz6pmgjNEfUHjLQdJzUjqihz1o +T+EklYsjWsVk8LotiURVHn8B8NTdbAXt9KgnM4= X-Received: by 2002:a05:6102:2086:: with SMTP id h6mr4418320vsr.50.1632408230604; Thu, 23 Sep 2021 07:43:50 -0700 (PDT) MIME-Version: 1.0 References: <89b7f0e5-21a5-5828-1eb8-5119fb8e2d58@linux-m68k.org> In-Reply-To: <89b7f0e5-21a5-5828-1eb8-5119fb8e2d58@linux-m68k.org> From: Geert Uytterhoeven Date: Thu, 23 Sep 2021 16:43:39 +0200 Message-ID: Subject: Re: [RFC][CFT] signal handling fixes To: Finn Thain Cc: Al Viro , linux-m68k , Greg Ungerer , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Finn, On Thu, Sep 16, 2021 at 11:03 AM Finn Thain wrote: > On Sun, 25 Jul 2021, Al Viro wrote: > > ... > > > > PS: FWIW, ifdefs in arch/m68k/kernel/signal.c are wrong - it's not !MMU > > vs. coldfire/MMU vs. classic/MMU. It's actually 68000 vs. coldfire vs. > > everything else. These days it's nearly correct, but only because on > > MMU variants of coldfire we never see exception stack frames with type > > other than 4 - it's controlled by alignment of kernel stack pointer on > > those, and it's under the kernel control, so it's always 32bit-aligned. > > It used to be more serious back when we had 68360 support - that's !MMU > > and exception stack frames are like those on 68020, unless I'm > > misreading their manual... > > > > I don't claim to understand this code but CPU32 cores appear to be > unsupported on either #ifdef branch: the MMU branch due to CACR and CAAR > used in push_cache(), and the !MMU branch due to frame format $4 used in > adjust_format(). > > The CPU32 Reference Manual appendix says these chips only supports control > registers SFC, DFC, VBR and stack frame formats $0, $2, $C. > https://www.nxp.com/files-static/microcontrollers/doc/ref_manual/CPU32RM.pdf As of commit a3595962d82495f5 ("m68knommu: remove obsolete 68360 support"), nothing selects MCPU32 anymore. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds