- Linux-stable-mirror - lists.linaro.org

patch "usb: dwc3: Fix lock-up on ID change during system suspend/resume" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: Fix lock-up on ID change during system suspend/resume to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 084a804e01205bcd74cd0849bc72cb5c88f8e648 Mon Sep 17 00:00:00 2001 From: Roger Quadros <rogerq(a)ti.com> Date: Tue, 27 Feb 2018 12:41:41 +0200 Subject: usb: dwc3: Fix lock-up on ID change during system suspend/resume To reproduce the lock up do the following - connect otg host adapter and a USB device to the dual-role port so that it is in host mode. - suspend to mem. - disconnect otg adapter. - resume the system. If we call dwc3_host_exit() before tasks are thawed xhci_plat_remove() seems to lock up at the second usb_remove_hcd() call. To work around this we queue the _dwc3_set_mode() work on the system_freezable_wq. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: <stable(a)vger.kernel.org> # v4.12+ Suggested-by: Manu Gautam <mgautam(a)codeaurora.org> Signed-off-by: Roger Quadros <rogerq(a)ti.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> --- drivers/usb/dwc3/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index f1d838a4acd6..e94bf91cc58a 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -175,7 +175,7 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode) dwc->desired_dr_role = mode; spin_unlock_irqrestore(&dwc->lock, flags); - queue_work(system_power_efficient_wq, &dwc->drd_work); + queue_work(system_freezable_wq, &dwc->drd_work); } u32 dwc3_core_fifo_space(struct dwc3_ep *dep, u8 type) -- 2.16.2

7 years, 3 months

1
0
0 0

[PATCH 1/4] xhci: fix endpoint context tracer output

by Mathias Nyman

Fix incorrent values showed for max Primary stream and Linear stream array (LSA) values in the endpoint context decoder. Fixes: 19a7d0d65c4a ("usb: host: xhci: add Slot and EP Context tracers") Cc: <stable(a)vger.kernel.org> # v4.12+ Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci.h | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index e4d7d3d..d20e57b 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -718,11 +718,12 @@ struct xhci_ep_ctx { /* bits 10:14 are Max Primary Streams */ /* bit 15 is Linear Stream Array */ /* Interval - period between requests to an endpoint - 125u increments. */ -#define EP_INTERVAL(p) (((p) & 0xff) << 16) -#define EP_INTERVAL_TO_UFRAMES(p) (1 << (((p) >> 16) & 0xff)) -#define CTX_TO_EP_INTERVAL(p) (((p) >> 16) & 0xff) -#define EP_MAXPSTREAMS_MASK (0x1f << 10) -#define EP_MAXPSTREAMS(p) (((p) << 10) & EP_MAXPSTREAMS_MASK) +#define EP_INTERVAL(p) (((p) & 0xff) << 16) +#define EP_INTERVAL_TO_UFRAMES(p) (1 << (((p) >> 16) & 0xff)) +#define CTX_TO_EP_INTERVAL(p) (((p) >> 16) & 0xff) +#define EP_MAXPSTREAMS_MASK (0x1f << 10) +#define EP_MAXPSTREAMS(p) (((p) << 10) & EP_MAXPSTREAMS_MASK) +#define CTX_TO_EP_MAXPSTREAMS(p) (((p) & EP_MAXPSTREAMS_MASK) >> 10) /* Endpoint is set up with a Linear Stream Array (vs. Secondary Stream Array) */ #define EP_HAS_LSA (1 << 15) /* hosts with LEC=1 use bits 31:24 as ESIT high bits. */ @@ -2549,21 +2550,22 @@ static inline const char *xhci_decode_ep_context(u32 info, u32 info2, u64 deq, u8 burst; u8 cerr; u8 mult; - u8 lsa; - u8 hid; + + bool lsa; + bool hid; esit = CTX_TO_MAX_ESIT_PAYLOAD_HI(info) << 16 | CTX_TO_MAX_ESIT_PAYLOAD(tx_info); ep_state = info & EP_STATE_MASK; - max_pstr = info & EP_MAXPSTREAMS_MASK; + max_pstr = CTX_TO_EP_MAXPSTREAMS(info); interval = CTX_TO_EP_INTERVAL(info); mult = CTX_TO_EP_MULT(info) + 1; - lsa = info & EP_HAS_LSA; + lsa = !!(info & EP_HAS_LSA); cerr = (info2 & (3 << 1)) >> 1; ep_type = CTX_TO_EP_TYPE(info2); - hid = info2 & (1 << 7); + hid = !!(info2 & (1 << 7)); burst = CTX_TO_MAX_BURST(info2); maxp = MAX_PACKET_DECODED(info2); -- 2.7.4

