RE: [PATCH 2/2] Fixed typo Intel RNG driver for2.6.21-rc7-mm1
Hi Jan, Thank you for the comment. > ># Do you think that a "FWH not detected" message is noisy? > > No, I think it helps understanding why there's no RNG device > in the system. OK, the typo fixes patch was corrected. intel-rng.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c~2007-04-26 13:41:53.0 +0900 +++ linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c 2007-04-26 16:26:16.0 +0900 @@ -365,7 +365,8 @@ static int __init mod_init(void) pci_dev_put(dev); iounmap(intel_rng_hw->mem); kfree(intel_rng_hw); - goto out; + if (err) + goto out; fwh_done: err = -ENOMEM; - 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/
[PATCH 1/2] Fix the memory leak Intel RNG driver for 2.6.21-rc7-mm1
This patch fixes a memory leak in mod_init().
In the error, intel_rng_hw was freed.
intel-rng.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c.orig
2007-04-26 11:56:03.0 +0900
+++ linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c 2007-04-26
13:39:50.0 +0900
@@ -345,11 +345,11 @@ static int __init mod_init(void)
}
err = intel_init_hw_struct(intel_rng_hw, dev);
- if (err == -ENODEV) {
- pci_dev_put(dev);
- goto fwh_done;
- } else if (err < 0) {
+ if (err) {
pci_dev_put(dev);
+ kfree(intel_rng_hw);
+ if (err == -ENODEV)
+ goto fwh_done;
goto out;
}
-
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/
[PATCH 2/2] Fixed typo Intel RNG driver for 2.6.21-rc7-mm1
This patch fixes a typo in mod_init().
fwh_done is performed when Intel fwh is found.
intel-rng.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c~2007-04-26
13:41:53.0 +0900
+++ linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c 2007-04-26
13:43:35.0 +0900
@@ -264,7 +264,6 @@ static int __init intel_rng_hw_init(void
if (mfc != INTEL_FWH_MANUFACTURER_CODE ||
(dvc != INTEL_FWH_DEVICE_CODE_8M &&
dvc != INTEL_FWH_DEVICE_CODE_4M)) {
- printk(KERN_ERR PFX "FWH not detected\n");
return -ENODEV;
}
@@ -365,7 +364,8 @@ static int __init mod_init(void)
pci_dev_put(dev);
iounmap(intel_rng_hw->mem);
kfree(intel_rng_hw);
- goto out;
+ if (err)
+ goto out;
fwh_done:
err = -ENOMEM;
-
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/
RE: [PATCH 2/2] Fixed typo Intel RNG driver for2.6.21-rc7-mm1
> But why do you remove the printk()? I think that FWH connected to LPC of ICHx are not only Intel products. For example, sst... etc. Does rng address differ in except Intel products? I think that this driver is targeting Intel FWH. Therefore, printk() was removed. # Do you think that a "FWH not detected" message is noisy? -- Haruo - 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/
[PATCH 0/2] Clean up Intel RNG driver for 2.6.21-rc7-mm1
Hi Prarit and Jan, Clean up Intel RNG driver for 2.6.21-rc7-mm1. Patch 1/2 fixed the memory leak. Patch 2/2 fixed typo. Please give me a comment. -- Haruo - 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/
[PATCH 0/2] Clean up Intel RNG driver for 2.6.21-rc7-mm1
Hi Prarit and Jan, Clean up Intel RNG driver for 2.6.21-rc7-mm1. Patch 1/2 fixed the memory leak. Patch 2/2 fixed typo. Please give me a comment. -- Haruo - 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/
[PATCH 1/2] Fix the memory leak Intel RNG driver for 2.6.21-rc7-mm1
This patch fixes a memory leak in mod_init().
In the error, intel_rng_hw was freed.
intel-rng.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c.orig
2007-04-26 11:56:03.0 +0900
+++ linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c 2007-04-26
13:39:50.0 +0900
@@ -345,11 +345,11 @@ static int __init mod_init(void)
}
err = intel_init_hw_struct(intel_rng_hw, dev);
- if (err == -ENODEV) {
- pci_dev_put(dev);
- goto fwh_done;
- } else if (err 0) {
+ if (err) {
pci_dev_put(dev);
+ kfree(intel_rng_hw);
+ if (err == -ENODEV)
+ goto fwh_done;
goto out;
}
-
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/
[PATCH 2/2] Fixed typo Intel RNG driver for 2.6.21-rc7-mm1
This patch fixes a typo in mod_init().
fwh_done is performed when Intel fwh is found.
intel-rng.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c~2007-04-26
13:41:53.0 +0900
+++ linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c 2007-04-26
13:43:35.0 +0900
@@ -264,7 +264,6 @@ static int __init intel_rng_hw_init(void
if (mfc != INTEL_FWH_MANUFACTURER_CODE ||
(dvc != INTEL_FWH_DEVICE_CODE_8M
dvc != INTEL_FWH_DEVICE_CODE_4M)) {
- printk(KERN_ERR PFX FWH not detected\n);
return -ENODEV;
}
@@ -365,7 +364,8 @@ static int __init mod_init(void)
pci_dev_put(dev);
iounmap(intel_rng_hw-mem);
kfree(intel_rng_hw);
- goto out;
+ if (err)
+ goto out;
fwh_done:
err = -ENOMEM;
-
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/
RE: [PATCH 2/2] Fixed typo Intel RNG driver for2.6.21-rc7-mm1
But why do you remove the printk()? I think that FWH connected to LPC of ICHx are not only Intel products. For example, sst... etc. Does rng address differ in except Intel products? I think that this driver is targeting Intel FWH. Therefore, printk() was removed. # Do you think that a FWH not detected message is noisy? -- Haruo - 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/
RE: [PATCH 2/2] Fixed typo Intel RNG driver for2.6.21-rc7-mm1
Hi Jan, Thank you for the comment. # Do you think that a FWH not detected message is noisy? No, I think it helps understanding why there's no RNG device in the system. OK, the typo fixes patch was corrected. intel-rng.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c~2007-04-26 13:41:53.0 +0900 +++ linux-2.6.21-rc7-mm1/drivers/char/hw_random/intel-rng.c 2007-04-26 16:26:16.0 +0900 @@ -365,7 +365,8 @@ static int __init mod_init(void) pci_dev_put(dev); iounmap(intel_rng_hw-mem); kfree(intel_rng_hw); - goto out; + if (err) + goto out; fwh_done: err = -ENOMEM; - 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/
RE: libata-dev queue updated
Hi Bunk, Thank you for your replay. > With SCSI=m and SCSI_SATA=y this allows the static enabling > of the SATA drivers with unwanted effects, e.g.: > - SCSI=m, SCSI_SATA=y, SCSI_ATA_ADMA=y > -> SCSI_ATA_ADMA is built statically but scsi/built-in.o is > not linked > into the kernel > - SCSI=m, SCSI_SATA=y, SCSI_ATA_ADMA=y, SCSI_SATA_AHCI=m > -> SCSI_ATA_ADMA and libata are built statically but > scsi/built-in.o is not linked into the kernel, > SCSI_SATA_AHCI is built modular (unresolved symbols due > to missing > libata) I agree. Thanks again, Haruo - 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/
RE: libata-dev queue updated
Hi Bunk, Thank you for your replay. With SCSI=m and SCSI_SATA=y this allows the static enabling of the SATA drivers with unwanted effects, e.g.: - SCSI=m, SCSI_SATA=y, SCSI_ATA_ADMA=y - SCSI_ATA_ADMA is built statically but scsi/built-in.o is not linked into the kernel - SCSI=m, SCSI_SATA=y, SCSI_ATA_ADMA=y, SCSI_SATA_AHCI=m - SCSI_ATA_ADMA and libata are built statically but scsi/built-in.o is not linked into the kernel, SCSI_SATA_AHCI is built modular (unresolved symbols due to missing libata) I agree. Thanks again, Haruo - 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/
RE: libata-dev queue updated
On Thursday, August 25, 2005 8:02 PM (JST), Adrian Bunk wrote: > > 2.6.13- rc7-libata1.patch.bz2 was used. > > A combined mode of ata_piix seems not to work. > > Is the following patches correct? > > > > diff -urN linux-2.6.13-rc7.orig/drivers/scsi/Kconfig > linux-2.6.13-rc7/drivers/scsi/Kconfig > > --- linux-2.6.13-rc7.orig/drivers/scsi/Kconfig > 2005-08-25 13:44:33.0 +0900 > > +++ linux-2.6.13-rc7/drivers/scsi/Kconfig 2005-08-25 > 14:33:38.0 +0900 > > @@ -424,7 +424,7 @@ > > source "drivers/scsi/megaraid/Kconfig.megaraid" > > > > config SCSI_SATA > > - tristate "Serial ATA (SATA) support" > > + bool "Serial ATA (SATA) support" > > depends on SCSI > > help > > This driver family supports Serial ATA host controllers > > No, this bug reintroduces a problem with SCSI=m. Please explain this bug in detail. > Which problem do you face? > And how did this change alone fix it for you? I am using Intel 82801EB SATA controller. 2.6.13-rc7-libata1.patch.bz2 worked as PATA when 82801EB was used in a combined mode. Does quirk_intel_ide_combined() work effectively? Thanks, Haruo - 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/
RE: libata-dev queue updated
Hi Jeff, 2.6.13- rc7-libata1.patch.bz2 was used. A combined mode of ata_piix seems not to work. Is the following patches correct? diff -urN linux-2.6.13-rc7.orig/drivers/scsi/Kconfig linux-2.6.13-rc7/drivers/scsi/Kconfig --- linux-2.6.13-rc7.orig/drivers/scsi/Kconfig 2005-08-25 13:44:33.0 +0900 +++ linux-2.6.13-rc7/drivers/scsi/Kconfig 2005-08-25 14:33:38.0 +0900 @@ -424,7 +424,7 @@ source "drivers/scsi/megaraid/Kconfig.megaraid" config SCSI_SATA - tristate "Serial ATA (SATA) support" + bool "Serial ATA (SATA) support" depends on SCSI help This driver family supports Serial ATA host controllers -- Haruo - 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/
RE: libata-dev queue updated
Hi Jeff, 2.6.13- rc7-libata1.patch.bz2 was used. A combined mode of ata_piix seems not to work. Is the following patches correct? diff -urN linux-2.6.13-rc7.orig/drivers/scsi/Kconfig linux-2.6.13-rc7/drivers/scsi/Kconfig --- linux-2.6.13-rc7.orig/drivers/scsi/Kconfig 2005-08-25 13:44:33.0 +0900 +++ linux-2.6.13-rc7/drivers/scsi/Kconfig 2005-08-25 14:33:38.0 +0900 @@ -424,7 +424,7 @@ source drivers/scsi/megaraid/Kconfig.megaraid config SCSI_SATA - tristate Serial ATA (SATA) support + bool Serial ATA (SATA) support depends on SCSI help This driver family supports Serial ATA host controllers -- Haruo - 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/
RE: libata-dev queue updated
On Thursday, August 25, 2005 8:02 PM (JST), Adrian Bunk wrote: 2.6.13- rc7-libata1.patch.bz2 was used. A combined mode of ata_piix seems not to work. Is the following patches correct? diff -urN linux-2.6.13-rc7.orig/drivers/scsi/Kconfig linux-2.6.13-rc7/drivers/scsi/Kconfig --- linux-2.6.13-rc7.orig/drivers/scsi/Kconfig 2005-08-25 13:44:33.0 +0900 +++ linux-2.6.13-rc7/drivers/scsi/Kconfig 2005-08-25 14:33:38.0 +0900 @@ -424,7 +424,7 @@ source drivers/scsi/megaraid/Kconfig.megaraid config SCSI_SATA - tristate Serial ATA (SATA) support + bool Serial ATA (SATA) support depends on SCSI help This driver family supports Serial ATA host controllers No, this bug reintroduces a problem with SCSI=m. Please explain this bug in detail. Which problem do you face? And how did this change alone fix it for you? I am using Intel 82801EB SATA controller. 2.6.13-rc7-libata1.patch.bz2 worked as PATA when 82801EB was used in a combined mode. Does quirk_intel_ide_combined() work effectively? Thanks, Haruo - 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/
RE: Isn't there race issue during fput() and the dentry_open()?
Hi Viro,
Thank you for your help and advice.
I made the following patches referring to your advice.
I try to debugging by using this patch.
Thanks again,
Haruo
diff -urN linux-2.6.12-rc2.orig/fs/file_table.c linux-2.6.12-rc2/fs/file_table.c
--- linux-2.6.12-rc2.orig/fs/file_table.c 2005-03-02 16:37:47.0
+0900
+++ linux-2.6.12-rc2/fs/file_table.c2005-04-05 11:21:58.0 +0900
@@ -26,6 +26,7 @@
/* public. Not pretty! */
__cacheline_aligned_in_smp DEFINE_SPINLOCK(files_lock);
+pid_t holder_pid;
static DEFINE_SPINLOCK(filp_count_lock);
diff -urN linux-2.6.12-rc2.orig/include/linux/fs.h
linux-2.6.12-rc2/include/linux/fs.h
--- linux-2.6.12-rc2.orig/include/linux/fs.h2005-04-05 11:12:53.0
+0900
+++ linux-2.6.12-rc2/include/linux/fs.h 2005-04-05 11:20:15.0 +0900
@@ -602,8 +602,17 @@
struct address_space*f_mapping;
};
extern spinlock_t files_lock;
-#define file_list_lock() spin_lock(_lock);
-#define file_list_unlock() spin_unlock(_lock);
+extern pid_t holder_pid;
+#define file_list_lock() \
+ do { \
+ spin_lock(_lock); \
+ holder_pid = current->pid; \
+ }while(0)
+#define file_list_unlock() \
+ do { \
+ holder_pid = 0; \
+ spin_unlock(_lock); \
+ }while(0)
#define get_file(x)atomic_inc(&(x)->f_count)
#define file_count(x) atomic_read(&(x)->f_count)
-
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/
RE: Isn't there race issue during fput() and the dentry_open()?
Hi Viro,
Thank you for your help and advice.
I made the following patches referring to your advice.
I try to debugging by using this patch.
Thanks again,
Haruo
diff -urN linux-2.6.12-rc2.orig/fs/file_table.c linux-2.6.12-rc2/fs/file_table.c
--- linux-2.6.12-rc2.orig/fs/file_table.c 2005-03-02 16:37:47.0
+0900
+++ linux-2.6.12-rc2/fs/file_table.c2005-04-05 11:21:58.0 +0900
@@ -26,6 +26,7 @@
/* public. Not pretty! */
__cacheline_aligned_in_smp DEFINE_SPINLOCK(files_lock);
+pid_t holder_pid;
static DEFINE_SPINLOCK(filp_count_lock);
diff -urN linux-2.6.12-rc2.orig/include/linux/fs.h
linux-2.6.12-rc2/include/linux/fs.h
--- linux-2.6.12-rc2.orig/include/linux/fs.h2005-04-05 11:12:53.0
+0900
+++ linux-2.6.12-rc2/include/linux/fs.h 2005-04-05 11:20:15.0 +0900
@@ -602,8 +602,17 @@
struct address_space*f_mapping;
};
extern spinlock_t files_lock;
-#define file_list_lock() spin_lock(files_lock);
-#define file_list_unlock() spin_unlock(files_lock);
+extern pid_t holder_pid;
+#define file_list_lock() \
+ do { \
+ spin_lock(files_lock); \
+ holder_pid = current-pid; \
+ }while(0)
+#define file_list_unlock() \
+ do { \
+ holder_pid = 0; \
+ spin_unlock(files_lock); \
+ }while(0)
#define get_file(x)atomic_inc((x)-f_count)
#define file_count(x) atomic_read((x)-f_count)
-
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/
RE: Isn't there race issue during fput() and the dentry_open()?
Hi Viro,
Thank you for your replay.
> > Stack traceback for pid 2130
> > 0xf717f1b0 21301 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.0 +0900
> > +++ linux-2.6.12-rc1/fs/file_table.c2005-03-31
> 17:50:46.323999320 +0900
> > @@ -209,11 +209,11 @@
> >
> > void file_kill(struct file *file)
> > {
> > + file_list_lock();
> > if (!list_empty(>f_list)) {
> > - file_list_lock();
> > list_del_init(>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?
I think that it is true not to be able to acquire file_list_lock()
that is called from file_move().
> 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?
Indeed, Is there a good method of debugging this issue?
In the check on the source, a doubtful place was not found except file_kill().
I might call not race of fput() and the dentry_open() but
the deadlock of file_list_lock().
--
Haruo
-
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/
RE: Isn't there race issue during fput() and the dentry_open()?
Hi Viro,
Thank you for your replay.
Stack traceback for pid 2130
0xf717f1b0 21301 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.0 +0900
+++ linux-2.6.12-rc1/fs/file_table.c2005-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?
I think that it is true not to be able to acquire file_list_lock()
that is called from file_move().
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?
Indeed, Is there a good method of debugging this issue?
In the check on the source, a doubtful place was not found except file_kill().
I might call not race of fput() and the dentry_open() but
the deadlock of file_list_lock().
--
Haruo
-
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/
Isn't there race issue during fput() and the dentry_open()?
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 21301 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.0
+0900
+++ linux-2.6.12-rc1/fs/file_table.c2005-03-31 17:50:46.323999320 +0900
@@ -209,11 +209,11 @@
void file_kill(struct file *file)
{
+ file_list_lock();
if (!list_empty(>f_list)) {
- file_list_lock();
list_del_init(>f_list);
- file_list_unlock();
}
+ file_list_unlock();
}
int fs_may_remount_ro(struct super_block *sb)
--
Haruo
-
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/
Isn't there race issue during fput() and the dentry_open()?
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 21301 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.0
+0900
+++ linux-2.6.12-rc1/fs/file_table.c2005-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();
}
int fs_may_remount_ro(struct super_block *sb)
--
Haruo
-
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/
tty->driver_data is NULL
I obtained following oops.
Modules Linked in: parport_pc lp parport autofs4 i2c_dev i2c_core xxxnrpc dm_mod
button battery ac md5 ipv6 uhci_hcd ehci_hcd e1000 floppy ext3 jbd ata_piix liba
ta sd_mod scsi_mod
CPU:0
EIP:0060:[<021f39cd>] Not tainted VLI
EFLAGS: 00010216(2.6.9-5.0.3.ELhugeme)
EIP is at vt_ioctl+0x1d/0x17b7
eax: ebx: 4b3b ecx: 4b3b edx: 02dcea80
esi: feed6f60 edi: feed6f60 ebp: 11145000 esp: 08b0fe88
ds: 007b es: 007b ss: 0068
Process gpm (pid: 2190, threadinfo=08b0f000 task=0813ab30)
Stack: 0001 11ed3e80 11949344
11145000
0246 0246 0246 5315 02120dbc 0007 11145000
Call Trace:
[<02120dbc>] release_console_sem+0x75/0xa9
[<021fbe9c>] con_open+0x88/0x8e
[<021eecd0>] tty_open+0x189/0x2a0
[<0215c132>] chrdev_open+0x171/0x187
[<02154058>] dentry_open+0xf0/0x1a5
[<02153f62>] filp_open+0x36/0x3c
[<021efad4>] tty_ioctl+0x33e/0x38d
[<0216415a>] sys_ioctl+0x211/0x253
Code: Bad EIP value.
tty->driver_data is NULL.
The following patches were made. Is this patch correct?
diff -urN linux-2.6.11.3orig/drivers/char/vt_ioctl.c
linux-2.6.11.3/drivers/char/vt_ioctl.c
--- linux-2.6.11.3orig/drivers/char/vt_ioctl.c 2005-03-13 15:44:51.0
+0900
+++ linux-2.6.11.3/drivers/char/vt_ioctl.c 2005-03-16 15:08:49.0
+0900
@@ -366,7 +366,7 @@
unsigned int cmd, unsigned long arg)
{
struct vt_struct *vt = (struct vt_struct *)tty->driver_data;
- struct vc_data *vc = vc_cons[vt->vc_num].d;
+ struct vc_data *vc;
struct console_font_op op; /* used in multiple places here */
struct kbd_struct * kbd;
unsigned int console;
@@ -374,7 +374,14 @@
void __user *up = (void __user *)arg;
int i, perm;
+ acquire_console_sem();
+ if (vt == NULL) {
+ release_console_sem();
+ return -EINVAL;
+ }
+ vc = vc_cons[vt->vc_num].d;
console = vt->vc_num;
+ release_console_sem();
if (!vc_cons_allocated(console))/* impossible? */
return -ENOIOCTLCMD;
--
Haruo
-
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/
tty-driver_data is NULL
I obtained following oops.
Modules Linked in: parport_pc lp parport autofs4 i2c_dev i2c_core xxxnrpc dm_mod
button battery ac md5 ipv6 uhci_hcd ehci_hcd e1000 floppy ext3 jbd ata_piix liba
ta sd_mod scsi_mod
CPU:0
EIP:0060:[021f39cd] Not tainted VLI
EFLAGS: 00010216(2.6.9-5.0.3.ELhugeme)
EIP is at vt_ioctl+0x1d/0x17b7
eax: ebx: 4b3b ecx: 4b3b edx: 02dcea80
esi: feed6f60 edi: feed6f60 ebp: 11145000 esp: 08b0fe88
ds: 007b es: 007b ss: 0068
Process gpm (pid: 2190, threadinfo=08b0f000 task=0813ab30)
Stack: 0001 11ed3e80 11949344
11145000
0246 0246 0246 5315 02120dbc 0007 11145000
Call Trace:
[02120dbc] release_console_sem+0x75/0xa9
[021fbe9c] con_open+0x88/0x8e
[021eecd0] tty_open+0x189/0x2a0
[0215c132] chrdev_open+0x171/0x187
[02154058] dentry_open+0xf0/0x1a5
[02153f62] filp_open+0x36/0x3c
[021efad4] tty_ioctl+0x33e/0x38d
[0216415a] sys_ioctl+0x211/0x253
Code: Bad EIP value.
tty-driver_data is NULL.
The following patches were made. Is this patch correct?
diff -urN linux-2.6.11.3orig/drivers/char/vt_ioctl.c
linux-2.6.11.3/drivers/char/vt_ioctl.c
--- linux-2.6.11.3orig/drivers/char/vt_ioctl.c 2005-03-13 15:44:51.0
+0900
+++ linux-2.6.11.3/drivers/char/vt_ioctl.c 2005-03-16 15:08:49.0
+0900
@@ -366,7 +366,7 @@
unsigned int cmd, unsigned long arg)
{
struct vt_struct *vt = (struct vt_struct *)tty-driver_data;
- struct vc_data *vc = vc_cons[vt-vc_num].d;
+ struct vc_data *vc;
struct console_font_op op; /* used in multiple places here */
struct kbd_struct * kbd;
unsigned int console;
@@ -374,7 +374,14 @@
void __user *up = (void __user *)arg;
int i, perm;
+ acquire_console_sem();
+ if (vt == NULL) {
+ release_console_sem();
+ return -EINVAL;
+ }
+ vc = vc_cons[vt-vc_num].d;
console = vt-vc_num;
+ release_console_sem();
if (!vc_cons_allocated(console))/* impossible? */
return -ENOIOCTLCMD;
--
Haruo
-
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/
