[email protected]
[Top] [All Lists]

Re: [zfs-discuss] zfs/lofi/share panic

Subject: Re: [zfs-discuss] zfs/lofi/share panic
From: Frank Middleton
Date: Sun, 30 May 2010 14:20:06 -0400
On 05/27/10 05:16 PM, Dennis Clarke wrote:

I just tried this with a UFS based filesystem just for a lark.

It never failed on UFS, regardless of the contents of /etc/dfs/dfstab.

Guess I must now try this with a ZFS fs under that iso file.

Just tried it again with b134  *with* "share /mnt" in /etc/dfs/dfstab.

# mount -O -F hsfs /export/iso_images/moblin-2.1-PR-Final-ivi-201002090924.img 
# ls /mnt
isolinux  LiveOS
# unshare /mnt
/mnt: path doesn't exist
# share /mnt
# unshare /mnt
# share /mnt

Panic ensues (the following observed on the serial console); note that
the dataset is not UFS!

# May 30 13:35:44 host5 ufs: NOTICE: mount: not a UFS magic number (0x0)

panic[cpu1]/thread=30001f5f560: BAD TRAP: type=31 rp=2a1014769a0 addr=218 mmu_fsr=0 
occurred in module "nfssrv" due to a NULL pointer dereference

Tried again after it rebooted

Edited /etc/dfs/dfstab  to remove the share /mnt
# unshare /mnt
# mount -O -F hsfs /backups/icon/moblin-2.1-PR-Final-ivi-201002090924.img /mnt
# ls /mnt
isolinux  LiveOS
# unshare /mnt
/mnt: bad path
# share /mnt
# unshare  /mnt
# share /mnt

No panic. So the problem all along appears to be what happens if you
mount -O to an already shared mountpoint. Deliberately sharing before
mounting (but with nothing in /etc/dfs/dfstab) resulted in a slightly
different panic (more like the ones documented in the CR):

panic[cpu1]/thread=30002345e0: BAD TRAP: type=34 rp=2a100f84460 
addr=ffffff6f6c2f5267 mmu_fsr=0

unshare: alignment error:

So CR6798273 should be amended to show the following:

To reproduce, share (say) /mnt
mount -O some-image-file /mnt
share /mnt
unshare /mnt
unshare ./mnt
Highly reproducible panic ensues.

Workaround - make sure mountpoints are not shared before
mounting iso images stored on a ZFS dataset.

So the problem, now seen to be relatively trivial, isn't fixed. at least
in b134. For all of you who responded both off and on the list and
motivated this experiment,  much thanks. Perhaps someone with
access to a more recent build could try this, and if it still happens,
update and reopen CR6798273, although it doesn't seem very
important now.

Regards -- Frank
zfs-discuss mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>