7 years, 3 months

1
0
0 0

Re: 4.14.18 -> 4.14.24 - almost all guests hanged

by Greg KH

On Wed, Mar 07, 2018 at 09:29:10PM +0100, Nikola Ciprich wrote: > Hi, > > > > > I'd like to report that when upgrading our cluster from 4.14.18 to > > > > 4.14.24-rc1 (with live guests migration), almost none of guests survived.. > > > What's your hardware setup, intel with IBPB enabled microcode? > > Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz > > > > therefore I suppose no IBPB (at least meltdown checker reports so) > > > > > > > Does guests hang right after live migration? > > yes, just tried it. > > > > > > > > > > Are you able to reproduce the problem, does it work with latest upstream? > > yup, so I'm able to reproduce quickly. I'll revert the cluster to 4.14.18 now, > > but setup test system just afterwards, so and test the patch you've proposed. > > > > > > > > Not sure it helps, but following patch is missing in 4.14.24 > > > > > > commit 37b95951c58fdf08dc10afa9d02066ed9f176fb5 upstream. > > > > > > kvm_valid_sregs() should use X86_CR0_PG and X86_CR4_PAE to check bit > > > status rather than X86_CR0_PG_BIT and X86_CR4_PAE_BIT. This patch is > > > to fix it. > > > > > > Fixes: f29810335965a(KVM/x86: Check input paging mode when cs.l is set) > > > Reported-by: Jeremi Piotrowski <jeremi.piotrowski(a)gmail.com> > > > Cc: Paolo Bonzini <pbonzini(a)redhat.com> > > > Cc: Radim Krčmář <rkrcmar(a)redhat.com> > > > Signed-off-by: Tianyu Lan <Tianyu.Lan(a)microsoft.com> > > > Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> > > > > I'll test and report. > > so indeed, this one on top of 4.14.24-rc1 fixes the migration for me. > Greg, could you queue this one up please? As was already pointed out, this is already queued up to be in the next release. thanks, greg k-h

7 years, 3 months

1
0
0 0

Patch "leds: do not overflow sysfs buffer in led_trigger_show" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled leds: do not overflow sysfs buffer in led_trigger_show to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: leds-do-not-overflow-sysfs-buffer-in-led_trigger_show.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3b9b95363c45365d606ad4bbba16acca75fdf6d3 Mon Sep 17 00:00:00 2001 From: Nathan Sullivan <nathan.sullivan(a)ni.com> Date: Mon, 15 Aug 2016 17:20:14 -0500 Subject: leds: do not overflow sysfs buffer in led_trigger_show From: Nathan Sullivan <nathan.sullivan(a)ni.com> commit 3b9b95363c45365d606ad4bbba16acca75fdf6d3 upstream. Per the documentation, use scnprintf instead of sprintf to ensure there is never more than PAGE_SIZE bytes of trigger names put into the buffer. Signed-off-by: Nathan Sullivan <nathan.sullivan(a)ni.com> Signed-off-by: Zach Brown <zach.brown(a)ni.com> Signed-off-by: Jacek Anaszewski <j.anaszewski(a)samsung.com> Cc: Willy Tarreau <w(a)1wt.eu> Cc: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/leds/led-triggers.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/drivers/leds/led-triggers.c +++ b/drivers/leds/led-triggers.c @@ -88,21 +88,23 @@ ssize_t led_trigger_show(struct device * down_read(&led_cdev->trigger_lock); if (!led_cdev->trigger) - len += sprintf(buf+len, "[none] "); + len += scnprintf(buf+len, PAGE_SIZE - len, "[none] "); else - len += sprintf(buf+len, "none "); + len += scnprintf(buf+len, PAGE_SIZE - len, "none "); list_for_each_entry(trig, &trigger_list, next_trig) { if (led_cdev->trigger && !strcmp(led_cdev->trigger->name, trig->name)) - len += sprintf(buf+len, "[%s] ", trig->name); + len += scnprintf(buf+len, PAGE_SIZE - len, "[%s] ", + trig->name); else - len += sprintf(buf+len, "%s ", trig->name); + len += scnprintf(buf+len, PAGE_SIZE - len, "%s ", + trig->name); } up_read(&led_cdev->trigger_lock); up_read(&triggers_list_lock); - len += sprintf(len+buf, "\n"); + len += scnprintf(len+buf, PAGE_SIZE - len, "\n"); return len; } EXPORT_SYMBOL_GPL(led_trigger_show); Patches currently in stable-queue which might be from nathan.sullivan(a)ni.com are queue-4.4/leds-do-not-overflow-sysfs-buffer-in-led_trigger_show.patch

