From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 2954B274B39
	for <linux-kernel@vger.kernel.org>; Fri, 27 Feb 2026 16:32:49 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1772209972; cv=none; b=hAplIM48aFR+nFAaT/7Wes1i1Q3OT8wABjQP6ugCk8SWJ3zLnrBsidJwpVoeoHIj6mEHNYdsx+aRENTbyWylzz9P4ANK4A1S1VUbuYtnDIu8MjT7J9SUB10+A2ecKYXSfA0I6ZD5HTt04P+KXdX40Vi8OpI9rJc3P9aLkGSYkqI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1772209972; c=relaxed/simple;
	bh=ezX+tG9JPuiCLyiqGsTR9HMQBnhPZvX/0NEDuxt6BbI=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=uokYGhE8PbFwNn70eCG0os9OWu7imE0NfsM1eqtpe52993XHXOEVdq/t53u/Mt4/h1BGM5arlRilWQdsR2I+qzZf4fs3uocq3neqP5X6jDg+68p1xX+DeEwQP708DadyOXqWi1XVliW+NG3q8cKkMO2Ue9JwmHvSn0j/XCvrk5I=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
	by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7F31D14BF;
	Fri, 27 Feb 2026 08:32:42 -0800 (PST)
Received: from [192.168.0.16] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19])
	by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 809D83F73B;
	Fri, 27 Feb 2026 08:32:44 -0800 (PST)
Message-ID: <4f80f4cb-860c-4c78-b58e-041e62c419ec@arm.com>
Date: Fri, 27 Feb 2026 16:32:37 +0000
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [patch 35/48] entry: Prepare for deferred hrtimer rearming
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
 Anna-Maria Behnsen <anna-maria@linutronix.de>,
 John Stultz <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>,
 Daniel Lezcano <daniel.lezcano@linaro.org>,
 Juri Lelli <juri.lelli@redhat.com>,
 Vincent Guittot <vincent.guittot@linaro.org>,
 Dietmar Eggemann <dietmar.eggemann@arm.com>,
 Steven Rostedt <rostedt@goodmis.org>, Ben Segall <bsegall@google.com>,
 Mel Gorman <mgorman@suse.de>, Valentin Schneider <vschneid@redhat.com>,
 x86@kernel.org, Frederic Weisbecker <frederic@kernel.org>,
 Eric Dumazet <edumazet@google.com>
References: <20260224163022.795809588@kernel.org>
 <20260224163431.066469985@kernel.org>
 <51f8535f-b98c-48e3-ba7b-f28759a92c16@arm.com>
 <20260227162521.GI606826@noisy.programming.kicks-ass.net>
Content-Language: en-US
From: Christian Loehle <christian.loehle@arm.com>
In-Reply-To: <20260227162521.GI606826@noisy.programming.kicks-ass.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 2/27/26 16:25, Peter Zijlstra wrote:
> On Fri, Feb 27, 2026 at 03:57:55PM +0000, Christian Loehle wrote:
> 
>>> @@ -239,7 +252,7 @@ static __always_inline void __exit_to_us
>>>  /* Temporary workaround to keep ARM64 alive */
>>>  static __always_inline void exit_to_user_mode_prepare_legacy(struct pt_regs *regs)
>>>  {
>>> -	__exit_to_user_mode_prepare(regs);
>>> +	__exit_to_user_mode_prepare(regs, EXIT_TO_USER_MODE_WORK);
>>
>> Should this also be EXIT_TO_USER_MODE_WORK_IRQ?
>> I guess it doesn't really matter for now (since arm64 doesn't have the generic entry
>> path and generic TIF bits yet and therefore HRTIMER_REARM_DEFERRED=n), but I've been
>> playing around with the this series, the generic entry series
>> https://lore.kernel.org/lkml/20260203133728.848283-1-ruanjinjie@huawei.com
>> (and using generic TIF bits) and noticed this.
> 
> I'm confused; if ARM64 goes GENERIC_ENTRY, its use of legacy should go
> away and we can delete that whole thing, no?

Duh, the confusion was on my side
Let me check why the conversion again and see why it wouldn't, if there's a reason...