All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Jason Wang <jasowang@redhat.com>, Yongji Xie <xieyongji@bytedance.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Stefano Garzarella <sgarzare@redhat.com>,
	Parav Pandit <parav@nvidia.com>, Bob Liu <bob.liu@oracle.com>,
	Christoph Hellwig <hch@infradead.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Matthew Wilcox <willy@infradead.org>,
	viro@zeniv.linux.org.uk, bcrl@kvack.org,
	Jonathan Corbet <corbet@lwn.net>,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, kvm@vger.kernel.org, linux-aio@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [RFC v3 01/11] eventfd: track eventfd_signal() recursion depth separately in different cases
Date: Wed, 27 Jan 2021 20:08:19 -0700	[thread overview]
Message-ID: <4e482f00-163a-f957-4665-141502cf4dff@kernel.dk> (raw)
In-Reply-To: <b5c9f2d4-5b95-4552-3886-f5cbcb7de232@redhat.com>

On 1/27/21 8:04 PM, Jason Wang wrote:
> 
> On 2021/1/27 下午5:11, Yongji Xie wrote:
>> On Wed, Jan 27, 2021 at 11:38 AM Jason Wang <jasowang@redhat.com> wrote:
>>>
>>> On 2021/1/20 下午2:52, Yongji Xie wrote:
>>>> On Wed, Jan 20, 2021 at 12:24 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>> On 2021/1/19 下午12:59, Xie Yongji wrote:
>>>>>> 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).

io_uring should be fine in current kernels, but aio would still be
affected by this. But just in terms of recursion, bumping it one more
should probably still be fine.

-- 
Jens Axboe


WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: Jason Wang <jasowang@redhat.com>, Yongji Xie <xieyongji@bytedance.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	linux-aio@kvack.org, netdev@vger.kernel.org,
	Randy Dunlap <rdunlap@infradead.org>,
	Matthew Wilcox <willy@infradead.org>,
	virtualization@lists.linux-foundation.org,
	Christoph Hellwig <hch@infradead.org>,
	Bob Liu <bob.liu@oracle.com>,
	bcrl@kvack.org, viro@zeniv.linux.org.uk,
	Stefan Hajnoczi <stefanha@redhat.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [RFC v3 01/11] eventfd: track eventfd_signal() recursion depth separately in different cases
Date: Wed, 27 Jan 2021 20:08:19 -0700	[thread overview]
Message-ID: <4e482f00-163a-f957-4665-141502cf4dff@kernel.dk> (raw)
In-Reply-To: <b5c9f2d4-5b95-4552-3886-f5cbcb7de232@redhat.com>

On 1/27/21 8:04 PM, Jason Wang wrote:
> 
> On 2021/1/27 下午5:11, Yongji Xie wrote:
>> On Wed, Jan 27, 2021 at 11:38 AM Jason Wang <jasowang@redhat.com> wrote:
>>>
>>> On 2021/1/20 下午2:52, Yongji Xie wrote:
>>>> On Wed, Jan 20, 2021 at 12:24 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>> On 2021/1/19 下午12:59, Xie Yongji wrote:
>>>>>> 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).

io_uring should be fine in current kernels, but aio would still be
affected by this. But just in terms of recursion, bumping it one more
should probably still be fine.

