This was a regression from hrev39870 where a private Referenceable class
was replaced with BReferenceable. Referenceable::RemoveReference()
returned a boolean to indicate whether the last reference was released
while BReferenceable::ReleaseReference() returns the previous reference
count.
A file system would therefore be deleted when any but the last reference
to it would be released (when multiple volumes of that file system were
mounted and one of them was unmounted) and leaked otherwise (when only
one volume of that file system was mounted and then unmounted).
Fixes#11718.
* based on current glibc sysdeps/nptl/bits/libc-lock.h file.
* include missing headers which were previously included by libc-lock.h.
* This fixes#11182.
* drop my fdt tests
* we have to call fdt parsing code *after* cpu_init (why?)
* pass fdt pointer to all FDT support calls to avoid confusion
once we get into the kernel land
* look for PL011 compatible uart and use it
* Add some saftey checks to serial putc code to avoid null*
* fdt_node_check_compatible returns 0 on success not 1
* fdt_get_device_reg needs to add the SOC base to the result
* fdt_get_device_reg might need to add the second range cell
instead of reg?
The comparison to decide whether or not to reuse the name buffer when
renaming a rootfs entry was reversed. For renames where the new name
was longer than the old one this resulted in writing beyond the name
buffer and corrupting random kernel memory.
A likely candidate for this to be triggered was when a audio cd was
renamed due to a CDDB lookup, as the placeholder "Audio CD" is quite
short and the actual CD name is usually longer.
Fixes: #10259. Possibly fixes the related #9528 and #9858.
* BNetworkSettings now set unspecified addresses to their empty family
specific addresses, instead of using AF_UNSPEC.
* This allows the net_server to set those addresses on the address
specific stack interface.
* Until now, only AF_UNSPEC addresses could be empty.
* Now, the unspecified IPV4/IPv6 address is considered empty, too.
* This corresponds to how the kernel modules handles this.
* _AddParameter() would ignore all BMessage::Add*() errors.
* _ConvertFromDriverParameter() would ignore most intermediate error,
but would fail badly over some incorrect settings file.
* Also, it checked for the parent value for each parameter, which
doesn't make any sense, but would add as often as there are
parameters -- which also may be none, in which case the value
got ignored.
* DNS add-on does not yet support it, the rest does.
* However, there seems to be some problems with the net_server when
changing interfaces -- not just with revert.
* And call it from the DNS client -- this is the only add-on that does
not trigger a configuration or settings update, so we have to notify
the changes manually.
* Otherwise there is nothing to it.
* Removed comment and commented out invalidation. Seems to work
just fine without it, and I cannot think of a reason why it should
be there.
Humdinger