Re: [PATCH] vgaarb: fix signal handling in vga_get()
Hi On Mon, Dec 14, 2015 at 9:19 AM, Kirill A. Shutemovwrote: > On Thu, Dec 10, 2015 at 11:28:58AM +0100, David Herrmann wrote: >> Hi >> >> On Mon, Nov 30, 2015 at 3:17 AM, Kirill A. Shutemov >> wrote: >> > There are few defects in vga_get() related to signal hadning: >> > >> > - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE >> > case; >> > >> > - if we found pending signal we must remove ourself from wait queue >> > and change task state back to running; >> > >> > - -ERESTARTSYS is more appropriate, I guess. >> > >> > Signed-off-by: Kirill A. Shutemov >> > --- >> > >> > Alex, I try to get KVM with VGA passthrough working properly. I have i915 >> > (HD 4600) on the host and GTX 580 for the guest. The guest GPU is not >> > capabale of EFI, so I have to use x-vga=on. It's kinda work with your >> > patch for i915.enable_hd_vgaarb=1. But guest refuse to initialize the GPU >> > after KVM was not shut down correctly, resulting in host crash like this: >> > >> > BUG: unable to handle kernel paging request at 880870187ed8 >> > IP: [] 0x880870187ed8 >> > PGD 2129067 PUD 800841e3 >> > Oops: 0011 [#1] PREEMPT SMP >> > Modules linked in: iwlmvm iwlwifi >> > CPU: 6 PID: 3983 Comm: qemu-system-x86 Not tainted 4.3.0-gentoo #6 >> > Hardware name: Gigabyte Technology Co., Ltd. Z87X-UD7 TH/Z87X-UD7 TH-CF, >> > BIOS F5a 06/12/2014 >> > task: 88087a91 ti: 8808632c task.ti: 8808632c >> > RIP: 0010:[] [] 0x880870187ed8 >> > RSP: 0018:8808632c3d08 EFLAGS: 00010006 >> > RAX: 880870187db0 RBX: 70187f58 RCX: >> > RDX: RSI: 0003 RDI: 880870187db0 >> > RBP: 8808632c3d48 R08: R09: >> > R10: 000103c0 R11: 0293 R12: 81ea03c8 >> > R13: 8104c7cb R14: R15: 0003 >> > FS: 7f984f9b2700() GS:88089f38() >> > knlGS: >> > CS: 0010 DS: ES: CR0: 80050033 >> > CR2: 880870187ed8 CR3: 0008645f8000 CR4: 001426e0 >> > Stack: >> > 810cc83d 632c3d28 81ea03c0 >> > 0046 0003 >> > 8808632c3d80 810cca44 88087af63800 0286 >> > Call Trace: >> > [] ? __wake_up_common+0x4d/0x80 >> > [] __wake_up+0x34/0x50 >> > [] __vga_put+0x73/0xd0 >> > [] vga_put+0x54/0x80 >> > [] vfio_pci_vga_rw+0x1d2/0x220 >> > [] vfio_pci_rw+0x33/0x60 >> > [] vfio_pci_write+0x17/0x20 >> > [] vfio_device_fops_write+0x26/0x30 >> > [] __vfs_write+0x23/0xe0 >> > [] ? __vfs_read+0x23/0xd0 >> > [] ? do_vfs_ioctl+0x2b5/0x490 >> > [] vfs_write+0xa4/0x190 >> > [] SyS_pwrite64+0x66/0xa0 >> > [] entry_SYSCALL_64_fastpath+0x12/0x6a >> > Code: 88 ff ff e0 7e 18 70 08 88 ff ff 00 8c 57 76 08 88 ff ff 20 7f 18 70 >> > 08 88 ff ff 08 7f 18 70 08 88 ff ff 94 51 1a 81 ff ff ff ff <09> 00 00 00 >> > 00 00 00 00 01 8c 57 76 08 88 ff ff 00 8c 57 76 08 >> > RIP [] 0x880870187ed8 >> > RSP >> > CR2: 880870187ed8 >> > >> > The patch fixes the crash, but doesn't help with getting GPU in guest >> > working again. >> > >> > Any ideas? >> > >> > --- >> > drivers/gpu/vga/vgaarb.c | 6 -- >> > 1 file changed, 4 insertions(+), 2 deletions(-) >> > >> > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c >> > index 3166e4bc4eb6..9abcaa53bd25 100644 >> > --- a/drivers/gpu/vga/vgaarb.c >> > +++ b/drivers/gpu/vga/vgaarb.c >> > @@ -395,8 +395,10 @@ int vga_get(struct pci_dev *pdev, unsigned int rsrc, >> > int interruptible) >> > set_current_state(interruptible ? >> > TASK_INTERRUPTIBLE : >> > TASK_UNINTERRUPTIBLE); >> > - if (signal_pending(current)) { >> > - rc = -EINTR; >> > + if (interruptible && signal_pending(current)) { >> > + __set_current_state(TASK_RUNNING); >> > + remove_wait_queue(_wait_queue, ); >> > + rc = -ERESTARTSYS; >> > break; >> >> All 3 points are valid, and the patch looks good to me: >> >> Reviewed-by: David Herrmann >> >> However, there seems to be a race between vga_lock and putting the >> thread asleep. > > I'm not sure I understand the race you're talking about. > Could you elaborate? Normal wake-up race. You have to check the condition you wait for *after* linking your wait-queue and setting your thread-state. In the current code, if the wake-up happens between spin_unlock_irqrestore() and add_wait_queue(), you will never get woken up. Thanks David -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [PATCH] vgaarb: fix signal handling in vga_get()
On Mon, Dec 14, 2015 at 11:20:00AM +0100, David Herrmann wrote: > Hi > > On Mon, Dec 14, 2015 at 9:19 AM, Kirill A. Shutemov >wrote: > > On Thu, Dec 10, 2015 at 11:28:58AM +0100, David Herrmann wrote: > >> Hi > >> > >> On Mon, Nov 30, 2015 at 3:17 AM, Kirill A. Shutemov > >> wrote: > >> > There are few defects in vga_get() related to signal hadning: > >> > > >> > - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE > >> > case; > >> > > >> > - if we found pending signal we must remove ourself from wait queue > >> > and change task state back to running; > >> > > >> > - -ERESTARTSYS is more appropriate, I guess. > >> > > >> > Signed-off-by: Kirill A. Shutemov > >> > --- > >> > > >> > Alex, I try to get KVM with VGA passthrough working properly. I have i915 > >> > (HD 4600) on the host and GTX 580 for the guest. The guest GPU is not > >> > capabale of EFI, so I have to use x-vga=on. It's kinda work with your > >> > patch for i915.enable_hd_vgaarb=1. But guest refuse to initialize the GPU > >> > after KVM was not shut down correctly, resulting in host crash like this: > >> > > >> > BUG: unable to handle kernel paging request at 880870187ed8 > >> > IP: [] 0x880870187ed8 > >> > PGD 2129067 PUD 800841e3 > >> > Oops: 0011 [#1] PREEMPT SMP > >> > Modules linked in: iwlmvm iwlwifi > >> > CPU: 6 PID: 3983 Comm: qemu-system-x86 Not tainted 4.3.0-gentoo #6 > >> > Hardware name: Gigabyte Technology Co., Ltd. Z87X-UD7 TH/Z87X-UD7 TH-CF, > >> > BIOS F5a 06/12/2014 > >> > task: 88087a91 ti: 8808632c task.ti: 8808632c > >> > RIP: 0010:[] [] 0x880870187ed8 > >> > RSP: 0018:8808632c3d08 EFLAGS: 00010006 > >> > RAX: 880870187db0 RBX: 70187f58 RCX: > >> > RDX: RSI: 0003 RDI: 880870187db0 > >> > RBP: 8808632c3d48 R08: R09: > >> > R10: 000103c0 R11: 0293 R12: 81ea03c8 > >> > R13: 8104c7cb R14: R15: 0003 > >> > FS: 7f984f9b2700() GS:88089f38() > >> > knlGS: > >> > CS: 0010 DS: ES: CR0: 80050033 > >> > CR2: 880870187ed8 CR3: 0008645f8000 CR4: 001426e0 > >> > Stack: > >> > 810cc83d 632c3d28 81ea03c0 > >> > 0046 0003 > >> > 8808632c3d80 810cca44 88087af63800 0286 > >> > Call Trace: > >> > [] ? __wake_up_common+0x4d/0x80 > >> > [] __wake_up+0x34/0x50 > >> > [] __vga_put+0x73/0xd0 > >> > [] vga_put+0x54/0x80 > >> > [] vfio_pci_vga_rw+0x1d2/0x220 > >> > [] vfio_pci_rw+0x33/0x60 > >> > [] vfio_pci_write+0x17/0x20 > >> > [] vfio_device_fops_write+0x26/0x30 > >> > [] __vfs_write+0x23/0xe0 > >> > [] ? __vfs_read+0x23/0xd0 > >> > [] ? do_vfs_ioctl+0x2b5/0x490 > >> > [] vfs_write+0xa4/0x190 > >> > [] SyS_pwrite64+0x66/0xa0 > >> > [] entry_SYSCALL_64_fastpath+0x12/0x6a > >> > Code: 88 ff ff e0 7e 18 70 08 88 ff ff 00 8c 57 76 08 88 ff ff 20 7f 18 > >> > 70 08 88 ff ff 08 7f 18 70 08 88 ff ff 94 51 1a 81 ff ff ff ff <09> 00 > >> > 00 00 00 00 00 00 01 8c 57 76 08 88 ff ff 00 8c 57 76 08 > >> > RIP [] 0x880870187ed8 > >> > RSP > >> > CR2: 880870187ed8 > >> > > >> > The patch fixes the crash, but doesn't help with getting GPU in guest > >> > working again. > >> > > >> > Any ideas? > >> > > >> > --- > >> > drivers/gpu/vga/vgaarb.c | 6 -- > >> > 1 file changed, 4 insertions(+), 2 deletions(-) > >> > > >> > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c > >> > index 3166e4bc4eb6..9abcaa53bd25 100644 > >> > --- a/drivers/gpu/vga/vgaarb.c > >> > +++ b/drivers/gpu/vga/vgaarb.c > >> > @@ -395,8 +395,10 @@ int vga_get(struct pci_dev *pdev, unsigned int > >> > rsrc, int interruptible) > >> > set_current_state(interruptible ? > >> > TASK_INTERRUPTIBLE : > >> > TASK_UNINTERRUPTIBLE); > >> > - if (signal_pending(current)) { > >> > - rc = -EINTR; > >> > + if (interruptible && signal_pending(current)) { > >> > + __set_current_state(TASK_RUNNING); > >> > + remove_wait_queue(_wait_queue, ); > >> > + rc = -ERESTARTSYS; > >> > break; > >> > >> All 3 points are valid, and the patch looks good to me: > >> > >> Reviewed-by: David Herrmann > >> > >> However, there seems to be a race between vga_lock and putting the > >> thread asleep. > > > > I'm not sure I understand the race you're talking about. > > Could you elaborate? > > Normal wake-up race. You have to check the condition you wait for > *after* linking your wait-queue and setting your thread-state. In the >
Re: [PATCH] vgaarb: fix signal handling in vga_get()
On Thu, Dec 10, 2015 at 11:28:58AM +0100, David Herrmann wrote: > Hi > > On Mon, Nov 30, 2015 at 3:17 AM, Kirill A. Shutemov >wrote: > > There are few defects in vga_get() related to signal hadning: > > > > - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE > > case; > > > > - if we found pending signal we must remove ourself from wait queue > > and change task state back to running; > > > > - -ERESTARTSYS is more appropriate, I guess. > > > > Signed-off-by: Kirill A. Shutemov > > --- > > > > Alex, I try to get KVM with VGA passthrough working properly. I have i915 > > (HD 4600) on the host and GTX 580 for the guest. The guest GPU is not > > capabale of EFI, so I have to use x-vga=on. It's kinda work with your > > patch for i915.enable_hd_vgaarb=1. But guest refuse to initialize the GPU > > after KVM was not shut down correctly, resulting in host crash like this: > > > > BUG: unable to handle kernel paging request at 880870187ed8 > > IP: [] 0x880870187ed8 > > PGD 2129067 PUD 800841e3 > > Oops: 0011 [#1] PREEMPT SMP > > Modules linked in: iwlmvm iwlwifi > > CPU: 6 PID: 3983 Comm: qemu-system-x86 Not tainted 4.3.0-gentoo #6 > > Hardware name: Gigabyte Technology Co., Ltd. Z87X-UD7 TH/Z87X-UD7 TH-CF, > > BIOS F5a 06/12/2014 > > task: 88087a91 ti: 8808632c task.ti: 8808632c > > RIP: 0010:[] [] 0x880870187ed8 > > RSP: 0018:8808632c3d08 EFLAGS: 00010006 > > RAX: 880870187db0 RBX: 70187f58 RCX: > > RDX: RSI: 0003 RDI: 880870187db0 > > RBP: 8808632c3d48 R08: R09: > > R10: 000103c0 R11: 0293 R12: 81ea03c8 > > R13: 8104c7cb R14: R15: 0003 > > FS: 7f984f9b2700() GS:88089f38() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 880870187ed8 CR3: 0008645f8000 CR4: 001426e0 > > Stack: > > 810cc83d 632c3d28 81ea03c0 > > 0046 0003 > > 8808632c3d80 810cca44 88087af63800 0286 > > Call Trace: > > [] ? __wake_up_common+0x4d/0x80 > > [] __wake_up+0x34/0x50 > > [] __vga_put+0x73/0xd0 > > [] vga_put+0x54/0x80 > > [] vfio_pci_vga_rw+0x1d2/0x220 > > [] vfio_pci_rw+0x33/0x60 > > [] vfio_pci_write+0x17/0x20 > > [] vfio_device_fops_write+0x26/0x30 > > [] __vfs_write+0x23/0xe0 > > [] ? __vfs_read+0x23/0xd0 > > [] ? do_vfs_ioctl+0x2b5/0x490 > > [] vfs_write+0xa4/0x190 > > [] SyS_pwrite64+0x66/0xa0 > > [] entry_SYSCALL_64_fastpath+0x12/0x6a > > Code: 88 ff ff e0 7e 18 70 08 88 ff ff 00 8c 57 76 08 88 ff ff 20 7f 18 70 > > 08 88 ff ff 08 7f 18 70 08 88 ff ff 94 51 1a 81 ff ff ff ff <09> 00 00 00 > > 00 00 00 00 01 8c 57 76 08 88 ff ff 00 8c 57 76 08 > > RIP [] 0x880870187ed8 > > RSP > > CR2: 880870187ed8 > > > > The patch fixes the crash, but doesn't help with getting GPU in guest > > working again. > > > > Any ideas? > > > > --- > > drivers/gpu/vga/vgaarb.c | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c > > index 3166e4bc4eb6..9abcaa53bd25 100644 > > --- a/drivers/gpu/vga/vgaarb.c > > +++ b/drivers/gpu/vga/vgaarb.c > > @@ -395,8 +395,10 @@ int vga_get(struct pci_dev *pdev, unsigned int rsrc, > > int interruptible) > > set_current_state(interruptible ? > > TASK_INTERRUPTIBLE : > > TASK_UNINTERRUPTIBLE); > > - if (signal_pending(current)) { > > - rc = -EINTR; > > + if (interruptible && signal_pending(current)) { > > + __set_current_state(TASK_RUNNING); > > + remove_wait_queue(_wait_queue, ); > > + rc = -ERESTARTSYS; > > break; > > All 3 points are valid, and the patch looks good to me: > > Reviewed-by: David Herrmann > > However, there seems to be a race between vga_lock and putting the > thread asleep. I'm not sure I understand the race you're talking about. Could you elaborate? -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vgaarb: fix signal handling in vga_get()
Hi On Mon, Nov 30, 2015 at 3:17 AM, Kirill A. Shutemovwrote: > There are few defects in vga_get() related to signal hadning: > > - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE > case; > > - if we found pending signal we must remove ourself from wait queue > and change task state back to running; > > - -ERESTARTSYS is more appropriate, I guess. > > Signed-off-by: Kirill A. Shutemov > --- > > Alex, I try to get KVM with VGA passthrough working properly. I have i915 > (HD 4600) on the host and GTX 580 for the guest. The guest GPU is not > capabale of EFI, so I have to use x-vga=on. It's kinda work with your > patch for i915.enable_hd_vgaarb=1. But guest refuse to initialize the GPU > after KVM was not shut down correctly, resulting in host crash like this: > > BUG: unable to handle kernel paging request at 880870187ed8 > IP: [] 0x880870187ed8 > PGD 2129067 PUD 800841e3 > Oops: 0011 [#1] PREEMPT SMP > Modules linked in: iwlmvm iwlwifi > CPU: 6 PID: 3983 Comm: qemu-system-x86 Not tainted 4.3.0-gentoo #6 > Hardware name: Gigabyte Technology Co., Ltd. Z87X-UD7 TH/Z87X-UD7 TH-CF, BIOS > F5a 06/12/2014 > task: 88087a91 ti: 8808632c task.ti: 8808632c > RIP: 0010:[] [] 0x880870187ed8 > RSP: 0018:8808632c3d08 EFLAGS: 00010006 > RAX: 880870187db0 RBX: 70187f58 RCX: > RDX: RSI: 0003 RDI: 880870187db0 > RBP: 8808632c3d48 R08: R09: > R10: 000103c0 R11: 0293 R12: 81ea03c8 > R13: 8104c7cb R14: R15: 0003 > FS: 7f984f9b2700() GS:88089f38() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 880870187ed8 CR3: 0008645f8000 CR4: 001426e0 > Stack: > 810cc83d 632c3d28 81ea03c0 > 0046 0003 > 8808632c3d80 810cca44 88087af63800 0286 > Call Trace: > [] ? __wake_up_common+0x4d/0x80 > [] __wake_up+0x34/0x50 > [] __vga_put+0x73/0xd0 > [] vga_put+0x54/0x80 > [] vfio_pci_vga_rw+0x1d2/0x220 > [] vfio_pci_rw+0x33/0x60 > [] vfio_pci_write+0x17/0x20 > [] vfio_device_fops_write+0x26/0x30 > [] __vfs_write+0x23/0xe0 > [] ? __vfs_read+0x23/0xd0 > [] ? do_vfs_ioctl+0x2b5/0x490 > [] vfs_write+0xa4/0x190 > [] SyS_pwrite64+0x66/0xa0 > [] entry_SYSCALL_64_fastpath+0x12/0x6a > Code: 88 ff ff e0 7e 18 70 08 88 ff ff 00 8c 57 76 08 88 ff ff 20 7f 18 70 08 > 88 ff ff 08 7f 18 70 08 88 ff ff 94 51 1a 81 ff ff ff ff <09> 00 00 00 00 00 > 00 00 01 8c 57 76 08 88 ff ff 00 8c 57 76 08 > RIP [] 0x880870187ed8 > RSP > CR2: 880870187ed8 > > The patch fixes the crash, but doesn't help with getting GPU in guest > working again. > > Any ideas? > > --- > drivers/gpu/vga/vgaarb.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c > index 3166e4bc4eb6..9abcaa53bd25 100644 > --- a/drivers/gpu/vga/vgaarb.c > +++ b/drivers/gpu/vga/vgaarb.c > @@ -395,8 +395,10 @@ int vga_get(struct pci_dev *pdev, unsigned int rsrc, int > interruptible) > set_current_state(interruptible ? > TASK_INTERRUPTIBLE : > TASK_UNINTERRUPTIBLE); > - if (signal_pending(current)) { > - rc = -EINTR; > + if (interruptible && signal_pending(current)) { > + __set_current_state(TASK_RUNNING); > + remove_wait_queue(_wait_queue, ); > + rc = -ERESTARTSYS; > break; All 3 points are valid, and the patch looks good to me: Reviewed-by: David Herrmann However, there seems to be a race between vga_lock and putting the thread asleep. We should fix that as well. See the hunk below (completely untested.. why is VGA still in use? *sigh*). Thanks David diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c index a0b4334..82cf1e3 100644 --- a/drivers/gpu/vga/vgaarb.c +++ b/drivers/gpu/vga/vgaarb.c @@ -359,8 +359,8 @@ static void __vga_put int vga_get(struct pci_dev *pdev, unsigned int rsrc, int interruptible) { struct vga_device *vgadev, *conflict; + DECLARE_WAITQUEUE(wait, current); unsigned long flags; - wait_queue_t wait; int rc = 0; vga_check_first_use(); @@ -371,6 +371,11 @@ int vga_get return 0; for (;;) { + add_wait_queue(_wait_queue, ); + set_current_state(interruptible ? + TASK_INTERRUPTIBLE : + TASK_UNINTERRUPTIBLE); + spin_lock_irqsave(_lock, flags); vgadev =
Re: [PATCH] vgaarb: fix signal handling in vga_get()
On Mon, Nov 30, 2015 at 04:17:31AM +0200, Kirill A. Shutemov wrote: > There are few defects in vga_get() related to signal hadning: > > - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE > case; > > - if we found pending signal we must remove ourself from wait queue > and change task state back to running; > > - -ERESTARTSYS is more appropriate, I guess. > > Signed-off-by: Kirill A. ShutemovPing? David, this patch fixes crash. It would be nice to get it into 4.4. > --- > > Alex, I try to get KVM with VGA passthrough working properly. I have i915 > (HD 4600) on the host and GTX 580 for the guest. The guest GPU is not > capabale of EFI, so I have to use x-vga=on. It's kinda work with your > patch for i915.enable_hd_vgaarb=1. But guest refuse to initialize the GPU > after KVM was not shut down correctly, resulting in host crash like this: > > BUG: unable to handle kernel paging request at 880870187ed8 > IP: [] 0x880870187ed8 > PGD 2129067 PUD 800841e3 > Oops: 0011 [#1] PREEMPT SMP > Modules linked in: iwlmvm iwlwifi > CPU: 6 PID: 3983 Comm: qemu-system-x86 Not tainted 4.3.0-gentoo #6 > Hardware name: Gigabyte Technology Co., Ltd. Z87X-UD7 TH/Z87X-UD7 TH-CF, BIOS > F5a 06/12/2014 > task: 88087a91 ti: 8808632c task.ti: 8808632c > RIP: 0010:[] [] 0x880870187ed8 > RSP: 0018:8808632c3d08 EFLAGS: 00010006 > RAX: 880870187db0 RBX: 70187f58 RCX: > RDX: RSI: 0003 RDI: 880870187db0 > RBP: 8808632c3d48 R08: R09: > R10: 000103c0 R11: 0293 R12: 81ea03c8 > R13: 8104c7cb R14: R15: 0003 > FS: 7f984f9b2700() GS:88089f38() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 880870187ed8 CR3: 0008645f8000 CR4: 001426e0 > Stack: > 810cc83d 632c3d28 81ea03c0 > 0046 0003 > 8808632c3d80 810cca44 88087af63800 0286 > Call Trace: > [] ? __wake_up_common+0x4d/0x80 > [] __wake_up+0x34/0x50 > [] __vga_put+0x73/0xd0 > [] vga_put+0x54/0x80 > [] vfio_pci_vga_rw+0x1d2/0x220 > [] vfio_pci_rw+0x33/0x60 > [] vfio_pci_write+0x17/0x20 > [] vfio_device_fops_write+0x26/0x30 > [] __vfs_write+0x23/0xe0 > [] ? __vfs_read+0x23/0xd0 > [] ? do_vfs_ioctl+0x2b5/0x490 > [] vfs_write+0xa4/0x190 > [] SyS_pwrite64+0x66/0xa0 > [] entry_SYSCALL_64_fastpath+0x12/0x6a > Code: 88 ff ff e0 7e 18 70 08 88 ff ff 00 8c 57 76 08 88 ff ff 20 7f 18 70 08 > 88 ff ff 08 7f 18 70 08 88 ff ff 94 51 1a 81 ff ff ff ff <09> 00 00 00 00 00 > 00 00 01 8c 57 76 08 88 ff ff 00 8c 57 76 08 > RIP [] 0x880870187ed8 > RSP > CR2: 880870187ed8 > > The patch fixes the crash, but doesn't help with getting GPU in guest > working again. > > Any ideas? > > --- > drivers/gpu/vga/vgaarb.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c > index 3166e4bc4eb6..9abcaa53bd25 100644 > --- a/drivers/gpu/vga/vgaarb.c > +++ b/drivers/gpu/vga/vgaarb.c > @@ -395,8 +395,10 @@ int vga_get(struct pci_dev *pdev, unsigned int rsrc, int > interruptible) > set_current_state(interruptible ? > TASK_INTERRUPTIBLE : > TASK_UNINTERRUPTIBLE); > - if (signal_pending(current)) { > - rc = -EINTR; > + if (interruptible && signal_pending(current)) { > + __set_current_state(TASK_RUNNING); > + remove_wait_queue(_wait_queue, ); > + rc = -ERESTARTSYS; > break; > } > schedule(); > -- > 2.6.3 > -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html