Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1590499ybh; Thu, 23 Jul 2020 12:45:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynzJZGAEHJRCdqbK5F12LaKSD1NAN49gkSbtccS/CosQqQTEi+T2vB3C4TccS8P1q4kN+Y X-Received: by 2002:a17:906:364e:: with SMTP id r14mr5817022ejb.258.1595533549454; Thu, 23 Jul 2020 12:45:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595533549; cv=none; d=google.com; s=arc-20160816; b=fUHc0DlkJgzgoycTpZu73BwBEwY8W4S9AslfnyW15aC5gyJGOqPIAc+IXDLsm9xQjG aZ5lZIIbOZbbotlRuQsv9n6VdhVr8cdxY0/GipXvatzcwW+KbOcn9eUdOtB+M2dnwCNJ x6ylQoK1uY/R9kVQtnuPrc+BKba0aHRfhDo19+lg5kSKQfKFi9B33WjglOHYFxkieLIN 9joTocVLWzKdcIdfTWNBNJ9VJZTQR4HSHsr3HDrvmVw81LQsCiu9hwNvOiS1mDyfXTVV PcjhJ5VxOXDDNDvStxdzUqFaCFWcrb+2uJhXttLIs17Y/e+enJRbSZ3VZnhDq1NPEqtQ gASA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:date:to:cc:from :subject:references:in-reply-to:content-transfer-encoding :mime-version; bh=9czhCImo7IQ6UYHWj6DKBM6rxAHlPqZbMBwaYTvalvE=; b=JQQA7hcwniP2QU+tpy7LJgaJYYWhIWGfHd1TTV4wd31k+JZhm4jgTF+5IPpBvmcVwa pOagbwkemT6xxCJKUrpLkIb1c2t5z2GuySdnTfTiIk/ZImWG7JNNplEzFXom0KycmGqi GobdU3fUyN1S1EvHB/HR5J88hgsgAAFS2OJ50j1HGwkAtsy+z9s5T4caFRsDAueu4kYh R8jHay7SGy1gFszpQSm4SeLwHxkEHz/KaTko6WrNCXHYr9VuUb9hz1CoDgNA7aVWh9Cj RLGaOjTIoeAPvM46rQ6EzoDYZ09twsosO8AdRni7j2acsp3q6fWM6wGU52q+2+RVWlnP Hu+g== 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 n21si2455081ejy.545.2020.07.23.12.45.26; Thu, 23 Jul 2020 12:45:49 -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 S1726501AbgGWTmJ convert rfc822-to-8bit (ORCPT + 99 others); Thu, 23 Jul 2020 15:42:09 -0400 Received: from mail.fireflyinternet.com ([77.68.26.236]:51996 "EHLO fireflyinternet.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726146AbgGWTmJ (ORCPT ); Thu, 23 Jul 2020 15:42:09 -0400 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 21911803-1500050 for multiple; Thu, 23 Jul 2020 20:41:05 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT In-Reply-To: <20200723182841.GS10769@hirez.programming.kicks-ass.net> References: <20200622100122.477087977@infradead.org> <20200622100825.726200103@infradead.org> <159532854586.15672.5123219635720172265@build.alporthouse.com> <20200721113719.GI119549@hirez.programming.kicks-ass.net> <159541187604.15672.2433896906671712337@build.alporthouse.com> <20200723182841.GS10769@hirez.programming.kicks-ass.net> Subject: Re: [PATCH -v2 1/5] sched: Fix ttwu() race From: Chris Wilson Cc: mingo@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, paulmck@kernel.org, frederic@kernel.org, torvalds@linux-foundation.org, hch@lst.de To: Peter Zijlstra Date: Thu, 23 Jul 2020 20:41:03 +0100 Message-ID: <159553326368.21069.3167204000119437062@build.alporthouse.com> User-Agent: alot/0.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Peter Zijlstra (2020-07-23 19:28:41) > On Wed, Jul 22, 2020 at 10:57:56AM +0100, Chris Wilson wrote: > > > Perhaps more damning is that I can replace WF_ON_CPU with p->on_cpu to > > suppress the warning: > > *argh*, I'm starting to go mad... > > Chris, could you please try the below patch? ttwu-IPI-self: 1==1, p->on_cpu=0;0, task_cpu(p)=1;1 ttwu-IPI-self: 1==1, p->on_cpu=0;0, task_cpu(p)=1;1 ttwu-IPI-self: 0==0, p->on_cpu=0;0, task_cpu(p)=0;0 ttwu-IPI-self: 3==3, p->on_cpu=0;0, task_cpu(p)=3;3 ttwu-IPI-self: 2==2, p->on_cpu=0;0, task_cpu(p)=2;2 ttwu-IPI-self: 1==1, p->on_cpu=0;0, task_cpu(p)=1;1 ttwu-IPI-self: 2==2, p->on_cpu=0;0, task_cpu(p)=2;2 ttwu-IPI-self: 2==2, p->on_cpu=0;0, task_cpu(p)=2;2 ttwu-IPI-self: 2==2, p->on_cpu=0;0, task_cpu(p)=2;2 > Can you also confirm that if you do: > > $ echo NO_TTWU_QUEUE_ON_CPU > /debug/sched_features With, sched_feat_disable(10):TTWU_QUEUE_ON_CPU the pr_alert is still being hit ttwu-IPI-self: 3==3, p->on_cpu=0;0, task_cpu(p)=3;3 At which point, it darns on me. Mea culpa, stray bits being passed into default_wake_function. I am very sorry for the wild goose chase. -Chris