There's also an unnecessary INIT_LIST_HEAD() in send_op().
Andreas
---
fs/dlm/plock.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/dlm/plock.c b/fs/dlm/plock.c
index ce1af7986e16..ff439d780cb1 100644
--- a/fs/dlm/plock.c
+++ b/fs/dlm/plock.c
@@ -67,7 +67,6 @@ static void
On Wed, Feb 16, 2022 at 5:16 PM Alexander Aring wrote:
>
> Hi,
>
> On Wed, Feb 16, 2022 at 11:08 AM Andreas Gruenbacher
> wrote:
> >
> > On Wed, Feb 16, 2022 at 4:53 PM Alexander Aring wrote:
> > > There are several sanity checks and recover handling if they occur in
> > > the dlm plock
Good afternoon,
After recently receiving a bug report from Syzbot [0] which was raised
specifically against the Android v5.10 kernel, I spent some time
trying to get to the crux. Firstly I reproduced the issue on the
reported kernel, then did the same using the latest release kernel
v5.16.
The
Hi,
On Wed, Feb 16, 2022 at 11:25 AM Alexander Aring wrote:
>
> Hi,
>
> On Wed, Feb 16, 2022 at 11:16 AM Alexander Aring wrote:
> >
> > Hi,
> >
> > On Wed, Feb 16, 2022 at 11:08 AM Andreas Gruenbacher
> > wrote:
> > >
> > > On Wed, Feb 16, 2022 at 4:53 PM Alexander Aring
> > > wrote:
> > > >
Hi,
On Wed, Feb 16, 2022 at 11:16 AM Alexander Aring wrote:
>
> Hi,
>
> On Wed, Feb 16, 2022 at 11:08 AM Andreas Gruenbacher
> wrote:
> >
> > On Wed, Feb 16, 2022 at 4:53 PM Alexander Aring wrote:
> > > There are several sanity checks and recover handling if they occur in
> > > the dlm plock
Hi,
On Wed, Feb 16, 2022 at 11:08 AM Andreas Gruenbacher
wrote:
>
> On Wed, Feb 16, 2022 at 4:53 PM Alexander Aring wrote:
> > There are several sanity checks and recover handling if they occur in
> > the dlm plock handling. They should never occur otherwise we have a bug
> > in the code. To
On Wed, Feb 16, 2022 at 4:53 PM Alexander Aring wrote:
> There are several sanity checks and recover handling if they occur in
> the dlm plock handling. They should never occur otherwise we have a bug
> in the code. To make such bugs more visible we remove the recover
> handling and add a
This patch changes the log level if a plock is removed when interrupted
from debug to info. Additional it signals now that the plock entity was
removed to let the user know what's happening.
If on a dev_write() a pending plock cannot be find it will signal that
it might have been removed because
Lately the different casting between plock_op and plock_xop and list
holders which was involved showed some issues which were hard to see.
This patch removes the "plock_xop" structure and introduces a
"struct plock_async_data". This structure will be set in "struct plock_op"
in case of
There are several sanity checks and recover handling if they occur in
the dlm plock handling. They should never occur otherwise we have a bug
in the code. To make such bugs more visible we remove the recover
handling and add a WARN_ON() on those sanity checks.
Signed-off-by: Alexander Aring
---
This patch moves the return of FILE_LOCK_DEFERRED a little bit earlier
than checking afterwards again if the request was an asynchronous request.
Signed-off-by: Alexander Aring
---
fs/dlm/plock.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git
Hi,
this patch-series cleanups some plock code handling and remove the
plock_op vs plock_xop casting which had made trouble in the past. Also
I add the logging improvment handling to see when a plock op was not
being found, the wait was interrupted before.
This followed up cleanup patch series
This patch fixes an invalid read showed by KASAN. A unlock will allocate a
"struct plock_op" and a followed send_op() will append it to a global
send_list data structure. In some cases a followed dev_read() moves it
to recv_list and dev_write() will cast it to "struct plock_xop" and access
fields
13 matches
Mail list logo
