mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Cen Zhang <zzzccc427@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
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 v2] ocfs2: stop recovery before shutting down local allocators
Date: Fri, 30 Oct 2026 11:34:13 +0800	[thread overview]
Message-ID: <992c4f5c-e9d0-4768-a53e-8a581b3632b3@linux.alibaba.com> (raw)
In-Reply-To: <pm-ocfs2-objects-candidate-0019-v8-574dd69fd3f47f56348b@gmail.com>



On 10/29/26 2:57 PM, Cen Zhang wrote:
> Recovery completion needs the local allocators until it has finished
> reclaiming a failed node's allocation window and truncate log. During
> unmount, quota recovery is stopped first, but that leaves recovery_state
> at OCFS2_REC_QUOTA_DISABLED. New non-quota recovery can still start.
> 
> ocfs2_truncate_log_shutdown() drains existing completion work and releases
> osb_tl_bh before ocfs2_recovery_exit() closes that publication path:
> 
>   Unmount                             Recovery
>   -------                             --------
>   stop quota recovery; disable quotas
>   truncate_log_shutdown()
>     flush existing completion work
>                                       recover another failed node
>                                         queue completion
>     flush local log; release buffer
>                                       complete_truncate_log_recovery()
>                                         use released osb_tl_bh
>   recovery_exit(): disable and drain
> 
> An extra buffer reference alone would still let completion append new
> records after the final truncate-log flush.
> 
> Split stopping and draining recovery from freeing its state. Stop all
> recovery producers and drain completion work before shutting down either
> local allocator. Keep recovery-state release at its existing later point,
> so its lifetime relative to other teardown users stays unchanged. The
> second stop at recovery_exit() is harmless once recovery is disabled.
> 
> KASAN report as below:
> 
>     BUG: KASAN: slab-use-after-free in ocfs2_truncate_log_needs_flush+0x23d/0x360
>     Read of size 8 at addr ffff8881093711e8 by task kworker/u16:3/53
>     
>     CPU: 0 UID: 0 PID: 53 Comm: kworker/u16:3 Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) 
>     Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
>     Workqueue: ocfs2_wq ocfs2_complete_recovery
>     Call Trace:
>      <TASK>
>      dump_stack_lvl+0x93/0xd0
>      print_report+0xce/0x630
>      ? ocfs2_truncate_log_needs_flush+0x23d/0x360
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __virt_addr_valid+0x20e/0x420
>      ? ocfs2_truncate_log_needs_flush+0x23d/0x360
>      kasan_report+0xe0/0x110
>      ? ocfs2_truncate_log_needs_flush+0x23d/0x360
>      ocfs2_truncate_log_needs_flush+0x23d/0x360
>      ? __pfx_ocfs2_truncate_log_needs_flush+0x10/0x10
>      ? __pfx_down_write+0x10/0x10
>      ocfs2_complete_truncate_log_recovery+0x315/0x780
>      ? trace_hardirqs_on+0x18/0x160
>      ? __pfx_ocfs2_complete_truncate_log_recovery+0x10/0x10
>      ? ocfs2_complete_recovery+0x666/0x11b0
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? kfree+0x308/0x580
>      ocfs2_complete_recovery+0x676/0x11b0
>      ? __pfx_ocfs2_complete_recovery+0x10/0x10
>      ? reacquire_held_locks+0xdd/0x200
>      ? process_one_work+0x7c8/0x1b40
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? lock_acquire+0x190/0x300
>      ? __pfx_autoremove_wake_function+0x10/0x10
>      ? 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>
>     
>     Allocated by task 538:
>      kasan_save_stack+0x33/0x60
>      kasan_save_track+0x14/0x30
>      __kasan_slab_alloc+0x89/0x90
>      kmem_cache_alloc_noprof+0x20b/0x5c0
>      alloc_buffer_head+0x26/0x120
>      folio_alloc_buffers+0x122/0x1d0
>      bdev_getblk+0x299/0x4f0
>      ocfs2_read_blocks_sync+0x513/0xbc0
>      ocfs2_iget+0x9cd/0x1a00
>      ocfs2_get_system_file_inode+0x25e/0x7a0
>      ocfs2_fill_super+0x1b05/0x3930
>      get_tree_bdev_flags+0x35d/0x5f0
>      vfs_get_tree+0x93/0x320
>      fc_mount+0x1d/0x200
>      path_mount+0x592/0x1e00
>      __x64_sys_mount+0x24b/0x2d0
>      do_syscall_64+0x114/0x620
>      entry_SYSCALL_64_after_hwframe+0x77/0x7f
>     
>     Freed by task 553:
>      kasan_save_stack+0x33/0x60
>      kasan_save_track+0x14/0x30
>      kasan_save_free_info+0x3b/0x60
>      __kasan_slab_free+0x5f/0x80
>      kmem_cache_free+0x242/0x580
>      free_buffer_head+0x4b/0xc0
>      try_to_free_buffers+0x1dc/0x330
>      ocfs2_truncate_log_shutdown+0x789/0x1290
>      ocfs2_dismount_volume+0x1da/0x940
>      generic_shutdown_super+0x15f/0x490
>      kill_block_super+0x40/0xa0
>      deactivate_locked_super+0xae/0x120
>      deactivate_super+0xa2/0xc0
>      cleanup_mnt+0x217/0x450
>      task_work_run+0x144/0x230
>      exit_to_user_mode_loop+0x17d/0x570
>      do_syscall_64+0x4d1/0x620
>      entry_SYSCALL_64_after_hwframe+0x77/0x7f
>     
>     The buggy address belongs to the object at ffff8881093711c0
>      which belongs to the cache buffer_head of size 160
>     The buggy address is located 40 bytes inside of
>      freed 160-byte region [ffff8881093711c0, ffff888109371260)
>     
>     The buggy address belongs to the physical page:
>     page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x109371
>     flags: 0x200000000000000(node=0|zone=2)
>     page_type: f5(slab)
>     raw: 0200000000000000 ffff8881008883c0 dead000000000100 dead000000000122
>     raw: 0000000000000000 0000000000120012 00000000f5000000 0000000000000000
>     page dumped because: kasan: bad access detected
>     
>     Memory state around the buggy address:
>      ffff888109371080: 00 00 00 00 fc fc fc fc fc fc fc fc 00 00 00 00
>      ffff888109371100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>     >ffff888109371180: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
>                                                               ^
>      ffff888109371200: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
>      ffff888109371280: fc fc fc fc 00 00 00 00 00 00 00 00 00 00 00 00
>     ==================================================================
> 
> Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Suggested-by: Joseph Qi <joseph.qi@linux.alibaba.com>
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>

Looks fine.
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>

      reply	other threads:[~2026-10-30  3:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29  6:57 Cen Zhang
2026-10-30  3:34 ` Joseph Qi [this message]

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=992c4f5c-e9d0-4768-a53e-8a581b3632b3@linux.alibaba.com \
    --to=joseph.qi@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®