On Sun, Apr 03, 2005 at 10:56:44AM +0900, Tomita, Haruo wrote:
> Isn't there race issue during fput() and the dentry_open()?
> When booting kernel, the following deadlocks are experienced.
> Stack traceback for pid 2130
> 0xf717f1b0 2130 1 1 0 R 0xf717f400 *irqbalance
> ESP EIP Function (args)
> 0xf75bfe38 0xc02d04b2 _spin_lock+0x2e (0xf7441a80)
> 0xf75bff34 0xc015667c file_move+0x14 (0xf63080e4, 0xf75bff58, 0x0, 0xf74bf000)
> 0xf75bff40 0xc0154e37 dentry_open+0xb9 (0xf63080e4, 0xf7f5ad80, 0xc02d00e6, 0x100100, 0x246)
> 0xf75bff58 0xc0154d78 filp_open+0x36
> 0xf75bffb4 0xc0155079 sys_open+0x31
> 0xf75bffc4 0xc02d196f syscall_call+0x7
>
> The patch was made. Is this patch right?
>
> diff -urN linux-2.6.12-rc1.orig/fs/file_table.c linux-2.6.12-rc1/fs/file_table.c
> --- linux-2.6.12-rc1.orig/fs/file_table.c 2005-03-02 16:37:47.000000000 +0900
> +++ linux-2.6.12-rc1/fs/file_table.c 2005-03-31 17:50:46.323999320 +0900
> @@ -209,11 +209,11 @@
>
> void file_kill(struct file *file)
> {
> + file_list_lock();
> if (!list_empty(&file->f_list)) {
> - file_list_lock();
> list_del_init(&file->f_list);
> - file_list_unlock();
> }
> + file_list_unlock();
> }
This is absolutely useless. What are you trying to protect and how the
hell could keeping a lock around that check prevent any sort of deadlock?
Besides, who could possibly call fput() on struct file allocated by
dentry_open() and do that before the latter returns a reference to
that struct file?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
