From: Ingo Molnar <mingo@elte.hu>
To: Maneesh Soni <maneesh@in.ibm.com>
Cc: Greg KH <greg@kroah.com>, Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: What protection does sysfs_readdir have with SMP/Preemption?
Date: Wed, 23 Nov 2005 09:18:45 +0100 [thread overview]
Message-ID: <20051123081845.GA32021@elte.hu> (raw)
In-Reply-To: <20051123045049.GA22714@in.ibm.com>
* Maneesh Soni <maneesh@in.ibm.com> wrote:
> But the bad pointer reference seen in sysfs_readdir() has to be
> debugged. Assumption here is that if there is a dentry attached to
> s_dirent, there has to be a inode associated becuase negative dentries
> are not created in sysfs. Is it possible to get some more information
> about the recreation scenario. Could you enable DEBUG printks for
> lib/kobject.c and drivers/base/class.c to see the events happening.
on a related note - i've been carrying the patch below in -rt for 2
months (i.e. Steven's kernel has it too), as a workaround against the
crash described below.
so it appears that the -rt kernel is triggering some genuine sysfs race.
[note that it only happens on an SMP kernel, booting an UP kernel or
with maxcpus=1 makes the bug go away.] I have done full kobject
debugging but no conclusive results. Also, that particular crash happens
earliest with PAGEALLOC enabled. [i have packed up the email discussion
related to that crash, and i'm sending it to Maneesh separately.
Maneesh, any ideas or suggestions?]
note that Steven has a dual-core Athlon64 X2 system. Steven, do you get
the crash even with maxcpus=1?
Ingo
-----
i'm occasionally getting the crash below on a PREEMPT_RT kernel. Might
be a PREEMPT_RT bug, or might be some sysfs race only visible under
PREEMPT_RT. Any ideas? The crash is at:
(gdb) list *0xc01a2095
0xc01a2095 is in sysfs_hash_and_remove (fs/sysfs/inode.c:229).
224 }
225
226 void sysfs_hash_and_remove(struct dentry * dir, const char * name)
227 {
228 struct sysfs_dirent * sd;
229 struct sysfs_dirent * parent_sd = dir->d_fsdata;
230
231 if (dir->d_inode == NULL)
232 /* no inode means this hasn't been made visible yet */
233 return;
(gdb)
[...]
Calling initcall 0xc05ba6e0: spi_transport_init+0x0/0x30()
Calling initcall 0xc05ba710: ahc_linux_init+0x0/0xf0()
ACPI: PCI Interrupt 0000:03:04.0[A] -> GSI 18 (level, low) -> IRQ 20
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
Vendor: SEAGATE Model: ST336706LC Rev: 010A
Type: Direct-Access ANSI SCSI revision: 03
scsi0:A:0:0: Tagged Queuing enabled. Depth 32
target0:0:0: Beginning Domain Validation
target0:0:0: wide asynchronous.
target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
target0:0:0: Ending Domain Validation
Vendor: SEAGATE Model: ST336706LC Rev: 010A
Type: Direct-Access ANSI SCSI revision: 03
scsi0:A:1:0: Tagged Queuing enabled. Depth 32
target0:0:1: Beginning Domain Validation
target0:0:1: wide asynchronous.
target0:0:1: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
target0:0:1: Ending Domain Validation
BUG: Unable to handle kernel paging request at virtual address f6c47fc0
printing eip:
c01a2095
*pde = 006cc067
*pte = 36c47000
Oops: 0000 [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 1
EIP: 0060:[<c01a2095>] Not tainted VLI
EFLAGS: 00010282 (2.6.14-rc2-rt2)
EIP is at sysfs_hash_and_remove+0x15/0x110
eax: f6c47f2c ebx: f6c42f64 ecx: c013edb4 edx: f6c3e5b8
esi: f6c42f5c edi: c04fd880 ebp: c277ec88 esp: c277ec70
ds: 007b es: 007b ss: 0068 preempt: 00000001
Process swapper (pid: 1, threadinfo=c277e000 task=c277d900 stack_left=3132 worst_left=-1)
Stack: f6c4a3b8 f6c3e5b8 f6c47f2c f6c42f64 f6c42f5c c04fd880 c277ec90 c01a3ddb
c277ecb0 c02a8051 c04fd888 f6c3e5b8 c04fd7a0 f6c42f5c f7ad6c68 c04fd7a0
c277ecbc c02a9d52 00000000 c277ecd4 c02a9f88 f6c42f5c f7ad6c68 f79ac80c
Call Trace:
[<c010405a>] show_stack+0x7a/0x90 (32)
[<c010421e>] show_registers+0x18e/0x1f0 (56)
[<c0104420>] die+0x100/0x180 (68)
[<c0442ea8>] do_page_fault+0x368/0x556 (92)
[<c0103d0b>] error_code+0x4f/0x54 (84)
[<c01a3ddb>] sysfs_remove_link+0xb/0x10 (8)
[<c02a8051>] class_device_del+0xf1/0x100 (32)
[<c02a9d52>] attribute_container_class_device_del+0x12/0x20 (12)
[<c02a9f88>] transport_remove_classdev+0x38/0x70 (24)
[<c02a9bfd>] attribute_container_device_trigger+0x8d/0xc0 (40)
[<c02a9fcd>] transport_remove_device+0xd/0x10 (8)
[<c032f01b>] scsi_target_reap+0x9b/0xb0 (20)
[<c032feb4>] __scsi_scan_target+0x94/0x130 (44)
[<c0330068>] scsi_scan_channel+0x78/0x90 (32)
[<c0330109>] scsi_scan_host_selected+0x89/0xf0 (32)
[<c0330192>] scsi_scan_host+0x22/0x30 (16)
[<c0349a85>] ahc_linux_register_host+0x1b5/0x1c0 (132)
[<c034d53d>] ahc_linux_pci_dev_probe+0xed/0x140 (132)
[<c022a02d>] pci_call_probe+0xd/0x10 (12)
[<c022a081>] __pci_device_probe+0x51/0x60 (20)
[<c022a0b9>] pci_device_probe+0x29/0x60 (16)
[<c02a6d76>] driver_probe_device+0x36/0xb0 (36)
[<c02a6ebd>] __driver_attach+0x4d/0x70 (20)
[<c02a6419>] bus_for_each_dev+0x49/0x70 (40)
[<c02a6ef9>] driver_attach+0x19/0x20 (12)
[<c02a68e1>] bus_add_driver+0x81/0xd0 (36)
[<c02a72a1>] driver_register+0x51/0x60 (20)
[<c022a34b>] pci_register_driver+0x8b/0xa0 (16)
[<c034d59d>] ahc_linux_pci_init+0xd/0x20 (8)
[<c05ba799>] ahc_linux_init+0x89/0xf0 (24)
[<c059ba62>] do_initcalls+0x32/0xe0 (36)
[<c059bb35>] do_basic_setup+0x25/0x30 (8)
[<c01003de>] init+0xae/0x2d0 (24)
[<c0101359>] kernel_thread_helper+0x5/0xc (1032327196)
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c013fc41>] .... add_preempt_count+0x11/0x20
.....[<c01169a0>] .. ( <= try_to_wake_up+0x50/0x440)
------------------------------
| showing all locks held by: | (swapper/1 [c277d900, 116]):
------------------------------
#001: [c067618c] {(struct semaphore *)(&hwif->gendev_rel_sem)}
... acquired at: init_hwif_data+0x8d/0x180
#002: [c0676d0c] {(struct semaphore *)(&hwif->gendev_rel_sem)}
... acquired at: init_hwif_data+0x8d/0x180
#003: [c067788c] {(struct semaphore *)(&hwif->gendev_rel_sem)}
... acquired at: init_hwif_data+0x8d/0x180
#004: [c067840c] {(struct semaphore *)(&hwif->gendev_rel_sem)}
... acquired at: init_hwif_data+0x8d/0x180
#005: [c0678f8c] {(struct semaphore *)(&hwif->gendev_rel_sem)}
... acquired at: init_hwif_data+0x8d/0x180
#006: [c0679b0c] {(struct semaphore *)(&hwif->gendev_rel_sem)}
... acquired at: init_hwif_data+0x8d/0x180
#007: [c067a68c] {(struct semaphore *)(&hwif->gendev_rel_sem)}
... acquired at: init_hwif_data+0x8d/0x180
#008: [c067b20c] {(struct semaphore *)(&hwif->gendev_rel_sem)}
... acquired at: init_hwif_data+0x8d/0x180
#009: [c067bd8c] {(struct semaphore *)(&hwif->gendev_rel_sem)}
... acquired at: init_hwif_data+0x8d/0x180
#010: [c067c90c] {(struct semaphore *)(&hwif->gendev_rel_sem)}
... acquired at: init_hwif_data+0x8d/0x180
#011: [f79a7a00] {(struct semaphore *)(&dev->sem)}
... acquired at: __driver_attach+0x22/0x70
#012: [f7aee8ac] {(struct semaphore *)(&shost->scan_mutex)}
... acquired at: scsi_scan_host_selected+0x56/0xf0
#013: [c04dc604] {kernel_sem.lock}
... acquired at: __reacquire_kernel_lock+0x33/0x70
#014: [c04eed24] {attribute_container_mutex.lock}
... acquired at: attribute_container_device_trigger+0x18/0xc0
Code: 8b 7c 24 08 89 ec 5d c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 83 ec 18 89 5d f4 89 75 f8 89 7d fc 89 45 f0 89 55 ec <8b> b0 94 00 00 00 8b 40 4c 85 c0 75 0e 8b 5d f4 8b 75 f8 8b 7d
<0>Kernel panic - not syncing: Attempted to kill init!
Signed-off-by: Ingo Molnar <mingo@elte.hu>
drivers/base/class.c | 4 ++++
1 files changed, 4 insertions(+)
Index: linux/drivers/base/class.c
===================================================================
--- linux.orig/drivers/base/class.c
+++ linux/drivers/base/class.c
@@ -520,8 +520,10 @@ int class_device_add(struct class_device
class_name = make_class_name(class_dev);
sysfs_create_link(&class_dev->kobj,
&class_dev->dev->kobj, "device");
+ /*
sysfs_create_link(&class_dev->dev->kobj, &class_dev->kobj,
class_name);
+ */
}
/* notify any interfaces this device is now here */
@@ -618,7 +620,9 @@ void class_device_del(struct class_devic
if (class_dev->dev) {
class_name = make_class_name(class_dev);
sysfs_remove_link(&class_dev->kobj, "device");
+ /*
sysfs_remove_link(&class_dev->dev->kobj, class_name);
+ */
}
if (class_dev->devt_attr)
class_device_remove_file(class_dev, class_dev->devt_attr);
next prev parent reply other threads:[~2005-11-23 8:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-22 21:33 What protection does sysfs_readdir have with SMP/Preemption? Steven Rostedt
2005-11-22 21:39 ` Greg KH
2005-11-23 4:50 ` Maneesh Soni
2005-11-23 8:18 ` Ingo Molnar [this message]
2005-11-23 12:35 ` Steven Rostedt
2005-11-23 12:54 ` Maneesh Soni
2005-11-23 12:50 ` Maneesh Soni
2005-11-23 12:52 ` [OOPS] sysfs_hash_and_remove (was Re: What protection ....) Maneesh Soni
2005-11-24 12:26 ` Maneesh Soni
2005-11-24 14:34 ` Ingo Molnar
2005-11-26 22:26 ` James Bottomley
2006-02-11 0:33 ` Greg KH
2006-02-11 15:46 ` Steven Rostedt
2006-02-24 1:04 ` Greg KH
2005-11-23 12:56 ` What protection does sysfs_readdir have with SMP/Preemption? Steven Rostedt
2005-11-23 13:58 ` Maneesh Soni
2005-11-23 14:15 ` Steven Rostedt
2005-11-23 14:20 ` Steven Rostedt
2005-11-23 15:24 ` kobject_register needs return value checks (was: What protection does sysfs_readdir have with SMP/Preemption?) Steven Rostedt
2005-11-24 4:16 ` What protection does sysfs_readdir have with SMP/Preemption? Maneesh Soni
2005-11-24 14:32 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051123081845.GA32021@elte.hu \
--to=mingo@elte.hu \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maneesh@in.ibm.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.