All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tuo Li via Ocfs2-devel <ocfs2-devel@oss.oracle.com>
To: mark@fasheh.com, jlbec@evilplan.org,
	Joseph Qi <joseph.qi@linux.alibaba.com>,
	akpm@linux-foundation.org
Cc: baijiaju1990@outlook.com,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [BUG] ocfs2/dlm: possible data races in dlm_drop_lockres_ref_done() and dlm_get_lock_resource()
Date: Tue, 13 Jun 2023 15:58:28 +0800	[thread overview]
Message-ID: <32dc96d0-2d27-47e4-448a-a42e9ce352af@gmail.com> (raw)

Hello,

Our static analysis tool finds some possible data races in the OCFS2 file
system in Linux 6.4.0-rc6.

In most calling contexts, the variables  such as res->lockname.name and
res->owner are accessed with holding the lock res->spinlock. Here is an
example:

   lockres_seq_start() --> Line 539 in dlmdebug.c
     spin_lock(&res->spinlock); --> Line 574 in dlmdebug.c (Lock 
res->spinlock)
     dump_lockres(res, ...); --> Line 575 in fs/ocfs2/dlm/dlmdebug.c
       stringify_lockname(res->lockname.name, ...);  --> Line 493 in 
dlmdebug.c (Access res->lockname.name)
       scnprintf(..., res->owner, ...);  -->Line 498 in dlmdebug.c 
(Access res->owner)

However, in the following calling contexts:

   dlm_deref_lockres_worker() --> Line 2439 in dlmmaster.c
     dlm_drop_lockres_ref_done() --> Line 2459 in dlmmaster.c
       lockname = res->lockname.name; --> Line 2416 in dlmmaster.c 
(Access res->lockname.name)

   dlm_get_lock_resource() --> Line 701 in dlmmaster.c
     if (res->owner != dlm->node_num) --> Line 1023 in dlmmaster.c 
(Access res->owner)

The variables res->lockname.name and res->owner are accessed respectively
without holding the lock res->spinlock, and thus data races can occur.

I am not quite sure whether these possible data races are real and how 
to fix
them if they are real.

Any feedback would be appreciated, thanks!

Reported-by: BassCheck <bass@buaa.edu.cn>

Best wishes,
Tuo Li

_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel

WARNING: multiple messages have this Message-ID (diff)
From: Tuo Li <islituo@gmail.com>
To: mark@fasheh.com, jlbec@evilplan.org,
	Joseph Qi <joseph.qi@linux.alibaba.com>,
	akpm@linux-foundation.org
Cc: ocfs2-devel@oss.oracle.com,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	baijiaju1990@outlook.com
Subject: [BUG] ocfs2/dlm: possible data races in dlm_drop_lockres_ref_done() and dlm_get_lock_resource()
Date: Tue, 13 Jun 2023 15:58:28 +0800	[thread overview]
Message-ID: <32dc96d0-2d27-47e4-448a-a42e9ce352af@gmail.com> (raw)

Hello,

Our static analysis tool finds some possible data races in the OCFS2 file
system in Linux 6.4.0-rc6.

In most calling contexts, the variables  such as res->lockname.name and
res->owner are accessed with holding the lock res->spinlock. Here is an
example:

   lockres_seq_start() --> Line 539 in dlmdebug.c
     spin_lock(&res->spinlock); --> Line 574 in dlmdebug.c (Lock 
res->spinlock)
     dump_lockres(res, ...); --> Line 575 in fs/ocfs2/dlm/dlmdebug.c
       stringify_lockname(res->lockname.name, ...);  --> Line 493 in 
dlmdebug.c (Access res->lockname.name)
       scnprintf(..., res->owner, ...);  -->Line 498 in dlmdebug.c 
(Access res->owner)

However, in the following calling contexts:

   dlm_deref_lockres_worker() --> Line 2439 in dlmmaster.c
     dlm_drop_lockres_ref_done() --> Line 2459 in dlmmaster.c
       lockname = res->lockname.name; --> Line 2416 in dlmmaster.c 
(Access res->lockname.name)

   dlm_get_lock_resource() --> Line 701 in dlmmaster.c
     if (res->owner != dlm->node_num) --> Line 1023 in dlmmaster.c 
(Access res->owner)

The variables res->lockname.name and res->owner are accessed respectively
without holding the lock res->spinlock, and thus data races can occur.

I am not quite sure whether these possible data races are real and how 
to fix
them if they are real.

Any feedback would be appreciated, thanks!

Reported-by: BassCheck <bass@buaa.edu.cn>

Best wishes,
Tuo Li

             reply	other threads:[~2023-06-13  7:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-13  7:58 Tuo Li via Ocfs2-devel [this message]
2023-06-13  7:58 ` [BUG] ocfs2/dlm: possible data races in dlm_drop_lockres_ref_done() and dlm_get_lock_resource() Tuo Li
  -- strict thread matches above, loose matches on Subject: below --
2023-06-13  8:23 [Ocfs2-devel] " Tuo Li via Ocfs2-devel
2023-06-16  2:11 ` Joseph Qi via Ocfs2-devel
2023-06-16  3:27   ` Tuo Li via Ocfs2-devel

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=32dc96d0-2d27-47e4-448a-a42e9ce352af@gmail.com \
    --to=ocfs2-devel@oss.oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=baijiaju1990@outlook.com \
    --cc=islituo@gmail.com \
    --cc=jlbec@evilplan.org \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@fasheh.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.