Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp849275ybt; Wed, 17 Jun 2020 15:54:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwaq/CrCksrrRotKz55696KTOkKK6bT8XC98U+8uACfYIzUD8i1Yyg3/imJuCMTKORSNege X-Received: by 2002:a50:cd1c:: with SMTP id z28mr1363718edi.257.1592434456550; Wed, 17 Jun 2020 15:54:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592434456; cv=none; d=google.com; s=arc-20160816; b=oK/2/tMQZ3AcrWReYoD7vhCkyogvgTqRxs4g6G4i3B1WJw/TulwYdPLvbxxsoS9A5h IylpoZAZ3piRqvgKG5Hx0folVOyqJ4+WFEajO3Q+Drfuj6gzCZdSR2ixIMO1PrHH6jSq I6CA91FDEZV7LF4nupuXss3mNDw7dffrq0KVl6cy+FkkdXEQzy7NZ1RAJ0mEUUHoHKnP SjPJ/oNWXeUwooE86AsDCuhxvLuLwUocCi/dBYet9XyFXg5D7C40IhGHEaNN8uW03NdI YUpasw4GMELiiSBBJ/DiBckQHsupmfN+l0BniZKmbZVofuIPA2HhT7XmrezFzHgO/Y6A MWJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=orWx+/3XMb05Rqs5NYz0sIWDOdOQGOdIAEzCS5djo9E=; b=Ak3TNG5Qm2TyVfB2ac13mHmd8ux8YJVYxNmvyfhcgk0H+oR1hmRz11D7PYXVCQE/zN XbD13E7D6o2KPTK8HcAYPSeZx4Czc6YC6jYyY8EQd6LBSwZpuHdYYHwm9vjaiRX2LX0b WIcZvkRcNu2JJyB1cjyXao24P0T9MnvqdWmkHLsjspT/XH9AKNVmJfU80Rh2wAB1ZpvX Mfg4rWZq8Txvv57qDzhE4i6auh/1kJ+Dm5HKHr8YoE2OOLNfr1u119HsKm7obRG/fcmo Ig3+C1RvrXaACA9Wc2W5JTXXhxU1L2yd+DqudhhlVqCTj0gPuYVJVuA5pj8/lD+pa7gU bPTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="IOIRCA/+"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v24si852239edw.95.2020.06.17.15.53.54; Wed, 17 Jun 2020 15:54:16 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="IOIRCA/+"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727039AbgFQWt7 (ORCPT + 99 others); Wed, 17 Jun 2020 18:49:59 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:50196 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726909AbgFQWt7 (ORCPT ); Wed, 17 Jun 2020 18:49:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592434197; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=orWx+/3XMb05Rqs5NYz0sIWDOdOQGOdIAEzCS5djo9E=; b=IOIRCA/+0CP3fAJCQ1lbEo/TiqppwUdzhM5pkJ7fSf9zqZy5oRag5zD32EG+ClHjN/7YPi aa2WKF4m+X4zzkw5B63fnQMQmmaNkhcLPf0IHFG4yRJTEGadEVeaGdpLpNPZKxFg9yNscy jo+TRyeIte3RAh2k9LF179I1EhWc0z4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-109-kidHweHCNA6cszRyDcFJqg-1; Wed, 17 Jun 2020 18:49:55 -0400 X-MC-Unique: kidHweHCNA6cszRyDcFJqg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CFAF78005AD; Wed, 17 Jun 2020 22:49:53 +0000 (UTC) Received: from ovpn-112-150.phx2.redhat.com (ovpn-112-150.phx2.redhat.com [10.3.112.150]) by smtp.corp.redhat.com (Postfix) with ESMTP id 70EB85D9D3; Wed, 17 Jun 2020 22:49:49 +0000 (UTC) Message-ID: <696309d91635fa965ad8436388e7ae7d098420a1.camel@redhat.com> Subject: Re: [PATCH] sched: __set_cpus_allowed_ptr(): Check cpus_mask, not cpus_ptr From: Scott Wood To: Valentin Schneider , Sebastian Andrzej Siewior Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Thomas Gleixner Date: Wed, 17 Jun 2020 17:49:48 -0500 In-Reply-To: References: <20200617121742.cpxppyi7twxmpin7@linutronix.de> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2020-06-17 at 15:15 +0100, Valentin Schneider wrote: > On 17/06/20 13:17, Sebastian Andrzej Siewior wrote: > > From: Scott Wood > > > > This function is concerned with the long-term cpu mask, not the > > transitory mask the task might have while migrate disabled. Before > > this patch, if a task was migrate disabled at the time > > __set_cpus_allowed_ptr() was called, and the new mask happened to be > > equal to the cpu that the task was running on, then the mask update > > would be lost. > > > > Signed-off-by: Scott Wood > > Signed-off-by: Sebastian Andrzej Siewior > > --- > > kernel/sched/core.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > --- a/kernel/sched/core.c > > +++ b/kernel/sched/core.c > > @@ -1637,7 +1637,7 @@ static int __set_cpus_allowed_ptr(struct > > goto out; > > } > > > > - if (cpumask_equal(p->cpus_ptr, new_mask)) > > + if (cpumask_equal(&p->cpus_mask, new_mask)) > > goto out; > > > > /* > > 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. -Scott