Project

General

Profile

Actions

Bug #5372

open

Double lofi mount is toxic

Added by Alexander Kolbasov over 8 years ago. Updated over 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2014-11-26
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:
External Bug:

Description

I did a lofi mount of a file as UFS file system as read-only mount and then attempted to mount another file which resided in this filesystem. The system panicked with assertion failure

fs->fs_ronly == 0, file: ../../common/fs/ufs/ufs_vnops.c, line: 5374

Stack trace:

ffffff01ee5d1490 vpanic()
ffffff01ee5d14c0 0xfffffffffbdf49a8()
ffffff01ee5d1590 ufs_putapage+0x3d0(ffffffb26fc93700, ffffff0151d70ab8, 0, 0, 0, ffffff4a2ab00388)
ffffff01ee5d1660 pvn_vplist_dirty+0x45b(ffffffb26fc93700, 0, fffffffff781ebd0, 0, ffffff4a2ab00388)
ffffff01ee5d1730 ufs_putpages+0x2f8(ffffffb26fc93700, 0, 0, 0, ffffff4a2ab00388)
ffffff01ee5d17c0 ufs_putpage+0x81(ffffffb26fc93700, 0, 0, 0, ffffff4a2ab00388, 0)
ffffff01ee5d1840 fop_putpage+0x4c(ffffffb26fc93700, 0, 0, 0, ffffff4a2ab00388, 0)
ffffff01ee5d18b0 ufs_syncip+0xe7(ffffff5fd3a670b0, 0, 1, b)
ffffff01ee5d1920 ufs_fsync+0x27c(ffffffb26fc93700, 10, ffffff455c4fae08, 0)
ffffff01ee5d1980 fop_fsync+0x44(ffffffb26fc93700, 10, ffffff455c4fae08, 0)
ffffff01ee5d1a60 lofi_strategy_task+0x2e0(ffffffa065d223c0)
ffffff01ee5d1b20 taskq_thread+0x318(ffffffa12d6fe8b0)
ffffff01ee5d1b30 thread_start+8()

The panic is here:

/*
 * Write out a single page, possibly klustering adjacent
 * dirty pages.  The inode lock must be held.
 *
 * LMXXX - bsize < pagesize not done.
 */
/*ARGSUSED*/
int
ufs_putapage(
    struct vnode *vp,
    page_t *pp,
    u_offset_t *offp,
    size_t *lenp,        /* return values */
    int flags,
    struct cred *cr)
{
    struct inode *ip = VTOI(vp);

    ASSERT(RW_LOCK_HELD(&ip->i_contents));

    if (ufsvfsp == NULL) {
        err = EIO;
        goto out_trace;
    }

    fs = ip->i_fs;
    ASSERT(fs->fs_ronly == 0); // Panic!

It seems that no one along the way checks whether the underlying filesystem is read-only. I am not sure why mount request causes some data to be written to disk, but I think that we should add something like this in us_putapage():

-       ASSERT(fs->fs_ronly == 0);
+
+       if (fs->fs_ronly != 0) {
+               return (EROFS);
+       }
Actions #1

Updated by Alexander Kolbasov over 8 years ago

BTW, the whole thing was happening in a local zone, so this is a way to panic system from a local zone.

Actions #2

Updated by Alexander Kolbasov over 8 years ago

It may be the same issue as 5405.

Actions

Also available in: Atom PDF