From mboxrd@z Thu Jan 1 00:00:00 1970 From: joeyli Subject: Re: [PATCH] efivarfs: Delete dentry from dcache in efivarfs_file_write() Date: Thu, 17 Jan 2013 17:00:04 +0800 Message-ID: <1358413204.14569.167.camel@linux-s257.site> References: <1358408353-24497-1-git-send-email-matt@console-pimps.org> <1358412483.14569.164.camel@linux-s257.site> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <1358412483.14569.164.camel-ONCj+Eqt86TasUa73XJKwA@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Matt Fleming Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Matt Fleming , Josh Boyer , Jeremy Kerr , Andy Whitcroft List-Id: linux-efi@vger.kernel.org =E6=96=BC =E5=9B=9B=EF=BC=8C2013-01-17 =E6=96=BC 16:48 +0800=EF=BC=8Cjo= eyli =E6=8F=90=E5=88=B0=EF=BC=9A > =E6=96=BC =E5=9B=9B=EF=BC=8C2013-01-17 =E6=96=BC 07:39 +0000=EF=BC=8C= Matt Fleming =E6=8F=90=E5=88=B0=EF=BC=9A > > From: Matt Fleming > >=20 > > Unlike the unlink path that is called from the VFS layer, we need t= o > > call d_delete() ourselves when a variable is deleted in > > efivarfs_file_write(). > >=20 > > Failure to do so means we can access a stale struct efivar_entry wh= en > > reading/writing the file, which can result in the following oops, > >=20 > > [ 59.978216] general protection fault: 0000 [#1] SMP > > [ 60.038660] CPU 9 > > [ 60.040501] Pid: 1001, comm: cat Not tainted 3.7.0-2.fc19.x86_= 64 #1 IBM System x3550 M3 -[7944I21]-/69Y4438 > > [ 60.050840] RIP: 0010:[] [] __lock_acquire+0x5e/0x1bb0 > > [ 60.059198] RSP: 0018:ffff880270595ce8 EFLAGS: 00010046 > > [ 60.064500] RAX: 0000000000000046 RBX: 0000000000000002 RCX: 0= 000000000000000 > > [ 60.071617] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 6= b6b6b6b6b6b6b83 > > [ 60.078735] RBP: ffff880270595dd8 R08: 0000000000000002 R09: 0= 000000000000000 > > [ 60.085852] R10: 6b6b6b6b6b6b6b83 R11: 0000000000000000 R12: 0= 000000000000000 > > [ 60.092971] R13: ffff88027170cd20 R14: 0000000000000000 R15: 0= 000000000000000 > > [ 60.100091] FS: 00007fc0c8ff3740(0000) GS:ffff880277000000(00= 00) knlGS:0000000000000000 > > [ 60.108164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 60.113899] CR2: 0000000001520000 CR3: 000000026d594000 CR4: 0= 0000000000007e0 > > [ 60.121016] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0= 000000000000000 > > [ 60.128135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0= 000000000000400 > > [ 60.135254] Process cat (pid: 1001, threadinfo ffff88027059400= 0, task ffff88027170cd20) > > [ 60.143239] Stack: > > [ 60.145251] ffff880270595cf8 ffffffff81021da3 ffff880270595d0= 8 ffffffff81021e19 > > [ 60.152714] ffff880270595d38 ffffffff810acdb5 ffff88020000016= 8 0000000000000086 > > [ 60.160175] ffff88027170d5e8 ffffffff810d25ed ffff880270595d5= 8 ffffffff810ace7f > > [ 60.167638] Call Trace: > > [ 60.170088] [] ? native_sched_clock+0x13/0x= 80 > > [ 60.176085] [] ? sched_clock+0x9/0x10 > > [ 60.181389] [] ? sched_clock_cpu+0xc5/0x120 > > [ 60.187211] [] ? trace_hardirqs_off+0xd/0x1= 0 > > [ 60.193121] [] ? local_clock+0x6f/0x80 > > [ 60.198513] [] ? lock_release_holdtime.part= =2E26+0xf/0x180 > > [ 60.205465] [] ? lock_release_non_nested+0x= 2e7/0x320 > > [ 60.212073] [] ? efivarfs_file_write+0x5b/0= x280 > > [ 60.218242] [] lock_acquire+0xa1/0x1f0 > > [ 60.223633] [] ? efivarfs_file_write+0x111/= 0x280 > > [ 60.229892] [] ? might_fault+0x5c/0xb0 > > [ 60.235287] [] _raw_spin_lock+0x46/0x80 > > [ 60.240762] [] ? efivarfs_file_write+0x111/= 0x280 > > [ 60.247018] [] efivarfs_file_write+0x111/0x= 280 > > [ 60.253103] [] vfs_write+0xaf/0x190 > > [ 60.258233] [] sys_write+0x55/0xa0 > > [ 60.263278] [] system_call_fastpath+0x16/0x= 1b > > [ 60.269271] Code: 41 0f 45 d8 4c 89 75 f0 4c 89 7d f8 85 c0 0f= 84 09 01 00 00 8b 05 a3 f9 ff 00 49 89 fa 41 89 f6 41 89 d3 85 c0 0f 8= 4 12 01 00 00 <49> 8b 02 ba 01 00 00 00 48 3d a0 07 14 82 0f 44 da 41 8= 3 fe 01 > > [ 60.289431] RIP [] __lock_acquire+0x5e/0x1b= b0 > > [ 60.295444] RSP > > [ 60.298928] ---[ end trace 1bbfd41a2cf6a0d8 ]--- > >=20 > > Cc: Josh Boyer > > Cc: Jeremy Kerr > > Cc: Lee, Chun-Yi > > Cc: Andy Whitcroft > > Reported-by: Lingzhu Xiang > > Signed-off-by: Matt Fleming >=20 > This patch works to me for fix the ghost file after remove variable f= rom > EFI file system. And, I test create/remote variable then reboot syste= m a ^^^^^^^^^ remove Sorry for typo! In additional, I tested use 'echo -en "\x07\0\0\0" >' to delete variable, also can not reproduce issue. Thanks Joey Lee > couple of times, didn't see problem. >=20 > Tested-by: Lee, Chun-Yi >=20 >=20 > Thanks a lot! > Joey Lee >=20 > > --- > > drivers/firmware/efivars.c | 1 + > > 1 file changed, 1 insertion(+) > >=20 > > diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.= c > > index 807dad4..2ed59dc 100644 > > --- a/drivers/firmware/efivars.c > > +++ b/drivers/firmware/efivars.c > > @@ -793,6 +793,7 @@ static ssize_t efivarfs_file_write(struct file = *file, > > spin_unlock(&efivars->lock); > > efivar_unregister(var); > > drop_nlink(inode); > > + d_delete(file->f_dentry); > > dput(file->f_dentry); > > =20 > > } else { >=20 >=20 > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" = in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >=20