Oops due to VFS mount 'shm_mnt' not marked as a long-term internal mount
Issue
-
Oops due to VFS mount
shm_mntnot marked as a long-term internal mount -
The real mount of the VFS mount
shm_mntwas de-allocated (viamntfree()) due to a final call tomntput(); subsequently in the free mount code path, the correspondingsuper_blockobject i.e.m->mnt_sbwas subsequently de-allocated too -
According to the Oops, the system crash occurred in
shmem_reserve_inode(), since thes_fs_infofield of thesuper_blockobject was unexpectedlyNULL: -
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_inodesfield of structshmem_sb_infois 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 of over 48,000 articles and solutions.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
