From: Andreas Gruenbacher <agruenba@redhat.com>
To: Alexander Aring <aahringo@redhat.com>
Cc: gfs2 <gfs2@lists.linux.dev>,
teigland@redhat.com, mark@fasheh.com, jlbec@evilplan.org,
joseph.qi@linux.alibaba.com, ocfs2-devel@lists.linux.dev
Subject: Re: [PATCHv3 v6.5-rc2 2/3] fs: dlm: allow to F_SETLKW getting interrupted
Date: Tue, 26 Mar 2024 12:31:20 +0100 [thread overview]
Message-ID: <CAHc6FU6ii3NXm-_eraNTW-UEKEuR5gr+Qi2WeefRxdxH-GJrtw@mail.gmail.com> (raw)
In-Reply-To: <CAK-6q+h8nUXKX0ecFXeHxc5BPONXrtfD+sOGcDgaWWuvWobTEQ@mail.gmail.com>
On Tue, Mar 26, 2024 at 1:32 AM Alexander Aring <aahringo@redhat.com> wrote:
> Hi,
>
> On Mon, Mar 25, 2024 at 11:09 AM Andreas Gruenbacher
> <agruenba@redhat.com> wrote:
> >
> > On Tue, Jul 18, 2023 at 8:07 PM Alexander Aring <aahringo@redhat.com> wrote:
> > > This patch implements dlm plock F_SETLKW interruption feature. If a
> > > blocking posix lock request got interrupted in user space by a signal a
> > > cancellation request for a non granted lock request to the user space
> > > lock manager will be send. The user lock manager answers either with
> > > zero or a negative errno code. A errno of -ENOENT signals that there is
> > > currently no blocking lock request waiting to being granted. In case of
> > > -ENOENT it was probably to late to request a cancellation and the
> > > pending lock got granted. In any error case we will wait until the lock
> > > is being granted as cancellation failed, this causes also that in case
> > > of an older user lock manager returning -EINVAL we will wait as
> > > cancellation is not supported which should be fine. If a user requires
> > > this feature the user should update dlm user space to support lock
> > > request cancellation.
> > >
> > > Signed-off-by: Alexander Aring <aahringo@redhat.com>
> > > ---
> > > fs/dlm/plock.c | 56 ++++++++++++++++++++++------------
> > > include/uapi/linux/dlm_plock.h | 1 +
> > > 2 files changed, 37 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/fs/dlm/plock.c b/fs/dlm/plock.c
> > > index a34f605d8505..a8ffa0760913 100644
> > > --- a/fs/dlm/plock.c
> > > +++ b/fs/dlm/plock.c
> > > @@ -74,30 +74,26 @@ static void send_op(struct plock_op *op)
> > > wake_up(&send_wq);
> > > }
> > >
> > > -/* If a process was killed while waiting for the only plock on a file,
> > > - locks_remove_posix will not see any lock on the file so it won't
> > > - send an unlock-close to us to pass on to userspace to clean up the
> > > - abandoned waiter. So, we have to insert the unlock-close when the
> > > - lock call is interrupted. */
> > > -
> > > -static void do_unlock_close(const struct dlm_plock_info *info)
> > > +static int do_lock_cancel(const struct dlm_plock_info *orig_info)
> > > {
> > > struct plock_op *op;
> > > + int rv;
> > >
> > > op = kzalloc(sizeof(*op), GFP_NOFS);
> > > if (!op)
> > > - return;
> > > + return -ENOMEM;
> > > +
> > > + op->info = *orig_info;
> > > + op->info.optype = DLM_PLOCK_OP_CANCEL;
> > > + op->info.wait = 0;
> > >
> > > - op->info.optype = DLM_PLOCK_OP_UNLOCK;
> > > - op->info.pid = info->pid;
> > > - op->info.fsid = info->fsid;
> > > - op->info.number = info->number;
> > > - op->info.start = 0;
> > > - op->info.end = OFFSET_MAX;
> > > - op->info.owner = info->owner;
> > > -
> > > - op->info.flags |= DLM_PLOCK_FL_CLOSE;
> > > send_op(op);
> > > + wait_event(recv_wq, (op->done != 0));
> > > +
> > > + rv = op->info.rv;
> > > +
> > > + dlm_release_plock_op(op);
> > > + return rv;
> > > }
> > >
> > > int dlm_posix_lock(dlm_lockspace_t *lockspace, u64 number, struct file *file,
> > > @@ -156,7 +152,7 @@ int dlm_posix_lock(dlm_lockspace_t *lockspace, u64 number, struct file *file,
> > > send_op(op);
> > >
> > > if (op->info.wait) {
> > > - rv = wait_event_killable(recv_wq, (op->done != 0));
> > > + rv = wait_event_interruptible(recv_wq, (op->done != 0));
> >
> > It seems that this patch leads to an unnecessary change in behavior
> > when a fatal signal is received (fatal_signal_pending()): before, the
> > process would terminate. Now, it will try to cancel the lock, and when
> > that fails, the process will keep waiting. In case of a fatal signal,
> > can we skip the cancelling and do what we did before?
>
> From my understanding interruptible() "reacts" on everything that is
> also killable() and returns -ERESTARTSYS on "fatal signal". I even
> tested it because wait_event_killable() has an issue, see reproducer
> [0]. The issue was that it cleans too many waiters, the other waiter
> of child in F_SETLKW was also cleared and it will never get a result
> back from dlm_controld. I fixed that with an additional check on pid
> in [1], but I have no idea about other side effects that could have
> occurred as FL_CLOSE is also being used on other parts in the DLM
> plock handling.
>
> I rechecked the behaviour with the cancellation feature and sent
> SIGKILL and the issue was gone without changing anything in user
> space. The only thing I see why it would not have the old behaviour
> (killable - that having the mentioned issue above) is that the
> dlm_controld version is too old. To not run into this known issue we
> just do a wait_event() that does not have those issues.
>
> The mentioned "cancellation fails" - is not that it failed to cancel
> the lock, there is some unexpected behaviour of dlm_controld, only
> then we do wait_event() e.g. when we receive -EINVAL because
> dlm_controld does not understand the op.
What happens on a system that has this kernel change, but doesn't have
the corresponding dlm_controld change for DLM_PLOCK_OP_CANCEL support?
In this scenario, when a process is killed with SIGKILL, the kernel
will send a DLM_PLOCK_OP_CANCEL request to dlm_controld. dlm_controld
doesn't understand the DLM_PLOCK_OP_CANCEL request, so I assume that
it will return a value other than 0 or -ENOENT. As a consequence, we
will end up in wait_event(), which isn't interruptible. So before this
kernel change, the process would be killable, but with this kernel
change, it isn't killable anymore.
I'm worried about this scenario because it isn't entirely unrealistic
for a system to end up with this kernel change but without the
corresponding user-space change.
Andreas
next prev parent reply other threads:[~2024-03-26 11:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230718180721.745569-1-aahringo@redhat.com>
[not found] ` <20230718180721.745569-3-aahringo@redhat.com>
2024-03-25 15:08 ` [PATCHv3 v6.5-rc2 2/3] fs: dlm: allow to F_SETLKW getting interrupted Andreas Gruenbacher
2024-03-26 0:32 ` Alexander Aring
2024-03-26 11:31 ` Andreas Gruenbacher [this message]
2024-03-26 13:02 ` Alexander Aring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHc6FU6ii3NXm-_eraNTW-UEKEuR5gr+Qi2WeefRxdxH-GJrtw@mail.gmail.com \
--to=agruenba@redhat.com \
--cc=aahringo@redhat.com \
--cc=gfs2@lists.linux.dev \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=teigland@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).