7 years, 3 months

1
0
0 0

Patch "leds: do not overflow sysfs buffer in led_trigger_show" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled leds: do not overflow sysfs buffer in led_trigger_show to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: leds-do-not-overflow-sysfs-buffer-in-led_trigger_show.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3b9b95363c45365d606ad4bbba16acca75fdf6d3 Mon Sep 17 00:00:00 2001 From: Nathan Sullivan <nathan.sullivan(a)ni.com> Date: Mon, 15 Aug 2016 17:20:14 -0500 Subject: leds: do not overflow sysfs buffer in led_trigger_show From: Nathan Sullivan <nathan.sullivan(a)ni.com> commit 3b9b95363c45365d606ad4bbba16acca75fdf6d3 upstream. Per the documentation, use scnprintf instead of sprintf to ensure there is never more than PAGE_SIZE bytes of trigger names put into the buffer. Signed-off-by: Nathan Sullivan <nathan.sullivan(a)ni.com> Signed-off-by: Zach Brown <zach.brown(a)ni.com> Signed-off-by: Jacek Anaszewski <j.anaszewski(a)samsung.com> Cc: Willy Tarreau <w(a)1wt.eu> Cc: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/leds/led-triggers.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/drivers/leds/led-triggers.c +++ b/drivers/leds/led-triggers.c @@ -78,21 +78,23 @@ ssize_t led_trigger_show(struct device * down_read(&led_cdev->trigger_lock); if (!led_cdev->trigger) - len += sprintf(buf+len, "[none] "); + len += scnprintf(buf+len, PAGE_SIZE - len, "[none] "); else - len += sprintf(buf+len, "none "); + len += scnprintf(buf+len, PAGE_SIZE - len, "none "); list_for_each_entry(trig, &trigger_list, next_trig) { if (led_cdev->trigger && !strcmp(led_cdev->trigger->name, trig->name)) - len += sprintf(buf+len, "[%s] ", trig->name); + len += scnprintf(buf+len, PAGE_SIZE - len, "[%s] ", + trig->name); else - len += sprintf(buf+len, "%s ", trig->name); + len += scnprintf(buf+len, PAGE_SIZE - len, "%s ", + trig->name); } up_read(&led_cdev->trigger_lock); up_read(&triggers_list_lock); - len += sprintf(len+buf, "\n"); + len += scnprintf(len+buf, PAGE_SIZE - len, "\n"); return len; } EXPORT_SYMBOL_GPL(led_trigger_show); Patches currently in stable-queue which might be from nathan.sullivan(a)ni.com are queue-3.18/leds-do-not-overflow-sysfs-buffer-in-led_trigger_show.patch

7 years, 3 months

1
0
0 0

Re: [PATCH 00/45] arm Spectre fix backport review for LTS 4.9

