Not in the drivers/pci/pci-driver.c case because the setting of
cpus_allowed to nodecpumask is only temporary (as is the disabling of the
mempolicy). It's just done for the probe callback and then reset to the
old cpumask. So any migration here would be lost.
I can't speculate about the net/sunrpc/svc.c case because I don't know if
user migration is harmful or discouraged. The behavior with my patch is
the same for any calls to set_cpus_allowed_ptr() for tasks that haven't
called kthread_bind(), so I'll leave that decision up to those who know
best for this networking code.
This particular case is simply moving the thread to any online cpu so that
it survives long enough for the subsequent kthread_stop() in
destroy_comp_task(). So I don't see a problem with this instance.
A caller to kthread_bind() can always remove PF_THREAD_BOUND itself upon
return, but I haven't found any cases in the tree where that is currently
necessary. And doing that would defeat the semantics of kthread_bind()
where these threads are supposed to be bound to a specific cpu and not
allowed to run on others.