Oops due to VFS mount 'shm_mnt' not marked as a long-term internal mount

Solution Verified - Updated -

Issue

  • Oops due to VFS mount shm_mnt not marked as a long-term internal mount

  • The real mount of the VFS mount shm_mnt was de-allocated (via mntfree()) due to a final call to mntput(); subsequently in the free mount code path, the corresponding super_block object i.e. m->mnt_sb was subsequently de-allocated too

  • According to the Oops, the system crash occurred in shmem_reserve_inode(), since the s_fs_info field of the super_block object was unexpectedly NULL:

  • The following is an excerpt of dmesg

[5777285.223382] <26>Unable to handle kernel paging request for data at
                     address 0x00000030
[5777285.223395] <26>Faulting instruction address: 0xc000000000280ed8
[5777285.223399] <82>Oops: Kernel access of bad area, sig: 11 [#1]
  • The Faulting instruction address (0xc000000000280ed8) translates to mm/shmem.c:203

  • The following is an excerpt of shmem_reserve_inode()

             200 static int shmem_reserve_inode(struct super_block *sb)
             201 {
             202         struct shmem_sb_info *sbinfo = SHMEM_SB(sb);
  (1) ---->  203         if (sbinfo->max_inodes) {
  • The max_inodes field of struct shmem_sb_info is at offset +0x30
crash> p &((struct shmem_sb_info *)0x0)->max_inodes
$1 = (unsigned long *) 0x30

As seen from the excerpt of shmem_reserve_inode() above, it is not expected for sb->s_fs_info to be NULL.

Environment

  • Red Hat Enterprise Linux 7.5

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.

Current Customers and Partners

Log in for full access

Log In

New to Red Hat?

Learn more about Red Hat subscriptions

Using a Red Hat product through a public cloud?

How to access this content