by Pali Rohár

On Thursday 08 March 2018 13:27:15 Pavel Machek wrote: > Hi! > > > Resent without non-upstream patches. > > > > This backport patchset fixed the spectre issue, it's original branch: > > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti > > A few dependency or fixingpatches are also picked up, if they are necessary > > and no functional changes. > > > > No bug found from kernelci.org and lkft testing. It also could be gotten from: > > > > git://git.linaro.org/kernel/linux-linaro-stable.git v4.9-spectre-upstream-only > > > > Comments are appreciated! > > Not entirely related to this patched, but... I have few older ARM > boards here, and Nokia N9000 I really care about. > > AFAICT Meltdown is arm64 only? IIRC ARMv7 is not affected by meltdown. > Spectre affects the older boards, too, right? Was there any work done > on that? cpuinfo says "ARMv7" for N900. I remember that I saw some spectre patches for ARMv7 on LKML. In general for ARMv7 it is problematic as mitigation needs to change IBE bit which is not possible on OMAP HS devices. But for Nokia N900 there is special code which do it via smc instruction (function rx51_secure_update_aux_cr(), see also nokia_n900_legacy_init()). -- Pali Rohár pali.rohar(a)gmail.com

7 years, 3 months

3
2
0 0

[PATCH resend] module: propagate error in modules_open()

by Leon Yu

otherwise kernel can oops later in seq_release() due to dereferencing null file->private_data which is only set if seq_open() succeeds. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: seq_release+0xc/0x30 Call Trace: close_pdeo+0x37/0xd0 proc_reg_release+0x5d/0x60 __fput+0x9d/0x1d0 ____fput+0x9/0x10 task_work_run+0x75/0x90 do_exit+0x252/0xa00 do_group_exit+0x36/0xb0 SyS_exit_group+0xf/0x10 Fixes: 516fb7f2e73d ("/proc/module: use the same logic as /proc/kallsyms for address exposure") Cc: Jessica Yu <jeyu(a)kernel.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org # 4.15+ Signed-off-by: Leon Yu <chianglungyu(a)gmail.com> --- kernel/module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/module.c b/kernel/module.c index ad2d420024f6..e42764acedb4 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -4228,7 +4228,7 @@ static int modules_open(struct inode *inode, struct file *file) m->private = kallsyms_show_value() ? NULL : (void *)8ul; } - return 0; + return err; } static const struct file_operations proc_modules_operations = { -- 2.16.2

7 years, 3 months

2
1
0 0

[PATCH] staging: android: ashmem: Remove deadlock

by Paul Lawrence

Regression introduced in commit ce8a3a9e76d0193e2e8d74a06d275b3c324ca652 ("staging: android: ashmem: Fix a race condition in pin ioctls") causing deadlock. No need to hold ashmem_mutex while copying from user Stacks are: ashmem_mmap+0x53/0x400 drivers/staging/android/ashmem.c:379 mmap_region+0x7dd/0xfd0 mm/mmap.c:1694 do_mmap+0x57b/0xbe0 mm/mmap.c:1473 and lock_acquire+0x12e/0x410 kernel/locking/lockdep.c:3756 __might_fault+0x14a/0x1d0 mm/memory.c:4014 copy_from_user arch/x86/include/asm/uaccess.h:705 [inline] ashmem_pin_unpin drivers/staging/android/ashmem.c:719 [inline] Signed-off-by: Paul Lawrence <paullawrence(a)google.com> Cc: <stable(a)vger.kernel.org> # 4.9.x Cc: <stable(a)vger.kernel.org> # 4.4.x Cc: <stable(a)vger.kernel.org> # 3.18.x: ce8a3a9e76d01 Cc: <stable(a)vger.kernel.org> # 3.18.x Cc: Ben Hutchings <ben(a)decadent.org.uk> --- drivers/staging/android/ashmem.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c index 6dbba5aff191..8c55706c2cfa 100644 --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -702,16 +702,14 @@ static int ashmem_pin_unpin(struct ashmem_area *asma, unsigned long cmd, size_t pgstart, pgend; int ret = -EINVAL; + if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) + return -EFAULT; + mutex_lock(&ashmem_mutex); if (unlikely(!asma->file)) goto out_unlock; - if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) { - ret = -EFAULT; - goto out_unlock; - } - /* per custom, you can pass zero for len to mean "everything onward" */ if (!pin.len) pin.len = PAGE_ALIGN(asma->size) - pin.offset; -- 2.16.2.395.g2e18187dfd-goog