-- 
Jens Axboe

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2021-01-28  3:09 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19  4:59 [RFC v3 00/11] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-01-19  4:59 ` [RFC v3 01/11] eventfd: track eventfd_signal() recursion depth separately in different cases Xie Yongji
2021-01-20  4:24   ` Jason Wang
2021-01-20  4:24     ` Jason Wang
2021-01-20  6:52     ` Yongji Xie
2021-01-27  3:37       ` Jason Wang
2021-01-27  3:37         ` Jason Wang
2021-01-27  9:11         ` Yongji Xie
2021-01-28  3:04           ` Jason Wang
2021-01-28  3:04             ` Jason Wang
2021-01-28  3:08             ` Jens Axboe [this message]
2021-01-28  3:08               ` Jens Axboe
2021-01-28  5:12               ` Yongji Xie
2021-01-28  3:52             ` Yongji Xie
2021-01-28  4:31               ` Jason Wang
2021-01-28  4:31                 ` Jason Wang
2021-01-28  6:08                 ` Yongji Xie
2021-01-19  4:59 ` [RFC v3 02/11] eventfd: Increase the recursion depth of eventfd_signal() Xie Yongji
2021-01-19  4:59 ` [RFC v3 03/11] vdpa: Remove the restriction that only supports virtio-net devices Xie Yongji
2021-01-20  3:46   ` Jason Wang
2021-01-20  3:46     ` Jason Wang
2021-01-20  6:46     ` Yongji Xie
2021-01-20 11:08     ` Stefano Garzarella
2021-01-20 11:08       ` Stefano Garzarella
2021-01-27  3:33       ` Jason Wang
2021-01-27  3:33         ` Jason Wang
2021-01-27  8:57         ` Stefano Garzarella
2021-01-27  8:57           ` Stefano Garzarella
2021-01-28  3:11           ` Jason Wang
2021-01-28  3:11             ` Jason Wang
2021-01-29 15:03             ` Stefano Garzarella
2021-01-30 11:33               ` Yongji Xie
2021-02-01 11:05                 ` Stefano Garzarella
2021-02-01 11:05                   ` Stefano Garzarella
2021-01-27  8:59   ` Stefano Garzarella
2021-01-27  8:59     ` Stefano Garzarella
2021-01-27  9:05     ` Yongji Xie
2021-01-19  4:59 ` [RFC v3 04/11] vhost-vdpa: protect concurrent access to vhost device iotlb Xie Yongji
2021-01-20  3:44   ` Jason Wang
2021-01-20  3:44     ` Jason Wang
2021-01-20  6:44     ` Yongji Xie
2021-01-19  4:59 ` [RFC v3 05/11] vdpa: shared virtual addressing support Xie Yongji
2021-01-20  5:55   ` Jason Wang
2021-01-20  5:55     ` Jason Wang
2021-01-20  7:10     ` Yongji Xie
2021-01-27  3:43       ` Jason Wang
2021-01-27  3:43         ` Jason Wang
2021-01-19  4:59 ` [RFC v3 06/11] vhost-vdpa: Add an opaque pointer for vhost IOTLB Xie Yongji
2021-01-20  6:24   ` Jason Wang
2021-01-20  6:24     ` Jason Wang
2021-01-20  7:52     ` Yongji Xie
2021-01-27  3:51       ` Jason Wang
2021-01-27  3:51         ` Jason Wang
2021-01-27  9:27         ` Yongji Xie
2021-01-19  5:07 ` [RFC v3 07/11] vdpa: Pass the netlink attributes to ops.dev_add() Xie Yongji
2021-01-19  5:07   ` [RFC v3 08/11] vduse: Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-01-19 14:53     ` Jonathan Corbet
2021-01-19 14:53       ` Jonathan Corbet
2021-01-20  2:25       ` Yongji Xie
2021-01-19 17:53     ` Randy Dunlap
2021-01-19 17:53       ` Randy Dunlap
2021-01-20  2:42       ` Yongji Xie
2021-01-26  8:08     ` Jason Wang
2021-01-26  8:08       ` Jason Wang
2021-01-27  8:50       ` Yongji Xie
2021-01-28  4:27         ` Jason Wang
2021-01-28  4:27           ` Jason Wang
2021-01-28  6:03           ` Yongji Xie
2021-01-28  6:14             ` Jason Wang
2021-01-28  6:14               ` Jason Wang
2021-01-28  6:43               ` Yongji Xie
2021-01-26  8:19     ` Jason Wang
2021-01-26  8:19       ` Jason Wang
2021-01-27  8:59       ` Yongji Xie
2021-01-19  5:07   ` [RFC v3 09/11] vduse: Add VDUSE_GET_DEV ioctl Xie Yongji
2021-01-19  5:07   ` [RFC v3 10/11] vduse: grab the module's references until there is no vduse device Xie Yongji
2021-01-26  8:09     ` Jason Wang
2021-01-26  8:09       ` Jason Wang
2021-01-27  8:51       ` Yongji Xie
2021-01-19  5:07   ` [RFC v3 11/11] vduse: Introduce a workqueue for irq injection Xie Yongji
2021-01-26  8:17     ` Jason Wang
2021-01-26  8:17       ` Jason Wang
2021-01-27  9:00       ` Yongji Xie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4e482f00-163a-f957-4665-141502cf4dff@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=bcrl@kvack.org \
    --cc=bob.liu@oracle.com \
    --cc=corbet@lwn.net \
    --cc=hch@infradead.org \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-aio@kvack.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=parav@nvidia.com \
    --cc=rdunlap@infradead.org \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=willy@infradead.org \
    --cc=xieyongji@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.