XFS unhappy with large holey loopback and syncs

[Andi Kleen <ak@xxxxxxx>]

I just found an new exciting way to break XFS. Or rather the 
version that's in 2.6.13. But might be a interesting try anyways.

You likely need a 64bit system for this.

I created a large holey file on XFS with

# (the funny number is about the maximum that ext2 supports)
dd if=/dev/zero of=LARGE bs=1 count=4096 seek=$[8*1024*1024*1024*1024-2*4096] 
losetup /dev/loop0 LARGE
mkfs.ext2 /dev/loop0

now wait until it has written a few thousands of its inode tables
and then press ctrl-c.  mkfs.ext2 will close the loop device which
causes a sync. And then it will hang for a very long time
until loop starts spewing out IO errors and then it deadlocks completely.
The mkfs process is busy waiting for its sync, loop0 does:

xfssyncd      S 0000000000000a7c     0  8846     15          8861  8845 (L-TLB)
ffff81013e179e38 0000000000000046 0000000000000000 ffff81013fda14f8 
       00000000000df8f8 ffffffff80558800 ffffffff80558800 ffffffff80170fea 
       0000000000000100 00000000000000cb 
Call Trace:<ffffffff80170fea>{pagevec_lookup_tag+26} <ffffffff80145149>{lock_tim
er_base+41}
       <ffffffff8035cf66>{schedule_timeout+150} <ffffffff80145700>{process_timeo
ut+0}
       <ffffffff884794a9>{:xfs:xfssyncd+105} <ffffffff88479440>{:xfs:xfssyncd+0}
       <ffffffff80152b90>{keventd_create_kthread+0} <ffffffff80152e43>{kthread+2
43}
       <ffffffff80137d10>{schedule_tail+64} <ffffffff8010f92e>{child_rip+8}
       <ffffffff80152b90>{keventd_create_kthread+0} <ffffffff80152d50>{kthread+0
}
       <ffffffff8010f926>{child_rip+0} 
loop0         D ffff8100057a00f0     0  8856      1                7860 (L-TLB)
ffff81013e297a38 0000000000000046 0000000000000000 ffffffff8842a880 
       ffff81013e297b98 ffffffff80558800 ffffffff80558800 ffff81013e297b78 
       0000000000000001 0000000000000437 
Call Trace:<ffffffff8842a880>{:xfs:xfs_bmap_search_extents+128}
       <ffffffff80145149>{lock_timer_base+41} <ffffffff80145e38>{__mod_timer+216
}
       <ffffffff8035cf66>{schedule_timeout+150} <ffffffff80145700>{process_timeo
ut+0}
       <ffffffff8847941a>{:xfs:xfs_flush_device+90} <ffffffff8845661e>{:xfs:xfs_
iomap_write_delay+1150}
       <ffffffff8011be6f>{smp_send_reschedule+63} <ffffffff8035d363>{__down_writ
e+51}
       <ffffffff8845540c>{:xfs:xfs_iomap+700} <ffffffff8846ffe6>{:xfs:__linvfs_g
et_block+134}

       <ffffffff8010f92e>{child_rip+8} <ffffffff802bd490>{loop_thread+0}
       <ffffffff8010f926>{child_rip+0} 


and it's completely stuck.

The machine I tested this one had quite a lot of memory (8GB), 
so it might be related to that. I don't think it was an OOM
issue though, other terminals were still perfectly responsive.

Anyways, filling that many holes and then syncing seems to send 
XFS into a frenzy.

-Andi