They do the same thing as their synchronous counterparts, but only
enqueue the operation, thus removing synchronization points during
service initialization.
If the callback function is passed as NULL we'll fallback to generic
implementations of the reply handlers, that terminate the connection if
the requested name cannot be acquired, under the assumption that not
being able to acquire the name is a technical problem.
When kdbus was still around we always had two implementations of the
various control calls: one for dbus1 and one for kdbus. Let'sget rid of
this, simplify things, and just merge the wrappers that used to
multiplex this with the implementations.
No change in behaviour, just some merging of functions
Currently, reply callback timeouts are started the instant the method
calls are enqueued, which can be very early on. For example, the Hello()
method call is enqueued right when sd_bus_start() is called, i.e. before
the socket connection and everything is established.
With this change we instead start the method timeout the moment we
actually leave the authentication phase of the connection. This way, the
timeout the kernel applies on socket connecting, and we apply on the
authentication phase no longer runs in parallel to the Hello() method
call, but all three run serially one after the other, which is
definitely a cleaner approach.
Moreover, this makes the "watch bind" feature a lot more useful, as it
allows enqueuing method calls while we are still waiting for inotify
events, without them timeouting until the connection is actually
established, i.e. when the method call actually has a chance of being
actually run.
This is a change of behaviour of course, but I think the new behaviour
is much better than the old one, since we don't race timeouts against
each other anymore...
This adds a "watch-bind" feature to sd-bus connections. If set and the
AF_UNIX socket we are connecting to doesn't exist yet, we'll establish
an inotify watch instead, and wait for the socket to appear. In other
words, a missing AF_UNIX just makes connecting slower.
This is useful for daemons such as networkd or resolved that shall be
able to run during early-boot, before dbus-daemon is up, and want to
connect to dbus-daemon as soon as it becomes ready.
We'd like to use inotify to get notified when AF_UNIX sockets become
connectable. That happens at the moment of listen(), but this is doesn't
necessarily create in a watchable inotify event. Hence, let's synthesize
one whenever we generically create a socket, or when we know we created
it for a D-Bus server.
Ideally we wouldn't have to do this, and the kernel would generate an
event anyway for this. Doing this explicitly isn't too bad however, as
the event is still nicely associated with the AF_UNIX socket node, and
we generate all D-Bus sockets in our code hence it's safe.
AF_UNIX socket addresses aren't necessarily NUL terminated, however
they are usually used as strings which are assumed to be NUL terminated.
Let's hence add an extra byte to the end of the sockaddr_un structure,
that contains this NUL byte, simply for safety reasons.
Note that actually this patch changes exactly nothing IRL, as the other
sockaddr structures already are large enough to accomodate for an extra
NUL byte. The size of the union hence doesn't change at all by doing
this. The entire value of this patch is hence in the philosophical
feeling of safety, and by making something explicit that before was
implicit.
This changes two things when binding to AF_UNIX file system sockets:
1. When wethe socket already exists in the fs, and unlink() on it fails,
don't bother to bind() a second time: since nothing changed it won't
work either.
2. Also use SELinux-aware bind() for the second attempt.
Let's rework touch_file() so that it works correctly on sockets, fifos,
and device nodes: let's open an O_PATH file descriptor first and operate
based on that, if we can. This is usually the better option as it this
means we can open AF_UNIX nodes in the file system, and update their
timestamps and ownership correctly. It also means we can correctly touch
symlinks and block/character devices without triggering their drivers.
Moreover, by operating on an O_PATH fd we can make sure that we
operate on the same inode the whole time, and it can't be swapped out in
the middle.
While we are at it, rework the call so that we try to adjust as much as
we can before returning on error. This is a good idea as we call the
function quite often without checking its result, and hence it's best to
leave the files around in the most "correct" fashion possible.
If we can't process the bus for some reason we shouldn't just disable
the event source, but log something and give up on the connection. Hence
do that, and disconnect.
Currently, when sd-bus is used to issue a method call, and we get a
reply and the specified reply handler fails, we log this locally at
debug priority and proceed. The idea is that a bad server-side reply
should not be fatal for the program, except when the developer
explicitly terminates the event loop.
The reply to the initial Hello() method call we issue when joining a bus
should not be handled like that however. Instead, propagate the error
immediately, as anything that is wrong with the Hello() reply should be
considered a fatal connection problem.
This is useful so that callers know whether anything at all and how much
was flushed.
This patches through users of this functions to ensure that the return
values > 0 which may be returned now are not propagated in public APIs.
Also, users that ignore the return value are changed to do so explicitly
now.
Including BitsPerSecond or Duplex values in .link files did not work when
set_slinksettings was called because the routine was not copying the base
parameters to the structure given to ioctl. As a result, EINVAL was always
reported, and no change occurred on the Ethernet device.
#Add "Early 2008 Core 2 Duo/Penryn" Macbook4,1 match string to the existing touchpad range definition
##Symptoms
* Jerky/Jumpy cursor motion using touchpad
* "Axis value outside expected range" message in Xorg.0.log
##Fix
I followed the instructions described here :https://wayland.freedesktop.org/libinput/doc/latest/absolute_coordinate_ranges.html and came up with the following :
evdev:input:b0003v05ACp022A*
EVDEV_ABS_00=256:1469:12
EVDEV_ABS_01=256:829:12
The ranges and resolutions are the same as stated in the existing definition (+/- 2) so only add the match string.
When receiving one or more prefixes with variable length, assign a
64 bit long prefix for each link that has been configured for DHCPv6
prefix delegation and is not using DHCPv6 to fetch IPv6 adresses.
Keep assigning prefixes with length 64 from each prefix received via
DHCPv6 as long as there are prefixes left. If the number of prefixes
available from a prefix received via DHCPv6 is smaller than the
number of links, continue with the next delegated prefix, if any.
Remember the prefixes used for each link by storing them in a hash
and checking the hash each time a prefix is to be delegated. If an
error occurs when assigning a prefix to a link, try assigning the
prefix to another link. If the error occurs while updating the
prefix, log the situation and continue delegating the rest of the
prefixes.
Add a hashmap to the Manager struct that stores the association
between an IPv6 prefix and the network Link it is assigned to.
This is added in order to keep assigning the same prefixes with
the same links even though they are delegated at different times
or by different DHCPv6 clients.
As DHCPv6 leases may expire at some point, the delegated prefixes
have to be removed. Add a prefix removal function to the Router
Advertisement handling code.
Add a boolean that indicates whether the prefixes will always exist
or if they will time out after the assigned valid lifetime. In the
latter case calculate the expiry times for both preferred and valid
lifetimes for the prefixes, and decrease the remaining lifetimes
each time when a Router Advertisement is sent.
Should the prefix be updated, re-calculate the prefix lifetime. When
updating, update the existing entry, if any, with the lifetimes of
the added entry as the existing entry has its lifetimes set
according to its previously calculated expiry times.
Compute one set of minimum lifetimes for T1 and T2, i.e. the smaller
ones assigned to IA NA and IA PD. The lifetimes should be the same,
see RFC 7550 for details.
Request prefixes via DHCPv6 if there are networks that are
configured to distribute them. As specified in RFC 3633, a DHCPv6
client cannot redistribute the prefixes via Router Advertisements
on the same link. Ignore such networks, and print out a warning if
the link where DHCPv6 is enabled tries to do so.
Parse IA PD options and the prefixes in one or more PD Prefix
options. As the PD option contains identical data as the IA NA
option, re-use the same general data structures and sub-option
parsing logic. Similar to IA NA addresses, PD and associated
prefixes are stored in the address list of the IA PD lease.
An IA sub-option Status code will affect the IA NA and IA PD
option in question and cause those options to be ignored. A
Status code option in an IA Address or IA PD Prefix option
affects only that IA Address or Prefix.
Factor out IA Address option parsing and fix it so that all conditions
are checked before a new address is allocated and added to the address
list. Note also that the IA Address option can contain a nested Status
option. If the status in anything else than zero, the DHCPv6 server is
communicating an error condition and the address cannot be used.
Status option nesting is clarified in RFC 7550, Section 4.1.
The IA Address option is included as a typedef so that the lifetimes
can be inspected before allocating a new address and the option length
needed is easily available.
Sanitize code for parsing DHCPv6 IA NA and TA options and their
nested Status options so that the options can be fully and
properly ignored should they not be conformant to the specification.
Do this by defining a proper DHCP6Option structure and sending that
structure to the parsing function. The parsing function will then
not manipulate either any option data pointers or their lengths in
order to iterate over the current option. Needless to say, this
affects a few files including the test program.
Lennart Poettering
John Lin
Zbigniew Jędrzejewski-Szmek
Bruce A. Johnson
Alexis Deruelle
Hans de Goede
Patrik Flykt