Re: Re: [RFC v3 01/11] eventfd: track eventfd_signal() recursion depth separately in different cases

On Thu, Jan 28, 2021 at 11:05 AM Jason Wang [off-list ref] wrote:

On 2021/1/27 下午5:11, Yongji Xie wrote:

quoted

On Wed, Jan 27, 2021 at 11:38 AM Jason Wang [off-list ref] wrote:

quoted

On 2021/1/20 下午2:52, Yongji Xie wrote:

quoted

On Wed, Jan 20, 2021 at 12:24 PM Jason Wang [off-list ref] wrote:

quoted

On 2021/1/19 下午12:59, Xie Yongji wrote:

quoted

Now we have a global percpu counter to limit the recursion depth
of eventfd_signal(). This can avoid deadlock or stack overflow.
But in stack overflow case, it should be OK to increase the
recursion depth if needed. So we add a percpu counter in eventfd_ctx
to limit the recursion depth for deadlock case. Then it could be
fine to increase the global percpu counter later.

I wonder whether or not it's worth to introduce percpu for each eventfd.

How about simply check if eventfd_signal_count() is greater than 2?

It can't avoid deadlock in this way.

I may miss something but the count is to avoid recursive eventfd call.
So for VDUSE what we suffers is e.g the interrupt injection path:

userspace write IRQFD -> vq->cb() -> another IRQFD.

It looks like increasing EVENTFD_WAKEUP_DEPTH should be sufficient?

Actually I mean the deadlock described in commit f0b493e ("io_uring:
prevent potential eventfd recursion on poll"). It can break this bug
fix if we just increase EVENTFD_WAKEUP_DEPTH.

Ok, so can wait do something similar in that commit? (using async stuffs
like wq).

We can do that. But it will reduce the performance. Because the
eventfd recursion will be triggered every time kvm kick eventfd in
vhost-vdpa cases:

KVM write KICKFD -> ops->kick_vq -> VDUSE write KICKFD

Thanks,
Yongji