[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