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