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 D7F99C63697 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 7F07324655 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 S1727883AbgKSOaT (ORCPT ); Thu, 19 Nov 2020 09:30:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727758AbgKSOaS (ORCPT ); Thu, 19 Nov 2020 09:30:18 -0500 Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C0ADC0613D4 for ; Thu, 19 Nov 2020 06:30:18 -0800 (PST) Received: by mail-wm1-x344.google.com with SMTP id 1so6946879wme.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=WHzJGxlJZzVvVwpkCmPLybTalGpiDxQOJyv6P3y1bvh1xLJ2/0DJ60EGdk3wR+J1ga ClaGajJglH/XJXE+peER4XeTGqu2WmKl6fQbZHhO5NClxzBPhWuOBFErgcVkVcxcpFfl ihj+9wkYnPwBCUDD+oSFJulLLRg30yERhve8eyWL+e2rQX2lFCdQVHUfJVGYYPl4m4JR 7oHZvkOuO9DTFYVPt/85KezPQOMNIyYccLQJ3WgGKmrM5WNaaZzhTfNz0FgDWFRsagyy q4VSNqrrJLbBYhGTq2SsjQxNaTHbB6CzS7n0pNrbvexRH4t0kskx6JtMW4sKxVVAEWR1 DU2A== X-Gm-Message-State: AOAM533lEy0J+zLnqeY58oE4nCSxIrkOsmj3RS0VQdi4/lwv9IIdD+Lf /sWn4T313eRMD/LEPqkSpaB8oQ== 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-kernel@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