Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4706947yba; Tue, 30 Apr 2019 03:05:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqw3ONpYZ32KjQGbLvQ8orYOZaon7hLFzQTh3HBHa/uF53SRBmq4OeynlXrNTTN11L+UTHfN X-Received: by 2002:a63:318b:: with SMTP id x133mr16288335pgx.297.1556618717932; Tue, 30 Apr 2019 03:05:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556618717; cv=none; d=google.com; s=arc-20160816; b=fo07Dehts+C2F4zl9ZyZq9/y9N+omCmg8UcG3CHDTCWXRy5fjfyhf0AfDytJgpom3x 8E2z1vCGuboXkuoNiYu/EWx0lbf/2cbB1JQieTas/rtMV7aCADz/tghnLe29bqwh7CCs EKE069xcRlN6+LWAmotHPIAqH5ajJas69ZwfPhCKNUpEbC+EH9HRTPSr+g/1iLl8iV0T Srip1Mp4d91423VtDqyVTuy/XkgP3NNCiOIk5XwkvAfCXsraq06ybNeH8vjFs2P1WKqy I6tmWWTFhZGJ3W2aILSIYl+b6witZ1GMJdrRiEnJIH6SbsPHjORcJwx9bbYrWijL16qP +pBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=39jQJu1pe1SwtBVRvFUc6v25BF8YLDJOZ0iwNDid4sw=; b=oVjtpI/xW+mqsAhI5dGhF5ys4kuTAKk+CRKCs7403VJv/aSxtjbjmwi0HMDlkfW2i4 gBTDp62dDCwKduJa8+GJDQ+pG/JcedH1rltZYw/fKDwgVecbCP22fvpG6Ah4QQ5AcJcF ysG61hulRMmGY6rXmXCVqJtYcCVz5rvpIbTCpniC6z/tu2g+GwD+n62Fc03AfB0UDVT2 v7PdGdrZ1Wx8SGnEXNzUcHe7Xg2tUn9lTW11NIsOnVv02h0rvnMFSYQujEiJC/eHE9le tg0YhAPQ/8AwvMCpiglhNzroL0oRurb74FC7/ZSaNqe/RJcsGYMjzH+D05a7k1FXkEGg O9nQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=fdnM3+wG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h8si36130038pgg.573.2019.04.30.03.05.00; Tue, 30 Apr 2019 03:05:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=fdnM3+wG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726930AbfD3KDW (ORCPT + 99 others); Tue, 30 Apr 2019 06:03:22 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:39268 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726012AbfD3KDW (ORCPT ); Tue, 30 Apr 2019 06:03:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=39jQJu1pe1SwtBVRvFUc6v25BF8YLDJOZ0iwNDid4sw=; b=fdnM3+wGbwVZVEY3nKXdhgTFR dq4kMJ+M/Fo86URyNEmTqhegBWXLApJtT1cQCGRZhE6IZgMwQiHRjEo8hJGtuqkxLyMjmKEDAKuyQ icr8yNzbCiQ2e41Qa2oBfmZ4FideevgGfmHlEa+fU+m6ajhdDFVFRLXOlA82MPsKlWYhwJ2HkMo2S C7O+ZIHCpudnuP31kKcPZG6CLicEOjvLI8IBqI0uPtvnpFts0NHIognu5ezPVFBey150X1IQ/WB4Y Qd2ezr6+P5S1kKWDn8btJxjGsTt80qQaX25iU7shLfYzMj9TAt0VaxKnfY7mb6CKWQEmp4GEAEFhn /ntbriRvg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1hLPbd-0000S6-5u; Tue, 30 Apr 2019 10:03:21 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 9B6DD29A242E4; Tue, 30 Apr 2019 12:03:18 +0200 (CEST) Date: Tue, 30 Apr 2019 12:03:18 +0200 From: Peter Zijlstra To: "Paul E. McKenney" Cc: linux-kernel@vger.kernel.org, andrea.parri@amarulasolutions.com Subject: Re: Question about sched_setaffinity() Message-ID: <20190430100318.GP2623@hirez.programming.kicks-ass.net> References: <20190427180246.GA15502@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190427180246.GA15502@linux.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 27, 2019 at 11:02:46AM -0700, Paul E. McKenney wrote: > This actually passes rcutorture. But, as Andrea noted, not klitmus. > After some investigation, it turned out that klitmus was creating kthreads > with PF_NO_SETAFFINITY, hence the failures. But that prompted me to > put checks into my code: After all, rcutorture can be fooled. > > void synchronize_rcu(void) > { > int cpu; > > for_each_online_cpu(cpu) { > sched_setaffinity(current->pid, cpumask_of(cpu)); > WARN_ON_ONCE(raw_smp_processor_id() != cpu); > } > } > > This triggers fairly quickly, usually in less than a minute of rcutorture > testing. > > And further investigation shows that sched_setaffinity() > always returned 0. > Is this expected behavior? Is there some configuration or setup that I > might be missing? ISTR there is hotplug involved in RCU torture? In that case, it can be sched_setaffinity() succeeds to place us on a CPU, which CPU hotplug then takes away. So when we run the WARN thingy, we'll be running on a different CPU than expected. If OTOH, your loop is written like (as it really should be): void synchronize_rcu(void) { int cpu; cpus_read_lock(); for_each_online_cpu(cpu) { sched_setaffinity(current->pid, cpumask_of(cpu)); WARN_ON_ONCE(raw_smp_processor_id() != cpu); } cpus_read_unlock(); } Then I'm not entirely sure how we can return 0 and not run on the expected CPU. If we look at __set_cpus_allowed_ptr(), the only paths out to 0 are: - if the mask didn't change - if we already run inside the new mask - if we migrated ourself with the stop-task - if we're not in fact running That last case should never trigger in your circumstances, since @p == current and current is obviously running. But for completeness, the wakeup of @p would do the task placement in that case.