[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAK-6q+gQOQsg5uE2-KioKBip5agCV5AjhXbxgwqngvg8ct=vVQ@mail.gmail.com>
Date: Fri, 29 Aug 2025 12:01:49 -0400
From: Alexander Aring <aahringo@...hat.com>
To: Alessio Attilio <alessio.attilio.dev@...il.com>
Cc: David Teigland <teigland@...hat.com>, gfs2@...ts.linux.dev, linux-kernel@...r.kernel.org,
Alessio Attilio <226562783+SigAttilio@...rs.noreply.github.com>
Subject: Re: [PATCH] fix(dlm): handle unlock/cancel during deferred lock messages
Hi,
On Fri, Aug 29, 2025 at 10:35 AM Alessio Attilio
<alessio.attilio.dev@...il.com> wrote:
>
>
> Hey there.
>
> This fix tackles a tricky race condition that can pop up when an unlock or cancel operation is triggered while a deferred lock message is still being processed. What this patch does is make sure these operations are handled safely, even if the lock is still being resolved through dlm_master_lookup.
>
> The problem I ran into was that, under certain timing scenarios, a lock could be canceled or unlocked while the deferred message was still pending.
depends on how your lock usage might be pretty normal. What exactly is
a "deferred lock message" here?
> This could lead to an inconsistent state or even accessing freed structures.
Do you have any reproducer or more information e.g. stacktrace for
that with a debug kernel?
- Alex
Powered by blists - more mailing lists