7 years, 3 months

3
2
0 0

Re: 4.14.18 -> 4.14.24 - almost all guests hanged

by 王金浦

2018-03-07 21:29 GMT+01:00 Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>: > Hi, > >> > > I'd like to report that when upgrading our cluster from 4.14.18 to >> > > 4.14.24-rc1 (with live guests migration), almost none of guests survived.. >> > What's your hardware setup, intel with IBPB enabled microcode? >> Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz >> >> therefore I suppose no IBPB (at least meltdown checker reports so) >> >> >> > Does guests hang right after live migration? >> yes, just tried it. >> >> >> > >> > Are you able to reproduce the problem, does it work with latest upstream? >> yup, so I'm able to reproduce quickly. I'll revert the cluster to 4.14.18 now, >> but setup test system just afterwards, so and test the patch you've proposed. >> >> > >> > Not sure it helps, but following patch is missing in 4.14.24 >> > >> > commit 37b95951c58fdf08dc10afa9d02066ed9f176fb5 upstream. >> > >> > kvm_valid_sregs() should use X86_CR0_PG and X86_CR4_PAE to check bit >> > status rather than X86_CR0_PG_BIT and X86_CR4_PAE_BIT. This patch is >> > to fix it. >> > >> > Fixes: f29810335965a(KVM/x86: Check input paging mode when cs.l is set) >> > Reported-by: Jeremi Piotrowski <jeremi.piotrowski(a)gmail.com> >> > Cc: Paolo Bonzini <pbonzini(a)redhat.com> >> > Cc: Radim Krčmář <rkrcmar(a)redhat.com> >> > Signed-off-by: Tianyu Lan <Tianyu.Lan(a)microsoft.com> >> > Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> >> >> I'll test and report. > > so indeed, this one on top of 4.14.24-rc1 fixes the migration for me. > Greg, could you queue this one up please? > > Jack, thanks for the hint! > BR > nik Hi Nik, Thanks for testing and let we know, the patch is already queued in 4.14.25-rc1 by Greg. There're some other KVM fixes and performance enhancement. Regards, Jack > > > >> >> n. >> >> >> > >> > Regards, >> > Jack >> > > >> > > I noticed that most of them got stuck in "paused" state without >> > > possibility to resume (virsh just reported guest cannot be continued and >> > > needs to be rebooted). >> > > >> > > in dmesg, lots of following messages appeared: >> > > >> > > [ 116.593508] device vnet0 entered promiscuous mode >> > > [ 124.143532] *** Guest State *** >> > > [ 124.143594] CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7 >> > > [ 124.143668] CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffe871 >> > > [ 124.143871] CR3 = 0x00000000feffc000 >> > > [ 124.143984] RSP = 0xffffffff82003e98 RIP = 0xffffffff816df002 >> > > [ 124.144102] RFLAGS=0x00000246 DR7 = 0x0000000000000400 >> > > [ 124.144221] Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 >> > > [ 124.144341] CS: sel=0xf000, attr=0x0009b, limit=0x0000ffff, base=0x00000000ffff0000 >> > > [ 124.144516] DS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.144692] SS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.144907] ES: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145089] FS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145272] GS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145447] GDTR: limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145626] LDTR: sel=0x0000, attr=0x00082, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145814] IDTR: limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.145995] TR: sel=0x0000, attr=0x0008b, limit=0x0000ffff, base=0x0000000000000000 >> > > [ 124.146173] EFER = 0x0000000000000000 PAT = 0x0007040600070406 >> > > [ 124.146292] DebugCtl = 0x0000000000000000 DebugExceptions = 0x0000000000000000 >> > > [ 124.146466] Interruptibility = 00000000 ActivityState = 00000000 >> > > [ 124.146579] *** Host State *** >> > > [ 124.146687] RIP = 0xffffffffa046a817 RSP = 0xffffc900200a7cb8 >> > > [ 124.146832] CS=0010 SS=0018 DS=0000 ES=0000 FS=0000 GS=0000 TR=0040 >> > > [ 124.146961] FSBase=00007fe82eff7700 GSBase=ffff881fffb40000 TRBase=fffffe00000df000 >> > > [ 124.147144] GDTBase=fffffe00000dd000 IDTBase=fffffe0000000000 >> > > [ 124.147262] CR0=0000000080050033 CR3=0000001f5b8fe004 CR4=00000000000626e0 >> > > [ 124.147381] Sysenter RSP=fffffe00000de200 CS:RIP=0010:ffffffff81801f60 >> > > [ 124.147499] EFER = 0x0000000000000d01 PAT = 0x0407050600070106 >> > > [ 124.147614] *** Control State *** >> > > [ 124.147734] PinBased=0000007f CPUBased=96a1e9fa SecondaryExec=000004f2 >> > > [ 124.147849] EntryControls=0000d1ff ExitControls=002fefff >> > > [ 124.147965] ExceptionBitmap=00060042 PFECmask=00000000 PFECmatch=00000000 >> > > [ 124.148085] VMEntry: intr_info=80000081 errcode=00000000 ilen=00000000 >> > > [ 124.148201] VMExit: intr_info=00000000 errcode=00000000 ilen=00000000 >> > > [ 124.148318] reason=80000021 qualification=0000000000000000 >> > > [ 124.148432] IDTVectoring: info=00000000 errcode=00000000 >> > > [ 124.148545] TSC Offset = 0xffed7296fb06bc34 >> > > [ 124.148655] TPR Threshold = 0x00 >> > > [ 124.148770] EPT pointer = 0x0000001f1a0af01e >> > > [ 124.148882] PLE Gap=00000080 Window=00001000 >> > > [ 124.148995] Virtual processor ID = 0x0001 >> > > >> > > (never seen anything like that) >> > > >> > > I haven't yet went through all patches between those two versions, so don't >> > > have any suspicion yet.. If anyone recognizes this as known problem, please >> > > let me know.. >> > > >> > > I'm going to try whether I'm able to reproduce the problem. >> > > >> > > BR >> > > >> > > nik >> > >> >> -- >> ------------------------------------- >> Ing. Nikola CIPRICH >> LinuxBox.cz, s.r.o. >> 28.rijna 168, 709 00 Ostrava >> >> tel.: +420 591 166 214 >> fax: +420 596 621 273 >> mobil: +420 777 093 799 >> www.linuxbox.cz >> >> mobil servis: +420 737 238 656 >> email servis: servis(a)linuxbox.cz >> ------------------------------------- >> > > -- > ------------------------------------- > Ing. Nikola CIPRICH > LinuxBox.cz, s.r.o. > 28. rijna 168, 709 00 Ostrava > > tel.: +420 591 166 214 > fax: +420 596 621 273 > mobil: +420 777 093 799 > > www.linuxbox.cz > > mobil servis: +420 737 238 656 > email servis: servis(a)linuxbox.cz > -------------------------------------

7 years, 3 months

1
0
0 0

[stable-4.14 0/2] 2 kvm fix for 4.14

by Jack Wang

From: Jack Wang <jinpu.wang(a)profitbricks.com> Hi Greg, I noticed 2 fixes for kvm are missing in your queue-4.14, both are bugfix, can be cherry pick cleanly. The patch from Tianyu should close bug below, also included in 3.16 https://bugzilla.kernel.org/show_bug.cgi?id=198991 Eric Biggers (1): KVM/x86: remove WARN_ON() for when vm_munmap() fails Tianyu Lan (1): KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs() arch/x86/kvm/x86.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) -- 2.7.4

7 years, 3 months

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror