thread-pool: Allow at least 1 thread in thread_pool_adjust_max_threads_to_work()

thread_pool_adjust_max_threads_to_work() is supposed to give each task its own thread by setting the pool max thread count limit accordingly. However, if there aren't any tasks currently in the pool the pool max thread count will be set to 0, which will trigger an assertion failure in thread_pool_set_max_threads() - because setting this value would completely block the pool by not allowing it to process any submitted tasks. This also can happen if a task is submitted via thread_pool_submit_immediate() to an empty pool but the task completes so quickly that by the time this function calls thread_pool_adjust_max_threads_to_work() the pool again has no unfinished tasks in it. Quoting from Maciej on reproducing this issue: It's difficult to reproduce in most setups. My main VFIO live migration setup never hit it for more than a year, other similar setup hit it recently 3 times. On the other hand, putting sleep(5) in the middle of thread_pool_submit_immediate() makes it reproduce nearly always for me. Fix this by making sure that the pool is allowed to create at least 1 thread. Fixes: b5aa74968b27 ("thread-pool: Implement generic (non-AIO) pool support") Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/b76c763f576b0fb8a35960a8e3c3da59701d2a74.1779390317.git.maciej.szmigiero@oracle.com [peterx: added quote into commit message on reproduce details of the issue] Signed-off-by: Peter Xu <peterx@redhat.com>