[Libguestfs] [nbdkit PATCH 2/3] server: Expose final thread_model to filter's .get_ready

[Eric Blake]

On 8/10/20 8:01 AM, Richard W.M. Jones wrote:
> On Fri, Aug 07, 2020 at 05:00:52PM -0500, Eric Blake wrote:
>> The next patch wants to add a filter that will prevent DoS attacks
>> from a plaintext client; to be successful, the filter must guarantee
>> that nbdkit did not settle on SERIALIZE_CONNECTIONS.  The easiest way
>> to solve this is to expose the final thread model to .get_ready, which
>> is after the point where .config_complete may have altered it, and
>> before any connections are permitted.
>>
>> Signed-off-by: Eric Blake <eblake at redhat.com>
>> ---
>>   docs/nbdkit-filter.pod          | 9 ++++++++-
>>   include/nbdkit-filter.h         | 3 ++-
>>   server/filters.c                | 4 ++--
>>   filters/extentlist/extentlist.c | 3 ++-
>>   filters/log/log.c               | 2 +-
>>   filters/rate/rate.c             | 2 +-
>>   filters/stats/stats.c           | 2 +-
>>   tests/test-layers-filter.c      | 2 +-
>>   8 files changed, 18 insertions(+), 9 deletions(-)
> 
> This is fine.  Is this something that we would also with to add to
> plugin->get_ready in V3 API?  If so it would be a good idea to add
> this to TODO.

We might as well, so I'll tweak TODO.  But at the moment, I'm having a 
hard time coming up with a justification for why any existing v2 plugin 
would need to know this information, so without a client, I'm reluctant 
to introduce a plugin-only nbdkit_final_thread_model() just to be 
deprecated when v3 comes out.

Oh, one other oddity: I've been thinking about adding a fifth threading 
model (SERIALIZE_RETIREMENT), where commands can be serviced in parallel 
on a single connection, but replies to the client are reordered to match 
the client's submission order; for filters, exposing a new threading 
model through .get_ready is not a problem (all filters are in tree), but 
for plugins, such an action would mean that the plugin may get a thread 
model selected at runtime that was unknown to the plugin at compile 
time.  If the plugin is trying to make decisions on how much internal 
locking it needs to create, those decisions become more awkward when 
having to deal with an unknown thread model (then again, robust code 
should always be written to assume as much parallelism as possible, and 
only optimize for less locking on known models that are more serialized).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org