linux-kernel - Re: [PATCH v9 16/17] vduse: Introduce VDUSE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a493bc51-9a5c-05f1-2eac-54cb9e6c9d9b@redhat.com>
Date:   Wed, 14 Jul 2021 16:56:55 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     "Michael S. Tsirkin" <mst@...hat.com>,
        Xie Yongji <xieyongji@...edance.com>, stefanha@...hat.com,
        sgarzare@...hat.com, parav@...dia.com, hch@...radead.org,
        christian.brauner@...onical.com, rdunlap@...radead.org,
        willy@...radead.org, viro@...iv.linux.org.uk, axboe@...nel.dk,
        bcrl@...ck.org, corbet@....net, mika.penttila@...tfour.com,
        dan.carpenter@...cle.com, joro@...tes.org, zhe.he@...driver.com,
        xiaodong.liu@...el.com, songmuchun@...edance.com,
        virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org,
        kvm@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 16/17] vduse: Introduce VDUSE - vDPA Device in
 Userspace


在 2021/7/14 下午2:47, Greg KH 写道:
> On Wed, Jul 14, 2021 at 02:02:50PM +0800, Jason Wang wrote:
>> 在 2021/7/14 下午1:54, Michael S. Tsirkin 写道:
>>> On Wed, Jul 14, 2021 at 01:45:39PM +0800, Jason Wang wrote:
>>>>> +static int vduse_dev_msg_sync(struct vduse_dev *dev,
>>>>> +			      struct vduse_dev_msg *msg)
>>>>> +{
>>>>> +	int ret;
>>>>> +
>>>>> +	init_waitqueue_head(&msg->waitq);
>>>>> +	spin_lock(&dev->msg_lock);
>>>>> +	msg->req.request_id = dev->msg_unique++;
>>>>> +	vduse_enqueue_msg(&dev->send_list, msg);
>>>>> +	wake_up(&dev->waitq);
>>>>> +	spin_unlock(&dev->msg_lock);
>>>>> +
>>>>> +	wait_event_killable_timeout(msg->waitq, msg->completed,
>>>>> +				    VDUSE_REQUEST_TIMEOUT * HZ);
>>>>> +	spin_lock(&dev->msg_lock);
>>>>> +	if (!msg->completed) {
>>>>> +		list_del(&msg->list);
>>>>> +		msg->resp.result = VDUSE_REQ_RESULT_FAILED;
>>>>> +	}
>>>>> +	ret = (msg->resp.result == VDUSE_REQ_RESULT_OK) ? 0 : -EIO;
>>>> I think we should mark the device as malfunction when there is a timeout and
>>>> forbid any userspace operations except for the destroy aftwards for safety.
>>> This looks like if one tried to run gdb on the program the behaviour
>>> will change completely because kernel wants it to respond within
>>> specific time. Looks like a receipe for heisenbugs.
>>>
>>> Let's not build interfaces with arbitrary timeouts like that.
>>> Interruptible wait exists for this very reason.
>>
>> The problem is. Do we want userspace program like modprobe to be stuck for
>> indefinite time and expect the administrator to kill that?
> Why would modprobe be stuck for forever?
>
> Is this on the module probe path?


Yes, it is called in the device probing path where the kernel forwards 
the device configuration request to userspace and wait for its response.

If it turns out to be tricky, we can implement the whole device inside 
the kernel and leave only the datapath in the userspace (as what TUN did).

Thanks


>