於 三，2012-12-26 於 17:21 +0800，Lingzhu Xiang 提到： > On 12/26/2012 02:02 PM, joeyli wrote: > >> Maybe you can try v3.8-rc1 kernel. > > > > hm... I just re-test and do more times, I also can reproduce on > v3.8-rc1 > > and 54e37b8dbe branch now. > > Good news you reproduce it. I manage to isolate the following > reproducer. > > This reproducer causes general protection fault, NULL dereference or > just > hanging on QEMU/OVMF (OVMF-0.1+r13902-1.1) with 3.8-rc1 vanilla > kernel. > > With a logging point in efivarfs_file_write checking &efivars->lock, > it > looks like the spinlock is corrupted before call trace kicks in. > > Currently deletion with efivarfs_file_write just does the same thing > of > unlinking an file while it's open. > > Steps to reproduce: > $ gcc efivarfs-unlink-open-file.c -o efivarfs-unlink-open-file > # mount -t efivarfs - /sys/firmware/efi/efivars > # ./efivarfs-unlink-open-file > [ 74.893152] BUG: unable to handle kernel NULL pointer dereference > at > (null) > [ 74.894131] IP: [<ffffffff81646b4e>] _raw_spin_lock+0xe/0x30 > [ 74.894131] PGD 78b3d067 PUD 3f91b067 PMD 0 > [ 74.894131] Oops: 0002 [#1] SMP > (...) I am checking the write/umount/mount/read problem on v3.8-rc1. The issue also can trigger by read the GHOST test file. When issue happen, the size of test file is zero. The 'var->efivars' already set to NULL when issue reproduced, that's why we always got NULL pointer dereference when try to spin lock it. If we don't do umount/mount step, then everything is OK for we can create/delete test file many times. But, if we umount/mount efivarfs then more easy to trigger issue. When issue happen, inode of test file didn't removed but efivars already set to NULL. I think there have race condition between maintain efivars and vars. Still tracing... Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
