lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <a8e1da0710282036g6720803fj10647316a4144cef@mail.gmail.com> Date: Mon, 29 Oct 2007 11:36:28 +0800 From: "Dave Young" <hidave.darkstar@...il.com> To: "Marcel Holtmann" <marcel@...tmann.org> Cc: bluez-devel@...ts.sourceforge.net, LKML <linux-kernel@...r.kernel.org> Subject: Re: bluetooth: hci_sysfs work queue problem On 10/1/07, Marcel Holtmann <marcel@...tmann.org> wrote: > Hi Dave, > > > The hci_sysfs uses work queue to finish the sysfs add/del fuction. > > But when the same device connection failed, if another connection of > > same device come in before the delete work finish, sysfs will warn > > about duplicate filename creating. > > which kernel are we talking about. This problem should not exist > anymore. However the usage of a work queue is unavoidable. Recently, I encounted this issue again: Oct 26 16:57:00 darkstar kernel: sysfs: duplicate filename 'acl00194FA4E517' can not be created Oct 26 16:57:00 darkstar kernel: WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() Oct 26 16:57:00 darkstar kernel: [<c01c0120>] sysfs_add_one+0xa0/0xe0 Oct 26 16:57:00 darkstar kernel: [<c01c0d7b>] sysfs_create_link+0x9b/0x140 Oct 26 16:57:00 darkstar kernel: [<c01c1671>] create_files+0x31/0x60 Oct 26 16:57:00 darkstar kernel: [<c02b537b>] bus_add_device+0x5b/0xf0 Oct 26 16:57:00 darkstar kernel: [<c02b391c>] device_add+0x11c/0x350 Oct 26 16:57:00 darkstar kernel: [<f8879410>] add_conn+0x0/0x90 [bluetooth] Oct 26 16:57:00 darkstar kernel: [<f887941f>] add_conn+0xf/0x90 [bluetooth] Oct 26 16:57:00 darkstar kernel: [<c013baee>] run_workqueue+0x5e/0x110 Oct 26 16:57:00 darkstar kernel: [<c013bc4c>] worker_thread+0xac/0x100 Oct 26 16:57:00 darkstar kernel: [<c0140000>] autoremove_wake_function+0x0/0x50 Oct 26 16:57:00 darkstar kernel: [<c0140000>] autoremove_wake_function+0x0/0x50 Oct 26 16:57:00 darkstar kernel: [<c013bba0>] worker_thread+0x0/0x100 Oct 26 16:57:00 darkstar kernel: [<c013fa39>] kthread+0x59/0xa0 Oct 26 16:57:00 darkstar kernel: [<c013f9e0>] kthread+0x0/0xa0 Oct 26 16:57:00 darkstar kernel: [<c0104f83>] kernel_thread_helper+0x7/0x14 Oct 26 16:57:00 darkstar kernel: ======================= Oct 26 16:57:00 darkstar kernel: add_conn: Failed to register connection device Seems same problem as before. This time, I just used several rfcomm connections. I think if we can add an atomic variable 'going_away' like this: in hci_conn_del_sysfs: before INIT_WORK; atomic_set(&going_away, 1) in del_conn: after deleting completed atomic_set(&going_away, 0) in add_conn: busy waiting the going_away while (atomic_read(&going_away)) cpu_relax() Regards dave > Regards > > Marcel > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists