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=-8.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 363CDC433DF for ; Fri, 9 Oct 2020 08:33:30 +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 8214F22260 for ; Fri, 9 Oct 2020 08:33:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="L+I5Wivp"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Waaes3G6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8214F22260 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=9b42Br+lWQjKRgehL7jA7ThBbBIyc1A5XGJYks3Qdww=; b=L+I5WivpOFg4T3wq/iNom8PvJ T4W+i5ycAJazl0AqA9ve2KAygqjeu/UU3ExFaN5NgWzV11wX8H5/9BLRnByM/bHrqjZWUYdqNzPI2 K3dT5G6RQte0oF+vwZWAjeohfkFRj0AYgLZuwsmDaNeK/TbaiOPCQGSLeT8/dO/A2hcYzx+DrNWjz GY3xFdQvWTDJasidc0+onAG0b1VigkE7RdZB4x2nXgdx9kQPlXziY+nsBhhskd3XqyEPNZFa3gJGy 5C0t1vXO7AGckvhzZ9AygU9RKULbDDxLbNTwfagO/3RP2ePNJXgHDx9a19nYOvNTq3VLRYIRS+CB6 cetayqh/g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQnoi-00046L-Mf; Fri, 09 Oct 2020 08:31:56 +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 1kQnof-00045M-So for linux-arm-kernel@lists.infradead.org; Fri, 09 Oct 2020 08:31:54 +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 95E8722251; Fri, 9 Oct 2020 08:31:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602232312; bh=tbYuOpQDVa83BZYltjwMSS2+tI316DFb2wbnl2m8DrQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Waaes3G6nyzIcv5Vfex9WPbs3koRa1o0GU5V/xaGIGmEV1UgzMPw1Yg1J93tyTYdF sUYTv2ELdpgEpZ6dUvWnBfyJi6g26L+PY9GLyPAhuiZbFb4vXZTlqmgTHefQWFWaDW VKLdnq/Uey+VjsWuOZP3pMAj7gRGNQVYkH9ersyQ= Date: Fri, 9 Oct 2020 09:31:47 +0100 From: Will Deacon To: Morten Rasmussen Subject: Re: [RFC PATCH 3/3] arm64: Handle AArch32 tasks running on non AArch32 cpu Message-ID: <20201009083146.GA29594@willie-the-truck> References: <20201008181641.32767-1-qais.yousef@arm.com> <20201008181641.32767-4-qais.yousef@arm.com> <20201009072943.GD2628@hirez.programming.kicks-ass.net> <20201009081312.GA8004@e123083-lin> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201009081312.GA8004@e123083-lin> 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-20201009_043154_078260_4309B804 X-CRM114-Status: GOOD ( 30.55 ) 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 , Peter Zijlstra , Greg Kroah-Hartman , Catalin Marinas , Linus Torvalds , Qais Yousef , 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, Oct 09, 2020 at 10:13:12AM +0200, Morten Rasmussen wrote: > On Fri, Oct 09, 2020 at 09:29:43AM +0200, Peter Zijlstra wrote: > > On Thu, Oct 08, 2020 at 07:16:41PM +0100, Qais Yousef wrote: > > > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c > > > index cf94cc248fbe..7e97f1589f33 100644 > > > --- a/arch/arm64/kernel/signal.c > > > +++ b/arch/arm64/kernel/signal.c > > > @@ -908,13 +908,28 @@ static void do_signal(struct pt_regs *regs) > > > restore_saved_sigmask(); > > > } > > > > > > +static void set_32bit_cpus_allowed(void) > > > { > > > + cpumask_var_t cpus_allowed; > > > + int ret = 0; > > > + > > > + if (cpumask_subset(current->cpus_ptr, &aarch32_el0_mask)) > > > + return; > > > + > > > /* > > > + * On asym aarch32 systems, if the task has invalid cpus in its mask, > > > + * we try to fix it by removing the invalid ones. > > > */ > > > + if (!alloc_cpumask_var(&cpus_allowed, GFP_ATOMIC)) { > > > + ret = -ENOMEM; > > > + } else { > > > + cpumask_and(cpus_allowed, current->cpus_ptr, &aarch32_el0_mask); > > > + ret = set_cpus_allowed_ptr(current, cpus_allowed); > > > + free_cpumask_var(cpus_allowed); > > > + } > > > + > > > + if (ret) { > > > + pr_warn_once("Failed to fixup affinity of running 32-bit task\n"); > > > force_sig(SIGKILL); > > > } > > > } > > > > Yeah, no. Not going to happen. > > > > Fundamentally, you're not supposed to change the userspace provided > > affinity mask. If we want to do something like this, we'll have to teach > > the scheduler about this second mask such that it can compute an > > effective mask as the intersection between the 'feature' and user mask. > > I agree that we shouldn't mess wit the user-space mask directly. Would it > be unthinkable to go down the route of maintaining a new mask which is > the intersection of the feature mask (controlled and updated by arch > code) and the user-space mask? > > It shouldn't add overhead in the scheduler as it would use the > intersection mask instead of the user-space mask, the main complexity > would be around making sure the intersection mask is updated correctly > (cpusets, hotplug, ...). > > Like the above tweak, this won't help if the intersection mask is empty, > task will still get killed but it will allow tasks to survive > user-space masks including some non-compatible CPUs. If we want to > prevent task killing in all cases (ignoring hotplug) it gets more ugly > as we would have to ignore the user-space mask in some cases. Honestly, I don't understand why we're trying to hide this asymmetry from userspace by playing games with affinity masks in the kernel. Userspace is likely to want to move things about _anyway_ because even amongst the 32-bit capable cores, you may well have different clock frequencies to contend with. So I'd be *much* happier to let the schesduler do its thing, and if one of these 32-bit tasks ends up on a core that can't deal with it, then tough, it gets killed. Give userspace the information it needs to avoid that happening in the first place, rather than implicitly limit the mask. That way, the kernel support really boils down to two parts: 1. Remove the sanity checks we have to prevent 32-bit applications running on asymmetric systems 2. Tell userspace about the problem Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel