Bug 13949 - loop driver barriers support problem
Summary: loop driver barriers support problem
Status: CLOSED OBSOLETE
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: io_other
URL:
Keywords:
Depends on:
Blocks: 13070
  Show dependency tree
 
Reported: 2009-08-09 22:45 UTC by Rafael J. Wysocki
Modified: 2012-06-13 14:45 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.30.4
Subsystem:
Regression: Yes
Bisected commit-id:

Attachments
Add an attachment (proposed patch, testcase, etc.)

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.
Note You need to log in before you can comment on or make changes to this bug.