Reproducible kernel BUG while using VirtualBox:

Reproducible kernel BUG while using VirtualBox:

[Kenneth Lakin]

[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

I believe that I can pretty reliably reproduce the BUG mentioned in the
attached dmesg output. (This doesn't mean that you can, but I'll detail
what I've done here.) [This BUG is the same one that I reported last night.]

1) Create a 2 GB dynamically expanding disk.
2) Attach it to a VirtualBox machine.
3) Start the Kubuntu install process.
4) Wait until the virtual disk grows to around ~850MB. (This happens
when the install process is in the "installing packages" phase.)
5) Notice that that progress bar hasn't moved in a little while.
6) Record the BUG info from dmesg.
7) Wait around a little while more until the Kubuntu install mentions
that it has encountered an error.
8) Reboot your physical machine to kill the VirtualBox instance that now
won't shut down, but isn't actually using any CPU time. [Using xkill on
this instance results in the zombie VirtualBox process that's stuck in
IO-wait that I reported last night.]

Note that dd'ing 1GB of data to a file on disk (from /dev/zero or
/dev/urandom) does not cause an error, so this doesn't seem to be a disk
fullness thing.

More information about my machine:
I once mounted the filesystem in question with the space_cache option.
All free space numbers here are from *before* I dd'd 1GB of data onto disk.

$ btrfs fi df /
Data: total=71.23GB, used=68.16GB
System, DUP: total=8.00MB, used=24.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=4.75GB, used=2.26GB

$ df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/campstovevg-root
                       81G   73G  3.4G  96% /
$ mount | grep btrfs
/dev/mapper/campstovevg-root on / type btrfs (rw,relatime,ssd)

$ uname -a
Linux campstove 2.6.36+ #5 SMP PREEMPT Mon Dec 20 09:28:14 PST 2010 i686
Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz GenuineIntel GNU/Linux

~/btrfs-unstable $ git log -n1 | head -n3
commit 83a50de97fe96aca82389e061862ed760ece2283
Author: Chris Mason <chris.mason@oracle.com>
Date:   Mon Dec 13 15:06:46 2010 -0500

~/btrfs-progs-unstable $ git log -n1 | head -n3
commit 1b444cd2e6ab8dcafdd47dbaeaae369dd1517c17
Author: Chris Mason <chris.mason@oracle.com>
Date:   Wed Oct 6 09:53:38 2010 -0400


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNG610AAoJEIsblWe5kJ+jNP0IAIUfHtBts4L5Ym5xGrBBOR/7
ujBNVTQlWp/8jkEQOoHa8zrrSdnA9i4ijwOFHZQ3t5zvMYhw5PmtIVuMVEjFN0kx
ItuB0ClCOT+NA8rlwpWrrMWUlHxD+I8fH4QVEP2DZ8n8fJ9jj3ULZTBRBhBcvpeA
Yr5RoxBRN9jd1PZkx4RQ/mk0mv3h0Qv+BTese7EvsEbzeOFVYA94g6SQnY+qtVeH
b374E85R6cQYmlYQqVlrIvTj3NivUIG6js5Bs9oKwv/jN2BRK/1To5U26OwNWV/S
kbQn6fB6StTnJjteWZe8wRiUtWs7WHVAMKjqDd500+RScgsmGTWgjC3MySGnNlY=
=J5zb
-----END PGP SIGNATURE-----

[-- Attachment #2: dmesgReport101229.txt --]
[-- Type: text/plain, Size: 3343 bytes --]

[47383.296654] BUG: unable to handle kernel NULL pointer dereference at (null)
[47383.296741] IP: [<c01222de>] kmap_atomic_prot+0x19/0xbd
[47383.296804] *pde = 00000000 
[47383.296839] Oops: 0000 [#1] PREEMPT SMP 
[47383.296892] last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map
[47383.296970] Modules linked in: sky2 aes_i586 aes_generic fbcon tileblit font bitblit softcursor nfsd lockd nfs_acl auth_rpcgss ipv6 sunrpc coretemp snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss sco bnep snd_mixer_oss binfmt_misc vboxnetadp vboxnetflt vboxdrv snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device usbserial rfcomm l2cap hci_uart fuse cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative acpi_cpufreq mperf tun arc4 ecb iwl3945 i915 iwlcore snd_hda_codec_idt mac80211 snd_hda_intel drm_kms_helper snd_hda_codec drm snd_hwdep snd_pcm cfg80211 ppdev btusb snd_timer i2c_algo_bit parport_pc bluetooth panasonic_laptop cfbcopyarea video snd processor tpm_infineon container parport sg thermal rfkill battery cfbimgblt backlight i2c_i801 output ac cfbfillrect snd_page_alloc thermal_sys pcspkr button mmc_block pcmcia sdhci_pci sdhci yenta_socket firewire_ohci pcmcia_rsrc mmc_core firewire_core pcmcia_core dm_mod [last unloaded: microcode]
[47383.297009] 
[47383.297009] Pid: 9464, comm: VirtualBox Not tainted 2.6.36+ #5 CF30-1/CF-30C3PAZBM
[47383.297009] EIP: 0060:[<c01222de>] EFLAGS: 00010202 CPU: 1
[47383.297009] EIP is at kmap_atomic_prot+0x19/0xbd
[47383.297009] EAX: 00000000 EBX: ddb22000 ECX: 00000163 EDX: 00000003
[47383.297009] ESI: 00001000 EDI: 00000000 EBP: ddb22dd8 ESP: ddb22dc8
[47383.297009]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[47383.297009] Process VirtualBox (pid: 9464, ti=ddb22000 task=f708ca40 task.ti=ddb22000)
[47383.297009] Stack:
[47383.297009]  3c51b163 ddb22ea8 00001000 00000000 ddb22de0 c0122395 ddb22df4 c019426b
[47383.297009] <0> 00000200 00001000 00000000 ddb22e18 c040a1ae 00000200 00096e00 00000097
[47383.297009] <0> 00001000 00097000 ddb22ea8 c17c0800 ddb22ecc c040a7db c17c0400 ddb22ea8
[47383.297009] Call Trace:
[47383.297009]  [<c0122395>] ? kmap_atomic+0x13/0x15
[47383.297009]  [<c019426b>] ? iov_iter_copy_from_user_atomic+0x3f/0x85
[47383.297009]  [<c040a1ae>] ? btrfs_copy_from_user.clone.9+0x5a/0xa2
[47383.297009]  [<c040a7db>] ? btrfs_file_aio_write+0x4d0/0x7e2
[47383.297009]  [<c01e92e8>] ? aio_rw_vect_retry+0x6d/0x13b
[47383.297009]  [<c01e99fe>] ? __aio_get_req+0x1f/0xf2
[47383.297009]  [<c040a30b>] ? btrfs_file_aio_write+0x0/0x7e2
[47383.297009]  [<c01e927b>] ? aio_rw_vect_retry+0x0/0x13b
[47383.297009]  [<c01e9e28>] ? aio_run_iocb+0x67/0xf7
[47383.297009]  [<c01eabef>] ? do_io_submit+0x43e/0x602
[47383.297009]  [<c01eadcb>] ? sys_io_submit+0x18/0x1a
[47383.297009]  [<c010291f>] ? sysenter_do_call+0x12/0x28
[47383.297009]  [<c0610000>] ? slab_cpuup_callback+0x94/0xf0
[47383.297009] Code: 48 14 8b 40 08 a8 08 74 05 e8 f3 ee 4e 00 5b 5e 5d c3 55 89 e5 57 56 53 83 ec 04 0f 1f 44 00 00 89 e3 81 e3 00 f0 ff ff ff 43 14 <8b> 18 c1 eb 1e c1 e3 0a 8d b3 80 ce 8c c0 2b b3 0c d2 8c c0 81 
[47383.297009] EIP: [<c01222de>] kmap_atomic_prot+0x19/0xbd SS:ESP 0068:ddb22dc8
[47383.297009] CR2: 0000000000000000
[47383.314247] ---[ end trace 1dd3faaa9ea44a44 ]---
[47383.314300] note: VirtualBox[9464] exited with preempt_count 2

[-- Attachment #3: dmesgReport101229.txt.sig --]
[-- Type: application/pgp-signature, Size: 287 bytes --]

Re: Reproducible kernel BUG while using VirtualBox:

[Li Zefan]

Kenneth Lakin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> All,
> 
> I believe that I can pretty reliably reproduce the BUG mentioned in the
> attached dmesg output. (This doesn't mean that you can, but I'll detail
> what I've done here.) [This BUG is the same one that I reported last night.]
> 

Revert:

commit 914ee295af418e936ec20a08c1663eaabe4cd07a
Author: Xin Zhong <xin.zhong@intel.com>
Date:   Thu Dec 9 09:30:14 2010 +0000

    Btrfs: pwrite blocked when writing from the mmaped buffer of the same page

    This problem is found in meego testing:
    http://bugs.meego.com/show_bug.cgi?id=6672
    A file in btrfs is mmaped and the mmaped buffer is passed to pwrite to write
    of the same file. In btrfs_file_aio_write(), the pages is locked by prepare_
    btrfs_copy_from_user() is called, page fault happens and the same page needs
    in filemap_fault(). The fix is to move iov_iter_fault_in_readable() before p
    fault happen before pages are locked. And also disable page fault in critica
    btrfs_copy_from_user().

And see if the bug still exists?

> 1) Create a 2 GB dynamically expanding disk.
> 2) Attach it to a VirtualBox machine.
> 3) Start the Kubuntu install process.
> 4) Wait until the virtual disk grows to around ~850MB. (This happens
> when the install process is in the "installing packages" phase.)
> 5) Notice that that progress bar hasn't moved in a little while.
> 6) Record the BUG info from dmesg.
> 7) Wait around a little while more until the Kubuntu install mentions
> that it has encountered an error.
> 8) Reboot your physical machine to kill the VirtualBox instance that now
> won't shut down, but isn't actually using any CPU time. [Using xkill on
> this instance results in the zombie VirtualBox process that's stuck in
> IO-wait that I reported last night.]
> 
> Note that dd'ing 1GB of data to a file on disk (from /dev/zero or
> /dev/urandom) does not cause an error, so this doesn't seem to be a disk
> fullness thing.
> 
> More information about my machine:
> I once mounted the filesystem in question with the space_cache option.
> All free space numbers here are from *before* I dd'd 1GB of data onto disk.
> 
> $ btrfs fi df /
> Data: total=71.23GB, used=68.16GB
> System, DUP: total=8.00MB, used=24.00KB
> System: total=4.00MB, used=0.00
> Metadata, DUP: total=4.75GB, used=2.26GB
> 
> $ df -h /
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/mapper/campstovevg-root
>                        81G   73G  3.4G  96% /
> $ mount | grep btrfs
> /dev/mapper/campstovevg-root on / type btrfs (rw,relatime,ssd)
> 
> $ uname -a
> Linux campstove 2.6.36+ #5 SMP PREEMPT Mon Dec 20 09:28:14 PST 2010 i686
> Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz GenuineIntel GNU/Linux
> 
> ~/btrfs-unstable $ git log -n1 | head -n3
> commit 83a50de97fe96aca82389e061862ed760ece2283
> Author: Chris Mason <chris.mason@oracle.com>
> Date:   Mon Dec 13 15:06:46 2010 -0500
> 
> ~/btrfs-progs-unstable $ git log -n1 | head -n3
> commit 1b444cd2e6ab8dcafdd47dbaeaae369dd1517c17
> Author: Chris Mason <chris.mason@oracle.com>
> Date:   Wed Oct 6 09:53:38 2010 -0400
>