On Tue, 6 Aug 2019 21:00:10 +0300 From: Jaak Ristioja
> Hello!
>
> I'm writing to report a crash in the QXL / DRM code in the Linux kernel.
> I originally filed the issue on LaunchPad and more details can be found
> there, although I doubt whether these details are useful.
>
>
> +/* How many bytes left in this page. */
> +static unsigned int rest_of_page(void *data)
> +{
> + return PAGE_SIZE - offset_in_page(data);
> +}
Not needed.
> +/* Create sg_table from a vmalloc'd buffer. */
> +static struct sg_table *vmalloc_to_sgt(char *data, uint32_t size, int
>
On Mon, Aug 12, 2019 at 02:15:32PM +0200, Christoph Hellwig wrote:
> On Sun, Aug 11, 2019 at 04:55:27AM -0400, Michael S. Tsirkin wrote:
> > On Sun, Aug 11, 2019 at 07:56:07AM +0200, Christoph Hellwig wrote:
> > > So we need a flag on the virtio device, exposed by the
> > > hypervisor (or hardware
Userspace requested command buffer allocations could be too large
to make as a contiguous allocation. Use vmalloc if necessary to
satisfy those allocations.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +-
drivers/gpu/drm/virtio/virtgpu_vq.c| 114
It is possible that a mount is in progress and device is being removed at
the same time. Use virtio_fs_mutex to avoid races.
This also takes care of bunch of races and removes some TODO items.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 32 ++--
1 file
As of now we maintain this count only for VQ_HIPRIO. Maintain it for
VQ_REQUEST as well so that later it can be used to drain VQ_REQUEST
queue.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
virtio_fs_free_devs() is now called from ->kill_sb(). By this time
all device queues have been quiesced. I am assuming that while
->kill_sb() is in progress, another mount instance will wait for
it to finish (sb->s_umount mutex provides mutual exclusion).
W.r.t ->remove path, we should be fine as
In request submission path it is possible that virtqueue is already gone
due to driver->remove(). So do not access it in dev_dbg(). Use pr_debug()
instead.
If virtuqueue is gone, this will result in NULL pointer deference.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 8
1 file
This just marks are the queues are connected and ready to accept the
request.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index d5730a50b303..f2936daca39c
These data structures should go away when virtio_fs object is going away.
When deivce is going away, we need to just make sure virtqueues can go
away and after that none of the code accesses vq and all the requests
get error.
So allocate memory for virtio_fs and virtio_fs_vq normally and free it
We now stop queues and drain all the pending requests from all virtqueues.
So this is not a TODO anymore.
Got rid of incrementing fc->dev_count as well. It did not seem meaningful
for virtio_fs.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 2 --
1 file changed, 2 deletions(-)
diff
During virtio_kill_sb() we first stop forget queue and drain it and then
call fuse_kill_sb_anon(). This will result in sending DESTROY request to
fuse server. Once finished, stop all the queues and drain one more time
just to be sure and then free up the devices.
Given drain queues will call
This object is used both by fuse_connection as well virt device. So make
this object reference counted and that makes it easy to define life cycle
of the object.
Now deivce can be removed while filesystem is still mounted. This will
cleanup all the virtqueues but virtio_fs object will still be
Hi,
Michael Tsirkin pointed out issues w.r.t various locking related TODO
items and races w.r.t device removal.
In this first round of cleanups, I have taken care of most pressing
issues.
These patches apply on top of following.
In error path we are calling fuse_request_end() but we need to clear
FR_SENT bit as well as remove request from processing queue. Otherwise
fuse_request_end() triggers a warning as well as other issues show up.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 4
1 file changed, 4
For hiprio queue (forget requests), we are keeping a state in queue whether
queue is connected or not. If queue is not connected, do not try to submit
request and return error instead.
As of now, we are checking for this state only in path where worker tries
to submit forget after first attempt
Right now we are checking ->connected state only for VQ_HIPRIO. Now we want
to make use of this method for all queues. So check it for VQ_REQUEST as
well.
This will be helpful if device has been removed and virtqueue is gone. In
that case ->connected will be false and request can't be submitted
Stop all the virt queues when device is going away. This will ensure that
no new requests are submitted to virtqueue and and request will end with
error -ENOTCONN.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 14 ++
1 file changed, 14 insertions(+)
diff --git
When device is going away, drain all pending requests.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 83 -
1 file changed, 51 insertions(+), 32 deletions(-)
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index
We maintain a fuse device per virt queue. This fuse devices are allocated
and installed during mount time and should be cleaned up when super block
is going away. Device removal should not clean it. Device removal should
stop queues and virtuques can go away.
Signed-off-by: Vivek Goyal
---
We already have an helper to cleanup fuse devices. Use that instead of
duplicating the code.
Signed-off-by: Vivek Goyal
---
fs/fuse/virtio_fs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index a76bd5a04521..40259368a6bd 100644
Pass fsvq instead of vq as parameter to virtio_fs_enqueue_req(). We will
retrieve vq from fsvq under spin lock.
Later in the patch series we will retrieve vq only if fsvq is still connected
other vq might have been cleaned up by device ->remove code and we will
return error.
Signed-off-by: Vivek
On Tue, Sep 03, 2019 at 09:55:49AM -0400, Michael S. Tsirkin wrote:
[..]
> What's with all of the TODOs? Some of these are really scary,
> looks like they need to be figured out before this is merged.
Hi Michael,
One of the issue I noticed is races w.r.t device removal and super
block
On Fri, Aug 23, 2019 at 12:39:21PM +, Mircea CIRJALIU - MELIU wrote:
> > On Thu, Aug 15, 2019 at 03:19:29PM -0400, Jerome Glisse wrote:
> > > On Tue, Aug 13, 2019 at 02:01:35PM +0300, Adalbert Lazăr wrote:
> > > > On Fri, 9 Aug 2019 09:24:44 -0700, Matthew Wilcox
> > wrote:
> > > > > On Fri,
On Wed, Sep 4, 2019 at 10:23 PM Gerd Hoffmann wrote:
>
> On Wed, Sep 04, 2019 at 04:10:30PM -0700, Chia-I Wu wrote:
> > On Wed, Sep 4, 2019 at 12:48 AM Gerd Hoffmann wrote:
> > >
> > > Only call virtio_gpu_array_add_fence if we actually have a fence.
> > >
> > > Fixes: da758d51968a ("drm/virtio:
On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote:
> Hi:
>
> Per request from Michael and Jason, the metadata accelreation is
> reverted in this version and rework in next version.
>
> Please review.
>
> Thanks
>
> Jason Wang (2):
> Revert "vhost: access vq metadata through kernel
On 05.09.19 10:14, Gerd Hoffmann wrote:
> On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote:
>> Hello!
>>
>> I'm writing to report a crash in the QXL / DRM code in the Linux kernel.
>> I originally filed the issue on LaunchPad and more details can be found
>> there, although I doubt
This is a rework on the commit 7f466032dc9e ("vhost: access vq
metadata through kernel virtual address").
It was noticed that the copy_to/from_user() friends that was used to
access virtqueue metdata tends to be very expensive for dataplane
implementation like vhost since it involves lots of
It was reported that metadata acceleration introduces several issues,
so this patch reverts commit ff466032dc9e5a61217f22ea34b2df932786bbfc,
73f628ec9e6bcc45b77c53fe6d0c0ec55eaf82af and
0b4a7092ffe568a55bf8f3cefdf79ff666586d91.
We will rework it on the next version.
Cc: Jason Gunthorpe
From: "Michael S. Tsirkin"
Date: Tue, 3 Sep 2019 03:38:16 -0400
> The comment we have is just repeating what the code does.
> Include the *reason* for the condition instead.
>
> Cc: Stefano Garzarella
> Signed-off-by: Michael S. Tsirkin
Applied.
On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote:
> Hello!
>
> I'm writing to report a crash in the QXL / DRM code in the Linux kernel.
> I originally filed the issue on LaunchPad and more details can be found
> there, although I doubt whether these details are useful.
Any change
Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it
instead of its own embedded struct. This makes some gem functions
(specifically drm_gem_object_lookup) work on ttm objects.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
1 file changed, 1 insertion(+),
Rename the embedded struct vma_offset_manager, new name is _vma_manager.
ttm_bo_device.vma_manager changed to a pointer.
The ttm_bo_device_init() function gets an additional vma_manager
argument which allows to initialize ttm with a different vma manager.
When passing NULL the embedded
Dave, Joerg, Robin:
is there any chance we could at least pick up patches 2 and 4 ASAP
as they are clearly fixes for current deficits, even without the
amd conversion?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
34 matches
Mail list logo