From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C8C93DCD8B for ; Tue, 30 Jun 2026 18:26:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782844002; cv=none; b=UYEhTKQI18z1uYFVF1Kvam3XTk0zkMCh5WvkYbt9pxlZUvtyEHU8RcLLwAi4FiFQ8FnlNj54DO6vQQMv/DsCgcXj4f18ifvRn17fmtfzHyW/VhubMTG8vXXNU7t8BCag4IwYGXalsElkYku4YFca7E1sCju4ThHfHNhKps1+dOY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782844002; c=relaxed/simple; bh=iGv7dt0NCz0LZ74docjwKrjTWo3UrigqhAsaMZv+Wz8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QC8mYZ6/o3ViFWPNuKO74MSgWioV9O6+ikpRtGcVDOcGd3bGVCV46i8Mq2FDWh5Vj+Lpa4DJUNaG+6nL9LUEoGjDF8uYZ2zp5uhmdzyB/n55h8SMk7vJSpw3Tto4N9OEqHBIuywM/HeRFGomZHHBLgx2ru/kUeVOhdfjATlTfmc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TiRIpN/o; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TiRIpN/o" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782844000; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UX+VoizyTeQul5m1lulCtYJrGZJDJMrvwsBl7iUZhXw=; b=TiRIpN/o2Y28Szjw8s2db2JPPonmeooQHL/20MDLFRRNoC8aaTcRBxcdmlfYGR+gnfd3I8 RtdbSPUY2zeOK2sxd3gaoS3FBmnkIvomnUGjWKSUlmL9XU+x6GPLsvz6VnMrLwzRgGQMmi eW7jSD3y/nWMQ12wJIvtFFP/azy11gE= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-558-lcGsQxFYMFqHQWQeKoZNVQ-1; Tue, 30 Jun 2026 14:26:37 -0400 X-MC-Unique: lcGsQxFYMFqHQWQeKoZNVQ-1 X-Mimecast-MFC-AGG-ID: lcGsQxFYMFqHQWQeKoZNVQ_1782843996 Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 26BC81955D6D; Tue, 30 Jun 2026 18:26:36 +0000 (UTC) Received: from [10.2.17.12] (unknown [10.2.17.12]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0688236512; Tue, 30 Jun 2026 18:26:33 +0000 (UTC) Message-ID: <5b4114fa-b716-4235-b67a-d1d8d1dc6840@redhat.com> Date: Tue, 30 Jun 2026 14:26:32 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] locking/lockdep: skip irq save/restore in hardirq context in lock_release() To: Deepanshu Kartikey Cc: peterz@infradead.org, mingo@redhat.com, will@kernel.org, boqun@kernel.org, linux-kernel@vger.kernel.org, syzbot+0635dc2e2c3c21a6aa04@syzkaller.appspotmail.com References: <20260629041119.87790-1-kartikey406@gmail.com> <3df76993-ae50-4c28-a78e-fbd1db53e9a0@redhat.com> Content-Language: en-US From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 On 6/30/26 4:13 AM, Deepanshu Kartikey wrote: > On Tue, Jun 30, 2026 at 10:28 AM Waiman Long wrote: >> >> I looked at the generated code of raw_local_irq_restore(): >> >> ./arch/x86/include/asm/irqflags.h: >> 146 return !(flags & X86_EFLAGS_IF); >> 0x00000000000082b9 <+9>: test $0x200,%edi >> 0x00000000000082bf <+15>: je 0x82c2 >> >> 42 asm volatile("sti": : :"memory"); >> 0x00000000000082c1 <+17>: sti >> >> kernel/cgroup/cpuset.c: >> 4553 } >> 0x00000000000082c2 <+18>: jmp 0x82c7 >> >> sti should only be called if the saved flags has the IF bit set. In >> hardirq context, the IF bit shouldn't be set. Is my interpretation correct? >> >> Regards, >> Longman >> > You are correct - in hardirq context, the IF bit in EFLAGS should > already be 0 (IRQs disabled by CPU on interrupt entry). Therefore > raw_local_irq_restore() should not execute sti. > > However, the syzkaller reproducer consistently triggers the RCU stall, > indicating a real issue exists. Our fix is correct regardless of the > root cause - by completely skipping the raw_local_irq_save/restore > dance in hardirq context, we avoid any potential issues in this path. > > Hardirq handlers must never manipulate IRQ state mid-execution since > the CPU hardware manages it automatically on entry/exit. This is a > fundamental rule of interrupt handling. > > If you have insights into the actual root cause, we'd appreciate > understanding it better. > > Thank you for the thorough review. > As I have said previously, the only possible explanation that I can think of is speculative execution. I think the x86 sti instruction is not serializing. Depending on the actual processor, it may be possible for a CPU to speculatively execute an sti instruction and enable interrupt before it realizes that the speculation is incorrect and rewind it. If so, adding a in_hardirq() conditional check may have just further narrow the window that problem doesn't show up anymore. So what are those processors that are showing test failures? As an experiment, you can try to insert some delay between the IF flag check and the actual sti instruction to see if it can also avoid the test failures, like diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h index 6f25de05ed58..174962fcc37c 100644 --- a/arch/x86/include/asm/irqflags.h +++ b/arch/x86/include/asm/irqflags.h @@ -155,8 +155,10 @@ static __always_inline int arch_irqs_disabled(void)  static __always_inline void arch_local_irq_restore(unsigned long flags)  { -       if (!arch_irqs_disabled_flags(flags)) +       if (!arch_irqs_disabled_flags(flags)) { +               smp_mb();                 arch_local_irq_enable(); +       }  }  #endif /* !__ASSEMBLER__ */ If it is the real root cause, we would have to contact some Intel/AMD engineers with connection to their CPU hardware side to figure out the best way forward. Your current patch is currently not mergeable without a clear RCA. Cheers, Longman