[Unbound-users] Thread safety and atomicity assumptions for unbound-control set_option

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jake,

On 08/12/2011 11:01 PM, Jake Montgomery wrote:
> I'm a developer, and I sometimes make custom modifications to the the
> unbound code. I am a bit confused about the assumptions being made in
> the unbound code with regard to what is safe on multiprocessor systems.

It is multiprocessor safe.

> The 'new' "unbound-control set_option" command seems to allow the
> modification of many configuration variables by directly writing to the

Yes, it comes from the set_option() call to libunbound which accepts the
same parameters (and because it executes before libunbound starts it
support almost all options very well).  And it was very few lines of
code to provide the function in the live server - proviso that it does
not support all of the options.

What would work is in a threaded unbound compile you change 'boolean'
style options.  Changing a single integer is fairly safe on
multiprocessor machines, and using that as a boolean - remember that the
other threads only read, so the worst that could happen is that they get
a garbled value read back.  For a boolean, 0 or not zero, this is very
harmless.  For other variables, yes indeed, but you are saved by modern
cpus where the 'sig_atomic_t' is equal to 'int', therefore, you do not
see 'garbled' versions of the integers.

If something needs stronger support, this can be provided but would need
special code.  set_option is a power-user interface.

get_option is much more useful and highly appreciated, I hear, in some
environments (for accountability).

> globally shared config_file structure. Most of these variables are never
> used after initialization (which begs the question - why make them
> settable?) However, some of them are accessed directly during normal

Well they are settable because in libunbound, it works, and is a user
interface to set the options you want the validator to use.

> operation. AFAICT, it is possible for these variables to be written and
> read simultaneously on multiprocessor systems. The variable

Yes but only one thread can write, and the others read.  And this is
'int', often similar to 'sig_atomic_t', and very often interpreted as
booleans.  Hence I am not worried about it.

> config_file->log_queries is one of many examples. I have not done an
> exhaustive search, but the examples I have found are all single integer
> values. Nonetheless, concurrent writing and reading goes against what I

Pfew :-)

> understand to be _conservative_ best practices for cross platform code. 

Yes.  Set_option for some options may need special support.  Also, if
you are not running threaded but forked, I believe the set_option
command it sent and also processed by the other processes, and it would
work fine there.

> In addition, the variables are not marked as volatile, so it would be
> theoretically possible for subsequent reads to be optimized out by the c
> compiler, resulting in the settings changes not being reflected in
> behavioral changes on worker threads, other than the one which processed
> the command. (Admittedly, this is possible in theory, but unlikely in
> the extreme in practice, given current compilers and the scope of the
> variables.)

Yes.

> 
> * This is not intended as a troll or criticism, and I have the utmost
> respect for the creators and maintainers of the unbound code base. *

thanks, blush :-)

> It would be helpful for me to understand what assumptions and guidelines
> the unbound code uses for unprotected concurrent memory access. Armed
> with this information, I could make my modifications in a manner
> consistent with the current code.

The set_option is indeed as we spoke about.

In other code (the cache), there are proper mutexes.

For handling control commands (i.e. not set_option) it uses pipes to
signal and do IPC.

Also there is signal handling with proper volatile sig_atomic_t
declarations.

The set_option command certainly seems to be too powerful, and not easy
to understand, and with the concerns you rais, I wonder if it may be
better to remove the command from unbound-control (it would stay in
libunbound because that works).

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOSNj/AAoJEJ9vHC1+BF+N60QP/jJuR9qau2ENppHcnKFUHgRy
zXveUpUoC0o2tSbI8Fc0YVGIimgHue4zqDbcvk/kFHoV+f23kxHsFyWfZi1E1ckX
mUHHmH8Mx+gKH6s5sqpNiDjifRKbs7jG2lM6oXYZ+wfhiarNabt8OAXLHmwkT37i
cSmlIRpKjCQfpVKJpByqJ6sx4V1KOUaoTW8K+v3ANLEctR+N6I5xyAoJI4tnsc9g
Ra/We/EauMhvxpemnlk17lqhVF+DmarigDfIxwdtVbzLQq87SSV448hpRIW4q0CU
iFtwfS2Qo29z6frOAYw6n4Bx7R/jKHjo05aBPJFeL9d8zjWaUi9zMGLElBBSIhUo
1sTtUuwDEsIL+kGc/QPkrSnzE4t5gW0DnuoidLFQLbDcKOvX6GTM/qfQuTm3ldeI
dqLnYNu6KwNVvW0Gz2cF4Zm9iD7WBQqfs9kv6v1ClDWT1CYWzKjB1qlYLFGq6qOE
OkKLQRKupt+OnHnqA7AKESQKjlm3QuAK0mdH3CRF6N1lIOOrvFUv1OxYiRVgNGgc
EbhAzztTDU6gWBK3Rxq6YGecZUgpKLscePR+RmLXHFbIU8ajMYJ6cvcrOsA6K0TZ
PuG2ReWLYAaEeXfxdSFZmtnGSY6MIB5DtZYoVeOmMufNrrDEmwTh746iqzdBnVIf
5Y9VT9vB2n9Pp+RZ81Is
=n99e
-----END PGP SIGNATURE-----