From: Thomas de Grenier de Latour <tom.gl@free.fr>
To: linux-hotplug@vger.kernel.org
Subject: [PATCH] fix for move_later in udev_enumerate_get_list_entry
Date: Mon, 28 Dec 2009 21:12:19 +0000 [thread overview]
Message-ID: <20091228221219.709efbe0@gromit.localdomain> (raw)
[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]
Hi,
The attached patch fixes a bug in the udev_enumerate_get_list_entry()
function of "libudev-enumerate.c". The move_later_prefix variable was
reset to zero on each loop iteration, and thus the move_later entry (if
any) was not added right after changing to another syspath prefix, but
rather after exiting the enumeration loop.
So this patch makes the sound card control node be added asap (after
other nodes from the same sound card) rather than last (after all other
nodes), which is probably a good thing, and obviously seems to be the
original intent of this code.
On my system, under some circumstances, it has the additional benefice
to avoid an "udevadm trigger" segfault. What was happening was that, at
some point in the loop iteration (a few tens of iterations after it was
set), the move_later->syspath was becoming NULL, and thus the final
udev_list_entry_add() was failing. I absolutly don't know why it was
becoming NULL though, I've just seen it happening each time I have both
my mouse and keyboard plugged on the monitor USB hub (go figure...).
If this phenomena is of any interest, I can provide some printf-powered
traces showing it.
I'm not subscribed to the list, so please keep my address in replies.
Thanks,
Thomas de Grenier de Latour.
[-- Attachment #2: fix-enumerate-move-later.patch --]
[-- Type: text/x-patch, Size: 898 bytes --]
diff --git a/libudev/libudev-enumerate.c b/libudev/libudev-enumerate.c
index 53cd53b..605c246 100644
--- a/libudev/libudev-enumerate.c
+++ b/libudev/libudev-enumerate.c
@@ -251,6 +251,7 @@ struct udev_list_entry *udev_enumerate_get_list_entry(struct udev_enumerate *ude
unsigned int i;
unsigned int max;
struct syspath *prev = NULL, *move_later = NULL;
+ size_t move_later_prefix;
udev_list_cleanup_entries(udev_enumerate->udev, &udev_enumerate->devices_list);
qsort(udev_enumerate->devices, udev_enumerate->devices_cur, sizeof(struct syspath), syspath_cmp);
@@ -258,7 +259,6 @@ struct udev_list_entry *udev_enumerate_get_list_entry(struct udev_enumerate *ude
max = udev_enumerate->devices_cur;
for (i = 0; i < max; i++) {
struct syspath *entry = &udev_enumerate->devices[i];
- size_t move_later_prefix = 0;
/* skip duplicated entries */
if (prev != NULL &&
next reply other threads:[~2009-12-28 21:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-28 21:12 Thomas de Grenier de Latour [this message]
2009-12-30 15:24 ` [PATCH] fix for move_later in udev_enumerate_get_list_entry Kay Sievers
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=20091228221219.709efbe0@gromit.localdomain \
--to=tom.gl@free.fr \
--cc=linux-hotplug@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox