Bug 236095 - Kernel panic when mounting xfs formatted logical volume with quota on for the first time
Kernel panic when mounting xfs formatted logical volume with quota on for the...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-11 17:52 EDT by Marco Verleun
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-18 13:50:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marco Verleun 2007-04-11 17:52:35 EDT
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Marco Verleun 2007-04-11 17:59:48 EDT
Missed the steps filling in de fields above. Sorry...

After formatting a logical volume with the xfs filesystem I tried to mount using
the command mount -a.

In /etc/fstab there was a setting to enable quoata.

The system stopped and rebooted immediately.

/var/log/messages contains the following lines:
Apr 11 20:14:20 minnie kernel: Filesystem "dm-12": Disabling barriers, not suppo
rted by the underlying device
Apr 11 20:14:20 minnie kernel: XFS mounting filesystem dm-12
Apr 11 20:14:20 minnie kernel: XFS quotacheck dm-12: Please wait.
Apr 11 20:14:20 minnie kernel: BUG: sleeping function called from invalid contex
t at include/asm/semaphore.h:99
Apr 11 20:14:20 minnie kernel: in_atomic():1, irqs_disabled():0
Apr 11 20:14:20 minnie kernel:  [<c04056ff>] dump_trace+0x69/0x1b6
Apr 11 20:14:20 minnie kernel:  [<c0405864>] show_trace_log_lvl+0x18/0x2c
Apr 11 20:14:20 minnie kernel:  [<c0405e4b>] show_trace+0xf/0x11
Apr 11 20:14:20 minnie kernel:  [<c0405e7a>] dump_stack+0x15/0x17

After the reboot everything works fine. Can not reproduce the problem

Software involved:
xfsprogs-2.8.11-3.fc6
lvm2-2.02.17-1.fc6
kernel-xen-2.6.19-1.2895.fc6
Comment 2 Eric Sandeen 2007-04-19 22:54:35 EDT
the BUG was in the kernel....
Comment 3 Eric Sandeen 2007-08-27 17:12:49 EDT
This is almost certainly due to a stack overflow - mount+quotacheck goes very
deep - it's one of the codepaths I tried to slim down for the F8 test kernel.

Having blown the stack, the thread_info struct gets corrupted, and can cause
these sorts of errors.

The stack reductions I did for F8 will go upstream and eventually find their way
back to F6 via that path, and hopefully it will look a bit better.

Honestly for now (and even the foreseeable future) xfs on 4k stacks on x86 is a
bit dangerous, made moreso by running over dm (or any manager, vs. just running
on a plain partition) and the quota paths can go deeper too.

-Eric
Comment 4 Marco Verleun 2007-08-29 12:28:48 EDT
Thanks Eric for the work you've put into this issue.

Apart from the onetime experience when the kernel panic occurred the system
seems to be running very stable.

I understand that there is a risc involved running xfs. Currently I've got it
running on top of logical volumes who are running on top of a software raid,
level 1 system.
Some volumes are SATA based, others are external USB storage devices.

I'll take my chances with the 4k stacks on a x86 machine. I just love the speed
of xfs with large files.

Regards,

Marco
Comment 5 Eric Sandeen 2007-09-18 13:50:37 EDT
closing as RAWHIDE... F8 devel kernels have this issue under better control...
*hopefully* the stack-lightening change will make it into 2.6.23, and from there
to F6.

-Eric

Note You need to log in before you can comment on or make changes to this bug.