[Ocfs2-devel] [PATCH] ocfs2: fix error handling during mounting stage

heming.zhao at suse.com heming.zhao at suse.com
Tue Apr 5 10:26:50 UTC 2022


On 4/5/22 00:40, Heming Zhao wrote:
> This is draft version, It only passed compiling & mount/umount test.
> I want to know if my idea is acceptable for maintainers.
> 
> There left one issue: mounting crash when no dlm connection. I still
> can't find out a better solution without directly free inode memory.
> So I marked the related function (ocfs2_release_system_inodes) with
> comment: "/* FIXME crash when no journal */"
> 
> Signed-off-by: Heming Zhao <heming.zhao at suse.com>
> ---
>   fs/ocfs2/reservations.c |   4 +-
>   fs/ocfs2/reservations.h |   2 +-
>   fs/ocfs2/super.c        | 156 +++++++++++++++++++++++++---------------
>   3 files changed, 99 insertions(+), 63 deletions(-)
> 

For the issue: free inode trigger kernel crash when journal un-init.



There are three solutions:



1> Revert commit da5e7c87827e8

    For avoiding kernel crash, this make sense for us. I only concerned whether there

    has any non-system inode access before dlm init. And my answer is NO.
  all journal
    replay/recovery handling happen after dlm & journal init done.
  So this method is
    not graceful but workable.


2> My v1 & v2 patch, keep da5e7c87827e8, and do some checks (osb->journal) in

    ocfs2_clear_inode.

    tThe fix code is special for mounting phase, but it will continue working after

    mounting phase. In another word, this method adds useless code in normal inode

    free flow.



3> My v3 patch, directly free inode in mounting phase, but maintainer didn't like.





If maintainer didn't like solutions <1> & <3>, Do we choose solution <1>?



At last, all above three solutons had been test (without crash) based on my latest
patch.

Thanks,
Heming




More information about the Ocfs2-devel mailing list