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=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 4647AC83017 for ; Tue, 1 Dec 2020 16:57:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E86812076C for ; Tue, 1 Dec 2020 16:57:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z4L+aw0S" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392213AbgLAQ5W (ORCPT ); Tue, 1 Dec 2020 11:57:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:41478 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391923AbgLAQ5V (ORCPT ); Tue, 1 Dec 2020 11:57:21 -0500 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5DEA32076C; Tue, 1 Dec 2020 16:56:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606841800; bh=Lv7GIMUtEGurVreC2UmCreL5UbLTF5Qoi61IUV5s8/0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Z4L+aw0SQFzqPN8jvBANSDCIAYxMrudTWGcnfxHKtqDacHg1IBsstwIxnKr+E9wlz 4MoupL6pY0f2SPiGLb8g33bOY0ig8QG8yPMCF7ThFizJ+ozAQGCV4ZJTNbJmLBeSAo F/P9sTDcS3FnKyaTawnnOqzOvz0cw2wMUnaZXTNE= Date: Tue, 1 Dec 2020 16:56:34 +0000 From: Will Deacon To: Qais Yousef Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , Marc Zyngier , Greg Kroah-Hartman , Peter Zijlstra , Morten Rasmussen , Suren Baghdasaryan , Quentin Perret , Tejun Heo , Li Zefan , Johannes Weiner , Ingo Molnar , Juri Lelli , Vincent Guittot , kernel-team@android.com Subject: Re: [PATCH v4 04/14] arm64: Kill 32-bit applications scheduled on 64-bit-only CPUs Message-ID: <20201201165633.GC27783@willie-the-truck> References: <20201124155039.13804-1-will@kernel.org> <20201124155039.13804-5-will@kernel.org> <20201127131217.skekrybqjdidm5ki@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201127131217.skekrybqjdidm5ki@e107158-lin.cambridge.arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 27, 2020 at 01:12:17PM +0000, Qais Yousef wrote: > On 11/24/20 15:50, Will Deacon wrote: > > Scheduling a 32-bit application on a 64-bit-only CPU is a bad idea. > > > > Ensure that 32-bit applications always take the slow-path when returning > > to userspace on a system with mismatched support at EL0, so that we can > > avoid trying to run on a 64-bit-only CPU and force a SIGKILL instead. > > > > Signed-off-by: Will Deacon > > --- > > nit: We drop this patch at the end. Can't we avoid it altogether instead? I did it like this so that the last patch can be reverted for testing/debugging, but also because I think it helps the structure of the series. > > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c > > index a8184cad8890..bcb6ca2d9a7c 100644 > > --- a/arch/arm64/kernel/signal.c > > +++ b/arch/arm64/kernel/signal.c > > @@ -911,6 +911,19 @@ static void do_signal(struct pt_regs *regs) > > restore_saved_sigmask(); > > } > > > > +static bool cpu_affinity_invalid(struct pt_regs *regs) > > +{ > > + if (!compat_user_mode(regs)) > > + return false; > > Silly question. Is there an advantage of using compat_user_mode() vs > is_compat_task()? I see the latter used in the file although struct pt_regs > *regs is passed to the functions calling it. > > Nothing's wrong with it, just curious. Not sure about advantages, but is_compat_task() is available in core code, whereas compat_user_mode() is specific to arm64. The former implicitly operates on 'current' and just checks thread flag, whereas the latter actually goes and looks at mode field of the spsr to see what we're going to be returning into. Will 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=-17.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 7B730C64E7A for ; Tue, 1 Dec 2020 16:57:53 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 014812223F for ; Tue, 1 Dec 2020 16:57:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nMOuCGvB"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z4L+aw0S" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 014812223F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MNKaymKqQQOLpodT1mBOVaZkwcySIfswHZ1WYXJE5xs=; b=nMOuCGvB7F9k6IaqVsdbB6bWI /RYwSfThSYibD4VRu2uw2F7js3QTQrlaSlm1/DTSe7hsmuk976+CJOjmHUd4OIktZNtFStUhnuIS2 V7EegtyUQKIiBGQWkb2ZjFAX5Oz4fIVVkU0xcGtzSInO7iY0snoDvzAwYAtGCZzNyvaCFE7HHwEz1 W2fGf8zNQwcCemeX5vmBfI4XZ2GSLRhXPXQmIvCMKKl1/7TnTRpEz2d6lwaqoA6zHiRh1Ou21fClb yIF6Fv/ICAMeH/e5Sbf4hEm059VTHPai4n6HQ8ficgH6NEsk93foUpkn/FHU5TZc0wmCSI4IUslpV Xw30uHjFQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kk8xJ-0003oo-9k; Tue, 01 Dec 2020 16:56:45 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kk8xF-0003mF-F1 for linux-arm-kernel@lists.infradead.org; Tue, 01 Dec 2020 16:56:42 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5DEA32076C; Tue, 1 Dec 2020 16:56:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606841800; bh=Lv7GIMUtEGurVreC2UmCreL5UbLTF5Qoi61IUV5s8/0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Z4L+aw0SQFzqPN8jvBANSDCIAYxMrudTWGcnfxHKtqDacHg1IBsstwIxnKr+E9wlz 4MoupL6pY0f2SPiGLb8g33bOY0ig8QG8yPMCF7ThFizJ+ozAQGCV4ZJTNbJmLBeSAo F/P9sTDcS3FnKyaTawnnOqzOvz0cw2wMUnaZXTNE= Date: Tue, 1 Dec 2020 16:56:34 +0000 From: Will Deacon To: Qais Yousef Subject: Re: [PATCH v4 04/14] arm64: Kill 32-bit applications scheduled on 64-bit-only CPUs Message-ID: <20201201165633.GC27783@willie-the-truck> References: <20201124155039.13804-1-will@kernel.org> <20201124155039.13804-5-will@kernel.org> <20201127131217.skekrybqjdidm5ki@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201127131217.skekrybqjdidm5ki@e107158-lin.cambridge.arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201201_115641_737239_9E031BA4 X-CRM114-Status: GOOD ( 25.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Marc Zyngier , kernel-team@android.com, Vincent Guittot , Juri Lelli , Quentin Perret , Peter Zijlstra , Catalin Marinas , Johannes Weiner , linux-kernel@vger.kernel.org, Ingo Molnar , Li Zefan , Greg Kroah-Hartman , Tejun Heo , Suren Baghdasaryan , Morten Rasmussen , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Nov 27, 2020 at 01:12:17PM +0000, Qais Yousef wrote: > On 11/24/20 15:50, Will Deacon wrote: > > Scheduling a 32-bit application on a 64-bit-only CPU is a bad idea. > > > > Ensure that 32-bit applications always take the slow-path when returning > > to userspace on a system with mismatched support at EL0, so that we can > > avoid trying to run on a 64-bit-only CPU and force a SIGKILL instead. > > > > Signed-off-by: Will Deacon > > --- > > nit: We drop this patch at the end. Can't we avoid it altogether instead? I did it like this so that the last patch can be reverted for testing/debugging, but also because I think it helps the structure of the series. > > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c > > index a8184cad8890..bcb6ca2d9a7c 100644 > > --- a/arch/arm64/kernel/signal.c > > +++ b/arch/arm64/kernel/signal.c > > @@ -911,6 +911,19 @@ static void do_signal(struct pt_regs *regs) > > restore_saved_sigmask(); > > } > > > > +static bool cpu_affinity_invalid(struct pt_regs *regs) > > +{ > > + if (!compat_user_mode(regs)) > > + return false; > > Silly question. Is there an advantage of using compat_user_mode() vs > is_compat_task()? I see the latter used in the file although struct pt_regs > *regs is passed to the functions calling it. > > Nothing's wrong with it, just curious. Not sure about advantages, but is_compat_task() is available in core code, whereas compat_user_mode() is specific to arm64. The former implicitly operates on 'current' and just checks thread flag, whereas the latter actually goes and looks at mode field of the spsr to see what we're going to be returning into. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel