Bug#647203: "tar" writing files to an UDF filesystem ends up in D state

[Jonathan Nieder <jrnieder@gmail.com>]

merge 647203 647204
tags 647203 + moreinfo
quit

Hi Milko,

Milko Krachounov wrote:

> When extracting a certain tar archive to an UDF filesystem, the 
> tar process hangs and can't be killed.
[...]
> 3. mkudffs ./test
> 4. mount -o loop ./test ./test.mnt
> 5. cd test.mnt
> 6. tar xvzf ../broken.tar.gz
[...]
> [  360.652149] INFO: task tar:3570 blocked for more than 120 seconds.
> [  360.652159] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [  360.652166] tar             D ffff880051635020     0  3570   3121 0x00000000
> [  360.652179]  ffff880051635020 0000000000000086 ffffea0000e4daf0 0000000000000001
> [  360.652191]  ffff88007ec71590 0000000000012800 ffff8800438fffd8 ffff8800438fffd8
> [  360.652201]  0000000000012800 ffff880051635020 0000000000012800 0000000000012800
> [  360.652211] Call Trace:
> [  360.652230]  [<ffffffff8104064c>] ? select_task_rq_fair+0x38f/0x61b
> [  360.652243]  [<ffffffff813369e3>] ? rwsem_down_failed_common+0xda/0x10e
> [  360.652256]  [<ffffffff811ac8a3>] ? call_rwsem_down_write_failed+0x13/0x20
> [  360.652267]  [<ffffffff8111fca1>] ? bit_spin_lock.clone.13+0x22/0x22
> [  360.652278]  [<ffffffff813363aa>] ? down_write+0x25/0x27

Thanks for writing, and sorry for the slow reply.  Was this
reproducible?  Is it still?  What is the first warning?

Is this a regression?  What is the newest kernel you know that does
not have this problem?  (If you can try a current squeeze kernel,
that would be interesting --- it should work on a wheezy/sid system
without trouble.)

I guess our best bet for solving this is to get help from upstream.
Please try to reproduce it with a current (3.3 release candidate)
kernel and without the virtualbox drivers, and if you succeed, write a
summary to <http://bugzilla.kernel.org/>, product File System,
component UDF and let us know the bug number so we can track it.  Be
sure to mention:

 - steps to reproduce, expected result, actual result, and how the
   difference indicates a bug (should be simple enough)
 - what kernel versions you have tested and what happened with each
 - full "dmesg" output from booting an affected kernel and reproducing
   the bug, as an attachment
 - what kind of tests you would be able to do (would you be able to
   try a debugging patch if someone tries one?  if this is a
   regression, can you bisect?)
 - any other weird observations or workarounds

Hope that helps,
Jonathan