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.129.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 F1CE33E170E for ; Tue, 30 Jun 2026 04:58:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782795485; cv=none; b=e1l9Q7bM+oBJT2F8tIOvpI5miJoFMITs1EXtZmtFLCzk+9rOZzf5Bvu3z5pr/nfAgk1kd/lrnPZp6PSqf/+0nA1CdMRtZjJ8t+InIvTyupFl317AysC33vQaPj1Ok3RHnT5yEVxnjLOSloucpZNZ5AD/HsfVmvrgHc0RRAWC03A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782795485; c=relaxed/simple; bh=bOxxOeMrHu6mW3rfblMSgD0Frwt2nWGddkBAF4AY9xE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fVpm/Lgu3ERRKWh0Ht60mzwX73NWfkqzQxeaYD0E69WTITz0hj78xSfOa18L3Dc6OFhuR2mtCJOUGAaGr11BKUG3zeouhgGkZAk6M4xIilsGDhSkdziR3U9LRI+DuRmobPeSyLoGtgaaNgWkYb3PF7T0A+mV2Nocso8j34krdUM= 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=SAzE69yJ; arc=none smtp.client-ip=170.10.129.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="SAzE69yJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782795483; 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=IefTaPJd8x68NJiQn5u9/4gMdrcIsxqjrQcVdPdTNuw=; b=SAzE69yJHK3LGG1Hh9SchY9k9sieCmK64HgQNYH/0uhKjH8QvBKX2FBEL83B/84wQnhkoQ 130M+I4l3/TGkYHJ4ZgZOxo7DtEU/tMZkKk9wcBtznEOjkPuuFyoaVZnB1A6ZTgQ8aZTOR zeCXk7RUrEuYSQYylY/tR+UgQ3o46FU= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-355-0gGkLBB_NYGkyUdgdwPgOA-1; Tue, 30 Jun 2026 00:57:55 -0400 X-MC-Unique: 0gGkLBB_NYGkyUdgdwPgOA-1 X-Mimecast-MFC-AGG-ID: 0gGkLBB_NYGkyUdgdwPgOA_1782795474 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0349718052DB; Tue, 30 Jun 2026 04:57:54 +0000 (UTC) Received: from [10.2.16.38] (unknown [10.2.16.38]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1CC311956045; Tue, 30 Jun 2026 04:57:50 +0000 (UTC) Message-ID: Date: Tue, 30 Jun 2026 00:57:49 -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.0 on 10.30.177.17 On 6/29/26 7:44 PM, Deepanshu Kartikey wrote: > On Mon, Jun 29, 2026 at 10:57 AM Waiman Long wrote: >> >> On 6/29/26 12:11 AM, Deepanshu Kartikey wrote: >>> lock_release() performs a raw_local_irq_save/restore dance around its >>> validation work. While safe in process and softirq context, this is >>> dangerous in hardirq context where IRQs must remain disabled for the >>> entire duration of the handler. >>> >>> When lock_release() calls raw_local_irq_restore() inside a hardirq >>> handler, it briefly re-enables IRQs, creating a window where a new >>> interrupt can fire before the handler returns. This was observed with >>> taprio's advance_sched() hrtimer callback - the temporary IRQ >>> re-enablement inside lock_release() prevented CPU 0 from acknowledging >>> a pending TLB flush IPI sent by CPU 1 via smp_call_function_many(). >>> CPU 1 then spun indefinitely in csd_lock_wait(), starving the RCU >>> grace-period kthread and triggering an RCU stall with eventual OOM. >> Where exactly is the temporary window when interrupt is enabled during >> the raw_local_irq_restore() call? Interrupt handling is arch specific. >> Is it specific to certain architectures? > On x86, raw_local_irq_restore() executes the 'sti' instruction which > immediately re-enables IRQs. Inside lock_release(), after the validation > work completes, calling raw_local_irq_restore() with the saved flags > will execute 'sti' even when called from hardirq context. > > The window is between the 'sti' instruction (which re-enables IRQs) and > the return from lock_release(). During this window, a new interrupt can > fire and hijack the CPU before the hardirq handler can return and > acknowledge pending IPIs. > > In the syzkaller trace, this window allowed a new IRQ to fire on CPU 0 > after lock_release()'s sti, preventing CPU 0 from ever acknowledging > the TLB flush IPI sent by CPU 1, causing CPU 1 to spin indefinitely in > csd_lock_wait(), which starved the RCU grace-period kthread. > > The fix is correct on all architectures - hardirq context must never > restore IRQs mid-handler since the hardware manages IRQ state for > interrupt entry/exit. This is why we conditionally skip the > irq_save/restore dance when in_hardirq() is true. 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