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 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