Hi,
On Thu, Jul 13, 2023 at 10:57 AM Alexander Aring <aahringo@xxxxxxxxxx> wrote:
>
> Hi,
>
> On Thu, Jul 13, 2023 at 10:49 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Thu, Jul 13, 2023 at 10:40:28AM -0400, Alexander Aring wrote:
> > > This patch introduces a new flag DLM_PLOCK_FL_NO_REPLY in case an dlm
> > > plock operation should not send a reply back. Currently this is kind of
> > > being handled in DLM_PLOCK_FL_CLOSE, but DLM_PLOCK_FL_CLOSE has more
> > > meanings that it will remove all waiters for a specific nodeid/owner
> > > values in by doing a unlock operation. In case of an error in dlm user
> > > space software e.g. dlm_controld we get an reply with an error back.
> > > This cannot be matched because there is no op to match in recv_list. We
> > > filter now on DLM_PLOCK_FL_NO_REPLY in case we had an error back as
> > > reply. In newer dlm_controld version it will never send a result back
> > > when DLM_PLOCK_FL_NO_REPLY is set. This filter is a workaround to handle
> > > older dlm_controld versions.
> > >
> > > Fixes: 901025d2f319 ("dlm: make plock operation killable")
> > > Cc: stable@xxxxxxxxxxxxxxx
> > > Signed-off-by: Alexander Aring <aahringo@xxxxxxxxxx>
> >
> > Why is adding a new uapi a stable patch?
> >
>
> because the user space is just to copy the flags back to the kernel. I
> thought it would work. :)
>
* Speaking of dlm_controld here, we don't know any other
implementation which uses this UAPI. If there is another user space
application using it and does a different behaviour then this issue is
unfixable, as we don't know what behaviour we get there.
- Alex
