Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1138978ybt; Thu, 18 Jun 2020 01:12:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxqTh6PgLV0W9lILsRsozLV3RTMSnQlJU5AokF1ABKO34gghF7Y9C9Xldgn3r2mACnebyY+ X-Received: by 2002:aa7:de14:: with SMTP id h20mr3052161edv.173.1592467979428; Thu, 18 Jun 2020 01:12:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592467979; cv=none; d=google.com; s=arc-20160816; b=kr+o++X2/Dmj80tPNVqfejUp9IxT0gMD2QNII7qaIJV4uEbfVvBcOVBeeW9CrXhWK9 jcXq4ayA9WIXvcLYHzSfuwto8ta74W+3sgsfZKNekqGTyBXTUcNv5kVqbDgzw48Rhixo KIj68RHXtG4T9EtTbr6AVQ+TMHEbdDKqSHQ3wUMJnWToUYAw/r8WsHumFzWVCTbQ+4mh tpX2s4y1MJG7lCagpcDScDNmbwrEqtbN+VtS7ahsBDAywhQ7NZHDk253236ji1/Wb9Wl fJ3moyKrzStpweLdVYtXc7IaYx7hgykuxoOXnRK1g8ogmHDznqeKfZTPPUDfF2p2zCPQ p/9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=p3QwQJDkRWnU6+c2bR/uxK/eU3XeipNdzIVxwQA59Sg=; b=MZTT12Eme0MRdBRq4ZNt4VIy9B5wKAxX9IMm4b11tUDRf9GvOzEjh8bE1hx4r6LB2N tyyMfP1XF2nmq4GhF7j8IzRY3s9KEqvg67dRnBf0BwRVBLgc/3DsNzzshLMp0e+11P6B bs2kt+SfnV8kkJrsmuhsHCrzFJa9VIksw93eXF3Bx98LA6sBnaFmDGrbSxEneTlb6fZc fLRQCc2i+a3Tw5k4plAbv8w9siexhj44xZ69JvFIqCXQnDgy+B694VPedTb/ofze7Fa/ YMv90ruvM9JtQSbAzASAhD+LJaxspLjvTgjNGIG3dtTzoQ5L/lS4nlmDNGAlYYIIOSpZ zKIQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n11si1446105ejh.543.2020.06.18.01.12.37; Thu, 18 Jun 2020 01:12:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728452AbgFRIJ2 (ORCPT + 99 others); Thu, 18 Jun 2020 04:09:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52548 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728406AbgFRIHI (ORCPT ); Thu, 18 Jun 2020 04:07:08 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90465C061755 for ; Thu, 18 Jun 2020 01:07:04 -0700 (PDT) Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1jlpZc-000358-9s; Thu, 18 Jun 2020 10:07:00 +0200 Date: Thu, 18 Jun 2020 10:07:00 +0200 From: Sebastian Andrzej Siewior To: Scott Wood Cc: Valentin Schneider , linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Thomas Gleixner Subject: Re: [PATCH] sched: __set_cpus_allowed_ptr(): Check cpus_mask, not cpus_ptr Message-ID: <20200618080700.cig4x4y7n3thmneu@linutronix.de> References: <20200617121742.cpxppyi7twxmpin7@linutronix.de> <696309d91635fa965ad8436388e7ae7d098420a1.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <696309d91635fa965ad8436388e7ae7d098420a1.camel@redhat.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-06-17 17:49:48 [-0500], Scott Wood wrote: > > Makes sense, but what about the rest of the checks? Further down there is > > > > /* Can the task run on the task's current CPU? If so, we're done > > */ > > if (cpumask_test_cpu(task_cpu(p), new_mask)) > > goto out; > > > > If the task is currently migrate disabled and for some stupid reason it > > gets affined elsewhere, we could try to move it out - which AFAICT we > > don't > > want to do because migrate disabled. So I suppose you'd want an extra > > bailout condition here when the task is migrate disabled. > > > > ISTR in RT you do re-check the affinity and potentially move the task away > > when re-enabling migration, so that should work out all fine. > > On RT the above test is: > > /* Can the task run on the task's current CPU? If so, we're done */ > if (cpumask_test_cpu(task_cpu(p), new_mask) || > p->cpus_ptr != &p->cpus_mask) > goto out; > > ...so we do bail out if we're migrate disabled. correct. There is a complete migrate_disable() patch in the RT queue which has to wait. This patch however looked to be independent of that and could "fix" the pointer part which is already here so I sent it. > -Scott Sebastian