Bug 1015028

Here is much simpler way to trigger bug:


dd if=/dev/zero of=/tmp/x  bs=1M count=0 seek=1000000

losetup /dev/loop0 /tmp/x

vgcreate testvg /dev/loop0

lvcreate -s -l 100%FREE -n LV --virtualsize 64T testvg 


After this command 'systemd-udevd' starts to busy-loop in kernel
and system becomes unusable.

It seems to be related  to   i686 

Since the first failing size of device is  16T.


lvcreate -s -L10 -V8T  is ok on my system, but
lvcreate -s -L10 -V16T starts the loop.

SInce weeks I try to bisect a hang in a 32 bit user mode linux image rleated to an endless loop in radix_tree_next_chunk :

The user mode linux dev mailing list contains more info (and lklml too) - the picture is just shown here roo : at a fuzzied UML (using trinity) the trinity process hangs here :

tfoerste@n22 ~ $ date; sudo gdb /home/tfoerste/devel/linux/linux 6199 -n -batch -ex bt
Thu Nov 28 20:59:40 CET 2013
0x0829c46f in radix_tree_next_chunk (root=0x3f, iter=0x48f57cdc, flags=6) at lib/radix-tree.c:773
773                             index &= ~((RADIX_TREE_MAP_SIZE << shift) - 1);
#0  0x0829c46f in radix_tree_next_chunk (root=0x3f, iter=0x48f57cdc, flags=6) at lib/radix-tree.c:773
#1  0x080cc78e in find_get_pages (mapping=0x499d4a58, start=0, nr_pages=14, pages=0x6) at mm/filemap.c:844
#2  0x080d654a in pagevec_lookup (pvec=0x48f57d40, mapping=0x3f, start=63, nr_pages=63) at mm/swap.c:937
#3  0x080d694a in truncate_inode_pages_range (mapping=0x499d4a58, lstart=0, lend=-1) at mm/truncate.c:241
#4  0x080d6cef in truncate_inode_pages (mapping=0x3f, lstart=25769803839) at mm/truncate.c:358
#5  0x0818c152 in ext4_evict_inode (inode=0x499d49a0) at fs/ext4/inode.c:228
#6  0x0811b46f in evict (inode=0x499d49a0) at fs/inode.c:549
#7  0x0811bf5d in iput_final (inode=<optimized out>) at fs/inode.c:1419
#8  iput (inode=0x499d49a0) at fs/inode.c:1437
#9  0x08111ec6 in do_unlinkat (dfd=5, pathname=0x8067f34 <tap_open_common+52> "\211D$\b\211T$\f\211\034$\350<\216#") at fs/namei.c:3724
#10 0x08112035 in SYSC_unlinkat (flag=<optimized out>, pathname=<optimized out>, dfd=<optimized out>) at fs/namei.c:3760
#11 SyS_unlinkat (dfd=5, pathname=134643508, flag=0) at fs/namei.c:3752
#12 0x08062ab4 in handle_syscall (r=0x49e9f1cc) at arch/um/kernel/skas/syscall.c:35
#13 0x08075115 in handle_trap (local_using_sysemu=<optimized out>, regs=<optimized out>, pid=<optimized out>) at arch/um/os-Linux/skas/process.c:198
#14 userspace (regs=0x49e9f1cc) at arch/um/os-Linux/skas/process.c:431
#15 0x0805f770 in fork_handler () at arch/um/kernel/process.c:149
#16 0x00000000 in ?? ()
tfoerste@n22 ~ $ date; sudo gdb /home/tfoerste/devel/linux/linux 6199 -n -batch -ex bt
Thu Nov 28 22:53:58 CET 2013
radix_tree_next_chunk (root=0x2, iter=0x48f57cdc, flags=18) at lib/radix-tree.c:770
770                                             if (node->slots[offset])
#0  radix_tree_next_chunk (root=0x2, iter=0x48f57cdc, flags=18) at lib/radix-tree.c:770
#1  0x080cc78e in find_get_pages (mapping=0x499d4a58, start=0, nr_pages=14, pages=0x12) at mm/filemap.c:844
#2  0x080d654a in pagevec_lookup (pvec=0x48f57d40, mapping=0x2, start=2, nr_pages=2) at mm/swap.c:937
#3  0x080d694a in truncate_inode_pages_range (mapping=0x499d4a58, lstart=0, lend=-1) at mm/truncate.c:241
#4  0x080d6cef in truncate_inode_pages (mapping=0x2, lstart=77309411330) at mm/truncate.c:358
#5  0x0818c152 in ext4_evict_inode (inode=0x499d49a0) at fs/ext4/inode.c:228
#6  0x0811b46f in evict (inode=0x499d49a0) at fs/inode.c:549
#7  0x0811bf5d in iput_final (inode=<optimized out>) at fs/inode.c:1419
#8  iput (inode=0x499d49a0) at fs/inode.c:1437
#9  0x08111ec6 in do_unlinkat (dfd=5, pathname=0x8067f34 <tap_open_common+52> "\211D$\b\211T$\f\211\034$\350<\216#") at fs/namei.c:3724
#10 0x08112035 in SYSC_unlinkat (flag=<optimized out>, pathname=<optimized out>, dfd=<optimized out>) at fs/namei.c:3760
#11 SyS_unlinkat (dfd=5, pathname=134643508, flag=0) at fs/namei.c:3752
#12 0x08062ab4 in handle_syscall (r=0x49e9f1cc) at arch/um/kernel/skas/syscall.c:35
#13 0x08075115 in handle_trap (local_using_sysemu=<optimized out>, regs=<optimized out>, pid=<optimized out>) at arch/um/os-Linux/skas/process.c:198
#14 userspace (regs=0x49e9f1cc) at arch/um/os-Linux/skas/process.c:431
#15 0x0805f770 in fork_handler () at arch/um/kernel/process.c:149
#16 0x00000000 in ?? ()

It's probably worth to put into this BZ reference to various related emails I've found:

http://www.spinics.net/lists/linux-fsdevel/msg55633.html

http://www.redhat.com/archives/dm-devel/2009-July/msg00131.html

http://www.redhat.com/archives/dm-devel/2009-July/msg00182.html

So as long as DIRECT read is used then  32bit arch could possibly read even bigger then 16T devices - but anything cached will fail since
32bit are simply not enough to index so many cache pages.

Unsure what is the best fix here - but busy-looping kernel isn't the best one.

FWIW it is broken since few kernel version s - and with trinity and a 32 bit user mode linux image  I can reproduce it within 1/2 an hour or so - si if somebody has a good fix I can test it.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.12.6-200.fc19.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20.

If you experience different issues, please open a new bug report for those.

Still applies to latest vanilla 3.14....

(In reply to Zdenek Kabelac from comment #7)
> Still applies to latest vanilla 3.14....

What about more recent kernels?

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs.

Fedora 22 has now been rebased to 4.2.3-200.fc22.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23.

If you experience different issues, please open a new bug report for those.

*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.