Bug 236095 - Kernel panic when mounting xfs formatted logical volume with quota on for the first time
Summary: Kernel panic when mounting xfs formatted logical volume with quota on for the...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 6
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-11 21:52 UTC by Marco Verleun
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-09-18 17:50:37 UTC
Type: ---

Attachments (Terms of Use)

Description Marco Verleun 2007-04-11 21:52:35 UTC
Description of problem:

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Marco Verleun 2007-04-11 21:59:48 UTC
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:

Comment 2 Eric Sandeen 2007-04-20 02:54:35 UTC
the BUG was in the kernel....

Comment 3 Eric Sandeen 2007-08-27 21:12:49 UTC
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.


Comment 4 Marco Verleun 2007-08-29 16:28:48 UTC
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.



Comment 5 Eric Sandeen 2007-09-18 17:50:37 UTC
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.


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