Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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

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.