Bug 13949

Summary:	loop driver barriers support problem
Product:	IO/Storage	Reporter:	Rafael J. Wysocki (rjw)
Component:	Other	Assignee:	io_other
Status:	CLOSED OBSOLETE
Severity:	normal	CC:	alan, cebbert, jpiszcz
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.30.4	Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:
Bug Blocks:	13070

Description Rafael J. Wysocki 2009-08-09 22:45:08 UTC

Subject    : Kernel 2.6.30.4 XFS(..?) regression
Submitter  : Justin Piszcz <jpiszcz@lucidpixels.com>
Date       : 2009-08-08 8:39
References : http://marc.info/?l=linux-kernel&m=124972079229959&w=4
Notify-Also : Felix Blyakher <felixb@sgi.com>

This entry is being used for tracking a regression from 2.6.29.  Please don't
close it until the problem is fixed in the mainline.

Comment 1 Justin Piszcz 2009-08-20 09:49:18 UTC

Hello,

So far with 2.6.31-rc6 the issue has not recurred.. I am not sure if you want to keep this open/re-open if it recurs or leave it pending until 2.6.31 is released?

Justin.

Comment 2 Rafael J. Wysocki 2009-08-20 14:32:52 UTC

Closing for now, please reopen if it happens again.

Comment 3 Justin Piszcz 2009-08-22 08:20:05 UTC

Hello,

It has happened again.

$ uptime
 04:18:06 up 1 day, 16:00,  3 users,  load average: 62.95, 61.97, 58.64

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       209  0.0  0.0      0     0 ?        D    Aug20   0:05 [pdflush]
root       217  0.0  0.0      0     0 ?        D<   Aug20   0:01 [xfsdatad/0]
root      1999  0.0  0.0      0     0 ?        D<   Aug20   0:10 [loop0]
root      2008  0.0  0.0      0     0 ?        D<   Aug20   0:00 [xfssyncd]

[144104.513619] cron          S 00000000     0 19969   1868 0x00000000
[144104.513619]  00000000 00000086 c1805b80 00000000 00000000 c67728c0 c13eb17c c150e100
[144104.513619]  c49f0200 cc69fed8 cc69ff5c 00001000 c106a8c5 00000000 c1805b80 c102d930
[144104.513619]  c49f0200 c49f0200 c9283ca0 cc69fed8 c106b1b6 aead521a cc69ff5c cf5459dc
[144104.513619] Call Trace:
[144104.513619]  [<c106a8c5>] ? pipe_wait+0x45/0x60
[144104.513619]  [<c102d930>] ? autoremove_wake_function+0x0/0x50
[144104.513619]  [<c106b1b6>] ? pipe_read+0x366/0x420
[144104.513619]  [<c1041bcc>] ? find_get_page+0x1c/0x60
[144104.513619]  [<c1064595>] ? do_sync_read+0xd5/0x120
[144104.513619]  [<c102d930>] ? autoremove_wake_function+0x0/0x50
[144104.513619]  [<c1053e80>] ? handle_mm_fault+0x140/0x510
[144104.513619]  [<c10644c0>] ? do_sync_read+0x0/0x120
[144104.513619]  [<c10651cd>] ? vfs_read+0x9d/0x160
[144104.513619]  [<c1065361>] ? sys_read+0x41/0x80
[144104.513619]  [<c1002b88>] ? sysenter_do_call+0x12/0x26

Comment 4 Justin Piszcz 2009-09-07 10:26:55 UTC

The problem persists, one can "work-around" the bug by mounting with -o nobarrier but this is unsafe.

Comment 5 Chuck Ebbert 2009-09-08 15:26:18 UTC

Mounting with -o nobarrier is no more unsafe than it was when the loop driver didn't support barriers at all. I'd suggest reverting the barrier support if no other solution can be found.