Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp681860pxj; Thu, 10 Jun 2021 10:06:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwvVxHMBv9B2xmsCFTlH/cI2hOER9A8rVg0ZKPs81oZSc8OqdRSHrRLDTEYeHIaj2OxXhLt X-Received: by 2002:aa7:d0d4:: with SMTP id u20mr491447edo.228.1623344794963; Thu, 10 Jun 2021 10:06:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623344794; cv=none; d=google.com; s=arc-20160816; b=QcAK/lAsTeA+bDt84/Z9xYKa+kru1/uOiCH9FP9kaNNxQnv6q6Y5iskQczKRZBzY+V W3z23NadAj6ExsvsOv8TpPWemU/QN40iP+XiFnMbvZ5xdn6/+4xc6lQl58o5Ln+Eq87h Qlz9FR1IUyc/ZOTqmRyUxyuqXbri2CM1BwdClolSO4di0ZPC3Lx91hbPbMMTY2Q3sifj uIejM+Fw/j4wgHy59ns7EQaYlWAnDxX5+FWuiKvvDeF+fseZQuoD3UJd2Q7nqSoIiab9 SWZl5TtdE5pedW7ssVBruFtZJlAIK41vFrVDw0VMaMEKxTPntbyJzQ9YIeNvUF9JLEly +Ghw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:reply-to :message-id:subject:cc:to:from:date:dkim-signature; bh=rJSJP8Ay/Zus0CWDPTprfKZH6RcGsA2TKscIroGYvcQ=; b=D0sM8FabCotqtOnU9lqMHKUmsZp4HpWfXdOjoZjGDnQps4O515v4Lsg7Z6sVJGG9Z2 Wj7poevYkq4cMKXFWV+r5IZKiqYI5hFSaBIRIYlizzQLnDLFvP1k/s+JjyLF59JT7dC6 t/oB3WcQYrM7l+qTXOWmm5gteje7W/vFQtMOkBqXi4ILUGyNO85DrtUyecJsSpfEAg+X 5TrpECE7TsPbuKDi1cvOCfC/YrKwkDIki00RPbpUNIw8FxJFCT2vylj/OVazvKi98GPr AZCpdYm4eCs0Cn0gGbdZo7Pd/ThufbZIfXV4R2HjjUtYnaDAN0cr8vzVqoddRTQ+rsCB TO4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YOSOhpDk; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dg8si2646727edb.120.2021.06.10.10.06.10; Thu, 10 Jun 2021 10:06:34 -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=@kernel.org header.s=k20201202 header.b=YOSOhpDk; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230245AbhFJRGd (ORCPT + 99 others); Thu, 10 Jun 2021 13:06:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:41134 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229895AbhFJRGc (ORCPT ); Thu, 10 Jun 2021 13:06:32 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2004B613DD; Thu, 10 Jun 2021 17:04:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623344676; bh=XK8ZV/P/FXmDo57oE98G1FSZMrwBePkO66V8H3l/9jA=; h=Date:From:To:Cc:Subject:Reply-To:From; b=YOSOhpDkT1zNFJfMh4d3NmA3T1fi9fXbh6twcKJeLyAa+phi+0k6djpFb59sCfufW 5VJEo8zbyOqHHfk1juWuMWfrI4Qo/S4iSUR6YY6xueFzwz4BH41hCCJNWe5loPzBbx ZW1s5bS8fZQOUzzJ2/O1uOQ1b0lSGgzVNJiQNIatvq94mvJqavIdOiG3XhYjZy5vL/ Nu+s9f097VgGoMehI1lSHOVE1a3fxxM/5qNzzdIAN9W/gs1U6HGg7d5xSyIZmFmbcY 6FGSae2g9Xif4rRAVXin+ugXk0u05jq3VgsYZJ1uV++ByjOORPA5e/+LuhXkPjJHiT UgI3a86TDaOvg== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id D62125C0611; Thu, 10 Jun 2021 10:04:35 -0700 (PDT) Date: Thu, 10 Jun 2021 10:04:35 -0700 From: "Paul E. McKenney" To: frederic@kernel.org Cc: linux-kernel@vger.kernel.org Subject: Question about a8ea6fc9b089 ("sched: Stop PF_NO_SETAFFINITY from being inherited by various init system threads") Message-ID: <20210610170435.GA2187550@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Frederic, This commit works well, but has the unfortunate side-effect of making smp_processor_id() complain when used in a preemptible region even though the kthread has been pinned onto a single CPU by a call to set_cpus_allowed_ptr(). (Which did return success.) This isn't a big deal -- I can easily switch to raw_smp_processor_id(), which is arguably a better choice anyway because it prevents the complaints from flooding out any real warnings due to error returns from set_cpus_allowed_ptr() or something else unpinning the kthread. Which I am in the process of doing: 516e52e9f5ec ("scftorture: Avoid excess warnings") 475d6d49f21d ("refscale: Avoid excess warnings in ref_scale_reader()") But I figured that I should check to see if this change was in fact intentional. Thanx, Paul