IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The netlink socket is now used by udev event processes. We should take
care not to pass it to the programs they execute. This is the same way
the inotify fd was handled.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Instead of of our own private monitor socket, we send the
processed event back to our netlink socket, to the multicast
group 2 -- so any number of users can listen to udev events,
just like they can listen to kernel emitted events on group 1.
On Wed, Mar 18, 2009 at 16:00, Matthias Schwarzott <zzam@gentoo.org> wrote:
found out how the error occurs:
It is a difference between
A. udevadm test /sys/class/mem/null/
and
B. udevadm test /sys/class/mem/null
Case A was the case that showed the error behaviour. It seems udevadm is
confused by the trailing slash. This behaviour seems to be there since ages.
There's still a slight race condition when using udevadm settle, if the
udev daemon has a pending inotify event but hasn't yet generated the
"change" uevent for it, the kernel and udev sequence numbers will match
and settle will exit.
Now udevadm settle will send a control message to udevd, which will
respond by sending SIGUSR1 back to the waiting udevadm settle once it
has completed the main loop iteration in which it received the control
message.
If there were no pending inotify events, this will simply wake up the
udev daemon and allow settle to continue. If there are pending inotify
events, they are handled first in the main loop so when settle is
continued they will have been turned into uevents and the kernel
sequence number will have been incremented.
Since the inotify event is pending for udevd when the close() system
call returns (it's queued as part of the kernel handling for that system
call), and since the kernel sequence number is incremented by writing to
the uevent file (as udevd does), this solves the race.
When the settle continues, if there were pending inotify events that
udevd had not read, they are now pending uevents which settle can wait
for.
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
It might be useful in some cases not to wait for "all" events.
$ read START < /sys/kernel/uevent_seqnum
$ (do something which may create uevents)
$ udevadm settle --seq-start=$START
When building with './configure --enable-debug && make' it fails with:
udev-rules.c: In function ‘dump_token’:
udev-rules.c:366: error: ‘struct <anonymous>’ has no member named ‘i’
Signed-off-by: Michael Prokop <mika@grml.org>
This allows you to re-process the rules if the content of the device
has been changed, most useful for block subsystem to cause vol_id to
be run again.
udevd's event_queue_manager loop is pretty sensitive to the
delays of exiting child processes. I found that it helps boot
times if we try to reap children as quickly as possible.
This patch changes event_queue_manager to call sigchilds_waiting
if it finds a signal has been received.
Signed-off-by: Olaf Kirch <okir@suse.de>
In certain cut-down situations such as an installer or inside the
initramfs, we simply don't have any kind of name service. While we
could use rules without OWNER or GROUP, it's better to have the same
rules as a full system and have udevd ignore those parts of the rules.
Adds a --resolve-names=never switch to udevd that has this effect.
udevd uses a rather old-fashioned way of handling signals
while waiting for input through select (ie by using an unnamed
pipe, to which the signal handler writes one byte for every signal
received). This is rather awkward and may potentially even block
if we receive more signals than the kernel's pipe buffer.
This patch replaces all of that with ppoll, which was designed
for this purpose.
It also removes the SA_RESTART flag from all installed signal
handlers, because otherwise the ppoll call would just be restarted
after handling eg a SIGCHLD.
Signed-off-by: Olaf Kirch <okir@suse.de>
Picked up by "gcc -Wextra".
udevadm.c:83: warning: initialized field overwritten
udevadm.c:83: warning: (near initialization for ‘cmds[2].help’)
This is just a cleanup. It doesn't change the code generated by gcc.
Scott found that the node /dev/pktcdvd can not be replaced by
/dev/pktcdvd/control by changing the rules, and re-trigger the
event. We used to create the new names before we cleaned up the
old ones, which can not work if we need to create subdir with
the same name.
Since a while we change the database with a "test" run, but do not update
the node and symlinks. We need to "force" all the time, to keep things
in sync.
[...] running the command
`make maintainer-clean' should not delete `configure' even if
`configure' can be remade using a rule in the Makefile. More
generally, `make maintainer-clean' should not delete anything that
needs to exist in order to run `configure' and then begin to build
the program. This is the only exception; `maintainer-clean' should
delete everything else that can be rebuilt.
The klibc implementation of getopt_long() behaves slightly different
from the glibc one - in particular, it treats the change of the option
string argument between invocations as start of parsing a different
command line, and resets its state. However, the udevadm code
expected getopt_long() invocations in subcommands to continue parsing
the rest of command line after initial options has been parsed at the
top level; with klibc this broke, causing all udevadm subcommands to
stop recognizing their options.
Instead of relying on the glibc behavior, reset the getopt_long()
state properly before invoking the subcommand handler: move argv to
point to the subcommand name, decrease argc appropriately, and set
optind = 0. This also fixes a minor bug visible with glibc - without
setting optind = 0 all getopt_long() calls in subcommand handlers were
behaving as if "+" was specified as the first character of the option
string (which disables option reordering), because that state was set
by the first getopt_long() call at the top level, and was not reset
when parsing subcommand options.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
On my Ubuntu installation this removes 15k of duplicate strings,
using a temporary index of about 25k.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
On Fri, Nov 7, 2008 at 13:07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> I managed to let udev-131 segfault at startup.
>
> I configured it like this:
> CFLAGS="-Wall -ggdb" ./configure --prefix=/usr --sysconfdir=/etc --exec-prefix=
>
> Running it in gdb shows it segfaults at udev-rules.c:831
>
> (gdb) run
> Starting program: /tmp/udev-131/udev/udevd
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804ea06 in get_key (udev=0x9175008, line=0xafcdc8f0, key=0xafcdc5d8,
> op=0xafcdc5d0, value=0xafcdc5d4)
> at udev-rules.c:831
> 831 dbg(udev, "%s '%s'-'%s'\n", operation_str[*op], *key, *value);
If compiled without optimization, the dbg() macro dereferences variables
which are not available. Convert the string array to a function, which just
returns NULL if compiled without DEBUG.
I'm worried about what will happen with things like
KERNELS=="*" # pointless rule
KERNELS=="doesnt-match" # another pointless rule
Since TK_RULE < TK_M_PARENTS_MAX, we will try to match all three tokens
against parents of the current device. I can't think of a bad case,
but it's not exactly good either.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
LAST_RULE was broken, and I broke TK_END by making it do the same.
It used a "break" which exited the switch statement, but not the loop!
==2953== Invalid read of size 4
==2953== at 0x4081EE: dump_token (udev-rules.c:859)
==2953== by 0x40BADB: udev_rules_apply_to_event (udev-rules.c:1849)
==2953== by 0x403F17: udev_event_execute_rules (udev-event.c:554)
==2953== by 0x418626: main (test-udev.c:100)
==2953== Address 0x55ab1f8 is 0 bytes after a block of size 80 alloc'd
==2953== at 0x4C23082: realloc (vg_replace_malloc.c:429)
==2953== by 0x40B13B: udev_rules_new (udev-rules.c:1670)
==2953== by 0x418536: main (test-udev.c:84)
...
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Initializing a char array to "" is equivalent to a memset()
call - which is exactly what it gets compiled to.
Fixing this one callsite reduced memset() _user_ cpu cycles
from 2-4% to 0.05% on the EeePC.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
This crops up in my threaded udevd profiles from time to time.
It's not consistent - probably due to variations in the number
of concurrent events - but it can hit 4% user time and higher.
The change halves the user time spent in compare_devpath().
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
The wait should be ordered after matching KERNEL, ENV, etc.
but before ATTR.
Without this, WAIT_FOR_SYSFS rules will be applied unconditionally
to all events.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Re: b99028c963 shrink struct udev_event
TEST 136: test multi matches 2
device '/devices/pci0000:00/0000:00:1d.7/usb5/5-2/5-2:1.0/tty/ttyACM0' expecting node 'right'
==15011==
==15011== 7 bytes in 1 blocks are definitely lost in loss record 1 of 1
==15011== at 0x47F9AB8: malloc (vg_replace_malloc.c:207)
==15011== by 0x489CB5F: strdup (in /lib32/libc-2.7.so)
==15011== by 0x8050F40: udev_rules_apply_to_event (udev-rules.c:1973)
==15011== by 0x804A658: udev_event_execute_rules (udev-event.c:549)
==15011== by 0x805A636: main (test-udev.c:100)
add: ok
==15012==
==15012== 7 bytes in 1 blocks are definitely lost in loss record 1 of 1
==15012== at 0x47F1AB8: malloc (vg_replace_malloc.c:207)
==15012== by 0x4898B5F: strdup (in /lib32/libc-2.7.so)
==15012== by 0x8050F40: udev_rules_apply_to_event (udev-rules.c:1973)
==15012== by 0x804A9DF: udev_event_execute_rules (udev-event.c:658)
==15012== by 0x805A636: main (test-udev.c:100)
remove: ok
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
The in-memory rule array of a common desktop distro install took:
1151088 bytes
with the token list:
109232 bytes tokens (6827 * 16 bytes), 71302 bytes buffer
The problem was strncpy() doesn't stop after writing the terminating
NUL; by definition it goes on to zero the entire buffer.
I spy another use of strncpy in udev_device_add_property_from_string(),
which is responsible for another ~1% user cpu time...
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Since we already know the length, use memcpy() instead.
Measured 2% _user_ cpu time reduction on EeePC coldplug.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Use calloc to request cleared memory instead.
Kernel and libc conspire to make this more efficient.
Also, replace one malloc() + strcpy() with strdup().
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Unfortunately the linux rmdir implementation unhashes the dentry
even when the directory is not removed. This is apparently by
design (for filesystems that don't allow deleting open files).
Results from time(1) and oprofile follow.
Before:
0.35user 0.90system
samples % image name symbol name
608 9.6738 vmlinux shrink_dcache_parent
293 4.6619 vmlinux copy_page_c
271 4.3119 vmlinux copy_page_range
257 4.0891 udevd udev_rules_iter_next
After:
0.31user 0.67system
samples % image name symbol name
361 5.0419 vmlinux copy_page_range
322 4.4972 udevd udev_rules_iter_next
300 4.1899 vmlinux copy_page_c
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
