Bug 236095

Summary:	Kernel panic when mounting xfs formatted logical volume with quota on for the first time
Product:	[Fedora] Fedora	Reporter:	Marco Verleun <marco>
Component:	kernel	Assignee:	Eric Sandeen <esandeen>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6	CC:	esandeen
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-09-18 17:50:37 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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:
1.
2.
3.
  
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:
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-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.

-Eric

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.

Regards,

Marco

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.

-Eric