Kernel panic in gfs2_inplace_reserve

Issue:

System crashing in gfs2_dirent_find_space. Example call trace:

        gfs2_dirent_find_space+0x0/0x50 [gfs2]
        gfs2_dirent_search+0xff/0x1a0 [gfs2]
        gfs2_rename+0x6b1/0x8c0 [gfs2]
        gfs2_rename+0x128/0x8c0 [gfs2]
        gfs2_rename+0x146/0x8c0 [gfs2]
        gfs2_rename+0x16c/0x8c0 [gfs2]
        cache_alloc_refill+0x15b/0x240
        gfs2_rename+0xd5/0x8c0 [gfs2]
        vfs_rename+0x3ab/0x440
        sys_renameat+0x1da/0x240
        _atomic_dec_and_lock+0x55/0x80
        mntput_no_expire+0x30/0x110
        sys_fchmodat+0x73/0x100
        sys_newstat+0x36/0x50
        sys_rename+0x1b/0x20
        system_call_fastpath+0x16/0x1b
        

Environment:

  • Red Hat Enterprise Linux Server 6 (with the Resilient Storage Add on)
  • Specifically, this issue only occurs on kernel-2.6.32-358.2.1.el6 and 2.6.32-358.6.1.el6. See this solution if you have an earlier kernel.
  • Red Hat High Availability Cluster (Cluster Suite) with 2 or more nodes.
  • Global File System 2(GFS2) filesystem.

Resolution:

  • A solution in the form of a bug fix will be available in a future version of Red Hat Enterprise Linux 6.
  • If you believe you have encountered this issue and you have a current, valid support contract, please contact Red Hat Support for assistance with this issue.
  • Please note that this issue does not cause filesystem corruption and running fsck.gfs2 should not be required as a result of this issue.

Workaround:

  • The following kernels are recommended as workarounds as they are unaffected by this and other GFS2 issues:
    • The following kernels are recommended as workarounds as they are unaffected by this and other GFS2 issues:
      • kernel-2.6.32-279.14.1.el6
      • kernel-2.6.32-279.19.1.el6
      • kernel-2.6.32-279.22.1.el6
    • Another potential workaround if you must use an affected kernel is to always ensure that the destination directory has been written to (i.e use touch to make a zero sized file) before executing the rename.

Root Cause:

  • An error in backporting the block reservation feature from upstream resulted in a missing allocation of a reservation structure when an allocation is required during the rename system call.
  • Renaming a file system object (for example, file or directory) requires a block allocation for the destination directory.
    • If the destination directory had not had a reservation structure allocated, a NULL pointer dereference occurred, leading to a kernel panic.


Back to top...

+ Recent posts