All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Cen Zhang <zzzccc427@gmail.com>
Cc: mark@fasheh.com, jlbec@evilplan.org, heming.zhao@suse.com,
	ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, baijiaju1990@gmail.com,
	jjzuming@gmail.com
Subject: Re: [PATCH] ocfs2/dlm: drain join handlers before releasing module text
Date: Wed, 21 Oct 2026 21:01:56 +0800	[thread overview]
Message-ID: <71dabc63-7e67-4c25-87eb-17fcdf2ddd3a@linux.alibaba.com> (raw)
In-Reply-To: <pm-ocfs2-objects-candidate-0076-v5-dd198d8a9358ad81f70e@gmail.com>



On 10/20/26 9:04 PM, Cen Zhang wrote:
> The code for a registered DLM handler must remain resident until its
> last invocation finishes. dlm_unregister_net_handlers() only removes
> dlm_join_handlers from the o2net registry. o2net_handler_get() takes a
> kref on the wrapper, but that reference does not pin ocfs2_dlm text.
> o2net_process_message() calls nh_func after dropping o2net_handler_lock.
> 
> With CONFIG_OCFS2_FS_O2CB=m, ocfs2_dlm can be loaded independently of
> ocfs2_stack_o2cb while nodemanager continues handling messages from a
> configured, heartbeating peer. If no dependent module or module reference
> prevents normal unload, the following ordering is possible:
> 
>   Receive worker                       Module unload
>   --------------                       -------------
>   o2net_handler_get()
>     take wrapper kref
>     drop handler lock
>   <preempted>
>                                        dlm_exit()
>                                          unregister handlers
>                                        release DLM module text
>   call saved nh_func
>     in released module text
> 
> Use o2net_unregister_and_flush_handler_list() in the shared DLM
> unregister helper. It first prevents new lookups, then waits for the
> ordered o2net workqueue to drain, including a concurrent destruction of
> that queue. The acquired invocation therefore finishes before dlm_exit()
> returns and the loader releases the callback code. The same helper also
> covers partial registration and dlm_init() error unwind before module
> memory is released.
> 
> Oops report as below:
> 
>     Oops: int3: 0000 [#1] SMP KASAN NOPTI
>     CPU: 2 UID: 0 PID: 54 Comm: kworker/u16:3 Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy)
> 
> Hardware identification omitted.
> 
>     Workqueue: o2net o2net_rx_until_empty [ocfs2_nodemanager]
>     RIP: 0010:0xffffffffc0423871
>     Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc <cc> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
> 
> Register dump omitted.
> 
>     Call Trace:
>      <TASK>
>      ? o2net_rx_until_empty+0x19b1/0x3300 [ocfs2_nodemanager]
>      ? __pfx_o2net_rx_until_empty+0x10/0x10 [ocfs2_nodemanager]
>      ? lock_acquire+0x190/0x300
>      ? process_one_work+0x935/0x1b40
>      ? process_one_work+0x834/0x1b40
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? lock_release+0xc8/0x290
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? process_one_work+0x9a8/0x1b40
>      ? __pfx_process_one_work+0x10/0x10
>      ? lock_acquire+0x190/0x300
>      ? lock_is_held_type+0x8f/0x100
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? worker_thread+0x65c/0xe40
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __kthread_parkme+0x177/0x220
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __pfx_worker_thread+0x10/0x10
>      ? kthread+0x351/0x460
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __pfx_kthread+0x10/0x10
>      ? ret_from_fork+0x659/0x940
>      ? __pfx_ret_from_fork+0x10/0x10
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __switch_to+0x74f/0xf70
>      ? __pfx_kthread+0x10/0x10
>      ? ret_from_fork_asm+0x1a/0x30
>      </TASK>
>     Modules linked in: ocfs2_nodemanager [last unloaded: ocfs2_dlm]
>     ---[ end trace 0000000000000000 ]---
> 
> Fixes: 6714d8e86bf4 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
> Assisted-by: LLM
> ---
>  fs/ocfs2/dlm/dlmdomain.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ocfs2/dlm/dlmdomain.c b/fs/ocfs2/dlm/dlmdomain.c
> index 97bb9400e24b..0f4d29cbce81 100644
> --- a/fs/ocfs2/dlm/dlmdomain.c
> +++ b/fs/ocfs2/dlm/dlmdomain.c
> @@ -2215,7 +2215,7 @@ static LIST_HEAD(dlm_join_handlers);
>  
>  static void dlm_unregister_net_handlers(void)
>  {
> -	o2net_unregister_handler_list(&dlm_join_handlers);
> +	o2net_unregister_and_flush_handler_list(&dlm_join_handlers);
>  }
>  
>  static int dlm_register_net_handlers(void)

dlm_unregister_net_handlers() is also reached from the dlm_init() error
label on failures that happen before any handler was ever registered.
So in case of an empty dlm_join_handlers, o2net_unregister_handler_list()
walks nothing, but o2net_flush_wq() still takes o2net_wq_mutex and drains
the entire o2net workqueue.

Thanks,
Joseph


  reply	other threads:[~2026-10-21 13:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20 13:04 [PATCH] ocfs2/dlm: drain join handlers before releasing module text Cen Zhang
2026-10-21 13:01 ` Joseph Qi [this message]
2026-10-22  9:06   ` Cen Zhang

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=71dabc63-7e67-4c25-87eb-17fcdf2ddd3a@linux.alibaba.com \
    --to=joseph.qi@linux.alibaba.com \
    --cc=baijiaju1990@gmail.com \
    --cc=heming.zhao@suse.com \
    --cc=jjzuming@gmail.com \
    --cc=jlbec@evilplan.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@fasheh.com \
    --cc=ocfs2-devel@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=zzzccc427@gmail.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.