lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9fa1c126-00f1-95db-93a0-cee52a70062e@huawei.com>
Date: Fri, 22 Aug 2025 17:25:56 +0800
From: Jinjie Ruan <ruanjinjie@...wei.com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: <tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
	<dave.hansen@...ux.intel.com>, <hpa@...or.com>, <prarit@...hat.com>,
	<x86@...nel.org>, <stable@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6.6 RESEND 2/2] x86/irq: Plug vector setup race



On 2025/8/22 16:57, Greg KH wrote:
> On Fri, Aug 22, 2025 at 03:38:25AM +0000, Jinjie Ruan wrote:
>> From: Thomas Gleixner <tglx@...utronix.de>
>>
>> commit ce0b5eedcb753697d43f61dd2e27d68eb5d3150f upstream.
>>

[...]

>>  
>>  /*
>> @@ -273,7 +308,9 @@ DEFINE_IDTENTRY_IRQ(common_interrupt)
>>  	/* entry code tells RCU that we're not quiescent.  Check it. */
>>  	RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU");
>>  
>> -	call_irq_handler(vector, regs);
>> +	if (unlikely(!call_irq_handler(vector, regs)))
>> +		apic_eoi();
>> +
> 
> This chunk does not look correct.  The original commit did not have
> this, so why add it here?  Where did it come from?
> 
> The original patch said:
> 	-       if (unlikely(call_irq_handler(vector, regs)))
> 	+       if (unlikely(!call_irq_handler(vector, regs)))
> 
> And was not an if statement.
> 
> So did you forget to backport something else here?  Why is this not
> identical to what the original was?

The if statement is introduced in commit 1b03d82ba15e ("x86/irq: Install
posted MSI notification handler") which is a patch in patch set
https://lore.kernel.org/all/20240423174114.526704-1-jacob.jun.pan@linux.intel.com/,
but it seems to be a performance optimization patch set, and this patch
includes additional modifications. The context conflict is merely a
simple refactoring, but the cost of the entire round of this patch set
is too high.

> 
> thanks,
> 
> greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