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=-10.9 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=no 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 87E87C6369E for ; Thu, 19 Nov 2020 14:30:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2E03E24248 for ; Thu, 19 Nov 2020 14:30:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="SSZqdpj4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727800AbgKSOaS (ORCPT ); Thu, 19 Nov 2020 09:30:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727473AbgKSOaS (ORCPT ); Thu, 19 Nov 2020 09:30:18 -0500 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 185C2C0613CF for ; Thu, 19 Nov 2020 06:30:18 -0800 (PST) Received: by mail-wm1-x343.google.com with SMTP id p22so7385648wmg.3 for ; Thu, 19 Nov 2020 06:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uRlbyeBiYk1IUBo5HOH3WItMevxm3ru4Xm8qrRT2wyg=; b=SSZqdpj4RKoJCWr8oozomLprKyqS+l9AkT5kISQ17LF6RpK1CSWLxQlc4sTGOsxyHN yYmTFS5gRxoB86T6LfrrF24hrVqbIqulJ8UH//svICGbKaBjLtoTcnaDEXFWGPzc4Ul2 wpAIpiuIALpUL/C2M++d/zMV1a0YRSycbaBbl1o6BOBNIbSpAza5h5ANnCNVsEmhic4o YAkmkOgha5FGHYaEmLHJM0dh8zNxc3MzcU/frv+JV2GFeXl4bkQorrqvYt6HGVpI/xku 0C6nk6HeyRLeG8UH1/LSJaIX2Tn04O50iOD0dc3aTQv5ok3z5cr6fQ3paiCkX2G/ly7O zWsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uRlbyeBiYk1IUBo5HOH3WItMevxm3ru4Xm8qrRT2wyg=; b=bmdVOUuwifKwIe2oPgKIGjZ/Xfk0gHUNW38F5Y6UvsdGYWEPCXxjq1VGXRrCvXVP1i Cz8A+RxGuCOWdvM1gAq4VACwsBhyGDAcxOxEDorw/gLZZ5Gu1iRA224sPbXboqAp9/0M kwYQnMnFQyIc65UGlVYHJhJa/UC+4Ez3Yhn9BANRfa0tWq1l0nRhvu04TuJDxqidzsvj e3g4LI1R4zrlitRBJMtiQNe8vOmk+KFiu+UL5LVBteAT24dPE6VbZbrV71WkLmKOuzI9 bYkl3kI0FkwLDuTbrsVAcpVq2Fg07SUMKayAp+f5AeKcOYBPCacenDkAFEVdK5HCz4ja 9fdg== X-Gm-Message-State: AOAM531wgyx+Z6eSfOzyKr9DeA9JjdwHvd4f8Keem+C0AkIX+Y2XgBlk I/MdxvZa3xoR16Ek80vSTp3feaFwGMMHsw== X-Google-Smtp-Source: ABdhPJy8A5U+1WfeWMxxbnZ1WJ30eOzYlz6bx9wFXE1uJ7iC3YyfUJKLcd4aeL9iz56NGihKFjAC8A== X-Received: by 2002:a05:600c:218c:: with SMTP id e12mr1443488wme.28.1605796216613; Thu, 19 Nov 2020 06:30:16 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:f693:9fff:fef4:a7ef]) by smtp.gmail.com with ESMTPSA id p4sm40134200wrm.51.2020.11.19.06.30.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Nov 2020 06:30:16 -0800 (PST) Date: Thu, 19 Nov 2020 14:30:12 +0000 From: Quentin Perret To: Will Deacon 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 , Qais Yousef , Suren Baghdasaryan , Tejun Heo , Li Zefan , Johannes Weiner , Ingo Molnar , Juri Lelli , Vincent Guittot , kernel-team@android.com Subject: Re: [PATCH v3 11/14] sched: Reject CPU affinity changes based on arch_cpu_allowed_mask() Message-ID: <20201119143012.GA2458028@google.com> References: <20201113093720.21106-1-will@kernel.org> <20201113093720.21106-12-will@kernel.org> <20201119094744.GE2416649@google.com> <20201119110723.GE3946@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201119110723.GE3946@willie-the-truck> Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Thursday 19 Nov 2020 at 11:07:24 (+0000), Will Deacon wrote: > Yeah, the cpuset code ignores the return value of set_cpus_allowed_ptr() in > update_tasks_cpumask() so the failure won't be propagated, but then again I > think that might be the right thing to do. Nothing prevents 32-bit and > 64-bit tasks from co-existing in the same cpuseti afaict, so forcing the > 64-bit tasks onto the 32-bit-capable cores feels much worse than the > approach taken here imo. Ack. And thinking about it more, failing the cgroup operation wouldn't guarantee that the task's affinity and the cpuset are aligned anyway. We could still exec into a 32 bit task from within a 64 bit-only cpuset. > The interesting case is what happens if the cpuset for a 32-bit task is > changed to contain only the 64-bit-only cores. I think that's a userspace > bug Maybe, but I think Android will do exactly that in some cases :/ > but the fallback rq selection should avert disaster. I thought _this_ patch was 'fixing' this case by making the cpuset operation pretty much a nop on the task affinity? The fallback rq stuff is all about hotplug no? Thanks, Quentin 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=-1.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 3F28EC6379D for ; Thu, 19 Nov 2020 14:32:00 +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 B0E16246A7 for ; Thu, 19 Nov 2020 14:31:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fkuyKqUa"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="SSZqdpj4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B0E16246A7 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com 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=B85VwZoAZg7U7fgkuy7zHDNSL/g/IszNo89DK3SpfN0=; b=fkuyKqUafYfgpibYCIkax64dM X+0SR9oTrMqC4XgV3cbE+bLDHYkC8vq4J4CbgNTChMvnzJRG7Tvt0JBx/fmEhY5NzeEhR/8ywoZj8 VNJfEaftVHb9qzWJWZNbhD+e9Rq81oLXcpLFxJ6aYSUEwqS0cfNM24WIWgnHgwUCwaCYIVSgTCtPM 7mFd6ReMiKNg/uda3LJGHDiYKnOuc+HlSQwNzDej3ikTDbSgJn1HF0ZW6ueAWi6do8FXCFMX4NyWd 7nHzZj1sctrr869yHU+sfCEi01MqN9ZT0yJXJ4f1/HEUrPymGj16oqbKn3C0kC0hRUOAYmovENpzB NoNbRCm1g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfkx2-0006et-Ib; Thu, 19 Nov 2020 14:30:20 +0000 Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfkwz-0006e2-Vt for linux-arm-kernel@lists.infradead.org; Thu, 19 Nov 2020 14:30:19 +0000 Received: by mail-wm1-x341.google.com with SMTP id d142so7382438wmd.4 for ; Thu, 19 Nov 2020 06:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uRlbyeBiYk1IUBo5HOH3WItMevxm3ru4Xm8qrRT2wyg=; b=SSZqdpj4RKoJCWr8oozomLprKyqS+l9AkT5kISQ17LF6RpK1CSWLxQlc4sTGOsxyHN yYmTFS5gRxoB86T6LfrrF24hrVqbIqulJ8UH//svICGbKaBjLtoTcnaDEXFWGPzc4Ul2 wpAIpiuIALpUL/C2M++d/zMV1a0YRSycbaBbl1o6BOBNIbSpAza5h5ANnCNVsEmhic4o YAkmkOgha5FGHYaEmLHJM0dh8zNxc3MzcU/frv+JV2GFeXl4bkQorrqvYt6HGVpI/xku 0C6nk6HeyRLeG8UH1/LSJaIX2Tn04O50iOD0dc3aTQv5ok3z5cr6fQ3paiCkX2G/ly7O zWsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uRlbyeBiYk1IUBo5HOH3WItMevxm3ru4Xm8qrRT2wyg=; b=dsI1ojgcJcbIGyec0FDuwCLGiZ/UJlyI1i1G8ESNzkXWsY7TDtsUqvIZAFcoWIqWM7 kqK6tvUTk+3meBYV7IGYNJgt/aQ2zugnnDdbqM+Y9YEo+vz1ZSdvZVbPn0HkOWsNkdGF 8+pU03tgQAMHoHPjz7T0O17nch3vMmJ8W8TiFVIKKqh9Jf/LezRmwtM0ZsX9G0qEE0he EoIlxH90zPCE9m/FDtXT3junUd8UCHGCoRKARgBbzuQmJ+Vd/MjxJznKpx7LL2Eoqkg0 /RZ1sCyll65acAD2GzJEwr+ALHRgVGUEmuUXuUwYGIMGGwfuzbavZ0qpu12G6aDCJ1M0 Es2w== X-Gm-Message-State: AOAM532JnhkNhYM9ef7L9kxttCVDpkbOqn4RFrEuI2/+X+hgs9fB5qA+ dzCiJoPcy3m/7XDrAvKT0UITkA== X-Google-Smtp-Source: ABdhPJy8A5U+1WfeWMxxbnZ1WJ30eOzYlz6bx9wFXE1uJ7iC3YyfUJKLcd4aeL9iz56NGihKFjAC8A== X-Received: by 2002:a05:600c:218c:: with SMTP id e12mr1443488wme.28.1605796216613; Thu, 19 Nov 2020 06:30:16 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:f693:9fff:fef4:a7ef]) by smtp.gmail.com with ESMTPSA id p4sm40134200wrm.51.2020.11.19.06.30.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Nov 2020 06:30:16 -0800 (PST) Date: Thu, 19 Nov 2020 14:30:12 +0000 From: Quentin Perret To: Will Deacon Subject: Re: [PATCH v3 11/14] sched: Reject CPU affinity changes based on arch_cpu_allowed_mask() Message-ID: <20201119143012.GA2458028@google.com> References: <20201113093720.21106-1-will@kernel.org> <20201113093720.21106-12-will@kernel.org> <20201119094744.GE2416649@google.com> <20201119110723.GE3946@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201119110723.GE3946@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201119_093018_152581_E0869C40 X-CRM114-Status: GOOD ( 18.25 ) 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 , Ingo Molnar , Peter Zijlstra , Catalin Marinas , Johannes Weiner , linux-kernel@vger.kernel.org, Qais Yousef , 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 Thursday 19 Nov 2020 at 11:07:24 (+0000), Will Deacon wrote: > Yeah, the cpuset code ignores the return value of set_cpus_allowed_ptr() in > update_tasks_cpumask() so the failure won't be propagated, but then again I > think that might be the right thing to do. Nothing prevents 32-bit and > 64-bit tasks from co-existing in the same cpuseti afaict, so forcing the > 64-bit tasks onto the 32-bit-capable cores feels much worse than the > approach taken here imo. Ack. And thinking about it more, failing the cgroup operation wouldn't guarantee that the task's affinity and the cpuset are aligned anyway. We could still exec into a 32 bit task from within a 64 bit-only cpuset. > The interesting case is what happens if the cpuset for a 32-bit task is > changed to contain only the 64-bit-only cores. I think that's a userspace > bug Maybe, but I think Android will do exactly that in some cases :/ > but the fallback rq selection should avert disaster. I thought _this_ patch was 'fixing' this case by making the cpuset operation pretty much a nop on the task affinity? The fallback rq stuff is all about hotplug no? Thanks, Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel