Description of problem: When I plug in a USB hard drive with a Luks encrypted file system, the file system doesn't get mounted and cryptsetup loops at 100% cpu: [root@tlondon ~]# while : > do > ps agx | grep cryptsetup > sleep 30 > done 2994 ? R 13:06 [cryptsetup] 3235 pts/1 S+ 0:00 grep cryptsetup 2994 ? R 13:27 [cryptsetup] 3245 pts/1 S+ 0:00 grep cryptsetup 2994 ? R 13:51 [cryptsetup] 3248 pts/1 S+ 0:00 grep cryptsetup 2994 ? R 14:14 [cryptsetup] 3254 pts/1 S+ 0:00 grep cryptsetup 2994 ? R 14:39 [cryptsetup] 3261 pts/1 S+ 0:00 grep cryptsetup 2994 ? R 15:04 [cryptsetup] 3267 pts/1 S+ 0:00 grep cryptsetup I can mount the file system by running palimpsest and manually mounting the now unlocked file system. Here are messages from /var/log/messages: Aug 14 07:20:08 tlondon kernel: usb 1-5.3: new high speed USB device using ehci_hcd and address 6 Aug 14 07:20:08 tlondon kernel: usb 1-5.3: New USB device found, idVendor=04b4, idProduct=6830 Aug 14 07:20:08 tlondon kernel: usb 1-5.3: New USB device strings: Mfr=56, Product=78, SerialNumber=100 Aug 14 07:20:08 tlondon kernel: usb 1-5.3: Product: USB2.0 Storage Device Aug 14 07:20:08 tlondon kernel: usb 1-5.3: Manufacturer: Cypress Semiconductor Aug 14 07:20:08 tlondon kernel: usb 1-5.3: SerialNumber: DEF107679C83 Aug 14 07:20:08 tlondon kernel: usb 1-5.3: configuration #1 chosen from 1 choice Aug 14 07:20:08 tlondon kernel: scsi5 : SCSI emulation for USB Mass Storage devices Aug 14 07:20:08 tlondon kernel: usbcore: registered new interface driver ums-cypress Aug 14 07:20:15 tlondon kernel: scsi 5:0:0:0: Direct-Access MAXTOR S TM3320620A PQ: 0 ANSI: 0 Aug 14 07:20:15 tlondon kernel: sd 5:0:0:0: [sdc] 625142448 512-byte logical blocks: (320 GB/298 GiB) Aug 14 07:20:15 tlondon kernel: sd 5:0:0:0: [sdc] Write Protect is off Aug 14 07:20:15 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Aug 14 07:20:15 tlondon kernel: sd 5:0:0:0: Attached scsi generic sg3 type 0 Aug 14 07:20:15 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Aug 14 07:20:15 tlondon kernel: sdc: sdc1 Aug 14 07:20:15 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Aug 14 07:20:15 tlondon kernel: sd 5:0:0:0: [sdc] Attached SCSI disk Aug 14 07:20:22 tlondon kernel: usb 1-5.3: reset high speed USB device using ehci_hcd and address 6 Aug 14 07:20:23 tlondon kernel: Intel AES-NI instructions are not detected. Aug 14 07:20:23 tlondon kernel: padlock: VIA PadLock not detected. Aug 14 07:20:23 tlondon kernel: padlock: VIA PadLock Hash Engine not detected. Aug 14 07:20:23 tlondon modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.31-0.151.rc5.git3.fc12.x86_64/kernel/drivers/crypto/padlock-sha.ko): No such device Aug 14 07:20:52 tlondon kernel: EXT4-fs (dm-2): barriers enabled Aug 14 07:20:52 tlondon kernel: kjournald2 starting: pid 3086, dev dm-2:8, commit interval 5 seconds Aug 14 07:20:52 tlondon kernel: EXT4-fs (dm-2): internal journal on dm-2:8 Aug 14 07:20:52 tlondon kernel: EXT4-fs (dm-2): delayed allocation enabled Aug 14 07:20:52 tlondon kernel: EXT4-fs: file extents enabled Aug 14 07:20:52 tlondon kernel: EXT4-fs: mballoc enabled Aug 14 07:20:52 tlondon kernel: EXT4-fs (dm-2): mounted filesystem with ordered data mode This process appears "unkillable", and hangs around until I reboot. Version-Release number of selected component (if applicable): cryptsetup-luks-1.0.7-2.fc12.x86_64 DeviceKit-disks-debuginfo-005-5.fc12.x86_64 DeviceKit-disks-005-5.fc12.x86_64 How reproducible: Every time I plug in hard drive..... Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Attempting to strace the process yields no info: [root@tlondon ~]# strace -p 2994 Process 2994 attached - interrupt to quit ^C Current output of "ps": 2329 pts/0 R 0:00 -bash 2971 ? S< 0:00 [scsi_eh_5] 2972 ? S< 0:44 [usb-storage] 2981 ? S< 0:00 /sbin/udevd -d 2994 ? R 47:00 [cryptsetup] 3040 ? S< 0:01 [kdmflush] 3041 ? S< 0:00 [kcryptd_io] 3042 ? S< 2:42 [kcryptd] 3444 pts/0 S 0:00 strace -p 2994 3453 pts/0 R+ 0:00 ps gx strace process killable only with "kill -9"
Interesting, why so many instances of cryptsetup? (I guess some devkit rule is problem here) Anyway, first it would be good to know, what is it waiting for. Please can you reproduce it and when it is again in described state, run "echo t>/proc/sysrq-trigger" and attach full (including other processes) process log (from syslog)?
Also please add "dmsetup table" and "dmsetup info -c".
Created attachment 357468 [details] 2500 line tail from /var/log/messages showing spew from "echo t>/proc/sysrq-trigger" As requested.... Actually, there is only once copy of cryptsetup. I was showing the output of a "ps | grep cryptsetup; sleep 30" loop.....
Also as requested: [root@tlondon ~]# dmsetup table devkit-disks-luks-uuid-87bb5220-bc93-40b8-8e34-29d6e2cbdbfb-uid500: 0 625136250 crypt aes-cbc-essiv:sha256 00000000000000000000000000000000 0 8:33 1032 vg_tlondon-lv_swap: 0 11927552 linear 8:3 433045888 vg_tlondon-lv_root: 0 433045504 linear 8:3 384 [root@tlondon ~]# dmsetup info -c Name Maj Min Stat Open Targ Event UUID devkit-disks-luks-uuid-87bb5220-bc93-40b8-8e34-29d6e2cbdbfb-uid500 253 2 L--w 0 1 0 CRYPT-87bb5220-bc93-40b8-8e34-29d6e2cbdbfb vg_tlondon-lv_swap 253 1 L--w 1 1 0 LVM-Ikj7pTHbxcmOYkXX0rKem8ptRhFIewbs3LlCUTDBKMVWlDzfOA2eoDhxZbjCqBtb vg_tlondon-lv_root 253 0 L--w 1 1 0 LVM-Ikj7pTHbxcmOYkXX0rKem8ptRhFIewbsYG0wPKDNZHD3tdm4bqKxSfFP8aC9M2hn [root@tlondon ~]#
So according to dmsetup output, cryptsetup properly set mapping, 08:32:19 tlondon kernel: cryptsetup R running task 4120 2994 1821 0x00000080 Aug 14 08:32:19 tlondon kernel: ffff88005e401b88 0000000000000082 ffff880000000000 0000000000000017 Aug 14 08:32:19 tlondon kernel: 00007f35f1feb000 ffffea0007c2a588 ffffea0007c2a588 00000000553bbe8b Aug 14 08:32:19 tlondon kernel: ffff88005ea42890 000000000000fa20 ffff88005ea42898 00000000001d5bc0 Aug 14 08:32:19 tlondon kernel: Call Trace: Aug 14 08:32:19 tlondon kernel: [<ffffffff8105db58>] __cond_resched+0x45/0x82 Aug 14 08:32:19 tlondon kernel: [<ffffffff81500934>] _cond_resched+0x3f/0x5e Aug 14 08:32:19 tlondon kernel: [<ffffffff81113095>] cond_resched+0x21/0x37 Aug 14 08:32:19 tlondon kernel: [<ffffffff81116ac5>] __get_user_pages+0x381/0x42c Aug 14 08:32:19 tlondon kernel: [<ffffffff81118efd>] __mlock_vma_pages_range+0xef/0x2a9 Aug 14 08:32:19 tlondon kernel: [<ffffffff8111311c>] ? might_fault+0x71/0xd9 Aug 14 08:32:19 tlondon kernel: [<ffffffff811197ab>] munlock_vma_pages_range+0x2b/0x41 Aug 14 08:32:19 tlondon kernel: [<ffffffff810670fc>] ? exit_mm+0x4b/0x136 Aug 14 08:32:19 tlondon kernel: [<ffffffff8111a3bb>] exit_mmap+0x64/0x165 Aug 14 08:32:19 tlondon kernel: [<ffffffff81062277>] mmput+0x5a/0xcc Aug 14 08:32:19 tlondon kernel: [<ffffffff810671c6>] exit_mm+0x115/0x136 Aug 14 08:32:19 tlondon kernel: [<ffffffff81068f27>] do_exit+0x1e1/0x768 Aug 14 08:32:19 tlondon kernel: [<ffffffff8150078f>] ? thread_return+0x4e/0xd3 Aug 14 08:32:19 tlondon kernel: [<ffffffff8114bd0a>] ? path_put+0x31/0x4c Aug 14 08:32:19 tlondon kernel: [<ffffffff81069541>] do_group_exit+0x93/0xc3 Aug 14 08:32:19 tlondon kernel: [<ffffffff8106959b>] sys_exit_group+0x2a/0x42 Aug 14 08:32:19 tlondon kernel: [<ffffffff81012f42>] system_call_fastpath+0x16/0x1b Reading process log, I am really not sure what it is doing, it seems like a kernel problem... What's the exact kernel version (uname -a)?
kernel-2.6.31-0.151.rc5.git3.fc12.x86_64: [tbl@tlondon baroque]$ uname -a Linux tlondon.innopath.com 2.6.31-0.151.rc5.git3.fc12.x86_64 #1 SMP Wed Aug 12 17:26:45 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux [tbl@tlondon baroque]$ But I've noticed this for a few recent versions.... Checking my /var/log/messages, it appears it may have "stopped working" at 2.6.31-0.142.rc5.git3.fc12.x86_64. Looks like it "worked" for 2.6.31-0.138.rc5.git3.fc12.x86_64, at least as measured by the delay between the "can't load padlock module" message and the "EXT-4 barriers enabled" message.
Can you try to boot to that kernel to prove that it works?
OK. I still have 0.139 installed. I'll try that one first, and then sequence through my already installed kernels: kernel-2.6.31-0.139.rc5.git3.fc12.x86_64 kernel-2.6.31-0.142.rc5.git3.fc12.x86_64 kernel-2.6.31-0.145.rc5.git3.fc12.x86_64 kernel-2.6.31-0.149.rc5.git3.fc12.x86_64 kernel-2.6.31-0.151.rc5.git3.fc12.x86_64 If 0.139 fails, I'll install 0.138.
OK, works with kernel-2.6.31-0.139.rc5.git3.fc12.x86_64: Aug 14 11:26:57 tlondon kernel: usb 1-5.3: new high speed USB device using ehci_hcd and address 8 Aug 14 11:26:57 tlondon kernel: usb 1-5.3: New USB device found, idVendor=04b4, idProduct=6830 Aug 14 11:26:57 tlondon kernel: usb 1-5.3: New USB device strings: Mfr=56, Product=78, SerialNumber=100 Aug 14 11:26:57 tlondon kernel: usb 1-5.3: Product: USB2.0 Storage Device Aug 14 11:26:57 tlondon kernel: usb 1-5.3: Manufacturer: Cypress Semiconductor Aug 14 11:26:57 tlondon kernel: usb 1-5.3: SerialNumber: DEF107679C83 Aug 14 11:26:57 tlondon kernel: usb 1-5.3: configuration #1 chosen from 1 choice Aug 14 11:26:57 tlondon kernel: scsi5 : SCSI emulation for USB Mass Storage devices Aug 14 11:26:57 tlondon kernel: usbcore: registered new interface driver ums-cypress Aug 14 11:27:04 tlondon kernel: scsi 5:0:0:0: Direct-Access MAXTOR S TM3320620A PQ: 0 ANSI: 0 Aug 14 11:27:04 tlondon kernel: sd 5:0:0:0: Attached scsi generic sg3 type 0 Aug 14 11:27:04 tlondon kernel: sd 5:0:0:0: [sdc] 625142448 512-byte logical blocks: (320 GB/298 GiB) Aug 14 11:27:04 tlondon kernel: sd 5:0:0:0: [sdc] Write Protect is off Aug 14 11:27:04 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Aug 14 11:27:04 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Aug 14 11:27:04 tlondon kernel: sdc: sdc1 Aug 14 11:27:04 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Aug 14 11:27:04 tlondon kernel: sd 5:0:0:0: [sdc] Attached SCSI disk Aug 14 11:27:12 tlondon kernel: usb 1-5.3: reset high speed USB device using ehci_hcd and address 8 Aug 14 11:27:13 tlondon kernel: Intel AES-NI instructions are not detected. Aug 14 11:27:13 tlondon kernel: padlock: VIA PadLock not detected. Aug 14 11:27:13 tlondon kernel: padlock: VIA PadLock Hash Engine not detected. Aug 14 11:27:13 tlondon modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.31-0.139.rc5.git3.fc12.x86_64/kernel/drivers/crypto/padlock-sha.ko): No such device Aug 14 11:27:16 tlondon kernel: EXT4-fs (dm-2): barriers enabled Aug 14 11:27:16 tlondon kernel: kjournald2 starting: pid 2049, dev dm-2:8, commit interval 5 seconds Aug 14 11:27:16 tlondon kernel: EXT4-fs (dm-2): internal journal on dm-2:8 Aug 14 11:27:16 tlondon kernel: EXT4-fs (dm-2): delayed allocation enabled Aug 14 11:27:16 tlondon kernel: EXT4-fs: file extents enabled Aug 14 11:27:16 tlondon kernel: EXT4-fs: mballoc enabled Aug 14 11:27:16 tlondon kernel: EXT4-fs (dm-2): mounted filesystem with ordered data mode And gnome popped up a window with "/media/Backup". [root@tlondon ~]# mount /dev/mapper/vg_tlondon-lv_root on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw) /dev/sda2 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0") none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) gvfs-fuse-daemon on /home/tbl/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=tbl) /dev/sdb1 on /media/FlashCard type vfat (rw,nosuid,nodev,uhelper=devkit,uid=500,gid=500,shortname=lower,dmask=0077,utf8=1,flush) /dev/sda1 on /media/WinXP type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096) /dev/dm-2 on /media/Backup type ext4 (rw,nosuid,nodev,uhelper=devkit) [root@tlondon ~]#
Fails with kernel-2.6.31-0.142.rc5.git3.fc12.x86_64 (and I'm guessing, later). Notice there is no "barriers enabled" message. There is no popup of the mount point. Aug 14 11:32:31 tlondon kernel: usb 1-5.3: new high speed USB device using ehci_hcd and address 8 Aug 14 11:32:31 tlondon kernel: usb 1-5.3: New USB device found, idVendor=04b4, idProduct=6830 Aug 14 11:32:31 tlondon kernel: usb 1-5.3: New USB device strings: Mfr=56, Product=78, SerialNumber=100 Aug 14 11:32:31 tlondon kernel: usb 1-5.3: Product: USB2.0 Storage Device Aug 14 11:32:31 tlondon kernel: usb 1-5.3: Manufacturer: Cypress Semiconductor Aug 14 11:32:31 tlondon kernel: usb 1-5.3: SerialNumber: DEF107679C83 Aug 14 11:32:31 tlondon kernel: usb 1-5.3: configuration #1 chosen from 1 choice Aug 14 11:32:31 tlondon kernel: scsi5 : SCSI emulation for USB Mass Storage devices Aug 14 11:32:31 tlondon kernel: usbcore: registered new interface driver ums-cypress Aug 14 11:32:38 tlondon kernel: scsi 5:0:0:0: Direct-Access MAXTOR S TM3320620A PQ: 0 ANSI: 0 Aug 14 11:32:38 tlondon kernel: sd 5:0:0:0: Attached scsi generic sg3 type 0 Aug 14 11:32:38 tlondon kernel: sd 5:0:0:0: [sdc] 625142448 512-byte logical blocks: (320 GB/298 GiB) Aug 14 11:32:38 tlondon kernel: sd 5:0:0:0: [sdc] Write Protect is off Aug 14 11:32:38 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Aug 14 11:32:38 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Aug 14 11:32:38 tlondon kernel: sdc: sdc1 Aug 14 11:32:38 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Aug 14 11:32:38 tlondon kernel: sd 5:0:0:0: [sdc] Attached SCSI disk Aug 14 11:32:46 tlondon kernel: usb 1-5.3: reset high speed USB device using ehci_hcd and address 8 Aug 14 11:32:46 tlondon kernel: Intel AES-NI instructions are not detected. Aug 14 11:32:46 tlondon kernel: padlock: VIA PadLock not detected. Aug 14 11:32:47 tlondon kernel: padlock: VIA PadLock Hash Engine not detected. Aug 14 11:32:47 tlondon modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.31-0.142.rc5.git3.fc12.x86_64/kernel/drivers/crypto/padlock-sha.ko): No such device Mount does not show the FS (/dev/sdc1) mounted (on /media/Backup): [root@tlondon ~]# mount /dev/mapper/vg_tlondon-lv_root on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw) /dev/sda2 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0") none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) gvfs-fuse-daemon on /home/tbl/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=tbl) /dev/sdb1 on /media/FlashCard type vfat (rw,nosuid,nodev,uhelper=devkit,uid=500,gid=500,shortname=lower,dmask=0077,utf8=1,flush) /dev/sda1 on /media/WinXP type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096) [root@tlondon ~]# "ps" shows cryptsetup looping and eating up cycles: [root@tlondon ~]# ps agx | grep cryptsetup 2083 ? R 3:14 [cryptsetup] 2234 pts/0 S+ 0:00 grep cryptsetup [root@tlondon ~]# I collected the "echo t>/proc/sysrq-trigger" in /var/log/messages. Let me know if it is needed.... Here is a snippet for cryptsetup: Aug 14 11:36:43 tlondon kernel: cryptsetup R running task 4120 2083 1881 0x00000080 Aug 14 11:36:43 tlondon kernel: 00007f039b017000 0000000000000000 ffff88011dcaa4a0 0000000000000017 Aug 14 11:36:43 tlondon kernel: 00007f039b017000 0000000000000000 ffffffff81098a33 000000005e789e64 Aug 14 11:36:43 tlondon kernel: ffffffff81114d97 ffff88011dc8f6c0 ffff88011dcd50b8 ffff880100bde4d8 Aug 14 11:36:43 tlondon kernel: Call Trace: Aug 14 11:36:43 tlondon kernel: [<ffffffff81098a33>] ? lock_release+0x1a2/0x1c8 Aug 14 11:36:43 tlondon kernel: [<ffffffff81114d97>] ? follow_page+0x1cd/0x31e Aug 14 11:36:43 tlondon kernel: [<ffffffff814fd28b>] ? _spin_lock+0x71/0x8e Aug 14 11:36:43 tlondon kernel: [<ffffffff814fd036>] ? _spin_unlock+0x3a/0x55 Aug 14 11:36:43 tlondon kernel: [<ffffffff81116a6b>] ? __get_user_pages+0x32f/0x42c Aug 14 11:36:43 tlondon kernel: [<ffffffff81118ef5>] ? __mlock_vma_pages_range+0xef/0x2a9 Aug 14 11:36:43 tlondon kernel: [<ffffffff81113114>] ? might_fault+0x71/0xd9 Aug 14 11:36:43 tlondon kernel: [<ffffffff811197a3>] ? munlock_vma_pages_range+0x2b/0x41 Aug 14 11:36:43 tlondon kernel: [<ffffffff810670fc>] ? exit_mm+0x4b/0x136 Aug 14 11:36:43 tlondon kernel: [<ffffffff8111a3b3>] ? exit_mmap+0x64/0x165 Aug 14 11:36:43 tlondon kernel: [<ffffffff81062277>] ? mmput+0x5a/0xcc Aug 14 11:36:43 tlondon kernel: [<ffffffff810671c6>] ? exit_mm+0x115/0x136 Aug 14 11:36:43 tlondon kernel: [<ffffffff81068f27>] ? do_exit+0x1e1/0x768 Aug 14 11:36:43 tlondon kernel: [<ffffffff8113fc32>] ? sys_close+0x46/0x110 Aug 14 11:36:43 tlondon kernel: [<ffffffff8114bcd6>] ? path_put+0x31/0x4c Aug 14 11:36:43 tlondon kernel: [<ffffffff81069541>] ? do_group_exit+0x93/0xc3 Aug 14 11:36:43 tlondon kernel: [<ffffffff8106959b>] ? sys_exit_group+0x2a/0x42 Aug 14 11:36:43 tlondon kernel: [<ffffffff81012f42>] ? system_call_fastpath+0x16/0x1b
For completeness: still fails with kernel-2.6.31-0.156.rc6.fc12.x86_64: Aug 14 17:53:29 tlondon kernel: cryptsetup R running task 4056 2275 1936 0x00000080 Aug 14 17:53:29 tlondon kernel: 0000000000000000 00000000db53a7e3 ffff880103a03928 ffffffff81096d6b Aug 14 17:53:29 tlondon kernel: ffff880103a038f8 0000000000000000 ffff880103a03978 0000000000000246 Aug 14 17:53:29 tlondon kernel: ffff88010aa0ace8 ffffea0006b5c6c0 0000000000000002 0000000000000000 Aug 14 17:53:29 tlondon kernel: Call Trace: Aug 14 17:53:29 tlondon kernel: [<ffffffff81096d6b>] ? mark_lock+0x3c/0x253 Aug 14 17:53:29 tlondon kernel: [<ffffffff81115585>] ? __do_fault+0x241/0x419 Aug 14 17:53:29 tlondon kernel: [<ffffffff81095c3e>] ? register_lock_class+0x2d/0x37b Aug 14 17:53:29 tlondon kernel: [<ffffffff8101aa3b>] ? native_sched_clock+0x2d/0x62 Aug 14 17:53:29 tlondon kernel: [<ffffffff81095731>] ? lock_release_holdtime+0x3f/0x146 Aug 14 17:53:29 tlondon kernel: [<ffffffff81096d6b>] ? mark_lock+0x3c/0x253 Aug 14 17:53:29 tlondon kernel: [<ffffffff81098266>] ? __lock_acquire+0x33f/0xc0e Aug 14 17:53:29 tlondon kernel: [<ffffffff8111635f>] ? follow_page+0x1cd/0x31e Aug 14 17:53:29 tlondon kernel: [<ffffffff811156a3>] ? __do_fault+0x35f/0x419 Aug 14 17:53:29 tlondon kernel: [<ffffffff811178df>] ? handle_mm_fault+0x300/0x725 Aug 14 17:53:29 tlondon kernel: [<ffffffff8150699e>] ? _spin_unlock+0x3a/0x55 Aug 14 17:53:29 tlondon kernel: [<ffffffff81118033>] ? __get_user_pages+0x32f/0x42c Aug 14 17:53:29 tlondon kernel: [<ffffffff8111a4bd>] ? __mlock_vma_pages_range+0xef/0x2a9 Aug 14 17:53:29 tlondon kernel: [<ffffffff8127dbee>] ? __up_read+0x2d/0xaa Aug 14 17:53:29 tlondon kernel: [<ffffffff8111ad6b>] ? munlock_vma_pages_range+0x2b/0x41 Aug 14 17:53:29 tlondon kernel: [<ffffffff8111b97b>] ? exit_mmap+0x64/0x165 Aug 14 17:53:29 tlondon kernel: [<ffffffff8106290f>] ? mmput+0x5a/0xcc Aug 14 17:53:29 tlondon kernel: [<ffffffff8106786a>] ? exit_mm+0x115/0x136 Aug 14 17:53:29 tlondon kernel: [<ffffffff810695cb>] ? do_exit+0x1e1/0x768 Aug 14 17:53:29 tlondon kernel: [<ffffffff8150413f>] ? thread_return+0x4e/0xd3 Aug 14 17:53:29 tlondon kernel: [<ffffffff81069be5>] ? do_group_exit+0x93/0xc3 Aug 14 17:53:29 tlondon kernel: [<ffffffff81069c3f>] ? sys_exit_group+0x2a/0x42 Aug 14 17:53:29 tlondon kernel: [<ffffffff81012f42>] ? system_call_fastpath+0x16/0x1b
Looks like this also prevents a boot from an encrypted disk: https://bugzilla.redhat.com/show_bug.cgi?id=516909
*** This bug has been marked as a duplicate of bug 516909 ***