[PATCH nbdkit] build: Use dlsym as sentinel function for -ldl.
by Richard W.M. Jones
When testing which “dl library” we must use for dl* symbols, autoconf
runs a test similar to:
$ cat conftest.c
char dlopen ();
int main () { return dlopen (); }
$ gcc -o conftest $CFLAGS conftest.c [try various -ldl options here]
When using ‘CFLAGS="-fsanitize=address"’ this succeeds even if no dl
libraries are used at all, since it appears that using this option
causes dlopen to be included in the final binary implicitly. This
causes configure to set DL_LIBS='', but unfortunately dlsym is not
included implicitly and so linking fails.
Although I believe this is a bug in GCC 9, as a workaround use dlsym
as the sentinel function instead.
The new output from ‘./configure CFLAGS="-fsanitize=address"’ is:
checking for library containing dlsym... -ldl
[...]
checking for dladdr... yes
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1702761
---
configure.ac | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4624bf8..1d3aa7b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -224,11 +224,11 @@ AS_IF([test "x$nbdkit_cv_func_printf_percent_m" = xyes],
[Define to 1 if vfprintf supports %m.])])
old_LIBS="$LIBS"
-AC_SEARCH_LIBS([dlopen], [dl dld], [
- AS_IF([test "x$ac_cv_search_dlopen" != "xnone required"],
- [DL_LIBS="$ac_cv_search_dlopen"], [DL_LIBS=])
+AC_SEARCH_LIBS([dlsym], [dl dld], [
+ AS_IF([test "x$ac_cv_search_dlsym" != "xnone required"],
+ [DL_LIBS="$ac_cv_search_dlsym"], [DL_LIBS=])
AC_SUBST([DL_LIBS])
- ], [AC_MSG_ERROR([unable to find the dlopen() function])
+ ], [AC_MSG_ERROR([unable to find the dlsym() function])
])
LIBS="$old_LIBS"
--
2.20.1
5 years, 7 months
[PATCH nbdkit] server: Initialize ‘buf’ to avoid GCC 9.0.1 warning.
by Richard W.M. Jones
GCC 9.0.1 isn't smart enough to work out that buf is initialized on
all the relevant paths that lead to backend->pwrite being called. By
initializing it we can avoid the warning.
protocol.c: In function ‘protocol_recv_request_send_reply’:
protocol.c:241:9: error: ‘buf’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
241 | if (backend->pwrite (backend, conn, buf, count, offset, f, &err) == -1)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
protocol.c:614:9: note: ‘buf’ was declared here
614 | char *buf;
| ^~~
---
server/protocol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server/protocol.c b/server/protocol.c
index 6fd3b62..5033fd7 100644
--- a/server/protocol.c
+++ b/server/protocol.c
@@ -611,7 +611,7 @@ protocol_recv_request_send_reply (struct connection *conn)
uint16_t cmd, flags;
uint32_t magic, count, error = 0;
uint64_t offset;
- char *buf;
+ char *buf = NULL;
CLEANUP_EXTENTS_FREE struct nbdkit_extents *extents = NULL;
/* Read the request packet. */
--
2.20.1
5 years, 7 months
[PATCH nbdkit] Add support for writing plugins in Rust.
by Richard W.M. Jones
This adds very rough support for writing nbdkit plugins in Rust. This
is not very idiomatic -- essentially we're handling the direct C calls
from nbdkit in Rust. We have to use ‘unsafe’ in a few places because
there's no way to tell the Rust code that nbdkit satisfies guarantees
(eg. around thread safety, always returning leaked pointers back to
the close function, always doing bounds checking).
See the TODO file changes for the mising bits.
TBH there's not much to review here.
Rich.
5 years, 7 months
[RFC: nbdkit PATCH] cleanup: Assert mutex sanity
by Eric Blake
Although we haven't always checked that pthread_mutex_[un]lock
succeeded, it never hurts to avoid blatant programming bugs such as
when EINVAL can detect use of an uninitialized mutex.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
Applies on top of my series to move cleanup.c to common/
Should I also go through and add checking to other bare
pthread_mutex_[un]lock() calls?
common/utils/cleanup.h | 5 ++++-
common/utils/cleanup.c | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/common/utils/cleanup.h b/common/utils/cleanup.h
index e6e6140..0ab9e65 100644
--- a/common/utils/cleanup.h
+++ b/common/utils/cleanup.h
@@ -43,6 +43,9 @@ extern void cleanup_unlock (pthread_mutex_t **ptr);
#define CLEANUP_UNLOCK __attribute__((cleanup (cleanup_unlock)))
#define ACQUIRE_LOCK_FOR_CURRENT_SCOPE(mutex) \
CLEANUP_UNLOCK pthread_mutex_t *_lock = mutex; \
- pthread_mutex_lock (_lock)
+ do { \
+ int _r = pthread_mutex_lock (_lock); \
+ assert (!_r); \
+ } while (0)
#endif /* NBDKIT_CLEANUP_H */
diff --git a/common/utils/cleanup.c b/common/utils/cleanup.c
index 196d910..995f46c 100644
--- a/common/utils/cleanup.c
+++ b/common/utils/cleanup.c
@@ -53,5 +53,6 @@ cleanup_extents_free (void *ptr)
void
cleanup_unlock (pthread_mutex_t **ptr)
{
- pthread_mutex_unlock (*ptr);
+ int r = pthread_mutex_unlock (*ptr);
+ assert (!r);
}
--
2.20.1
5 years, 7 months
[nbdkit PATCH 0/4] Start using cleanup macros in filters/plugins
by Eric Blake
There's more that can be done (in particular, use of CLEANUP_FREE),
but this is enough to at least see if I'm on the right track.
I couldn't figure out an obvious difference between common/include and
common/utils, but it looks like the former is for things that are
inlineable via .h only, while the latter is when you need to link in
a convenience library, so this landed in the latter.
Eric Blake (4):
cleanup: Move cleanup.c to common
filters: Utilize CLEANUP_EXTENTS_FREE
filters: Utilize ACQUIRE_LOCK_FOR_CURRENT_SCOPE
plugins: Utilize ACQUIRE_LOCK_FOR_CURRENT_SCOPE
common/utils/cleanup.h | 48 ++++++++++++++++++++++++++++++
server/internal.h | 12 +-------
{server => common/utils}/cleanup.c | 5 ++--
filters/log/log.c | 10 +++----
filters/offset/offset.c | 13 ++++----
filters/partition/partition.c | 12 +++-----
filters/readahead/readahead.c | 15 ++++------
filters/truncate/truncate.c | 12 +++-----
plugins/data/data.c | 26 +++++-----------
plugins/file/file.c | 18 ++++-------
plugins/memory/memory.c | 26 +++++-----------
plugins/nbd/nbd.c | 4 +--
common/utils/Makefile.am | 4 ++-
filters/log/Makefile.am | 5 +++-
filters/offset/Makefile.am | 5 +++-
filters/partition/Makefile.am | 5 +++-
filters/readahead/Makefile.am | 5 +++-
filters/truncate/Makefile.am | 5 +++-
plugins/data/Makefile.am | 4 ++-
plugins/file/Makefile.am | 5 +++-
plugins/memory/Makefile.am | 6 ++--
plugins/nbd/Makefile.am | 4 ++-
server/Makefile.am | 7 +++--
23 files changed, 137 insertions(+), 119 deletions(-)
create mode 100644 common/utils/cleanup.h
rename {server => common/utils}/cleanup.c (96%)
--
2.20.1
5 years, 7 months
[PATCH 0/7] Make deprecation warnings more prominent
by Pino Toscano
Since there are deprecated APIs, make sure that users notice they are
deprecated in more prominent ways than done so far:
- using deprecated C functions now warns by default
- it is possible to use the C library making sure no deprecated function
is ever used
- Python/Ruby/Perl scripts now get warning messages (configured
according to their own systems) when deprecated functions are used
The Java binding already emits warnings since libguestfs 1.29.25
(85b6b5e589bea56046b85a5b0143a364e20dacd1).
Pino Toscano (7):
tests: switch last-errno away from deprecated APIs
lib: enable deprecation warnings by default
build: stop using GUESTFS_WARN_DEPRECATED
lib: introduce GUESTFS_NO_DEPRECATED
python: show warnings for deprecated functions
ruby: show warnings for deprecated functions
perl: show warnings for deprecated functions
align/Makefile.am | 2 +-
cat/Makefile.am | 10 +++++-----
common/edit/Makefile.am | 2 +-
common/options/Makefile.am | 2 +-
common/parallel/Makefile.am | 2 +-
common/progress/Makefile.am | 2 +-
common/structs/Makefile.am | 2 +-
common/utils/Makefile.am | 2 +-
common/visit/Makefile.am | 2 +-
common/windows/Makefile.am | 2 +-
df/Makefile.am | 2 +-
diff/Makefile.am | 2 +-
edit/Makefile.am | 2 +-
examples/Makefile.am | 17 ++++++++---------
fish/Makefile.am | 2 +-
format/Makefile.am | 2 +-
fuse/Makefile.am | 3 ++-
generator/GObject.ml | 4 ++++
generator/OCaml.ml | 4 ++++
generator/c.ml | 20 +++++++++++++++++---
generator/erlang.ml | 4 ++++
generator/fish.ml | 3 ++-
generator/golang.ml | 2 +-
generator/java.ml | 4 ++++
generator/lua.ml | 4 ++++
generator/perl.ml | 16 +++++++++++++++-
generator/php.ml | 4 ++++
generator/python.ml | 16 ++++++++++++++++
generator/ruby.ml | 14 ++++++++++++++
generator/tests_c_api.ml | 4 ++++
inspector/Makefile.am | 2 +-
lib/Makefile.am | 1 -
make-fs/Makefile.am | 2 +-
rescue/Makefile.am | 2 +-
test-tool/Makefile.am | 2 +-
tests/c-api/test-last-errno.c | 4 ++--
tests/c-api/tests-main.c | 5 -----
tests/mount-local/Makefile.am | 2 +-
tests/mountable/Makefile.am | 2 +-
tests/parallel/Makefile.am | 2 +-
tests/regressions/Makefile.am | 2 ++
41 files changed, 133 insertions(+), 50 deletions(-)
--
2.20.1
5 years, 7 months
[PATCH nbdkit 0/2] Be careful not to leak heap memory to the client.
by Richard W.M. Jones
This bug was found by Eric Blake.
In the .pread method we allocate a buffer in the server and pass it to
the plugin. The plugin is supposed to fill it with data. The buffer
was uninitialized so initially contained random heap data, but that's
OK provided the plugin fully overwrote it with data. All correctly
written plugins ought to do this, however there is the possibility of
an incorrectly written plugin not doing so. In that case heap memory
would be leaked to the client.
The fix for this is to zero the buffer before passing it to the
plugin, so even if the plugin doesn't fill it properly no heap memory
is leaked.
I checked our existing plugins and they are all safe, except for the
OCaml plugin. The OCaml plugin had the same kind of mistake and
needed a separate fix. Again, correctly written OCaml plugins should
be fine, but incorrect ones could leak heap memory.
Since nbdkit supports a stable API and ABI, plugins can be distributed
outside nbdkit and we have no control over whether those plugins are
doing the right thing.
Rich.
5 years, 7 months
supermin (chroot+systemd.resolved) - network cannot be configured on Ubuntu
by Ioanna Alifieraki
Hi,
I am facing the following bug while runnign guestfish on Ubuntu Bionic
onward,
where the network cannot be configured :
https://bugs.launchpad.net/ubuntu/+source/supermin/+bug/1824236
The actual problem is the combination of (a) supermin and the fact that it
does chroot
and (b) a dhclient hook present in Bionic
(/etc/dhcp/dhclient-eneter-hooks.d/resolved)
that overwrites the make_resolv_conf function of dhclient_script with one
that
in the end restarts the systemd.resolved service.
Being, however in chroot, the new make_resolv_conf function fails with
"System has not been booted with systemd as init system (PID 1). Can't
operate."
and the network is left unconfigured.
Although there is a workaround for this, I am seeking for a better solution.
I would like to ask you if this is the expected behaviour of supermin or
something
that needs fixing.
Thank you in advance.
Best,
Jo
5 years, 7 months
