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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,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 25F9CC63777 for ; Mon, 30 Nov 2020 17:37:33 +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 BE8C7206DF for ; Mon, 30 Nov 2020 17:37:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="2JCzufxD"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="YZSMYUXM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BE8C7206DF 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=1J7QJWgM5Ftjzaphy6WuLj4NiK/tb+OPbgH2PbiUW4A=; b=2JCzufxD0EQjfTetCTn6XbhPt 5l8gnfA8vYX+RfeC9PF30cvSFiUbh8ZikJAs2XU4WThZM73BtGmDG4GYXFqDa08TlZuJUySlzJgaJ SXvkL1Itvb3a6Dr2E1zOCP13Bsb7sGnN7MjihRbAuGIaVI36fVsv4SvrCa1nqXyUTVVJDTeEW53tp jQeqWH+/aESwxH2fR0MPS8ELrqKVekSk+7qRdu4spedh145TILWxOaSySR0ZA29vCmcwR5YBQ0OqT hK4u3CHKpwm7Ae2HPwqaOSKGkUTkrtw9I2z5c3j11nvXENV2uxyw31mc7WseAoOV4YwXDype2rYVY LpCfjHUxg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kjn65-00035Y-4V; Mon, 30 Nov 2020 17:36:21 +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 1kjn61-00033t-Qs for linux-arm-kernel@lists.infradead.org; Mon, 30 Nov 2020 17:36:18 +0000 Received: by mail-wm1-x341.google.com with SMTP id g185so8017wmf.3 for ; Mon, 30 Nov 2020 09:36:15 -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=HXquueW7RwtRbSUyF0GUkPiPyiBc1RMHTutwlm7gt9U=; b=YZSMYUXMw3eHMy3QopppKqtvLhx0+nK/5nPnT6HxkmvvKbkVhKWxBCqASbsFUuH1mC vyYI8CjHKvhEymyG1bGJaar0x8BJoFBwCj0U8OX7lDYxDYdPoo2TirozgKEtqfGu2ypf 1pzfRaAgWClglozMdpzqwSUxx2376Sf8XTEgB0k5roT+DbQOjljSFFV4JkU7piIwi6JT MmlcwkdrZzElnTO17j9uf/ZUHZioqVYEvoxafcHZodiA9Eq0pCtsa06PUxnTXvNn3eMD YM/bDhgOeLOq5hreUWI31EroxfJvM5E/zk0Qf+TGB1wmLNDnZyv4RFvVKMLwbiviUkdU yp4A== 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=HXquueW7RwtRbSUyF0GUkPiPyiBc1RMHTutwlm7gt9U=; b=jxdVpkG0g3BEXvYfmVcAlR2kS9AyQMWjA0jX/jSOjY5iU/uctMl0Qx3nn47QgtD3tS xIR+AeySKaxJr3OvzZpERLzfnBBWHbG3HL+a+mvtT2SS63j/leRoeO02103WYyz9al+D 9cTuZ33Lph/j8ltVie8intIh+u/THm20ep5spKGs6h5hL9T4TtcNatJd9fHkjtEJZWfD XWXySRmO/etVLCngk92HWklBG0RC0JvQTnth5rxIcP+iqGsfl2MMK1F81eZEXrMHP5+T Z2h6/CPH8eRYlffq5o+ARKVP9fSpDywhCKxftNzve9yHV7Wfdcrx9OhNWTC0BHgWi+ae xT0w== X-Gm-Message-State: AOAM530+1ziit5UFivY4xE0KuTSlSG/OIfQukaBt6JDFcZ1RtsVBglhW g5mgfTBJCrR8dE5hEvNlLmv2qg== X-Google-Smtp-Source: ABdhPJyv0kIDqw35nKHHG3r+Jvq9Q37fbXRLDAKsgXCJ4crAEZHm92iXyhudgXVwGNW3N/Z9A2F+pQ== X-Received: by 2002:a7b:c94d:: with SMTP id i13mr24303675wml.130.1606757774631; Mon, 30 Nov 2020 09:36:14 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:f693:9fff:fef4:a7ef]) by smtp.gmail.com with ESMTPSA id b14sm27809837wrq.47.2020.11.30.09.36.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Nov 2020 09:36:14 -0800 (PST) Date: Mon, 30 Nov 2020 17:36:10 +0000 From: Quentin Perret To: Qais Yousef Subject: Re: [PATCH v4 09/14] cpuset: Don't use the cpu_possible_mask as a last resort for cgroup v1 Message-ID: <20201130173610.GA1715200@google.com> References: <20201124155039.13804-1-will@kernel.org> <20201124155039.13804-10-will@kernel.org> <20201127133245.4hbx65mo3zinawvo@e107158-lin.cambridge.arm.com> <20201130170531.qo67rai5lftskmk2@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201130170531.qo67rai5lftskmk2@e107158-lin.cambridge.arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201130_123617_922057_56B531B0 X-CRM114-Status: GOOD ( 18.64 ) 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, Juri Lelli , kernel-team@android.com, Vincent Guittot , Greg Kroah-Hartman , Peter Zijlstra , Catalin Marinas , Johannes Weiner , linux-kernel@vger.kernel.org, Suren Baghdasaryan , Ingo Molnar , Li Zefan , Marc Zyngier , Tejun Heo , Will Deacon , 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 Monday 30 Nov 2020 at 17:05:31 (+0000), Qais Yousef wrote: > I create 3 cpusets: 64bit, 32bit and mix. As the name indicates, 64bit contains > all 64bit-only cpus, 32bit contains 32bit-capable ones and mix has a mixture of > both. > > If I try to move my test binary to 64bit cpuset, it moves there and I see the > WARN_ON_ONCE() triggered. The task has attached to the new cpuset but > set_allowed_cpus_ptr() has failed and we end up with whatever affinity we had > previously. Breaking cpusets effectively. Right, and so does exec'ing from a 64 bit task into 32 bit executable from within a 64 bit-only cpuset :( . And there is nothing we can really do about it, we cannot fail the exec because we need this to work for existing apps, and there is no way the Android framework can know upfront. So the only thing we can do really is WARN() and proceed to ignore the cpuset, which is what this series does :/. It's not exactly pretty but I don't think we can do much better than that TBH, and it's the same thing for the example you brought up. Failing cpuset_can_attach() will not help, we can only WARN and proceed ... Now, Android should be fine with that I think. We only need the kernel to implement a safe fallback mechanism when userspace gives contradictory commands, because we know there are edge cases userspace _cannot_ deal with correctly, but this fallback doesn't need to be highly optimized (at least for Android), but I'm happy to hear what others think. Thanks, Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel