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

Re: [PATCH] kbuild: Handle builtin dtb files containing hyphens

by Masahiro Yamada

2018-03-08 16:09 GMT+09:00 James Hogan <jhogan(a)kernel.org>: > On Wed, Mar 07, 2018 at 03:19:11PM -0800, Frank Rowand wrote: >> On 03/07/18 12:25, James Hogan wrote: >> > On Wed, Mar 07, 2018 at 12:11:41PM -0800, Frank Rowand wrote: >> >> On 03/07/18 06:06, James Hogan wrote: >> >>> Quite a lot of dts files have hyphens, but its only a problem on MIPS >> >>> where such files can be built into the kernel. For example when >> >>> CONFIG_DT_NETGEAR_CVG834G=y, or on BMIPS kernels when the dtbs target is >> >>> used (in the latter case it admitedly shouldn't really build all the >> >>> dtb.o files, but thats a separate issue). > >> > I'll keep the paragraph about MIPS and the example configuration though, >> > as I think its important information to reproduce the problem, and to >> > justify why it wouldn't be appropriate to just rename the files (which >> > was my first reaction). >> >> Other than the part that says "its only a problem on MIPS". That is >> pedantically correct because no other architecture (that I am aware >> of, not that I searched) currently has a devicetree source file name >> with a hyphen in it, where that file is compiled into the kernel as >> an asm file. But it is potentially a problem on any architecture >> to it is misleading to label it as MIPS only. > > Okay I'll reword to make it clearer and do a v2. > > Thanks > James The code looks good. If you send v2, I can shortly apply it to the fixes branch. If possible, I want to send a PR this weekend. -- Best Regards Masahiro Yamada

7 years, 6 months

2
2
0 0

[PATCH] ubi: Reject MLC NAND

by Richard Weinberger

While UBI and UBIFS seem to work at first sight with MLC NAND, you will most likely lose all your data upon a power-cut or due to read/write disturb. In order to protect users from bad surprises, refuse to attach to MLC NAND. Cc: stable(a)vger.kernel.org Signed-off-by: Richard Weinberger <richard(a)nod.at> --- drivers/mtd/ubi/build.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index e941395de3ae..753494e042d5 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -854,6 +854,17 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num, return -EINVAL; } + /* + * Both UBI and UBIFS have been designed for SLC NAND and NOR flashes. + * MLC NAND is different and needs special care, otherwise UBI or UBIFS + * will die soon and you will lose all your data. + */ + if (mtd->type == MTD_MLCNANDFLASH) { + pr_err("ubi: refuse attaching mtd%d - MLC NAND is not supported\n", + mtd->index); + return -EINVAL; + } + if (ubi_num == UBI_DEV_NUM_AUTO) { /* Search for an empty slot in the @ubi_devices array */ for (ubi_num = 0; ubi_num < UBI_MAX_DEVICES; ubi_num++) -- 2.13.6

7 years, 6 months

4
6
0 0

[RFC] mmc: block: fix updating ext_csd caches on ioctl call

by Bastian Stender

PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the currently active partition in mmc_blk_data->part_curr. These caches do not always reflect changes if the ioctl call modifies the PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE. Write the PARTITION_CONFIG value extracted from the ioctl call to the cache and update the currently active partition accordingly. This ensures that the user space cannot change the values behind the kernel's back. The next call to mmc_blk_part_switch() will operate on the data set by the ioctl and reflect the changes appropriately. Signed-off-by: Bastian Stender <bst(a)pengutronix.de> Signed-off-by: Jan Luebbe <jlu(a)pengutronix.de> Cc: stable(a)vger.kernel.org --- drivers/mmc/core/block.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index 20135a5de748..2cfb963d9f37 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -72,6 +72,7 @@ MODULE_ALIAS("mmc:block"); #define MMC_BLK_TIMEOUT_MS (10 * 1000) #define MMC_SANITIZE_REQ_TIMEOUT 240000 #define MMC_EXTRACT_INDEX_FROM_ARG(x) ((x & 0x00FF0000) >> 16) +#define MMC_EXTRACT_VALUE_FROM_ARG(x) ((x & 0x0000FF00) >> 8) #define mmc_req_rel_wr(req) ((req->cmd_flags & REQ_FUA) && \ (rq_data_dir(req) == WRITE)) @@ -586,6 +587,24 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md, return data.error; } + /* + * Make sure the cache of the PARTITION_CONFIG register and + * PARTITION_ACCESS bits is updated in case the ioctl ext_csd write + * changed it successfully. + */ + if ((MMC_EXTRACT_INDEX_FROM_ARG(cmd.arg) == EXT_CSD_PART_CONFIG) && + (cmd.opcode == MMC_SWITCH)) { + struct mmc_blk_data *main_md = dev_get_drvdata(&card->dev); + u8 value = MMC_EXTRACT_VALUE_FROM_ARG(cmd.arg); + + /* + * Update cache so the next mmc_blk_part_switch call operates + * on up-to-date data. + */ + card->ext_csd.part_config = value; + main_md->part_curr = value & EXT_CSD_PART_CONFIG_ACC_MASK; + } + /* * According to the SD specs, some commands require a delay after * issuing the command. -- 2.16.1

7 years, 6 months

1
1
0 0

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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 months

3
4
0 0

[PATCH] kbuild: Handle builtin dtb files containing hyphens

by James Hogan

On dtb files which contain hyphens, the dt_S_dtb command to build the dtb.S files (which allow DTB files to be built into the kernel) results in errors like the following: bcm3368-netgear-cvg834g.dtb.S: Assembler messages: bcm3368-netgear-cvg834g.dtb.S:5: Error: : no such section bcm3368-netgear-cvg834g.dtb.S:5: Error: junk at end of line, first unrecognized character is `-' bcm3368-netgear-cvg834g.dtb.S:6: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_begin:' bcm3368-netgear-cvg834g.dtb.S:8: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_end:' bcm3368-netgear-cvg834g.dtb.S:9: Error: : no such section bcm3368-netgear-cvg834g.dtb.S:9: Error: junk at end of line, first unrecognized character is `-' This is due to the hyphen being used in symbol names. Replace all hyphens with underscores in the dt_S_dtb command to avoid this problem. Quite a lot of dts files have hyphens, but its only a problem on MIPS where such files can be built into the kernel. For example when CONFIG_DT_NETGEAR_CVG834G=y, or on BMIPS kernels when the dtbs target is used (in the latter case it admitedly shouldn't really build all the dtb.o files, but thats a separate issue). Fixes: 695835511f96 ("MIPS: BMIPS: rename bcm96358nb4ser to bcm6358-neufbox4-sercom") Signed-off-by: James Hogan <jhogan(a)kernel.org> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Frank Rowand <frowand.list(a)gmail.com> Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com> Cc: Michal Marek <michal.lkml(a)markovi.net> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Kevin Cernekee <cernekee(a)gmail.com> Cc: devicetree(a)vger.kernel.org Cc: linux-kbuild(a)vger.kernel.org Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # 4.9+ --- scripts/Makefile.lib | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 5589bae34af6..a6f538b31ad6 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -297,11 +297,11 @@ cmd_dt_S_dtb= \ echo '\#include <asm-generic/vmlinux.lds.h>'; \ echo '.section .dtb.init.rodata,"a"'; \ echo '.balign STRUCT_ALIGNMENT'; \ - echo '.global __dtb_$(*F)_begin'; \ - echo '__dtb_$(*F)_begin:'; \ + echo '.global __dtb_$(subst -,_,$(*F))_begin'; \ + echo '__dtb_$(subst -,_,$(*F))_begin:'; \ echo '.incbin "$<" '; \ - echo '__dtb_$(*F)_end:'; \ - echo '.global __dtb_$(*F)_end'; \ + echo '__dtb_$(subst -,_,$(*F))_end:'; \ + echo '.global __dtb_$(subst -,_,$(*F))_end'; \ echo '.balign STRUCT_ALIGNMENT'; \ ) > $@ -- 2.13.6

7 years, 6 months

2
2
0 0

[PATCH AUTOSEL for 3.18 01/53] usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control()

by Sasha Levin

From: Yuyang Du <yuyang.du(a)intel.com> [ Upstream commit 9f20dfb44d03745d0d3cef2ffb3abf8d8024fa61 ] This fixes the commit: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add SuperSpeed support"). In the case of ClearPortFeature and USB_PORT_FEAT_POWER, simply clear the right bit regardless of what the wValue is. Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Yuyang Du <yuyang.du(a)intel.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/usb/gadget/udc/dummy_hcd.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/usb/gadget/udc/dummy_hcd.c b/drivers/usb/gadget/udc/dummy_hcd.c index 783715a9e399..215441690d32 100644 --- a/drivers/usb/gadget/udc/dummy_hcd.c +++ b/drivers/usb/gadget/udc/dummy_hcd.c @@ -2001,16 +2001,13 @@ static int dummy_hub_control( } break; case USB_PORT_FEAT_POWER: - if (hcd->speed == HCD_USB3) { - if (dum_hcd->port_status & USB_PORT_STAT_POWER) - dev_dbg(dummy_dev(dum_hcd), - "power-off\n"); - } else - if (dum_hcd->port_status & - USB_SS_PORT_STAT_POWER) - dev_dbg(dummy_dev(dum_hcd), - "power-off\n"); - /* FALLS THROUGH */ + dev_dbg(dummy_dev(dum_hcd), "power-off\n"); + if (hcd->speed == HCD_USB3) + dum_hcd->port_status &= ~USB_SS_PORT_STAT_POWER; + else + dum_hcd->port_status &= ~USB_PORT_STAT_POWER; + set_link_state(dum_hcd); + break; default: dum_hcd->port_status &= ~(1 << wValue); set_link_state(dum_hcd); @@ -2181,14 +2178,13 @@ static int dummy_hub_control( if ((dum_hcd->port_status & USB_SS_PORT_STAT_POWER) != 0) { dum_hcd->port_status |= (1 << wValue); - set_link_state(dum_hcd); } } else if ((dum_hcd->port_status & USB_PORT_STAT_POWER) != 0) { dum_hcd->port_status |= (1 << wValue); - set_link_state(dum_hcd); } + set_link_state(dum_hcd); } break; case GetPortErrorCount: -- 2.14.1

7 years, 6 months

1
52
0 0

[PATCH AUTOSEL for 4.4 001/101] usb: dwc2: Make sure we disconnect the gadget state

by Sasha Levin

From: John Stultz <john.stultz(a)linaro.org> [ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ] I had seen some odd behavior with HiKey's usb-gadget interface that I finally seemed to have chased down. Basically every other time I plugged in the OTG port, the gadget interface would properly initialize. The other times, I'd get a big WARN_ON in dwc2_hsotg_init_fifo() about the fifo_map not being clear. Ends up if we don't disconnect the gadget state, the fifo-map doesn't get cleared properly, which causes WARN_ON messages and also results in the device not properly being setup as a gadget every other time the OTG port is connected. So this patch adds a call to dwc2_hsotg_disconnect() in the reset path so the state is properly cleared. With it, the gadget interface initializes properly on every plug in. Cc: Wei Xu <xuwei5(a)hisilicon.com> Cc: Guodong Xu <guodong.xu(a)linaro.org> Cc: Amit Pundir <amit.pundir(a)linaro.org> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: John Youn <johnyoun(a)synopsys.com> Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Chen Yu <chenyu56(a)huawei.com> Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: linux-usb(a)vger.kernel.org Acked-by: John Youn <johnyoun(a)synopsys.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/usb/dwc2/hcd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index 571c21727ff9..88bd950665fa 100644 --- a/drivers/usb/dwc2/hcd.c +++ b/drivers/usb/dwc2/hcd.c @@ -1385,6 +1385,7 @@ static void dwc2_conn_id_status_change(struct work_struct *work) dwc2_core_init(hsotg, false, -1); dwc2_enable_global_interrupts(hsotg); spin_lock_irqsave(&hsotg->lock, flags); + dwc2_hsotg_disconnect(hsotg); dwc2_hsotg_core_init_disconnected(hsotg, false); spin_unlock_irqrestore(&hsotg->lock, flags); dwc2_hsotg_core_connect(hsotg); -- 2.14.1

7 years, 6 months

1
100
0 0

Patch "platform/x86: dell-laptop: fix kbd_get_state's request value" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/x86: dell-laptop: fix kbd_get_state's request value to the 4.15-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: platform-x86-dell-laptop-fix-kbd_get_state-s-request-value.patch and it can be found in the queue-4.15 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 eca39e7f0cdb9bde4003a29149fa695e876c6f73 Mon Sep 17 00:00:00 2001 From: Laszlo Toth <laszlth(a)gmail.com> Date: Tue, 13 Feb 2018 21:43:43 +0100 Subject: platform/x86: dell-laptop: fix kbd_get_state's request value MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Laszlo Toth <laszlth(a)gmail.com> commit eca39e7f0cdb9bde4003a29149fa695e876c6f73 upstream. Commit 9862b43624a5 ("platform/x86: dell-laptop: Allocate buffer on heap rather than globally") broke one request, changed it back to the original value. Tested on a Dell E6540, backlight came back. Fixes: 9862b43624a5 ("platform/x86: dell-laptop: Allocate buffer on heap rather than globally") Signed-off-by: Laszlo Toth <laszlth(a)gmail.com> Reviewed-by: Pali Rohár <pali.rohar(a)gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)dell.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/dell-laptop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/platform/x86/dell-laptop.c +++ b/drivers/platform/x86/dell-laptop.c @@ -1254,7 +1254,7 @@ static int kbd_get_state(struct kbd_stat struct calling_interface_buffer buffer; int ret; - dell_fill_request(&buffer, 0, 0, 0, 0); + dell_fill_request(&buffer, 0x1, 0, 0, 0); ret = dell_send_request(&buffer, CLASS_KBD_BACKLIGHT, SELECT_KBD_BACKLIGHT); if (ret) Patches currently in stable-queue which might be from laszlth(a)gmail.com are queue-4.15/platform-x86-dell-laptop-fix-kbd_get_state-s-request-value.patch

7 years, 6 months

1
0
0 0

Re: [PATCH] ubi: Reject MLC NAND

by Pavel Machek

On Wed 2018-03-07 22:11:13, David Woodhouse wrote: > > > On Wed, 2018-03-07 at 14:08 -0800, Steve deRosier wrote: > > > > To clarify one thing: the reason for this is MLC has actually never > > been supported, nor worked properly. The fact that it kinda worked was > > incidental and the cause of major problems for people due to that not > > being clear. This patch only makes it explicit and avoids people > > mistakenly trying to use UBIFS on MLC flash and risking their data and > > products. To me, that's what's important. > > > > This is an important patch, even if all it does is keep people from > > loosing data. It also changes the conversation from "I have a > > corrupted UBIFS device, BTW it's on MLC..." to "What can we do to get > > UBIFS to work on MLC". Well, for -stable I'd suggest printk(KERN_ALERT ...) but keep the system running. > This is a bug fix. > > UBI on MLC never worked. It was a bug that we ever permitted it. This > is now fixed. Yeah, well, so lets say I have a working hardware (maybe using read-only UBI on MLC), update to next stable kernel, and now kernel refuses to see the partition. I'll certainly not consider this patch a bug fix. Removing support for hardware that "only works by mistake" may be good idea, but maybe it is slightly too surprising for a -stable. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

7 years, 6 months

3
2
0 0

Re: [PATCH] kbuild: Handle builtin dtb files containing hyphens

by Frank Rowand

On 03/07/18 12:25, James Hogan wrote: > On Wed, Mar 07, 2018 at 12:11:41PM -0800, Frank Rowand wrote: >> I initially misread the patch description (and imagined an entirely >> different problem). >> >> >> On 03/07/18 06:06, James Hogan wrote: >>> On dtb files which contain hyphens, the dt_S_dtb command to build the> dtb.S files (which allow DTB files to be built into the kernel) results> in errors like the following:> > bcm3368-netgear-cvg834g.dtb.S: Assembler messages:> bcm3368-netgear-cvg834g.dtb.S:5: Error: : no such section> bcm3368-netgear-cvg834g.dtb.S:5: Error: junk at end of line, first unrecognized character is `-'> bcm3368-netgear-cvg834g.dtb.S:6: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_begin:'> bcm3368-netgear-cvg834g.dtb.S:8: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_end:'> bcm3368-netgear-cvg834g.dtb.S:9: Error: : no such section> bcm3368-netgear-cvg834g.dtb.S:9: Error: junk at end of line, first unrecognized character is `-' >> Please replace the following section: >> >>> This is due to the hyphen being used in symbol names. Replace all >>> hyphens >>> with underscores in the dt_S_dtb command to avoid this problem. >>> >>> Quite a lot of dts files have hyphens, but its only a problem on MIPS >>> where such files can be built into the kernel. For example when >>> CONFIG_DT_NETGEAR_CVG834G=y, or on BMIPS kernels when the dtbs target is >>> used (in the latter case it admitedly shouldn't really build all the >>> dtb.o files, but thats a separate issue). >> >> with: >> >> cmd_dt_S_dtb constructs the assembly source to incorporate a devicetree >> FDT (that is, the .dtb file) as binary data in the kernel image. >> This assembly source contains labels before and after the binary data. >> The label names incorporate the file name of the corresponding .dtb >> file. Hyphens are not legal characters in labels, so transform all >> hyphens from the file name to underscores when constructing the labels. > > Thanks, that is clearer. > > I'll keep the paragraph about MIPS and the example configuration though, > as I think its important information to reproduce the problem, and to > justify why it wouldn't be appropriate to just rename the files (which > was my first reaction). Other than the part that says "its only a problem on MIPS". That is pedantically correct because no other architecture (that I am aware of, not that I searched) currently has a devicetree source file name with a hyphen in it, where that file is compiled into the kernel as an asm file. But it is potentially a problem on any architecture to it is misleading to label it as MIPS only. > >> Reviewed-by: Frank Rowand <frowand.list(a)gmail.com> > > Thanks > James >

7 years, 6 months

1
0
0 0

Re: [PATCH] ubi: Reject MLC NAND

by Boris Brezillon

On Wed, 7 Mar 2018 22:43:42 +0100 Pavel Machek <pavel(a)ucw.cz> wrote: > On Wed 2018-03-07 09:01:16, Richard Weinberger wrote: > > Pavel, > > > > Am Mittwoch, 7. März 2018, 00:18:05 CET schrieb Pavel Machek: > > > On Sat 2018-03-03 11:45:54, Richard Weinberger wrote: > > > > While UBI and UBIFS seem to work at first sight with MLC NAND, you will > > > > most likely lose all your data upon a power-cut or due to read/write > > > > disturb. > > > > In order to protect users from bad surprises, refuse to attach to MLC > > > > NAND. > > > > > > > > Cc: stable(a)vger.kernel.org > > > > > > That sounds like _really_ bad idea for stable. All it does is it > > > removes support for hardware that somehow works. > > > > MLC is not supported and does not work. Full stop. > > If someone manages to get it somehow work, either with hardware or software > > hacks they are on their own. > > Having it in stable is the only chance we have to get it into vendor > > kernels. > > Can you show how it meets the stable kernel criteria? They are > documented in tree. This should not be in stable. > > And I'd like to see changelog improved. Real reason MLC is not > supported is upper/lower page parts on MLC. And real fix to work with > bigger pages in UBI. Come on! Don't you think this would have been fixed already if it was that easy?! Have you looked at an MLC datasheet to see how paired pages are combined? If you had you would now that paired pages are almost all the time not contiguous, thus preventing the trick you're suggesting here. Please document yourself before doing such presumptuous statements (you can have a look at these slides if you want some details about why this is not so simple [1]). I'm definitely not saying supporting MLC NANDs in Linux is impossible, and if you're interested in working on this topic I'd be happy to help. But please don't block this patch without understanding what supporting MLC NANDs implies. [1]https://events.static.linuxfound.org/sites/events/files/slides/ubi-mlc.pdf -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com

7 years, 6 months

1
0
0 0

Re: [PATCH] ubi: Reject MLC NAND

by Steve deRosier

Hi Pavel, On Wed, Mar 7, 2018 at 1:43 PM, Pavel Machek <pavel(a)ucw.cz> wrote: > On Wed 2018-03-07 09:01:16, Richard Weinberger wrote: >> Pavel, >> >> Am Mittwoch, 7. März 2018, 00:18:05 CET schrieb Pavel Machek: >> > On Sat 2018-03-03 11:45:54, Richard Weinberger wrote: >> > > While UBI and UBIFS seem to work at first sight with MLC NAND, you will >> > > most likely lose all your data upon a power-cut or due to read/write >> > > disturb. >> > > In order to protect users from bad surprises, refuse to attach to MLC >> > > NAND. >> > > >> > > Cc: stable(a)vger.kernel.org >> > >> > That sounds like _really_ bad idea for stable. All it does is it >> > removes support for hardware that somehow works. >> >> MLC is not supported and does not work. Full stop. >> If someone manages to get it somehow work, either with hardware or software >> hacks they are on their own. >> Having it in stable is the only chance we have to get it into vendor >> kernels. > > Can you show how it meets the stable kernel criteria? They are > documented in tree. This should not be in stable. > > And I'd like to see changelog improved. Real reason MLC is not > supported is upper/lower page parts on MLC. And real fix to work with > bigger pages in UBI. > To clarify one thing: the reason for this is MLC has actually never been supported, nor worked properly. The fact that it kinda worked was incidental and the cause of major problems for people due to that not being clear. This patch only makes it explicit and avoids people mistakenly trying to use UBIFS on MLC flash and risking their data and products. To me, that's what's important. This is an important patch, even if all it does is keep people from loosing data. It also changes the conversation from "I have a corrupted UBIFS device, BTW it's on MLC..." to "What can we do to get UBIFS to work on MLC". I don't know what the stable criteria is with re: to this patch. But what I do know is if it doesn't go back into the various stables, there will be manufacturers who will continue to try to use UBIFS on MLC in ignorance for the next several years until the current stable kernels EOL, despite there being a known patch that would make it immediately obvious they shouldn't. Thanks, - Steve

7 years, 6 months

1
0
0 0

Re: [PATCH] staging: android: ashmem: Remove deadlock

by Greg Kroah-Hartman

On Wed, Mar 07, 2018 at 02:02:13PM -0800, Paul Lawrence wrote: > Great! We need to make sure this gets backported to 4.4 and 4.9, and to > 3.18 with the original dependency, please. That will happen when it lands in Linus's tree, which should be later this week if all goes well. thanks, greg k-h

7 years, 6 months

1
0
0 0

[PATCH 4.4,4.9] x86/apic/vector: Handle legacy irq data correctly

by Ben Hutchings

From: Thomas Gleixner <tglx(a)linutronix.de> The backport of upstream commit 45d55e7bac40 ("x86/apic/vector: Fix off by one in error path") missed to fixup the legacy interrupt data which is not longer available upstream. Handle legacy irq data correctly by clearing the legacy storage to prevent use after free. Fixes: 7fd133539289 ("x86/apic/vector: Fix off by one in error path") - 4.4.y Fixes: c557481a9491 ("x86/apic/vector: Fix off by one in error path") - 4.9.y Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> --- arch/x86/kernel/apic/vector.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c index a41e523536a2..592e260ba05b 100644 --- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -91,8 +91,12 @@ out_data: return NULL; } -static void free_apic_chip_data(struct apic_chip_data *data) +static void free_apic_chip_data(unsigned int virq, struct apic_chip_data *data) { +#ifdef CONFIG_X86_IO_APIC + if (virq < nr_legacy_irqs()) + legacy_irq_data[virq] = NULL; +#endif if (data) { free_cpumask_var(data->domain); free_cpumask_var(data->old_domain); @@ -316,11 +320,7 @@ static void x86_vector_free_irqs(struct irq_domain *domain, apic_data = irq_data->chip_data; irq_domain_reset_irq_data(irq_data); raw_spin_unlock_irqrestore(&vector_lock, flags); - free_apic_chip_data(apic_data); -#ifdef CONFIG_X86_IO_APIC - if (virq + i < nr_legacy_irqs()) - legacy_irq_data[virq + i] = NULL; -#endif + free_apic_chip_data(virq + i, apic_data); } } } @@ -361,7 +361,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq, err = assign_irq_vector_policy(virq + i, node, data, info); if (err) { irq_data->chip_data = NULL; - free_apic_chip_data(data); + free_apic_chip_data(virq + i, data); goto error; } } -- 2.15.0.rc0

7 years, 6 months

2
2
0 0

Patch "nvme-rdma: don't suppress send completions" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nvme-rdma: don't suppress send completions to the 4.14-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: nvme-rdma-don-t-suppress-send-completions.patch and it can be found in the queue-4.14 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 b4b591c87f2b0f4ebaf3a68d4f13873b241aa584 Mon Sep 17 00:00:00 2001 From: Sagi Grimberg <sagi(a)grimberg.me> Date: Thu, 23 Nov 2017 17:35:21 +0200 Subject: nvme-rdma: don't suppress send completions From: Sagi Grimberg <sagi(a)grimberg.me> commit b4b591c87f2b0f4ebaf3a68d4f13873b241aa584 upstream. The entire completions suppress mechanism is currently broken because the HCA might retry a send operation (due to dropped ack) after the nvme transaction has completed. In order to handle this, we signal all send completions and introduce a separate done handler for async events as they will be handled differently (as they don't include in-capsule data by definition). Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/host/rdma.c | 54 ++++++++++++----------------------------------- 1 file changed, 14 insertions(+), 40 deletions(-) --- a/drivers/nvme/host/rdma.c +++ b/drivers/nvme/host/rdma.c @@ -88,7 +88,6 @@ enum nvme_rdma_queue_flags { struct nvme_rdma_queue { struct nvme_rdma_qe *rsp_ring; - atomic_t sig_count; int queue_size; size_t cmnd_capsule_len; struct nvme_rdma_ctrl *ctrl; @@ -521,7 +520,6 @@ static int nvme_rdma_alloc_queue(struct queue->cmnd_capsule_len = sizeof(struct nvme_command); queue->queue_size = queue_size; - atomic_set(&queue->sig_count, 0); queue->cm_id = rdma_create_id(&init_net, nvme_rdma_cm_handler, queue, RDMA_PS_TCP, IB_QPT_RC); @@ -1232,21 +1230,9 @@ static void nvme_rdma_send_done(struct i nvme_end_request(rq, req->status, req->result); } -/* - * We want to signal completion at least every queue depth/2. This returns the - * largest power of two that is not above half of (queue size + 1) to optimize - * (avoid divisions). - */ -static inline bool nvme_rdma_queue_sig_limit(struct nvme_rdma_queue *queue) -{ - int limit = 1 << ilog2((queue->queue_size + 1) / 2); - - return (atomic_inc_return(&queue->sig_count) & (limit - 1)) == 0; -} - static int nvme_rdma_post_send(struct nvme_rdma_queue *queue, struct nvme_rdma_qe *qe, struct ib_sge *sge, u32 num_sge, - struct ib_send_wr *first, bool flush) + struct ib_send_wr *first) { struct ib_send_wr wr, *bad_wr; int ret; @@ -1255,31 +1241,12 @@ static int nvme_rdma_post_send(struct nv sge->length = sizeof(struct nvme_command), sge->lkey = queue->device->pd->local_dma_lkey; - qe->cqe.done = nvme_rdma_send_done; - wr.next = NULL; wr.wr_cqe = &qe->cqe; wr.sg_list = sge; wr.num_sge = num_sge; wr.opcode = IB_WR_SEND; - wr.send_flags = 0; - - /* - * Unsignalled send completions are another giant desaster in the - * IB Verbs spec: If we don't regularly post signalled sends - * the send queue will fill up and only a QP reset will rescue us. - * Would have been way to obvious to handle this in hardware or - * at least the RDMA stack.. - * - * Always signal the flushes. The magic request used for the flush - * sequencer is not allocated in our driver's tagset and it's - * triggered to be freed by blk_cleanup_queue(). So we need to - * always mark it as signaled to ensure that the "wr_cqe", which is - * embedded in request's payload, is not freed when __ib_process_cq() - * calls wr_cqe->done(). - */ - if (nvme_rdma_queue_sig_limit(queue) || flush) - wr.send_flags |= IB_SEND_SIGNALED; + wr.send_flags = IB_SEND_SIGNALED; if (first) first->next = &wr; @@ -1329,6 +1296,12 @@ static struct blk_mq_tags *nvme_rdma_tag return queue->ctrl->tag_set.tags[queue_idx - 1]; } +static void nvme_rdma_async_done(struct ib_cq *cq, struct ib_wc *wc) +{ + if (unlikely(wc->status != IB_WC_SUCCESS)) + nvme_rdma_wr_error(cq, wc, "ASYNC"); +} + static void nvme_rdma_submit_async_event(struct nvme_ctrl *arg, int aer_idx) { struct nvme_rdma_ctrl *ctrl = to_rdma_ctrl(arg); @@ -1350,10 +1323,12 @@ static void nvme_rdma_submit_async_event cmd->common.flags |= NVME_CMD_SGL_METABUF; nvme_rdma_set_sg_null(cmd); + sqe->cqe.done = nvme_rdma_async_done; + ib_dma_sync_single_for_device(dev, sqe->dma, sizeof(*cmd), DMA_TO_DEVICE); - ret = nvme_rdma_post_send(queue, sqe, &sge, 1, NULL, false); + ret = nvme_rdma_post_send(queue, sqe, &sge, 1, NULL); WARN_ON_ONCE(ret); } @@ -1639,7 +1614,6 @@ static blk_status_t nvme_rdma_queue_rq(s struct nvme_rdma_request *req = blk_mq_rq_to_pdu(rq); struct nvme_rdma_qe *sqe = &req->sqe; struct nvme_command *c = sqe->data; - bool flush = false; struct ib_device *dev; blk_status_t ret; int err; @@ -1668,13 +1642,13 @@ static blk_status_t nvme_rdma_queue_rq(s goto err; } + sqe->cqe.done = nvme_rdma_send_done; + ib_dma_sync_single_for_device(dev, sqe->dma, sizeof(struct nvme_command), DMA_TO_DEVICE); - if (req_op(rq) == REQ_OP_FLUSH) - flush = true; err = nvme_rdma_post_send(queue, sqe, req->sge, req->num_sge, - req->mr->need_inval ? &req->reg_wr.wr : NULL, flush); + req->mr->need_inval ? &req->reg_wr.wr : NULL); if (unlikely(err)) { nvme_rdma_unmap_data(queue, rq); goto err; Patches currently in stable-queue which might be from sagi(a)grimberg.me are queue-4.14/nvme-rdma-don-t-suppress-send-completions.patch

7 years, 6 months

1
0
0 0

[PATCH stable 4.14.y] nvme-rdma: don't suppress send completions

by Sagi Grimberg

The entire completions suppress mechanism is currently broken because the HCA might retry a send operation (due to dropped ack) after the nvme transaction has completed. In order to handle this, we signal all send completions and introduce a separate done handler for async events as they will be handled differently (as they don't include in-capsule data by definition). Cc: <stable(a)vger.kernel.org> # v4.14+ Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> --- drivers/nvme/host/rdma.c | 54 +++++++++++++----------------------------------- 1 file changed, 14 insertions(+), 40 deletions(-) diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c index 33d4431c2b4b..93a082e0bdd4 100644 --- a/drivers/nvme/host/rdma.c +++ b/drivers/nvme/host/rdma.c @@ -88,7 +88,6 @@ enum nvme_rdma_queue_flags { struct nvme_rdma_queue { struct nvme_rdma_qe *rsp_ring; - atomic_t sig_count; int queue_size; size_t cmnd_capsule_len; struct nvme_rdma_ctrl *ctrl; @@ -521,7 +520,6 @@ static int nvme_rdma_alloc_queue(struct nvme_rdma_ctrl *ctrl, queue->cmnd_capsule_len = sizeof(struct nvme_command); queue->queue_size = queue_size; - atomic_set(&queue->sig_count, 0); queue->cm_id = rdma_create_id(&init_net, nvme_rdma_cm_handler, queue, RDMA_PS_TCP, IB_QPT_RC); @@ -1232,21 +1230,9 @@ static void nvme_rdma_send_done(struct ib_cq *cq, struct ib_wc *wc) nvme_end_request(rq, req->status, req->result); } -/* - * We want to signal completion at least every queue depth/2. This returns the - * largest power of two that is not above half of (queue size + 1) to optimize - * (avoid divisions). - */ -static inline bool nvme_rdma_queue_sig_limit(struct nvme_rdma_queue *queue) -{ - int limit = 1 << ilog2((queue->queue_size + 1) / 2); - - return (atomic_inc_return(&queue->sig_count) & (limit - 1)) == 0; -} - static int nvme_rdma_post_send(struct nvme_rdma_queue *queue, struct nvme_rdma_qe *qe, struct ib_sge *sge, u32 num_sge, - struct ib_send_wr *first, bool flush) + struct ib_send_wr *first) { struct ib_send_wr wr, *bad_wr; int ret; @@ -1255,31 +1241,12 @@ static int nvme_rdma_post_send(struct nvme_rdma_queue *queue, sge->length = sizeof(struct nvme_command), sge->lkey = queue->device->pd->local_dma_lkey; - qe->cqe.done = nvme_rdma_send_done; - wr.next = NULL; wr.wr_cqe = &qe->cqe; wr.sg_list = sge; wr.num_sge = num_sge; wr.opcode = IB_WR_SEND; - wr.send_flags = 0; - - /* - * Unsignalled send completions are another giant desaster in the - * IB Verbs spec: If we don't regularly post signalled sends - * the send queue will fill up and only a QP reset will rescue us. - * Would have been way to obvious to handle this in hardware or - * at least the RDMA stack.. - * - * Always signal the flushes. The magic request used for the flush - * sequencer is not allocated in our driver's tagset and it's - * triggered to be freed by blk_cleanup_queue(). So we need to - * always mark it as signaled to ensure that the "wr_cqe", which is - * embedded in request's payload, is not freed when __ib_process_cq() - * calls wr_cqe->done(). - */ - if (nvme_rdma_queue_sig_limit(queue) || flush) - wr.send_flags |= IB_SEND_SIGNALED; + wr.send_flags = IB_SEND_SIGNALED; if (first) first->next = &wr; @@ -1329,6 +1296,12 @@ static struct blk_mq_tags *nvme_rdma_tagset(struct nvme_rdma_queue *queue) return queue->ctrl->tag_set.tags[queue_idx - 1]; } +static void nvme_rdma_async_done(struct ib_cq *cq, struct ib_wc *wc) +{ + if (unlikely(wc->status != IB_WC_SUCCESS)) + nvme_rdma_wr_error(cq, wc, "ASYNC"); +} + static void nvme_rdma_submit_async_event(struct nvme_ctrl *arg, int aer_idx) { struct nvme_rdma_ctrl *ctrl = to_rdma_ctrl(arg); @@ -1350,10 +1323,12 @@ static void nvme_rdma_submit_async_event(struct nvme_ctrl *arg, int aer_idx) cmd->common.flags |= NVME_CMD_SGL_METABUF; nvme_rdma_set_sg_null(cmd); + sqe->cqe.done = nvme_rdma_async_done; + ib_dma_sync_single_for_device(dev, sqe->dma, sizeof(*cmd), DMA_TO_DEVICE); - ret = nvme_rdma_post_send(queue, sqe, &sge, 1, NULL, false); + ret = nvme_rdma_post_send(queue, sqe, &sge, 1, NULL); WARN_ON_ONCE(ret); } @@ -1639,7 +1614,6 @@ static blk_status_t nvme_rdma_queue_rq(struct blk_mq_hw_ctx *hctx, struct nvme_rdma_request *req = blk_mq_rq_to_pdu(rq); struct nvme_rdma_qe *sqe = &req->sqe; struct nvme_command *c = sqe->data; - bool flush = false; struct ib_device *dev; blk_status_t ret; int err; @@ -1668,13 +1642,13 @@ static blk_status_t nvme_rdma_queue_rq(struct blk_mq_hw_ctx *hctx, goto err; } + sqe->cqe.done = nvme_rdma_send_done; + ib_dma_sync_single_for_device(dev, sqe->dma, sizeof(struct nvme_command), DMA_TO_DEVICE); - if (req_op(rq) == REQ_OP_FLUSH) - flush = true; err = nvme_rdma_post_send(queue, sqe, req->sge, req->num_sge, - req->mr->need_inval ? &req->reg_wr.wr : NULL, flush); + req->mr->need_inval ? &req->reg_wr.wr : NULL); if (unlikely(err)) { nvme_rdma_unmap_data(queue, rq); goto err; -- 2.14.1

7 years, 6 months

3
3
0 0

Patch "netlink: put module reference if dump start fails" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netlink: put module reference if dump start fails to the 4.9-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: netlink-put-module-reference-if-dump-start-fails.patch and it can be found in the queue-4.9 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 b87b6194be631c94785fe93398651e804ed43e28 Mon Sep 17 00:00:00 2001 From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Date: Wed, 21 Feb 2018 04:41:59 +0100 Subject: netlink: put module reference if dump start fails From: Jason A. Donenfeld <Jason(a)zx2c4.com> commit b87b6194be631c94785fe93398651e804ed43e28 upstream. Before, if cb->start() failed, the module reference would never be put, because cb->cb_running is intentionally false at this point. Users are generally annoyed by this because they can no longer unload modules that leak references. Also, it may be possible to tediously wrap a reference counter back to zero, especially since module.c still uses atomic_inc instead of refcount_inc. This patch expands the error path to simply call module_put if cb->start() fails. Fixes: 41c87425a1ac ("netlink: do not set cb_running if dump's start() errs") Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netlink/af_netlink.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -2258,7 +2258,7 @@ int __netlink_dump_start(struct sock *ss if (cb->start) { ret = cb->start(cb); if (ret) - goto error_unlock; + goto error_put; } nlk->cb_running = true; @@ -2278,6 +2278,8 @@ int __netlink_dump_start(struct sock *ss */ return -EINTR; +error_put: + module_put(control->module); error_unlock: sock_put(sk); mutex_unlock(nlk->cb_mutex); Patches currently in stable-queue which might be from Jason(a)zx2c4.com are queue-4.9/netlink-put-module-reference-if-dump-start-fails.patch

7 years, 6 months

1
0
0 0

Patch "netlink: put module reference if dump start fails" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netlink: put module reference if dump start fails to the 4.14-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: netlink-put-module-reference-if-dump-start-fails.patch and it can be found in the queue-4.14 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 foo@baz Tue Mar 6 19:02:12 PST 2018 From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Date: Wed, 21 Feb 2018 04:41:59 +0100 Subject: netlink: put module reference if dump start fails From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> [ Upstream commit b87b6194be631c94785fe93398651e804ed43e28 ] Before, if cb->start() failed, the module reference would never be put, because cb->cb_running is intentionally false at this point. Users are generally annoyed by this because they can no longer unload modules that leak references. Also, it may be possible to tediously wrap a reference counter back to zero, especially since module.c still uses atomic_inc instead of refcount_inc. This patch expands the error path to simply call module_put if cb->start() fails. Fixes: 41c87425a1ac ("netlink: do not set cb_running if dump's start() errs") Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netlink/af_netlink.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -2276,7 +2276,7 @@ int __netlink_dump_start(struct sock *ss if (cb->start) { ret = cb->start(cb); if (ret) - goto error_unlock; + goto error_put; } nlk->cb_running = true; @@ -2296,6 +2296,8 @@ int __netlink_dump_start(struct sock *ss */ return -EINTR; +error_put: + module_put(control->module); error_unlock: sock_put(sk); mutex_unlock(nlk->cb_mutex); Patches currently in stable-queue which might be from Jason(a)zx2c4.com are queue-4.14/netlink-put-module-reference-if-dump-start-fails.patch

7 years, 6 months

3
2
0 0

Patch "x86/speculation: Use Indirect Branch Prediction Barrier in context switch" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/speculation: Use Indirect Branch Prediction Barrier in context switch to the 4.9-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: x86-speculation-use-indirect-branch-prediction-barrier-in-context-switch.patch and it can be found in the queue-4.9 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 18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7 Mon Sep 17 00:00:00 2001 From: Tim Chen <tim.c.chen(a)linux.intel.com> Date: Mon, 29 Jan 2018 22:04:47 +0000 Subject: x86/speculation: Use Indirect Branch Prediction Barrier in context switch MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Tim Chen <tim.c.chen(a)linux.intel.com> commit 18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7 upstream. Flush indirect branches when switching into a process that marked itself non dumpable. This protects high value processes like gpg better, without having too high performance overhead. If done naïvely, we could switch to a kernel idle thread and then back to the original process, such as: process A -> idle -> process A In such scenario, we do not have to do IBPB here even though the process is non-dumpable, as we are switching back to the same process after a hiatus. To avoid the redundant IBPB, which is expensive, we track the last mm user context ID. The cost is to have an extra u64 mm context id to track the last mm we were using before switching to the init_mm used by idle. Avoiding the extra IBPB is probably worth the extra memory for this common scenario. For those cases where tlb_defer_switch_to_init_mm() returns true (non PCID), lazy tlb will defer switch to init_mm, so we will not be changing the mm for the process A -> idle -> process A switch. So IBPB will be skipped for this case. Thanks to the reviewers and Andy Lutomirski for the suggestion of using ctx_id which got rid of the problem of mm pointer recycling. Signed-off-by: Tim Chen <tim.c.chen(a)linux.intel.com> Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: ak(a)linux.intel.com Cc: karahmed(a)amazon.de Cc: arjan(a)linux.intel.com Cc: torvalds(a)linux-foundation.org Cc: linux(a)dominikbrodowski.net Cc: peterz(a)infradead.org Cc: bp(a)alien8.de Cc: luto(a)kernel.org Cc: pbonzini(a)redhat.com Link: https://lkml.kernel.org/r/1517263487-3708-1-git-send-email-dwmw@amazon.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/tlbflush.h | 2 ++ arch/x86/mm/tlb.c | 31 +++++++++++++++++++++++++++++++ 2 files changed, 33 insertions(+) --- a/arch/x86/include/asm/tlbflush.h +++ b/arch/x86/include/asm/tlbflush.h @@ -68,6 +68,8 @@ static inline void invpcid_flush_all_non struct tlb_state { struct mm_struct *active_mm; int state; + /* last user mm's ctx id */ + u64 last_ctx_id; /* * Access to this CR4 shadow and to H/W CR4 is protected by --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -10,6 +10,7 @@ #include <asm/tlbflush.h> #include <asm/mmu_context.h> +#include <asm/nospec-branch.h> #include <asm/cache.h> #include <asm/apic.h> #include <asm/uv/uv.h> @@ -106,6 +107,28 @@ void switch_mm_irqs_off(struct mm_struct unsigned cpu = smp_processor_id(); if (likely(prev != next)) { + u64 last_ctx_id = this_cpu_read(cpu_tlbstate.last_ctx_id); + + /* + * Avoid user/user BTB poisoning by flushing the branch + * predictor when switching between processes. This stops + * one process from doing Spectre-v2 attacks on another. + * + * As an optimization, flush indirect branches only when + * switching into processes that disable dumping. This + * protects high value processes like gpg, without having + * too high performance overhead. IBPB is *expensive*! + * + * This will not flush branches when switching into kernel + * threads. It will also not flush if we switch to idle + * thread and back to the same process. It will flush if we + * switch to a different non-dumpable process. + */ + if (tsk && tsk->mm && + tsk->mm->context.ctx_id != last_ctx_id && + get_dumpable(tsk->mm) != SUID_DUMP_USER) + indirect_branch_prediction_barrier(); + if (IS_ENABLED(CONFIG_VMAP_STACK)) { /* * If our current stack is in vmalloc space and isn't @@ -120,6 +143,14 @@ void switch_mm_irqs_off(struct mm_struct set_pgd(pgd, init_mm.pgd[stack_pgd_index]); } + /* + * Record last user mm's context id, so we can avoid + * flushing branch buffer with IBPB if we switch back + * to the same user. + */ + if (next != &init_mm) + this_cpu_write(cpu_tlbstate.last_ctx_id, next->context.ctx_id); + this_cpu_write(cpu_tlbstate.state, TLBSTATE_OK); this_cpu_write(cpu_tlbstate.active_mm, next); Patches currently in stable-queue which might be from tim.c.chen(a)linux.intel.com are queue-4.9/x86-speculation-use-indirect-branch-prediction-barrier-in-context-switch.patch queue-4.9/x86-mm-give-each-mm-tlb-flush-generation-a-unique-id.patch

7 years, 6 months

1
0
0 0

Patch "md: only allow remove_and_add_spares when no sync_thread running." has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled md: only allow remove_and_add_spares when no sync_thread running. to the 4.9-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: md-only-allow-remove_and_add_spares-when-no-sync_thread-running.patch and it can be found in the queue-4.9 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 39772f0a7be3b3dc26c74ea13fe7847fd1522c8b Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.com> Date: Sat, 3 Feb 2018 09:19:30 +1100 Subject: md: only allow remove_and_add_spares when no sync_thread running. From: NeilBrown <neilb(a)suse.com> commit 39772f0a7be3b3dc26c74ea13fe7847fd1522c8b upstream. The locking protocols in md assume that a device will never be removed from an array during resync/recovery/reshape. When that isn't happening, rcu or reconfig_mutex is needed to protect an rdev pointer while taking a refcount. When it is happening, that protection isn't needed. Unfortunately there are cases were remove_and_add_spares() is called when recovery might be happening: is state_store(), slot_store() and hot_remove_disk(). In each case, this is just an optimization, to try to expedite removal from the personality so the device can be removed from the array. If resync etc is happening, we just have to wait for md_check_recover to find a suitable time to call remove_and_add_spares(). This optimization and not essential so it doesn't matter if it fails. So change remove_and_add_spares() to abort early if resync/recovery/reshape is happening, unless it is called from md_check_recovery() as part of a newly started recovery. The parameter "this" is only NULL when called from md_check_recovery() so when it is NULL, there is no need to abort. As this can result in a NULL dereference, the fix is suitable for -stable. cc: yuyufen <yuyufen(a)huawei.com> Cc: Tomasz Majchrzak <tomasz.majchrzak(a)intel.com> Fixes: 8430e7e0af9a ("md: disconnect device from personality before trying to remove it.") Cc: stable(a)ver.kernel.org (v4.8+) Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Shaohua Li <sh.li(a)alibaba-inc.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/md.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -8224,6 +8224,10 @@ static int remove_and_add_spares(struct int removed = 0; bool remove_some = false; + if (this && test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) + /* Mustn't remove devices when resync thread is running */ + return 0; + rdev_for_each(rdev, mddev) { if ((this == NULL || rdev == this) && rdev->raid_disk >= 0 && Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.9/md-only-allow-remove_and_add_spares-when-no-sync_thread-running.patch

7 years, 6 months

1
0
0 0

Patch "dm io: fix duplicate bio completion due to missing ref count" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dm io: fix duplicate bio completion due to missing ref count to the 4.9-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: dm-io-fix-duplicate-bio-completion-due-to-missing-ref-count.patch and it can be found in the queue-4.9 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 feb7695fe9fb83084aa29de0094774f4c9d4c9fc Mon Sep 17 00:00:00 2001 From: Mike Snitzer <snitzer(a)redhat.com> Date: Tue, 20 Jun 2017 19:14:30 -0400 Subject: dm io: fix duplicate bio completion due to missing ref count From: Mike Snitzer <snitzer(a)redhat.com> commit feb7695fe9fb83084aa29de0094774f4c9d4c9fc upstream. If only a subset of the devices associated with multiple regions support a given special operation (eg. DISCARD) then the dec_count() that is used to set error for the region must increment the io->count. Otherwise, when the dec_count() is called it can cause the dm-io caller's bio to be completed multiple times. As was reported against the dm-mirror target that had mirror legs with a mix of discard capabilities. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=196077 Reported-by: Zhang Yi <yizhan(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/dm-io.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/md/dm-io.c +++ b/drivers/md/dm-io.c @@ -302,6 +302,7 @@ static void do_region(int op, int op_fla special_cmd_max_sectors = q->limits.max_write_same_sectors; if ((op == REQ_OP_DISCARD || op == REQ_OP_WRITE_SAME) && special_cmd_max_sectors == 0) { + atomic_inc(&io->count); dec_count(io, region, -EOPNOTSUPP); return; } Patches currently in stable-queue which might be from snitzer(a)redhat.com are queue-4.9/dm-io-fix-duplicate-bio-completion-due-to-missing-ref-count.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux to the 4.9-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: arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch and it can be found in the queue-4.9 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 74402055a2d3ec998a1ded599e86185a27d9bbf4 Mon Sep 17 00:00:00 2001 From: Adam Ford <aford173(a)gmail.com> Date: Thu, 25 Jan 2018 14:10:37 -0600 Subject: ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux From: Adam Ford <aford173(a)gmail.com> commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream. The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at time. This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz Fixes: 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo DM3730 devkit") Signed-off-by: Adam Ford <aford173(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi @@ -100,6 +100,8 @@ }; &i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins>; clock-frequency = <2600000>; twl: twl@48 { @@ -207,6 +209,12 @@ OMAP3_CORE1_IOPAD(0x21b8, PIN_INPUT | MUX_MODE0) /* hsusb0_data7.hsusb0_data7 */ >; }; + i2c1_pins: pinmux_i2c1_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */ + OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */ + >; + }; }; &uart2 { Patches currently in stable-queue which might be from aford173(a)gmail.com are queue-4.9/arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch queue-4.9/arm-dts-logicpd-som-lv-fix-i2c1-pinmux.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux to the 4.9-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: arm-dts-logicpd-som-lv-fix-i2c1-pinmux.patch and it can be found in the queue-4.9 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 84c7efd607e7fb6933920322086db64654f669b2 Mon Sep 17 00:00:00 2001 From: Adam Ford <aford173(a)gmail.com> Date: Sat, 27 Jan 2018 15:27:05 -0600 Subject: ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux From: Adam Ford <aford173(a)gmail.com> commit 84c7efd607e7fb6933920322086db64654f669b2 upstream. The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at times. This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") Signed-off-by: Adam Ford <aford173(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/logicpd-som-lv.dtsi | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/arch/arm/boot/dts/logicpd-som-lv.dtsi +++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi @@ -97,6 +97,8 @@ }; &i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins>; clock-frequency = <2600000>; twl: twl@48 { @@ -215,7 +217,12 @@ >; }; - + i2c1_pins: pinmux_i2c1_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */ + OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */ + >; + }; }; &omap3_pmx_wkup { Patches currently in stable-queue which might be from aford173(a)gmail.com are queue-4.9/arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch queue-4.9/arm-dts-logicpd-som-lv-fix-i2c1-pinmux.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux" 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 ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux 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: arm-dts-logicpd-torpedo-fix-i2c1-pinmux.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 74402055a2d3ec998a1ded599e86185a27d9bbf4 Mon Sep 17 00:00:00 2001 From: Adam Ford <aford173(a)gmail.com> Date: Thu, 25 Jan 2018 14:10:37 -0600 Subject: ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux From: Adam Ford <aford173(a)gmail.com> commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream. The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at time. This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz Fixes: 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo DM3730 devkit") Signed-off-by: Adam Ford <aford173(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi @@ -90,6 +90,8 @@ }; &i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins>; clock-frequency = <2600000>; twl: twl@48 { @@ -146,6 +148,12 @@ OMAP3630_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP | MUX_MODE2) /* etk_ctl.sdmmc3_cmd */ >; }; + i2c1_pins: pinmux_i2c1_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */ + OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */ + >; + }; }; #include "twl4030.dtsi" Patches currently in stable-queue which might be from aford173(a)gmail.com are queue-4.4/arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch

7 years, 6 months

1
0
0 0

Patch "powerpc/64s/radix: Boot-time NULL pointer protection using a guard-PID" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/64s/radix: Boot-time NULL pointer protection using a guard-PID to the 4.15-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: powerpc-64s-radix-boot-time-null-pointer-protection-using-a-guard-pid.patch and it can be found in the queue-4.15 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 eeb715c3e995fbdda0cc05e61216c6c5609bce66 Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Wed, 7 Feb 2018 11:20:02 +1000 Subject: powerpc/64s/radix: Boot-time NULL pointer protection using a guard-PID From: Nicholas Piggin <npiggin(a)gmail.com> commit eeb715c3e995fbdda0cc05e61216c6c5609bce66 upstream. This change restores and formalises the behaviour that access to NULL or other user addresses by the kernel during boot should fault rather than succeed and modify memory. This was inadvertently broken when fixing another bug, because it was previously not well defined and only worked by chance. powerpc/64s/radix uses high address bits to select an address space "quadrant", which determines which PID and LPID are used to translate the rest of the address (effective PID, effective LPID). The kernel mapping at 0xC... selects quadrant 3, which uses PID=0 and LPID=0. So the kernel page tables are installed in the PID 0 process table entry. An address at 0x0... selects quadrant 0, which uses PID=PIDR for translating the rest of the address (that is, it uses the value of the PIDR register as the effective PID). If PIDR=0, then the translation is performed with the PID 0 process table entry page tables. This is the kernel mapping, so we effectively get another copy of the kernel address space at 0. A NULL pointer access will access physical memory address 0. To prevent duplicating the kernel address space in quadrant 0, this patch allocates a guard PID containing no translations, and initializes PIDR with this during boot, before the MMU is switched on. Any kernel access to quadrant 0 will use this guard PID for translation and find no valid mappings, and therefore fault. After boot, this PID will be switchd away to user context PIDs, but those contain user mappings (and usually NULL pointer protection) rather than kernel mapping, which is much safer (and by design). It may be in future this is tightened further, which the guard PID could be used for. Commit 371b8044 ("powerpc/64s: Initialize ISAv3 MMU registers before setting partition table"), introduced this problem because it zeroes PIDR at boot. However previously the value was inherited from firmware or kexec, which is not robust and can be zero (e.g., mambo). Fixes: 371b80447ff3 ("powerpc/64s: Initialize ISAv3 MMU registers before setting partition table") Cc: stable(a)vger.kernel.org # v4.15+ Reported-by: Florian Weimer <fweimer(a)redhat.com> Tested-by: Mauricio Faria de Oliveira <mauricfo(a)linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> [mauricfo: backport to v4.15.7 (context line updates only) and re-test] Signed-off-by: Mauricio Faria de Oliveira <mauricfo(a)linux.vnet.ibm.com> Acked-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/pgtable-radix.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) --- a/arch/powerpc/mm/pgtable-radix.c +++ b/arch/powerpc/mm/pgtable-radix.c @@ -21,6 +21,7 @@ #include <asm/pgtable.h> #include <asm/pgalloc.h> +#include <asm/mmu_context.h> #include <asm/dma.h> #include <asm/machdep.h> #include <asm/mmu.h> @@ -334,6 +335,22 @@ static void __init radix_init_pgtable(vo "r" (TLBIEL_INVAL_SET_LPID), "r" (0)); asm volatile("eieio; tlbsync; ptesync" : : : "memory"); trace_tlbie(0, 0, TLBIEL_INVAL_SET_LPID, 0, 2, 1, 1); + + /* + * The init_mm context is given the first available (non-zero) PID, + * which is the "guard PID" and contains no page table. PIDR should + * never be set to zero because that duplicates the kernel address + * space at the 0x0... offset (quadrant 0)! + * + * An arbitrary PID that may later be allocated by the PID allocator + * for userspace processes must not be used either, because that + * would cause stale user mappings for that PID on CPUs outside of + * the TLB invalidation scheme (because it won't be in mm_cpumask). + * + * So permanently carve out one PID for the purpose of a guard PID. + */ + init_mm.context.id = mmu_base_pid; + mmu_base_pid++; } static void __init radix_init_partition_table(void) @@ -580,6 +597,8 @@ void __init radix__early_init_mmu(void) radix_init_iamr(); radix_init_pgtable(); + /* Switch to the guard PID before turning on MMU */ + radix__switch_mmu_context(NULL, &init_mm); } void radix__early_init_mmu_secondary(void) @@ -601,6 +620,7 @@ void radix__early_init_mmu_secondary(voi radix_init_amor(); } radix_init_iamr(); + radix__switch_mmu_context(NULL, &init_mm); } void radix__mmu_cleanup_all(void) Patches currently in stable-queue which might be from npiggin(a)gmail.com are queue-4.15/powerpc-64s-radix-boot-time-null-pointer-protection-using-a-guard-pid.patch

7 years, 6 months

1
0
0 0

Patch "md: only allow remove_and_add_spares when no sync_thread running." has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled md: only allow remove_and_add_spares when no sync_thread running. to the 4.15-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: md-only-allow-remove_and_add_spares-when-no-sync_thread-running.patch and it can be found in the queue-4.15 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 39772f0a7be3b3dc26c74ea13fe7847fd1522c8b Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.com> Date: Sat, 3 Feb 2018 09:19:30 +1100 Subject: md: only allow remove_and_add_spares when no sync_thread running. From: NeilBrown <neilb(a)suse.com> commit 39772f0a7be3b3dc26c74ea13fe7847fd1522c8b upstream. The locking protocols in md assume that a device will never be removed from an array during resync/recovery/reshape. When that isn't happening, rcu or reconfig_mutex is needed to protect an rdev pointer while taking a refcount. When it is happening, that protection isn't needed. Unfortunately there are cases were remove_and_add_spares() is called when recovery might be happening: is state_store(), slot_store() and hot_remove_disk(). In each case, this is just an optimization, to try to expedite removal from the personality so the device can be removed from the array. If resync etc is happening, we just have to wait for md_check_recover to find a suitable time to call remove_and_add_spares(). This optimization and not essential so it doesn't matter if it fails. So change remove_and_add_spares() to abort early if resync/recovery/reshape is happening, unless it is called from md_check_recovery() as part of a newly started recovery. The parameter "this" is only NULL when called from md_check_recovery() so when it is NULL, there is no need to abort. As this can result in a NULL dereference, the fix is suitable for -stable. cc: yuyufen <yuyufen(a)huawei.com> Cc: Tomasz Majchrzak <tomasz.majchrzak(a)intel.com> Fixes: 8430e7e0af9a ("md: disconnect device from personality before trying to remove it.") Cc: stable(a)ver.kernel.org (v4.8+) Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Shaohua Li <sh.li(a)alibaba-inc.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/md.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -8554,6 +8554,10 @@ static int remove_and_add_spares(struct int removed = 0; bool remove_some = false; + if (this && test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) + /* Mustn't remove devices when resync thread is running */ + return 0; + rdev_for_each(rdev, mddev) { if ((this == NULL || rdev == this) && rdev->raid_disk >= 0 && Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.15/md-only-allow-remove_and_add_spares-when-no-sync_thread-running.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux to the 4.15-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: arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch and it can be found in the queue-4.15 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 74402055a2d3ec998a1ded599e86185a27d9bbf4 Mon Sep 17 00:00:00 2001 From: Adam Ford <aford173(a)gmail.com> Date: Thu, 25 Jan 2018 14:10:37 -0600 Subject: ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux From: Adam Ford <aford173(a)gmail.com> commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream. The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at time. This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz Fixes: 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo DM3730 devkit") Signed-off-by: Adam Ford <aford173(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi @@ -104,6 +104,8 @@ }; &i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins>; clock-frequency = <2600000>; twl: twl@48 { @@ -211,6 +213,12 @@ OMAP3_CORE1_IOPAD(0x21b8, PIN_INPUT | MUX_MODE0) /* hsusb0_data7.hsusb0_data7 */ >; }; + i2c1_pins: pinmux_i2c1_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */ + OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */ + >; + }; }; &uart2 { Patches currently in stable-queue which might be from aford173(a)gmail.com are queue-4.15/arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch queue-4.15/arm-dts-logicpd-som-lv-fix-i2c1-pinmux.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux to the 4.15-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: arm-dts-logicpd-som-lv-fix-i2c1-pinmux.patch and it can be found in the queue-4.15 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 84c7efd607e7fb6933920322086db64654f669b2 Mon Sep 17 00:00:00 2001 From: Adam Ford <aford173(a)gmail.com> Date: Sat, 27 Jan 2018 15:27:05 -0600 Subject: ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux From: Adam Ford <aford173(a)gmail.com> commit 84c7efd607e7fb6933920322086db64654f669b2 upstream. The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at times. This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") Signed-off-by: Adam Ford <aford173(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/logicpd-som-lv.dtsi | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/arch/arm/boot/dts/logicpd-som-lv.dtsi +++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi @@ -98,6 +98,8 @@ }; &i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins>; clock-frequency = <2600000>; twl: twl@48 { @@ -216,7 +218,12 @@ >; }; - + i2c1_pins: pinmux_i2c1_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */ + OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */ + >; + }; }; &omap3_pmx_wkup { Patches currently in stable-queue which might be from aford173(a)gmail.com are queue-4.15/arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch queue-4.15/arm-dts-logicpd-som-lv-fix-i2c1-pinmux.patch

7 years, 6 months

1
0
0 0

Patch "ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530 to the 4.15-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: acpi-bus-parse-tables-as-term_list-for-dell-xps-9570-and-precision-m5530.patch and it can be found in the queue-4.15 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 36904703aeeeb6cd31993f1353c8325006229f9a Mon Sep 17 00:00:00 2001 From: Kai Heng Feng <kai.heng.feng(a)canonical.com> Date: Mon, 5 Feb 2018 13:19:24 +0800 Subject: ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530 From: Kai Heng Feng <kai.heng.feng(a)canonical.com> commit 36904703aeeeb6cd31993f1353c8325006229f9a upstream. The i2c touchpad on Dell XPS 9570 and Precision M5530 doesn't work out of box. The touchpad relies on its _INI method to update its _HID value from XXXX0000 to SYNA2393. Also, the _STA relies on value of I2CN to report correct status. Set acpi_gbl_parse_table_as_term_list so the value of I2CN can be correctly set up, and _INI can get run. The ACPI table in this machine is designed to get parsed this way. Also, change the quirk table to a more generic name. Link: https://bugzilla.kernel.org/show_bug.cgi?id=198515 Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/bus.c | 38 +++++++++++++++++++++++++++++++------- 1 file changed, 31 insertions(+), 7 deletions(-) --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -66,10 +66,37 @@ static int set_copy_dsdt(const struct dm return 0; } #endif +static int set_gbl_term_list(const struct dmi_system_id *id) +{ + acpi_gbl_parse_table_as_term_list = 1; + return 0; +} -static const struct dmi_system_id dsdt_dmi_table[] __initconst = { +static const struct dmi_system_id acpi_quirks_dmi_table[] __initconst = { + /* + * Touchpad on Dell XPS 9570/Precision M5530 doesn't work under I2C + * mode. + * https://bugzilla.kernel.org/show_bug.cgi?id=198515 + */ + { + .callback = set_gbl_term_list, + .ident = "Dell Precision M5530", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Precision M5530"), + }, + }, + { + .callback = set_gbl_term_list, + .ident = "Dell XPS 15 9570", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "XPS 15 9570"), + }, + }, /* * Invoke DSDT corruption work-around on all Toshiba Satellite. + * DSDT will be copied to memory. * https://bugzilla.kernel.org/show_bug.cgi?id=14679 */ { @@ -83,7 +110,7 @@ static const struct dmi_system_id dsdt_d {} }; #else -static const struct dmi_system_id dsdt_dmi_table[] __initconst = { +static const struct dmi_system_id acpi_quirks_dmi_table[] __initconst = { {} }; #endif @@ -1001,11 +1028,8 @@ void __init acpi_early_init(void) acpi_permanent_mmap = true; - /* - * If the machine falls into the DMI check table, - * DSDT will be copied to memory - */ - dmi_check_system(dsdt_dmi_table); + /* Check machine-specific quirks */ + dmi_check_system(acpi_quirks_dmi_table); status = acpi_reallocate_root_table(); if (ACPI_FAILURE(status)) { Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are queue-4.15/bluetooth-btusb-use-dmi-matching-for-qca-reset_resume-quirking.patch queue-4.15/acpi-bus-parse-tables-as-term_list-for-dell-xps-9570-and-precision-m5530.patch

7 years, 6 months

1
0
0 0

Patch "md: only allow remove_and_add_spares when no sync_thread running." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled md: only allow remove_and_add_spares when no sync_thread running. to the 4.14-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: md-only-allow-remove_and_add_spares-when-no-sync_thread-running.patch and it can be found in the queue-4.14 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 39772f0a7be3b3dc26c74ea13fe7847fd1522c8b Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.com> Date: Sat, 3 Feb 2018 09:19:30 +1100 Subject: md: only allow remove_and_add_spares when no sync_thread running. From: NeilBrown <neilb(a)suse.com> commit 39772f0a7be3b3dc26c74ea13fe7847fd1522c8b upstream. The locking protocols in md assume that a device will never be removed from an array during resync/recovery/reshape. When that isn't happening, rcu or reconfig_mutex is needed to protect an rdev pointer while taking a refcount. When it is happening, that protection isn't needed. Unfortunately there are cases were remove_and_add_spares() is called when recovery might be happening: is state_store(), slot_store() and hot_remove_disk(). In each case, this is just an optimization, to try to expedite removal from the personality so the device can be removed from the array. If resync etc is happening, we just have to wait for md_check_recover to find a suitable time to call remove_and_add_spares(). This optimization and not essential so it doesn't matter if it fails. So change remove_and_add_spares() to abort early if resync/recovery/reshape is happening, unless it is called from md_check_recovery() as part of a newly started recovery. The parameter "this" is only NULL when called from md_check_recovery() so when it is NULL, there is no need to abort. As this can result in a NULL dereference, the fix is suitable for -stable. cc: yuyufen <yuyufen(a)huawei.com> Cc: Tomasz Majchrzak <tomasz.majchrzak(a)intel.com> Fixes: 8430e7e0af9a ("md: disconnect device from personality before trying to remove it.") Cc: stable(a)ver.kernel.org (v4.8+) Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Shaohua Li <sh.li(a)alibaba-inc.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/md.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -8522,6 +8522,10 @@ static int remove_and_add_spares(struct int removed = 0; bool remove_some = false; + if (this && test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) + /* Mustn't remove devices when resync thread is running */ + return 0; + rdev_for_each(rdev, mddev) { if ((this == NULL || rdev == this) && rdev->raid_disk >= 0 && Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.14/md-only-allow-remove_and_add_spares-when-no-sync_thread-running.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux to the 4.14-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: arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch and it can be found in the queue-4.14 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 74402055a2d3ec998a1ded599e86185a27d9bbf4 Mon Sep 17 00:00:00 2001 From: Adam Ford <aford173(a)gmail.com> Date: Thu, 25 Jan 2018 14:10:37 -0600 Subject: ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux From: Adam Ford <aford173(a)gmail.com> commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream. The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at time. This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz Fixes: 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo DM3730 devkit") Signed-off-by: Adam Ford <aford173(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi @@ -104,6 +104,8 @@ }; &i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins>; clock-frequency = <2600000>; twl: twl@48 { @@ -211,6 +213,12 @@ OMAP3_CORE1_IOPAD(0x21b8, PIN_INPUT | MUX_MODE0) /* hsusb0_data7.hsusb0_data7 */ >; }; + i2c1_pins: pinmux_i2c1_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */ + OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */ + >; + }; }; &uart2 { Patches currently in stable-queue which might be from aford173(a)gmail.com are queue-4.14/arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch queue-4.14/arm-dts-logicpd-som-lv-fix-i2c1-pinmux.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux to the 4.14-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: arm-dts-logicpd-som-lv-fix-i2c1-pinmux.patch and it can be found in the queue-4.14 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 84c7efd607e7fb6933920322086db64654f669b2 Mon Sep 17 00:00:00 2001 From: Adam Ford <aford173(a)gmail.com> Date: Sat, 27 Jan 2018 15:27:05 -0600 Subject: ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux From: Adam Ford <aford173(a)gmail.com> commit 84c7efd607e7fb6933920322086db64654f669b2 upstream. The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at times. This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") Signed-off-by: Adam Ford <aford173(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/logicpd-som-lv.dtsi | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/arch/arm/boot/dts/logicpd-som-lv.dtsi +++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi @@ -97,6 +97,8 @@ }; &i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins>; clock-frequency = <2600000>; twl: twl@48 { @@ -215,7 +217,12 @@ >; }; - + i2c1_pins: pinmux_i2c1_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */ + OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */ + >; + }; }; &omap3_pmx_wkup { Patches currently in stable-queue which might be from aford173(a)gmail.com are queue-4.14/arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch queue-4.14/arm-dts-logicpd-som-lv-fix-i2c1-pinmux.patch

7 years, 6 months

1
0
0 0

Patch "ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530 to the 4.14-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: acpi-bus-parse-tables-as-term_list-for-dell-xps-9570-and-precision-m5530.patch and it can be found in the queue-4.14 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 36904703aeeeb6cd31993f1353c8325006229f9a Mon Sep 17 00:00:00 2001 From: Kai Heng Feng <kai.heng.feng(a)canonical.com> Date: Mon, 5 Feb 2018 13:19:24 +0800 Subject: ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530 From: Kai Heng Feng <kai.heng.feng(a)canonical.com> commit 36904703aeeeb6cd31993f1353c8325006229f9a upstream. The i2c touchpad on Dell XPS 9570 and Precision M5530 doesn't work out of box. The touchpad relies on its _INI method to update its _HID value from XXXX0000 to SYNA2393. Also, the _STA relies on value of I2CN to report correct status. Set acpi_gbl_parse_table_as_term_list so the value of I2CN can be correctly set up, and _INI can get run. The ACPI table in this machine is designed to get parsed this way. Also, change the quirk table to a more generic name. Link: https://bugzilla.kernel.org/show_bug.cgi?id=198515 Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/bus.c | 38 +++++++++++++++++++++++++++++++------- 1 file changed, 31 insertions(+), 7 deletions(-) --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -66,10 +66,37 @@ static int set_copy_dsdt(const struct dm return 0; } #endif +static int set_gbl_term_list(const struct dmi_system_id *id) +{ + acpi_gbl_parse_table_as_term_list = 1; + return 0; +} -static const struct dmi_system_id dsdt_dmi_table[] __initconst = { +static const struct dmi_system_id acpi_quirks_dmi_table[] __initconst = { + /* + * Touchpad on Dell XPS 9570/Precision M5530 doesn't work under I2C + * mode. + * https://bugzilla.kernel.org/show_bug.cgi?id=198515 + */ + { + .callback = set_gbl_term_list, + .ident = "Dell Precision M5530", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Precision M5530"), + }, + }, + { + .callback = set_gbl_term_list, + .ident = "Dell XPS 15 9570", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "XPS 15 9570"), + }, + }, /* * Invoke DSDT corruption work-around on all Toshiba Satellite. + * DSDT will be copied to memory. * https://bugzilla.kernel.org/show_bug.cgi?id=14679 */ { @@ -83,7 +110,7 @@ static const struct dmi_system_id dsdt_d {} }; #else -static const struct dmi_system_id dsdt_dmi_table[] __initconst = { +static const struct dmi_system_id acpi_quirks_dmi_table[] __initconst = { {} }; #endif @@ -1001,11 +1028,8 @@ void __init acpi_early_init(void) acpi_permanent_mmap = true; - /* - * If the machine falls into the DMI check table, - * DSDT will be copied to memory - */ - dmi_check_system(dsdt_dmi_table); + /* Check machine-specific quirks */ + dmi_check_system(acpi_quirks_dmi_table); status = acpi_reallocate_root_table(); if (ACPI_FAILURE(status)) { Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are queue-4.14/bluetooth-btusb-use-dmi-matching-for-qca-reset_resume-quirking.patch queue-4.14/acpi-bus-parse-tables-as-term_list-for-dell-xps-9570-and-precision-m5530.patch

7 years, 6 months

1
0
0 0

Patch "net: fec: introduce fec_ptp_stop and use in probe fail path" 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 net: fec: introduce fec_ptp_stop and use in probe fail path 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: net-fec-introduce-fec_ptp_stop-and-use-in-probe-fail-path.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 32cba57ba74be58589aeb4cb6496183e46a5e3e5 Mon Sep 17 00:00:00 2001 From: Lucas Stach <l.stach(a)pengutronix.de> Date: Thu, 23 Jul 2015 16:06:20 +0200 Subject: net: fec: introduce fec_ptp_stop and use in probe fail path From: Lucas Stach <l.stach(a)pengutronix.de> commit 32cba57ba74be58589aeb4cb6496183e46a5e3e5 upstream. This function frees resources and cancels delayed work item that have been initialized in fec_ptp_init(). Use this to do proper error handling if something goes wrong in probe function after fec_ptp_init has been called. Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> Acked-by: Fugang Duan <B38611(a)freescale.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> [groeck: backport: context changes in .../fec_main.c] Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/freescale/fec.h | 1 + drivers/net/ethernet/freescale/fec_main.c | 5 ++--- drivers/net/ethernet/freescale/fec_ptp.c | 10 ++++++++++ 3 files changed, 13 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/freescale/fec.h +++ b/drivers/net/ethernet/freescale/fec.h @@ -546,6 +546,7 @@ struct fec_enet_private { }; void fec_ptp_init(struct platform_device *pdev); +void fec_ptp_stop(struct platform_device *pdev); void fec_ptp_start_cyclecounter(struct net_device *ndev); int fec_ptp_set(struct net_device *ndev, struct ifreq *ifr); int fec_ptp_get(struct net_device *ndev, struct ifreq *ifr); --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -3312,6 +3312,7 @@ failed_register: failed_mii_init: failed_irq: failed_init: + fec_ptp_stop(pdev); if (fep->reg_phy) regulator_disable(fep->reg_phy); failed_regulator: @@ -3331,14 +3332,12 @@ fec_drv_remove(struct platform_device *p struct net_device *ndev = platform_get_drvdata(pdev); struct fec_enet_private *fep = netdev_priv(ndev); - cancel_delayed_work_sync(&fep->time_keep); cancel_work_sync(&fep->tx_timeout_work); + fec_ptp_stop(pdev); unregister_netdev(ndev); fec_enet_mii_remove(fep); if (fep->reg_phy) regulator_disable(fep->reg_phy); - if (fep->ptp_clock) - ptp_clock_unregister(fep->ptp_clock); fec_enet_clk_enable(ndev, false); of_node_put(fep->phy_node); free_netdev(ndev); --- a/drivers/net/ethernet/freescale/fec_ptp.c +++ b/drivers/net/ethernet/freescale/fec_ptp.c @@ -620,6 +620,16 @@ void fec_ptp_init(struct platform_device schedule_delayed_work(&fep->time_keep, HZ); } +void fec_ptp_stop(struct platform_device *pdev) +{ + struct net_device *ndev = platform_get_drvdata(pdev); + struct fec_enet_private *fep = netdev_priv(ndev); + + cancel_delayed_work_sync(&fep->time_keep); + if (fep->ptp_clock) + ptp_clock_unregister(fep->ptp_clock); +} + /** * fec_ptp_check_pps_event * @fep: the fec_enet_private structure handle Patches currently in stable-queue which might be from l.stach(a)pengutronix.de are queue-3.18/net-fec-introduce-fec_ptp_stop-and-use-in-probe-fail-path.patch

7 years, 6 months

1
0
0 0

FAILED: patch "[PATCH] powerpc/64s/radix: Boot-time NULL pointer protection using a" failed to apply to 4.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From eeb715c3e995fbdda0cc05e61216c6c5609bce66 Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Wed, 7 Feb 2018 11:20:02 +1000 Subject: [PATCH] powerpc/64s/radix: Boot-time NULL pointer protection using a guard-PID This change restores and formalises the behaviour that access to NULL or other user addresses by the kernel during boot should fault rather than succeed and modify memory. This was inadvertently broken when fixing another bug, because it was previously not well defined and only worked by chance. powerpc/64s/radix uses high address bits to select an address space "quadrant", which determines which PID and LPID are used to translate the rest of the address (effective PID, effective LPID). The kernel mapping at 0xC... selects quadrant 3, which uses PID=0 and LPID=0. So the kernel page tables are installed in the PID 0 process table entry. An address at 0x0... selects quadrant 0, which uses PID=PIDR for translating the rest of the address (that is, it uses the value of the PIDR register as the effective PID). If PIDR=0, then the translation is performed with the PID 0 process table entry page tables. This is the kernel mapping, so we effectively get another copy of the kernel address space at 0. A NULL pointer access will access physical memory address 0. To prevent duplicating the kernel address space in quadrant 0, this patch allocates a guard PID containing no translations, and initializes PIDR with this during boot, before the MMU is switched on. Any kernel access to quadrant 0 will use this guard PID for translation and find no valid mappings, and therefore fault. After boot, this PID will be switchd away to user context PIDs, but those contain user mappings (and usually NULL pointer protection) rather than kernel mapping, which is much safer (and by design). It may be in future this is tightened further, which the guard PID could be used for. Commit 371b8044 ("powerpc/64s: Initialize ISAv3 MMU registers before setting partition table"), introduced this problem because it zeroes PIDR at boot. However previously the value was inherited from firmware or kexec, which is not robust and can be zero (e.g., mambo). Fixes: 371b80447ff3 ("powerpc/64s: Initialize ISAv3 MMU registers before setting partition table") Cc: stable(a)vger.kernel.org # v4.15+ Reported-by: Florian Weimer <fweimer(a)redhat.com> Tested-by: Mauricio Faria de Oliveira <mauricfo(a)linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c index 573a9a2ee455..96e07d1f673d 100644 --- a/arch/powerpc/mm/pgtable-radix.c +++ b/arch/powerpc/mm/pgtable-radix.c @@ -20,6 +20,7 @@ #include <asm/pgtable.h> #include <asm/pgalloc.h> +#include <asm/mmu_context.h> #include <asm/dma.h> #include <asm/machdep.h> #include <asm/mmu.h> @@ -333,6 +334,22 @@ static void __init radix_init_pgtable(void) "r" (TLBIEL_INVAL_SET_LPID), "r" (0)); asm volatile("eieio; tlbsync; ptesync" : : : "memory"); trace_tlbie(0, 0, TLBIEL_INVAL_SET_LPID, 0, 2, 1, 1); + + /* + * The init_mm context is given the first available (non-zero) PID, + * which is the "guard PID" and contains no page table. PIDR should + * never be set to zero because that duplicates the kernel address + * space at the 0x0... offset (quadrant 0)! + * + * An arbitrary PID that may later be allocated by the PID allocator + * for userspace processes must not be used either, because that + * would cause stale user mappings for that PID on CPUs outside of + * the TLB invalidation scheme (because it won't be in mm_cpumask). + * + * So permanently carve out one PID for the purpose of a guard PID. + */ + init_mm.context.id = mmu_base_pid; + mmu_base_pid++; } static void __init radix_init_partition_table(void) @@ -579,7 +596,8 @@ void __init radix__early_init_mmu(void) radix_init_iamr(); radix_init_pgtable(); - + /* Switch to the guard PID before turning on MMU */ + radix__switch_mmu_context(NULL, &init_mm); if (cpu_has_feature(CPU_FTR_HVMODE)) tlbiel_all(); } @@ -604,6 +622,7 @@ void radix__early_init_mmu_secondary(void) } radix_init_iamr(); + radix__switch_mmu_context(NULL, &init_mm); if (cpu_has_feature(CPU_FTR_HVMODE)) tlbiel_all(); }

7 years, 6 months

4
3
0 0

ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux

by Adam Ford

Can you please apply 84c7efd607e7 ("ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux") to the 4.9 and 4.15 kernels? Like the Torpedo, this fixes an intermittent issue with the RTC and Audio which are integrated into the PMIC on I2C1. Thank you, adam

7 years, 6 months

2
1
0 0

ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux

by Adam Ford

Can you please apply 74402055a2d3 ("ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux") to the 4.4, 4.9 and 4.15 stable kernels? There is a problem with older versions of the bootloader not setting this correctly and causes intermittent issues. This fixes the I2C1 bus to stablize communication with the PMIC which contains the RTC and audio. Thank you, adam

7 years, 6 months

2
1
0 0

[PATCH 4.8-4.11] dm io: fix duplicate bio completion due to missing ref count

by Mikulas Patocka

This is backport of the upstream commit that fixes memory corruption in dm-io. It is suitable for stable kernels 4.8 to 4.11. (the bug was already fixed in 4.12) Mikulas commit feb7695fe9fb83084aa29de0094774f4c9d4c9fc Author: Mike Snitzer <snitzer(a)redhat.com> Date: Tue Jun 20 19:14:30 2017 -0400 dm io: fix duplicate bio completion due to missing ref count If only a subset of the devices associated with multiple regions support a given special operation (eg. DISCARD) then the dec_count() that is used to set error for the region must increment the io->count. Otherwise, when the dec_count() is called it can cause the dm-io caller's bio to be completed multiple times. As was reported against the dm-mirror target that had mirror legs with a mix of discard capabilities. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=196077 Reported-by: Zhang Yi <yizhan(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> --- drivers/md/dm-io.c | 1 + 1 file changed, 1 insertion(+) Index: linux-stable/drivers/md/dm-io.c =================================================================== --- linux-stable.orig/drivers/md/dm-io.c 2018-03-06 14:13:59.000000000 +0100 +++ linux-stable/drivers/md/dm-io.c 2018-03-06 14:14:23.000000000 +0100 @@ -316,6 +316,7 @@ static void do_region(int op, int op_fla special_cmd_max_sectors = q->limits.max_write_same_sectors; if ((op == REQ_OP_DISCARD || op == REQ_OP_WRITE_SAME) && special_cmd_max_sectors == 0) { + atomic_inc(&io->count); dec_count(io, region, -EOPNOTSUPP); return; }

7 years, 6 months

2
1
0 0

[PATCH v3.18] net: fec: introduce fec_ptp_stop and use in probe fail path

by Guenter Roeck

From: Lucas Stach <l.stach(a)pengutronix.de> [ upstream commit 32cba57ba74be58589aeb4cb6496183e46a5e3e5 ] This function frees resources and cancels delayed work item that have been initialized in fec_ptp_init(). Use this to do proper error handling if something goes wrong in probe function after fec_ptp_init has been called. Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> Acked-by: Fugang Duan <B38611(a)freescale.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> [groeck: backport: context changes in .../fec_main.c] Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> --- Not really sure if I should send this one to David or Greg, since v3.18 is no longer officially supported, so I am sending it to both. Sorry for the noise. This patch fixes a crash seen when running sabrelite images in a version of qemu which fixes https://bugs.launchpad.net/qemu/+bug/1753309. drivers/net/ethernet/freescale/fec.h | 1 + drivers/net/ethernet/freescale/fec_main.c | 5 ++--- drivers/net/ethernet/freescale/fec_ptp.c | 10 ++++++++++ 3 files changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h index 9af296a1ca99..c16b6deff5ea 100644 --- a/drivers/net/ethernet/freescale/fec.h +++ b/drivers/net/ethernet/freescale/fec.h @@ -546,6 +546,7 @@ struct fec_enet_private { }; void fec_ptp_init(struct platform_device *pdev); +void fec_ptp_stop(struct platform_device *pdev); void fec_ptp_start_cyclecounter(struct net_device *ndev); int fec_ptp_set(struct net_device *ndev, struct ifreq *ifr); int fec_ptp_get(struct net_device *ndev, struct ifreq *ifr); diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c index 065a7616e961..f1224c2d112a 100644 --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -3312,6 +3312,7 @@ failed_register: failed_mii_init: failed_irq: failed_init: + fec_ptp_stop(pdev); if (fep->reg_phy) regulator_disable(fep->reg_phy); failed_regulator: @@ -3331,14 +3332,12 @@ fec_drv_remove(struct platform_device *pdev) struct net_device *ndev = platform_get_drvdata(pdev); struct fec_enet_private *fep = netdev_priv(ndev); - cancel_delayed_work_sync(&fep->time_keep); cancel_work_sync(&fep->tx_timeout_work); + fec_ptp_stop(pdev); unregister_netdev(ndev); fec_enet_mii_remove(fep); if (fep->reg_phy) regulator_disable(fep->reg_phy); - if (fep->ptp_clock) - ptp_clock_unregister(fep->ptp_clock); fec_enet_clk_enable(ndev, false); of_node_put(fep->phy_node); free_netdev(ndev); diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c index 992c8c3db553..9b2dcf4261a5 100644 --- a/drivers/net/ethernet/freescale/fec_ptp.c +++ b/drivers/net/ethernet/freescale/fec_ptp.c @@ -620,6 +620,16 @@ void fec_ptp_init(struct platform_device *pdev) schedule_delayed_work(&fep->time_keep, HZ); } +void fec_ptp_stop(struct platform_device *pdev) +{ + struct net_device *ndev = platform_get_drvdata(pdev); + struct fec_enet_private *fep = netdev_priv(ndev); + + cancel_delayed_work_sync(&fep->time_keep); + if (fep->ptp_clock) + ptp_clock_unregister(fep->ptp_clock); +} + /** * fec_ptp_check_pps_event * @fep: the fec_enet_private structure handle -- 2.7.4

7 years, 6 months

2
1
0 0

Stable inclusion for commit 36904703aeee

by Kai Heng Feng

Hi Greg, Please include commit 36904703aeee ("ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530") for v4.14+. This can be backported to older versions, but this system won't function on v4.4 or v4.9. It requires new drivers that don't exist in v4.4 or v4.9. Thanks! Kai-Heng

7 years, 6 months

2
1
0 0

Patch "btrfs: Don't clear SGID when inheriting ACLs" 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 btrfs: Don't clear SGID when inheriting ACLs 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: btrfs-don-t-clear-sgid-when-inheriting-acls.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 b7f8a09f8097db776b8d160862540e4fc1f51296 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack(a)suse.cz> Date: Thu, 22 Jun 2017 15:31:07 +0200 Subject: btrfs: Don't clear SGID when inheriting ACLs From: Jan Kara <jack(a)suse.cz> commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by moving posix_acl_update_mode() out of __btrfs_set_acl() into btrfs_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: stable(a)vger.kernel.org CC: linux-btrfs(a)vger.kernel.org CC: David Sterba <dsterba(a)suse.com> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Nikolay Borisov <nborisov(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/acl.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) --- a/fs/btrfs/acl.c +++ b/fs/btrfs/acl.c @@ -82,12 +82,6 @@ static int __btrfs_set_acl(struct btrfs_ switch (type) { case ACL_TYPE_ACCESS: name = POSIX_ACL_XATTR_ACCESS; - if (acl) { - ret = posix_acl_update_mode(inode, &inode->i_mode, &acl); - if (ret) - return ret; - } - ret = 0; break; case ACL_TYPE_DEFAULT: if (!S_ISDIR(inode->i_mode)) @@ -123,6 +117,13 @@ out: int btrfs_set_acl(struct inode *inode, struct posix_acl *acl, int type) { + int ret; + + if (type == ACL_TYPE_ACCESS && acl) { + ret = posix_acl_update_mode(inode, &inode->i_mode, &acl); + if (ret) + return ret; + } return __btrfs_set_acl(NULL, inode, acl, type); } Patches currently in stable-queue which might be from jack(a)suse.cz are queue-4.4/btrfs-don-t-clear-sgid-when-inheriting-acls.patch

7 years, 6 months

1
0
0 0

Patch "KVM/x86: remove WARN_ON() for when vm_munmap() fails" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM/x86: remove WARN_ON() for when vm_munmap() fails to the 4.15-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: kvm-x86-remove-warn_on-for-when-vm_munmap-fails.patch and it can be found in the queue-4.15 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 103c763c72dd2df3e8c91f2d7ec88f98ed391111 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Wed, 31 Jan 2018 17:30:21 -0800 Subject: KVM/x86: remove WARN_ON() for when vm_munmap() fails MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Eric Biggers <ebiggers(a)google.com> commit 103c763c72dd2df3e8c91f2d7ec88f98ed391111 upstream. On x86, special KVM memslots such as the TSS region have anonymous memory mappings created on behalf of userspace, and these mappings are removed when the VM is destroyed. It is however possible for removing these mappings via vm_munmap() to fail. This can most easily happen if the thread receives SIGKILL while it's waiting to acquire ->mmap_sem. This triggers the 'WARN_ON(r < 0)' in __x86_set_memory_region(). syzkaller was able to hit this, using 'exit()' to send the SIGKILL. Note that while the vm_munmap() failure results in the mapping not being removed immediately, it is not leaked forever but rather will be freed when the process exits. It's not really possible to handle this failure properly, so almost every other caller of vm_munmap() doesn't check the return value. It's a limitation of having the kernel manage these mappings rather than userspace. So just remove the WARN_ON() so that users can't spam the kernel log with this warning. Fixes: f0d648bdf0a5 ("KVM: x86: map/unmap private slots in __x86_set_memory_region") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Jack Wang <jinpu.wang(a)profitbricks.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/x86.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -8281,10 +8281,8 @@ int __x86_set_memory_region(struct kvm * return r; } - if (!size) { - r = vm_munmap(old.userspace_addr, old.npages * PAGE_SIZE); - WARN_ON(r < 0); - } + if (!size) + vm_munmap(old.userspace_addr, old.npages * PAGE_SIZE); return 0; } Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.15/kvm-x86-remove-warn_on-for-when-vm_munmap-fails.patch

7 years, 6 months

1
0
0 0

Patch "KVM/x86: remove WARN_ON() for when vm_munmap() fails" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM/x86: remove WARN_ON() for when vm_munmap() fails to the 4.14-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: kvm-x86-remove-warn_on-for-when-vm_munmap-fails.patch and it can be found in the queue-4.14 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 103c763c72dd2df3e8c91f2d7ec88f98ed391111 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Wed, 31 Jan 2018 17:30:21 -0800 Subject: KVM/x86: remove WARN_ON() for when vm_munmap() fails MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Eric Biggers <ebiggers(a)google.com> commit 103c763c72dd2df3e8c91f2d7ec88f98ed391111 upstream. On x86, special KVM memslots such as the TSS region have anonymous memory mappings created on behalf of userspace, and these mappings are removed when the VM is destroyed. It is however possible for removing these mappings via vm_munmap() to fail. This can most easily happen if the thread receives SIGKILL while it's waiting to acquire ->mmap_sem. This triggers the 'WARN_ON(r < 0)' in __x86_set_memory_region(). syzkaller was able to hit this, using 'exit()' to send the SIGKILL. Note that while the vm_munmap() failure results in the mapping not being removed immediately, it is not leaked forever but rather will be freed when the process exits. It's not really possible to handle this failure properly, so almost every other caller of vm_munmap() doesn't check the return value. It's a limitation of having the kernel manage these mappings rather than userspace. So just remove the WARN_ON() so that users can't spam the kernel log with this warning. Fixes: f0d648bdf0a5 ("KVM: x86: map/unmap private slots in __x86_set_memory_region") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Jack Wang <jinpu.wang(a)profitbricks.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/x86.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -8251,10 +8251,8 @@ int __x86_set_memory_region(struct kvm * return r; } - if (!size) { - r = vm_munmap(old.userspace_addr, old.npages * PAGE_SIZE); - WARN_ON(r < 0); - } + if (!size) + vm_munmap(old.userspace_addr, old.npages * PAGE_SIZE); return 0; } Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.14/kvm-x86-remove-warn_on-for-when-vm_munmap-fails.patch

7 years, 6 months

1
0
0 0

Patch "KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs() to the 4.14-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: kvm-x86-fix-wrong-macro-references-of-x86_cr0_pg_bit-and-x86_cr4_pae_bit-in-kvm_valid_sregs.patch and it can be found in the queue-4.14 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 37b95951c58fdf08dc10afa9d02066ed9f176fb5 Mon Sep 17 00:00:00 2001 From: Tianyu Lan <lantianyu1986(a)gmail.com> Date: Tue, 16 Jan 2018 17:34:07 +0800 Subject: KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Tianyu Lan <lantianyu1986(a)gmail.com> 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> Signed-off-by: Jack Wang <jinpu.wang(a)profitbricks.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/x86.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7482,13 +7482,13 @@ EXPORT_SYMBOL_GPL(kvm_task_switch); int kvm_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs) { - if ((sregs->efer & EFER_LME) && (sregs->cr0 & X86_CR0_PG_BIT)) { + if ((sregs->efer & EFER_LME) && (sregs->cr0 & X86_CR0_PG)) { /* * When EFER.LME and CR0.PG are set, the processor is in * 64-bit mode (though maybe in a 32-bit code segment). * CR4.PAE and EFER.LMA must be set. */ - if (!(sregs->cr4 & X86_CR4_PAE_BIT) + if (!(sregs->cr4 & X86_CR4_PAE) || !(sregs->efer & EFER_LMA)) return -EINVAL; } else { Patches currently in stable-queue which might be from lantianyu1986(a)gmail.com are queue-4.14/kvm-x86-fix-wrong-macro-references-of-x86_cr0_pg_bit-and-x86_cr4_pae_bit-in-kvm_valid_sregs.patch

7 years, 6 months

1
0
0 0

Patch "PCI/ASPM: Deal with missing root ports in link state handling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI/ASPM: Deal with missing root ports in link state handling to the 4.9-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: pci-aspm-deal-with-missing-root-ports-in-link-state-handling.patch and it can be found in the queue-4.9 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 ee8bdfb6568d86bb93f55f8d99c4c643e77304ee Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Mon, 2 Oct 2017 15:08:40 +0100 Subject: PCI/ASPM: Deal with missing root ports in link state handling From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> commit ee8bdfb6568d86bb93f55f8d99c4c643e77304ee upstream. Even though it is unconventional, some PCIe host implementations omit the root ports entirely, and simply consist of a host bridge (which is not modeled as a device in the PCI hierarchy) and a link. When the downstream device is an endpoint, our current code does not seem to mind this unusual configuration. However, when PCIe switches are involved, the ASPM code assumes that any downstream switch port has a parent, and blindly dereferences the bus->parent->self field of the pci_dev struct to chain the downstream link state to the link state of the root port. Given that the root port is missing, the link is not modeled at all, and nor is the link state, and attempting to access it results in a NULL pointer dereference and a crash. Avoid this by allowing the link state chain to terminate at the downstream port if no root port exists. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/pcie/aspm.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/pci/pcie/aspm.c +++ b/drivers/pci/pcie/aspm.c @@ -526,10 +526,14 @@ static struct pcie_link_state *alloc_pci /* * Root Ports and PCI/PCI-X to PCIe Bridges are roots of PCIe - * hierarchies. + * hierarchies. Note that some PCIe host implementations omit + * the root ports entirely, in which case a downstream port on + * a switch may become the root of the link state chain for all + * its subordinate endpoints. */ if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT || - pci_pcie_type(pdev) == PCI_EXP_TYPE_PCIE_BRIDGE) { + pci_pcie_type(pdev) == PCI_EXP_TYPE_PCIE_BRIDGE || + !pdev->bus->parent->self) { link->root = link; } else { struct pcie_link_state *parent; Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.9/pci-aspm-deal-with-missing-root-ports-in-link-state-handling.patch

7 years, 6 months

1
0
0 0

Re: [PATCH] ubi: Reject MLC NAND

by Richard Weinberger

Pavel, Am Mittwoch, 7. März 2018, 00:18:05 CET schrieb Pavel Machek: > On Sat 2018-03-03 11:45:54, Richard Weinberger wrote: > > While UBI and UBIFS seem to work at first sight with MLC NAND, you will > > most likely lose all your data upon a power-cut or due to read/write > > disturb. > > In order to protect users from bad surprises, refuse to attach to MLC > > NAND. > > > > Cc: stable(a)vger.kernel.org > > That sounds like _really_ bad idea for stable. All it does is it > removes support for hardware that somehow works. MLC is not supported and does not work. Full stop. If someone manages to get it somehow work, either with hardware or software hacks they are on their own. Having it in stable is the only chance we have to get it into vendor kernels. All this patch does is representing the current state of UBI/UBIFS. In the last months I got a way too much boards with MLC NAND on my desk where UBIFS broke. Customers wished they had known before... Thanks, //richard

7 years, 6 months

2
1
0 0

Patch "PCI/ASPM: Deal with missing root ports in link state handling" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI/ASPM: Deal with missing root ports in link state handling to the 4.14-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: pci-aspm-deal-with-missing-root-ports-in-link-state-handling.patch and it can be found in the queue-4.14 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 ee8bdfb6568d86bb93f55f8d99c4c643e77304ee Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Mon, 2 Oct 2017 15:08:40 +0100 Subject: PCI/ASPM: Deal with missing root ports in link state handling From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> commit ee8bdfb6568d86bb93f55f8d99c4c643e77304ee upstream. Even though it is unconventional, some PCIe host implementations omit the root ports entirely, and simply consist of a host bridge (which is not modeled as a device in the PCI hierarchy) and a link. When the downstream device is an endpoint, our current code does not seem to mind this unusual configuration. However, when PCIe switches are involved, the ASPM code assumes that any downstream switch port has a parent, and blindly dereferences the bus->parent->self field of the pci_dev struct to chain the downstream link state to the link state of the root port. Given that the root port is missing, the link is not modeled at all, and nor is the link state, and attempting to access it results in a NULL pointer dereference and a crash. Avoid this by allowing the link state chain to terminate at the downstream port if no root port exists. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/pcie/aspm.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/pci/pcie/aspm.c +++ b/drivers/pci/pcie/aspm.c @@ -803,10 +803,14 @@ static struct pcie_link_state *alloc_pci /* * Root Ports and PCI/PCI-X to PCIe Bridges are roots of PCIe - * hierarchies. + * hierarchies. Note that some PCIe host implementations omit + * the root ports entirely, in which case a downstream port on + * a switch may become the root of the link state chain for all + * its subordinate endpoints. */ if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT || - pci_pcie_type(pdev) == PCI_EXP_TYPE_PCIE_BRIDGE) { + pci_pcie_type(pdev) == PCI_EXP_TYPE_PCIE_BRIDGE || + !pdev->bus->parent->self) { link->root = link; } else { struct pcie_link_state *parent; Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.14/pci-aspm-deal-with-missing-root-ports-in-link-state-handling.patch

7 years, 6 months

1
0
0 0

please apply 'ee8bdfb6568d PCI/ASPM: Deal with missing root ports ...'

by Ard Biesheuvel

L.S., Please apply ee8bdfb6568d PCI/ASPM: Deal with missing root ports in link state handling to the -stable trees going back to v4.9 LTS It fixes an annoying boot crash that only occurs on systems with an unusual PCIe topology, but is rather hard to diagnose for unsuspecting users. Regards, Ard.

7 years, 6 months

2
4
0 0

Patch "KVM: X86: Fix SMRAM accessing even if VM is shutdown" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: X86: Fix SMRAM accessing even if VM is shutdown to the 4.14-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: kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch and it can be found in the queue-4.14 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 95e057e25892eaa48cad1e2d637b80d0f1a4fac5 Mon Sep 17 00:00:00 2001 From: Wanpeng Li <wanpengli(a)tencent.com> Date: Thu, 8 Feb 2018 15:32:45 +0800 Subject: KVM: X86: Fix SMRAM accessing even if VM is shutdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Wanpeng Li <wanpengli(a)tencent.com> commit 95e057e25892eaa48cad1e2d637b80d0f1a4fac5 upstream. Reported by syzkaller: WARNING: CPU: 6 PID: 2434 at arch/x86/kvm/vmx.c:6660 handle_ept_misconfig+0x54/0x1e0 [kvm_intel] CPU: 6 PID: 2434 Comm: repro_test Not tainted 4.15.0+ #4 RIP: 0010:handle_ept_misconfig+0x54/0x1e0 [kvm_intel] Call Trace: vmx_handle_exit+0xbd/0xe20 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xdaf/0x1d50 [kvm] kvm_vcpu_ioctl+0x3e9/0x720 [kvm] do_vfs_ioctl+0xa4/0x6a0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x25/0x9c The testcase creates a first thread to issue KVM_SMI ioctl, and then creates a second thread to mmap and operate on the same vCPU. This triggers a race condition when running the testcase with multiple threads. Sometimes one thread exits with a triple fault while another thread mmaps and operates on the same vCPU. Because CS=0x3000/IP=0x8000 is not mapped, accessing the SMI handler results in an EPT misconfig. This patch fixes it by returning RET_PF_EMULATE in kvm_handle_bad_page(), which will go on to cause an emulation failure and an exit with KVM_EXIT_INTERNAL_ERROR. Reported-by: syzbot+c1d9517cab094dae65e446c0c5b4de6c40f4dc58(a)syzkaller.appspotmail.com Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -3004,7 +3004,7 @@ static int kvm_handle_bad_page(struct kv return 0; } - return -EFAULT; + return RET_PF_EMULATE; } static void transparent_hugepage_adjust(struct kvm_vcpu *vcpu, Patches currently in stable-queue which might be from wanpengli(a)tencent.com are queue-4.14/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch

7 years, 6 months

4
3
0 0

Patch "KVM: x86: fix vcpu initialization with userspace lapic" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: fix vcpu initialization with userspace lapic to the 4.15-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: kvm-x86-fix-vcpu-initialization-with-userspace-lapic.patch and it can be found in the queue-4.15 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 b7e31be385584afe7f073130e8e570d53c95f7fe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar(a)redhat.com> Date: Thu, 1 Mar 2018 15:24:25 +0100 Subject: KVM: x86: fix vcpu initialization with userspace lapic MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Radim Krčmář <rkrcmar(a)redhat.com> commit b7e31be385584afe7f073130e8e570d53c95f7fe upstream. Moving the code around broke this rare configuration. Use this opportunity to finally call lapic reset from vcpu reset. Reported-by: syzbot+fb7a33a4b6c35007a72b(a)syzkaller.appspotmail.com Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com> Fixes: 0b2e9904c159 ("KVM: x86: move LAPIC initialization after VMCS creation") Cc: stable(a)vger.kernel.org Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/lapic.c | 10 ++++------ arch/x86/kvm/x86.c | 3 ++- 2 files changed, 6 insertions(+), 7 deletions(-) --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -1993,14 +1993,13 @@ void kvm_lapic_set_base(struct kvm_vcpu void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool init_event) { - struct kvm_lapic *apic; + struct kvm_lapic *apic = vcpu->arch.apic; int i; - apic_debug("%s\n", __func__); + if (!apic) + return; - ASSERT(vcpu); - apic = vcpu->arch.apic; - ASSERT(apic != NULL); + apic_debug("%s\n", __func__); /* Stop the timer in case it's a reset to an active apic */ hrtimer_cancel(&apic->lapic_timer.timer); @@ -2559,7 +2558,6 @@ void kvm_apic_accept_events(struct kvm_v pe = xchg(&apic->pending_events, 0); if (test_bit(KVM_APIC_INIT, &pe)) { - kvm_lapic_reset(vcpu, true); kvm_vcpu_reset(vcpu, true); if (kvm_vcpu_is_bsp(apic->vcpu)) vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE; --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7793,7 +7793,6 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu if (r) return r; kvm_vcpu_reset(vcpu, false); - kvm_lapic_reset(vcpu, false); kvm_mmu_setup(vcpu); vcpu_put(vcpu); return r; @@ -7836,6 +7835,8 @@ void kvm_arch_vcpu_destroy(struct kvm_vc void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) { + kvm_lapic_reset(vcpu, init_event); + vcpu->arch.hflags = 0; vcpu->arch.smi_pending = 0; Patches currently in stable-queue which might be from rkrcmar(a)redhat.com are queue-4.15/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch queue-4.15/kvm-x86-remove-indirect-msr-op-calls-from-spec_ctrl.patch queue-4.15/kvm-mmu-fix-overlap-between-public-and-private-memslots.patch queue-4.15/kvm-x86-fix-vcpu-initialization-with-userspace-lapic.patch queue-4.15/kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch

7 years, 6 months

1
0
0 0

Patch "KVM: x86: fix vcpu initialization with userspace lapic" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: fix vcpu initialization with userspace lapic to the 4.14-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: kvm-x86-fix-vcpu-initialization-with-userspace-lapic.patch and it can be found in the queue-4.14 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 b7e31be385584afe7f073130e8e570d53c95f7fe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar(a)redhat.com> Date: Thu, 1 Mar 2018 15:24:25 +0100 Subject: KVM: x86: fix vcpu initialization with userspace lapic MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Radim Krčmář <rkrcmar(a)redhat.com> commit b7e31be385584afe7f073130e8e570d53c95f7fe upstream. Moving the code around broke this rare configuration. Use this opportunity to finally call lapic reset from vcpu reset. Reported-by: syzbot+fb7a33a4b6c35007a72b(a)syzkaller.appspotmail.com Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com> Fixes: 0b2e9904c159 ("KVM: x86: move LAPIC initialization after VMCS creation") Cc: stable(a)vger.kernel.org Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/lapic.c | 10 ++++------ arch/x86/kvm/x86.c | 3 ++- 2 files changed, 6 insertions(+), 7 deletions(-) --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -1944,14 +1944,13 @@ void kvm_lapic_set_base(struct kvm_vcpu void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool init_event) { - struct kvm_lapic *apic; + struct kvm_lapic *apic = vcpu->arch.apic; int i; - apic_debug("%s\n", __func__); + if (!apic) + return; - ASSERT(vcpu); - apic = vcpu->arch.apic; - ASSERT(apic != NULL); + apic_debug("%s\n", __func__); /* Stop the timer in case it's a reset to an active apic */ hrtimer_cancel(&apic->lapic_timer.timer); @@ -2510,7 +2509,6 @@ void kvm_apic_accept_events(struct kvm_v pe = xchg(&apic->pending_events, 0); if (test_bit(KVM_APIC_INIT, &pe)) { - kvm_lapic_reset(vcpu, true); kvm_vcpu_reset(vcpu, true); if (kvm_vcpu_is_bsp(apic->vcpu)) vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE; --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7779,7 +7779,6 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu if (r) return r; kvm_vcpu_reset(vcpu, false); - kvm_lapic_reset(vcpu, false); kvm_mmu_setup(vcpu); vcpu_put(vcpu); return r; @@ -7822,6 +7821,8 @@ void kvm_arch_vcpu_destroy(struct kvm_vc void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) { + kvm_lapic_reset(vcpu, init_event); + vcpu->arch.hflags = 0; vcpu->arch.smi_pending = 0; Patches currently in stable-queue which might be from rkrcmar(a)redhat.com are queue-4.14/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch queue-4.14/kvm-x86-remove-indirect-msr-op-calls-from-spec_ctrl.patch queue-4.14/kvm-mmu-fix-overlap-between-public-and-private-memslots.patch queue-4.14/kvm-x86-fix-vcpu-initialization-with-userspace-lapic.patch queue-4.14/kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch

7 years, 6 months

1
0
0 0

Patch "KVM: x86: extend usage of RET_MMIO_PF_* constants" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: extend usage of RET_MMIO_PF_* constants to the 4.14-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: kvm-x86-extend-usage-of-ret_mmio_pf_-constants.patch and it can be found in the queue-4.14 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 9b8ebbdb74b5ad76b9dfd8b101af17839174b126 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Thu, 17 Aug 2017 15:03:32 +0200 Subject: KVM: x86: extend usage of RET_MMIO_PF_* constants From: Paolo Bonzini <pbonzini(a)redhat.com> commit 9b8ebbdb74b5ad76b9dfd8b101af17839174b126 upstream. The x86 MMU if full of code that returns 0 and 1 for retry/emulate. Use the existing RET_MMIO_PF_RETRY/RET_MMIO_PF_EMULATE enum, renaming it to drop the MMIO part. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Thomas Backlund <tmb(a)mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/mmu.c | 95 +++++++++++++++++++++------------------------ arch/x86/kvm/paging_tmpl.h | 18 ++++---- 2 files changed, 55 insertions(+), 58 deletions(-) --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -150,6 +150,20 @@ module_param(dbg, bool, 0644); /* make pte_list_desc fit well in cache line */ #define PTE_LIST_EXT 3 +/* + * Return values of handle_mmio_page_fault and mmu.page_fault: + * RET_PF_RETRY: let CPU fault again on the address. + * RET_PF_EMULATE: mmio page fault, emulate the instruction directly. + * + * For handle_mmio_page_fault only: + * RET_PF_INVALID: the spte is invalid, let the real page fault path update it. + */ +enum { + RET_PF_RETRY = 0, + RET_PF_EMULATE = 1, + RET_PF_INVALID = 2, +}; + struct pte_list_desc { u64 *sptes[PTE_LIST_EXT]; struct pte_list_desc *more; @@ -2794,13 +2808,13 @@ done: return ret; } -static bool mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep, unsigned pte_access, - int write_fault, int level, gfn_t gfn, kvm_pfn_t pfn, - bool speculative, bool host_writable) +static int mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep, unsigned pte_access, + int write_fault, int level, gfn_t gfn, kvm_pfn_t pfn, + bool speculative, bool host_writable) { int was_rmapped = 0; int rmap_count; - bool emulate = false; + int ret = RET_PF_RETRY; pgprintk("%s: spte %llx write_fault %d gfn %llx\n", __func__, *sptep, write_fault, gfn); @@ -2830,12 +2844,12 @@ static bool mmu_set_spte(struct kvm_vcpu if (set_spte(vcpu, sptep, pte_access, level, gfn, pfn, speculative, true, host_writable)) { if (write_fault) - emulate = true; + ret = RET_PF_EMULATE; kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu); } if (unlikely(is_mmio_spte(*sptep))) - emulate = true; + ret = RET_PF_EMULATE; pgprintk("%s: setting spte %llx\n", __func__, *sptep); pgprintk("instantiating %s PTE (%s) at %llx (%llx) addr %p\n", @@ -2855,7 +2869,7 @@ static bool mmu_set_spte(struct kvm_vcpu kvm_release_pfn_clean(pfn); - return emulate; + return ret; } static kvm_pfn_t pte_prefetch_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn, @@ -2994,14 +3008,13 @@ static int kvm_handle_bad_page(struct kv * Do not cache the mmio info caused by writing the readonly gfn * into the spte otherwise read access on readonly gfn also can * caused mmio page fault and treat it as mmio access. - * Return 1 to tell kvm to emulate it. */ if (pfn == KVM_PFN_ERR_RO_FAULT) - return 1; + return RET_PF_EMULATE; if (pfn == KVM_PFN_ERR_HWPOISON) { kvm_send_hwpoison_signal(kvm_vcpu_gfn_to_hva(vcpu, gfn), current); - return 0; + return RET_PF_RETRY; } return -EFAULT; @@ -3286,13 +3299,13 @@ static int nonpaging_map(struct kvm_vcpu } if (fast_page_fault(vcpu, v, level, error_code)) - return 0; + return RET_PF_RETRY; mmu_seq = vcpu->kvm->mmu_notifier_seq; smp_rmb(); if (try_async_pf(vcpu, prefault, gfn, v, &pfn, write, &map_writable)) - return 0; + return RET_PF_RETRY; if (handle_abnormal_pfn(vcpu, v, gfn, pfn, ACC_ALL, &r)) return r; @@ -3312,7 +3325,7 @@ static int nonpaging_map(struct kvm_vcpu out_unlock: spin_unlock(&vcpu->kvm->mmu_lock); kvm_release_pfn_clean(pfn); - return 0; + return RET_PF_RETRY; } @@ -3659,54 +3672,38 @@ exit: return reserved; } -/* - * Return values of handle_mmio_page_fault: - * RET_MMIO_PF_EMULATE: it is a real mmio page fault, emulate the instruction - * directly. - * RET_MMIO_PF_INVALID: invalid spte is detected then let the real page - * fault path update the mmio spte. - * RET_MMIO_PF_RETRY: let CPU fault again on the address. - * RET_MMIO_PF_BUG: a bug was detected (and a WARN was printed). - */ -enum { - RET_MMIO_PF_EMULATE = 1, - RET_MMIO_PF_INVALID = 2, - RET_MMIO_PF_RETRY = 0, - RET_MMIO_PF_BUG = -1 -}; - static int handle_mmio_page_fault(struct kvm_vcpu *vcpu, u64 addr, bool direct) { u64 spte; bool reserved; if (mmio_info_in_cache(vcpu, addr, direct)) - return RET_MMIO_PF_EMULATE; + return RET_PF_EMULATE; reserved = walk_shadow_page_get_mmio_spte(vcpu, addr, &spte); if (WARN_ON(reserved)) - return RET_MMIO_PF_BUG; + return -EINVAL; if (is_mmio_spte(spte)) { gfn_t gfn = get_mmio_spte_gfn(spte); unsigned access = get_mmio_spte_access(spte); if (!check_mmio_spte(vcpu, spte)) - return RET_MMIO_PF_INVALID; + return RET_PF_INVALID; if (direct) addr = 0; trace_handle_mmio_page_fault(addr, gfn, access); vcpu_cache_mmio_info(vcpu, addr, gfn, access); - return RET_MMIO_PF_EMULATE; + return RET_PF_EMULATE; } /* * If the page table is zapped by other cpus, let CPU fault again on * the address. */ - return RET_MMIO_PF_RETRY; + return RET_PF_RETRY; } EXPORT_SYMBOL_GPL(handle_mmio_page_fault); @@ -3756,7 +3753,7 @@ static int nonpaging_page_fault(struct k pgprintk("%s: gva %lx error %x\n", __func__, gva, error_code); if (page_fault_handle_page_track(vcpu, error_code, gfn)) - return 1; + return RET_PF_EMULATE; r = mmu_topup_memory_caches(vcpu); if (r) @@ -3877,7 +3874,7 @@ static int tdp_page_fault(struct kvm_vcp MMU_WARN_ON(!VALID_PAGE(vcpu->arch.mmu.root_hpa)); if (page_fault_handle_page_track(vcpu, error_code, gfn)) - return 1; + return RET_PF_EMULATE; r = mmu_topup_memory_caches(vcpu); if (r) @@ -3894,13 +3891,13 @@ static int tdp_page_fault(struct kvm_vcp } if (fast_page_fault(vcpu, gpa, level, error_code)) - return 0; + return RET_PF_RETRY; mmu_seq = vcpu->kvm->mmu_notifier_seq; smp_rmb(); if (try_async_pf(vcpu, prefault, gfn, gpa, &pfn, write, &map_writable)) - return 0; + return RET_PF_RETRY; if (handle_abnormal_pfn(vcpu, 0, gfn, pfn, ACC_ALL, &r)) return r; @@ -3920,7 +3917,7 @@ static int tdp_page_fault(struct kvm_vcp out_unlock: spin_unlock(&vcpu->kvm->mmu_lock); kvm_release_pfn_clean(pfn); - return 0; + return RET_PF_RETRY; } static void nonpaging_init_context(struct kvm_vcpu *vcpu, @@ -4919,25 +4916,25 @@ int kvm_mmu_page_fault(struct kvm_vcpu * vcpu->arch.gpa_val = cr2; } + r = RET_PF_INVALID; if (unlikely(error_code & PFERR_RSVD_MASK)) { r = handle_mmio_page_fault(vcpu, cr2, direct); - if (r == RET_MMIO_PF_EMULATE) { + if (r == RET_PF_EMULATE) { emulation_type = 0; goto emulate; } - if (r == RET_MMIO_PF_RETRY) - return 1; - if (r < 0) - return r; - /* Must be RET_MMIO_PF_INVALID. */ } - r = vcpu->arch.mmu.page_fault(vcpu, cr2, lower_32_bits(error_code), - false); + if (r == RET_PF_INVALID) { + r = vcpu->arch.mmu.page_fault(vcpu, cr2, lower_32_bits(error_code), + false); + WARN_ON(r == RET_PF_INVALID); + } + + if (r == RET_PF_RETRY) + return 1; if (r < 0) return r; - if (!r) - return 1; /* * Before emulating the instruction, check if the error code --- a/arch/x86/kvm/paging_tmpl.h +++ b/arch/x86/kvm/paging_tmpl.h @@ -593,7 +593,7 @@ static int FNAME(fetch)(struct kvm_vcpu struct kvm_mmu_page *sp = NULL; struct kvm_shadow_walk_iterator it; unsigned direct_access, access = gw->pt_access; - int top_level, emulate; + int top_level, ret; direct_access = gw->pte_access; @@ -659,15 +659,15 @@ static int FNAME(fetch)(struct kvm_vcpu } clear_sp_write_flooding_count(it.sptep); - emulate = mmu_set_spte(vcpu, it.sptep, gw->pte_access, write_fault, - it.level, gw->gfn, pfn, prefault, map_writable); + ret = mmu_set_spte(vcpu, it.sptep, gw->pte_access, write_fault, + it.level, gw->gfn, pfn, prefault, map_writable); FNAME(pte_prefetch)(vcpu, gw, it.sptep); - return emulate; + return ret; out_gpte_changed: kvm_release_pfn_clean(pfn); - return 0; + return RET_PF_RETRY; } /* @@ -762,12 +762,12 @@ static int FNAME(page_fault)(struct kvm_ if (!prefault) inject_page_fault(vcpu, &walker.fault); - return 0; + return RET_PF_RETRY; } if (page_fault_handle_page_track(vcpu, error_code, walker.gfn)) { shadow_page_table_clear_flood(vcpu, addr); - return 1; + return RET_PF_EMULATE; } vcpu->arch.write_fault_to_shadow_pgtable = false; @@ -789,7 +789,7 @@ static int FNAME(page_fault)(struct kvm_ if (try_async_pf(vcpu, prefault, walker.gfn, addr, &pfn, write_fault, &map_writable)) - return 0; + return RET_PF_RETRY; if (handle_abnormal_pfn(vcpu, addr, walker.gfn, pfn, walker.pte_access, &r)) return r; @@ -834,7 +834,7 @@ static int FNAME(page_fault)(struct kvm_ out_unlock: spin_unlock(&vcpu->kvm->mmu_lock); kvm_release_pfn_clean(pfn); - return 0; + return RET_PF_RETRY; } static gpa_t FNAME(get_level1_sp_gpa)(struct kvm_mmu_page *sp) Patches currently in stable-queue which might be from pbonzini(a)redhat.com are queue-4.14/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch queue-4.14/kvm-x86-extend-usage-of-ret_mmio_pf_-constants.patch queue-4.14/kvm-x86-remove-indirect-msr-op-calls-from-spec_ctrl.patch queue-4.14/kvm-x86-move-lapic-initialization-after-vmcs-creation.patch queue-4.14/kvm-mmu-fix-overlap-between-public-and-private-memslots.patch queue-4.14/kvm-x86-fix-vcpu-initialization-with-userspace-lapic.patch queue-4.14/kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch

7 years, 6 months

1
0
0 0

Re: Patch "KVM: x86: move LAPIC initialization after VMCS creation" has been added to the 4.14-stable tree

by Liran Alon

----- gregkh(a)linuxfoundation.org wrote: > This is a note to let you know that I've just added the patch titled > > KVM: x86: move LAPIC initialization after VMCS creation > > to the 4.14-stable tree which can be found at: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_git_-3Fp… > > The filename of the patch is: > kvm-x86-move-lapic-initialization-after-vmcs-creation.patch > and it can be found in the queue-4.14 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 0b2e9904c15963e715d33e5f3f1387f17d19333a Mon Sep 17 00:00:00 > 2001 > From: Paolo Bonzini <pbonzini(a)redhat.com> > Date: Fri, 23 Feb 2018 23:29:32 +0100 > Subject: KVM: x86: move LAPIC initialization after VMCS creation > > From: Paolo Bonzini <pbonzini(a)redhat.com> > > commit 0b2e9904c15963e715d33e5f3f1387f17d19333a upstream. > > The initial reset of the local APIC is performed before the VMCS has > been > created, but it tries to do a vmwrite: > > vmwrite error: reg 810 value 4a00 (err 18944) > CPU: 54 PID: 38652 Comm: qemu-kvm Tainted: G W I > 4.16.0-0.rc2.git0.1.fc28.x86_64 #1 > Hardware name: Intel Corporation S2600CW/S2600CW, BIOS > SE5C610.86B.01.01.0003.090520141303 09/05/2014 > Call Trace: > vmx_set_rvi [kvm_intel] > vmx_hwapic_irr_update [kvm_intel] > kvm_lapic_reset [kvm] > kvm_create_lapic [kvm] > kvm_arch_vcpu_init [kvm] > kvm_vcpu_init [kvm] > vmx_create_vcpu [kvm_intel] > kvm_vm_ioctl [kvm] > > Move it later, after the VMCS has been created. > > Fixes: 4191db26b714 ("KVM: x86: Update APICv on APIC reset") > Cc: stable(a)vger.kernel.org > Cc: Liran Alon <liran.alon(a)oracle.com> > Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> This commit broke a rare configuration. Don't we want to apply this to stable-tree together with the fix for that? The fix is at upstream commit b7e31be38558 ("KVM: x86: fix vcpu initialization with userspace lapic") -Liran

7 years, 6 months

3
2
0 0

[GIT PULL 0/9] perf/urgent fixes

by Arnaldo Carvalho de Melo

Hi Ingo, Please consider pulling, - Arnaldo Test results at the end of this message, as usual. The following changes since commit 58bdf601c2de6071d0386a7a6fa707bd04761c47: Merge branch 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux (2018-03-03 14:55:20 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-4.16-20180306 for you to fetch changes up to 8f2c9efabe1ed212b88ce1c5cf5e768385c9222e: perf record: Combine some auxtrace initialization into a single function (2018-03-06 12:03:39 -0300) ---------------------------------------------------------------- perf/urgent fixes: - Be more robust when drawing arrows in the annotation TUI, avoiding a segfault when jump instructions have as a target addresses in functions other that the one currently being annotated. The full fix will come in the following days, when jumping to other functions will work as call instructions (Arnaldo Carvalho de Melo) - Prevent auxtrace_queues__process_index() from queuing AUX area data for decoding when the --no-itrace option has been used (Adrian Hunter) - Sync copy of kvm UAPI headers and x86's cpufeatures.h (Arnaldo Carvalho de Melo) - Fix 'perf stat' CVS output format for non-supported counters (Ilya Pronin) - Fix crash in 'perf record|perf report' pipe mode (Jiri Olsa) - Fix annoying 'perf top' overwrite fallback message on older kernels (Kan Liang) - Fix the usage on the 'perf kallsyms' man page (Sangwon Hong) Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> ---------------------------------------------------------------- The following changes since commit 317660940fd9dddd3201c2f92e25c27902c753fa: perf/x86/intel/uncore: Fix Skylake UPI event format (2018-03-04 09:59:00 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-4.16-20180306 for you to fetch changes up to de19e5c3c51fdb1ff20d0f61d099db902ff7494b: perf tools: Fix trigger class trigger_on() (2018-03-06 11:31:14 -0300) ---------------------------------------------------------------- perf/urgent fixes: - Be more robust when drawing arrows in the annotation TUI, avoiding a segfault when jump instructions have as a target addresses in functions other that the one currently being annotated. The full fix will come in the following days, when jumping to other functions will work as call instructions (Arnaldo Carvalho de Melo) - Prevent auxtrace_queues__process_index() from queuing AUX area data for decoding when the --no-itrace option has been used (Adrian Hunter) - Sync copy of kvm UAPI headers and x86's cpufeatures.h (Arnaldo Carvalho de Melo) - Fix 'perf stat' CSV output format for non-supported counters (Ilya Pronin) - Fix crash in 'perf record|perf report' pipe mode (Jiri Olsa) - Fix annoying 'perf top' overwrite fallback message on older kernels (Kan Liang) - Fix the usage on the 'perf kallsyms' man page (Sangwon Hong) Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> ---------------------------------------------------------------- Adrian Hunter (2): perf auxtrace: Prevent decoding when --no-itrace perf tools: Fix trigger class trigger_on() Arnaldo Carvalho de Melo (3): perf annotate browser: Be more robust when drawing jump arrows tools headers: Sync copy of kvm UAPI headers tools headers: Sync x86's cpufeatures.h Ilya Pronin (1): perf stat: Fix CVS output format for non-supported counters Jiri Olsa (1): perf record: Fix crash in pipe mode Kan Liang (1): perf top: Fix annoying fallback message on older kernels Sangwon Hong (1): perf kallsyms: Fix the usage on the man page tools/arch/x86/include/asm/cpufeatures.h | 1 + tools/include/uapi/linux/kvm.h | 2 ++ tools/perf/Documentation/perf-kallsyms.txt | 2 +- tools/perf/builtin-record.c | 9 +++++++++ tools/perf/builtin-stat.c | 2 +- tools/perf/builtin-top.c | 2 +- tools/perf/perf.h | 1 + tools/perf/ui/browsers/annotate.c | 25 +++++++++++++++++++++++++ tools/perf/util/auxtrace.c | 15 +++++++++------ tools/perf/util/record.c | 8 ++++++-- tools/perf/util/trigger.h | 9 +++++---- 11 files changed, 61 insertions(+), 15 deletions(-) Test results: The first ones are container (docker) based builds of tools/perf with and without libelf support. Where clang is available, it is also used to build perf with/without libelf. The objtool and samples/bpf/ builds are disabled now that I'm switching from using the sources in a local volume to fetching them from a http server to build it inside the container, to make it easier to build in a container cluster. Those will come back later. Several are cross builds, the ones with -x-ARCH and the android one, and those may not have all the features built, due to lack of multi-arch devel packages, available and being used so far on just a few, like debian:experimental-x-{arm64,mipsel}. The 'perf test' one will perform a variety of tests exercising tools/perf/util/, tools/lib/{bpf,traceevent,etc}, as well as run perf commands with a variety of command line event specifications to then intercept the sys_perf_event syscall to check that the perf_event_attr fields are set up as expected, among a variety of other unit tests. Then there is the 'make -C tools/perf build-test' ones, that build tools/perf/ with a variety of feature sets, exercising the build with an incomplete set of features as well as with a complete one. It is planned to have it run on each of the containers mentioned above, using some container orchestration infrastructure. Get in contact if interested in helping having this in place. # dm 1 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0 2 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822 3 alpine:3.6 : Ok gcc (Alpine 6.3.0) 6.3.0 4 alpine:edge : Ok gcc (Alpine 6.4.0) 6.4.0 5 amazonlinux:1 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11) 6 amazonlinux:2 : Ok gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) 7 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease) 8 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease) 9 centos:5 : Ok gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55) 10 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18) 11 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16) 12 debian:7 : Ok gcc (Debian 4.7.2-5) 4.7.2 13 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u1) 4.9.2 14 debian:9 : Ok gcc (Debian 6.3.0-18) 6.3.0 20170516 15 debian:experimental : Ok gcc (Debian 7.2.0-17) 7.2.1 20171205 16 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 17 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 18 debian:experimental-x-mips64 : Ok mips64-linux-gnuabi64-gcc (Debian 7.2.0-11) 7.2.0 19 debian:experimental-x-mipsel : Ok mipsel-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 20 fedora:20 : Ok gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7) 21 fedora:21 : Ok gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) 22 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) 23 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) 24 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1) 25 fedora:24-x-ARC-uClibc : Ok arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710 26 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1) 27 fedora:26 : Ok gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) 28 fedora:27 : Ok gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) 29 fedora:rawhide : Ok gcc (GCC) 7.2.1 20170829 (Red Hat 7.2.1-1) 30 gentoo-stage3-amd64:latest : Ok gcc (Gentoo 6.4.0-r1 p1.3) 6.4.0 31 mageia:5 : Ok gcc (GCC) 4.9.2 32 mageia:6 : Ok gcc (Mageia 5.4.0-5.mga6) 5.4.0 33 opensuse:42.1 : Ok gcc (SUSE Linux) 4.8.5 34 opensuse:42.2 : Ok gcc (SUSE Linux) 4.8.5 35 opensuse:42.3 : Ok gcc (SUSE Linux) 4.8.5 36 opensuse:tumbleweed : Ok gcc (SUSE Linux) 7.3.0 37 oraclelinux:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18) 38 oraclelinux:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16) 39 ubuntu:12.04.5 : Ok gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 40 ubuntu:14.04.4 : Ok gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 41 ubuntu:14.04.4-x-linaro-arm64 : Ok aarch64-linux-gnu-gcc (Linaro GCC 5.4-2017.05) 5.4.1 20170404 42 ubuntu:15.04 : Ok gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2 43 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609 44 ubuntu:16.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 45 ubuntu:16.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 46 ubuntu:16.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 47 ubuntu:16.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1) 5.4.0 20160609 48 ubuntu:16.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 49 ubuntu:16.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 50 ubuntu:16.10 : Ok gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005 51 ubuntu:17.04 : Ok gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406 52 ubuntu:17.10 : Ok gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0 53 ubuntu:18.04 : Ok gcc (Ubuntu 7.2.0-16ubuntu1) 7.2.0 # uname -a Linux jouet 4.16.0-rc4 #1 SMP Mon Mar 5 12:18:05 -03 2018 x86_64 x86_64 x86_64 GNU/Linux # perf test 1: vmlinux symtab matches kallsyms : Ok 2: Detect openat syscall event : Ok 3: Detect openat syscall event on all cpus : Ok 4: Read samples using the mmap interface : Ok 5: Test data source output : Ok 6: Parse event definition strings : Ok 7: Simple expression parser : Ok 8: PERF_RECORD_* events & perf_sample fields : Ok 9: Parse perf pmu format : Ok 10: DSO data read : Ok 11: DSO data cache : Ok 12: DSO data reopen : Ok 13: Roundtrip evsel->name : Ok 14: Parse sched tracepoints fields : Ok 15: syscalls:sys_enter_openat event fields : Ok 16: Setup struct perf_event_attr : Ok 17: Match and link multiple hists : Ok 18: 'import perf' in python : Ok 19: Breakpoint overflow signal handler : Ok 20: Breakpoint overflow sampling : Ok 21: Number of exit events of a simple workload : Ok 22: Software clock events period values : Ok 23: Object code reading : Ok 24: Sample parsing : Ok 25: Use a dummy software event to keep tracking : Ok 26: Parse with no sample_id_all bit set : Ok 27: Filter hist entries : Ok 28: Lookup mmap thread : Ok 29: Share thread mg : Ok 30: Sort output of hist entries : Ok 31: Cumulate child hist entries : Ok 32: Track with sched_switch : Ok 33: Filter fds with revents mask in a fdarray : Ok 34: Add fd to a fdarray, making it autogrow : Ok 35: kmod_path__parse : Ok 36: Thread map : Ok 37: LLVM search and compile : 37.1: Basic BPF llvm compile : Ok 37.2: kbuild searching : Ok 37.3: Compile source for BPF prologue generation : Ok 37.4: Compile source for BPF relocation : Ok 38: Session topology : Ok 39: BPF filter : 39.1: Basic BPF filtering : Ok 39.2: BPF pinning : Ok 39.3: BPF prologue generation : Ok 39.4: BPF relocation checker : Ok 40: Synthesize thread map : Ok 41: Remove thread map : Ok 42: Synthesize cpu map : Ok 43: Synthesize stat config : Ok 44: Synthesize stat : Ok 45: Synthesize stat round : Ok 46: Synthesize attr update : Ok 47: Event times : Ok 48: Read backward ring buffer : Ok 49: Print cpu map : Ok 50: Probe SDT events : Ok 51: is_printable_array : Ok 52: Print bitmap : Ok 53: perf hooks : Ok 54: builtin clang support : Skip (not compiled in) 55: unit_number__scnprintf : Ok 56: x86 rdpmc : Ok 57: Convert perf time to TSC : Ok 58: DWARF unwind : Ok 59: x86 instruction decoder - new instructions : Ok 60: Use vfs_getname probe to get syscall args filenames : Ok 61: probe libc's inet_pton & backtrace it with ping : Ok 62: Check open filename arg using perf trace + vfs_getname: Ok 63: probe libc's inet_pton & backtrace it with ping : Ok 64: Add vfs_getname probe to get syscall args filenames : Ok # $ make -C tools/perf build-test make: Entering directory '/home/acme/git/perf/tools/perf' - tarpkg: ./tests/perf-targz-src-pkg . make_no_auxtrace_O: make NO_AUXTRACE=1 make_debug_O: make DEBUG=1 make_no_gtk2_O: make NO_GTK2=1 make_install_bin_O: make install-bin make_no_slang_O: make NO_SLANG=1 make_no_newt_O: make NO_NEWT=1 make_no_scripts_O: make NO_LIBPYTHON=1 NO_LIBPERL=1 make_no_ui_O: make NO_NEWT=1 NO_SLANG=1 NO_GTK2=1 make_perf_o_O: make perf.o make_util_map_o_O: make util/map.o make_pure_O: make make_install_prefix_O: make install prefix=/tmp/krava make_with_clangllvm_O: make LIBCLANGLLVM=1 make_util_pmu_bison_o_O: make util/pmu-bison.o make_no_libpython_O: make NO_LIBPYTHON=1 make_no_libelf_O: make NO_LIBELF=1 make_install_O: make install make_help_O: make help make_clean_all_O: make clean all make_no_libaudit_O: make NO_LIBAUDIT=1 make_doc_O: make doc make_tags_O: make tags make_no_libdw_dwarf_unwind_O: make NO_LIBDW_DWARF_UNWIND=1 make_install_prefix_slash_O: make install prefix=/tmp/krava/ make_no_backtrace_O: make NO_BACKTRACE=1 make_no_demangle_O: make NO_DEMANGLE=1 make_no_libbionic_O: make NO_LIBBIONIC=1 make_no_libnuma_O: make NO_LIBNUMA=1 make_with_babeltrace_O: make LIBBABELTRACE=1 make_no_libunwind_O: make NO_LIBUNWIND=1 make_minimal_O: make NO_LIBPERL=1 NO_LIBPYTHON=1 NO_NEWT=1 NO_GTK2=1 NO_DEMANGLE=1 NO_LIBELF=1 NO_LIBUNWIND=1 NO_BACKTRACE=1 NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1 NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1 NO_LIBBPF=1 NO_LIBCRYPTO=1 NO_SDT=1 NO_JVMTI=1 make_no_libperl_O: make NO_LIBPERL=1 make_no_libbpf_O: make NO_LIBBPF=1 make_static_O: make LDFLAGS=-static OK make: Leaving directory '/home/acme/git/perf/tools/perf' $

7 years, 6 months

2
3
0 0

[PATCH 4.1 00/65] page table isolation for stable 4.1

by Pavel Tatashin

The git of this backport can be found here: git clone --branch pti_v4.1.49 https://github.com/soleen/linux The patches were backported from stable 4.4 to Oracle UEK4.1, and from UEK4.1 to Stable 4.1 Aaron Lu (1): x86/irq: Do not substract irq_tlb_count from irq_call_count Andy Lutomirski (16): x86/mm: Add INVPCID helpers x86/mm: Add a 'noinvpcid' boot option to turn off INVPCID x86/mm: If INVPCID is available, use it to flush global mappings sched/core: Add switch_mm_irqs_off() and use it in the scheduler x86/mm: Build arch/x86/mm/tlb.c even on !SMP x86/mm, sched/core: Turn off IRQs in switch_mm() sched/core: Idle_task_exit() shouldn't use switch_mm_irqs_off() x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly() x86/mm: Remove flush_tlb() and flush_tlb_current_task() x86/mm: Make flush_tlb_mm_range() more predictable x86/mm: Reimplement flush_tlb_page() using flush_tlb_mm_range() x86/mm: Remove the UP asm/tlbflush.h code, always use the (formerly) SMP code x86/mm: Disable PCID on 32-bit kernels x86/mm: Add the 'nopcid' boot option to turn off PCID x86/mm: Enable CR4.PCIDE on supported systems x86/mm/64: Fix reboot interaction with CR4.PCIDE Borislav Petkov (5): x86/mm: Fix INVPCID asm constraint x86/kaiser: Rename and simplify X86_FEATURE_KAISER handling x86/kaiser: Check boottime cmdline params x86/kaiser: Reenable PARAVIRT x86/kaiser: Move feature detection up Dave Hansen (2): kaiser: merged update kaiser: enhanced by kernel and user PCIDs Denys Vlasenko (3): x86/entry: Stop using PER_CPU_VAR(kernel_stack) x86/entry: Remove unused 'kernel_stack' per-cpu variable x86/entry: Define 'cpu_current_top_of_stack' for 64-bit code Hugh Dickins (26): kaiser: do not set _PAGE_NX on pgd_none kaiser: stack map PAGE_SIZE at THREAD_SIZE-PAGE_SIZE kaiser: fix build and FIXME in alloc_ldt_struct() kaiser: KAISER depends on SMP kaiser: fix regs to do_nmi() ifndef CONFIG_KAISER kaiser: fix perf crashes kaiser: ENOMEM if kaiser_pagetable_walk() NULL kaiser: tidied up asm/kaiser.h somewhat kaiser: tidied up kaiser_add/remove_mapping slightly kaiser: kaiser_remove_mapping() move along the pgd kaiser: cleanups while trying for gold link kaiser: name that 0x1000 KAISER_SHADOW_PGD_OFFSET kaiser: delete KAISER_REAL_SWITCH option kaiser: vmstat show NR_KAISERTABLE as nr_overhead kaiser: load_new_mm_cr3() let SWITCH_USER_CR3 flush user kaiser: PCID 0 for kernel and 128 for user kaiser: x86_cr3_pcid_noflush and x86_cr3_pcid_user kaiser: paranoid_entry pass cr3 need to paranoid_exit kaiser: _pgd_alloc() without __GFP_REPEAT to avoid stalls kaiser: fix unlikely error in alloc_ldt_struct() kaiser: add "nokaiser" boot option, using ALTERNATIVE kaiser: add "nokaiser" boot option, using ALTERNATIVE kaiser: use ALTERNATIVE instead of x86_cr3_pcid_noflush kaiser: drop is_atomic arg to kaiser_pagetable_walk() kaiser: asm/tlbflush.h handle noPGE at lower level kaiser: kaiser_flush_tlb_on_return_to_user() check PCID Ingo Molnar (1): mm/mmu_context, sched/core: Fix mmu_context.h assumption Jamie Iles (1): x86/ldt: fix crash in ldt freeing. Jiri Kosina (1): PTI: unbreak EFI old_memmap Kees Cook (1): KPTI: Rename to PAGE_TABLE_ISOLATION Konrad Rzeszutek Wilk (1): kpti: Disable when running under Xen PV Pavel Tatashin (3): x86/mm, sched/core: Uninline switch_mm() pti: Rename X86_FEATURE_KAISER to X86_FEATURE_PTI x86/pti/efi: broken conversion from efi to kernel page table Richard Fellner (1): KAISER: Kernel Address Isolation Steven Rostedt (1): ARM: Hide finish_arch_post_lock_switch() from modules Thomas Gleixner (1): x86/paravirt: Dont patch flush_tlb_single Tom Lendacky (1): x86/boot: Add early cmdline parsing for options with arguments Documentation/kernel-parameters.txt | 12 + arch/arm/include/asm/mmu_context.h | 2 + arch/x86/boot/compressed/misc.h | 1 + arch/x86/ia32/ia32entry.S | 11 +- arch/x86/include/asm/cmdline.h | 2 + arch/x86/include/asm/cpufeature.h | 7 + arch/x86/include/asm/desc.h | 2 +- arch/x86/include/asm/disabled-features.h | 4 +- arch/x86/include/asm/hardirq.h | 6 +- arch/x86/include/asm/hw_irq.h | 2 +- arch/x86/include/asm/kaiser.h | 151 ++++++++++ arch/x86/include/asm/mmu.h | 6 - arch/x86/include/asm/mmu_context.h | 101 +------ arch/x86/include/asm/pgtable.h | 28 +- arch/x86/include/asm/pgtable_64.h | 25 +- arch/x86/include/asm/pgtable_types.h | 29 +- arch/x86/include/asm/processor.h | 2 +- arch/x86/include/asm/thread_info.h | 8 +- arch/x86/include/asm/tlbflush.h | 233 +++++++++------ arch/x86/include/uapi/asm/processor-flags.h | 3 +- arch/x86/kernel/cpu/bugs.c | 8 + arch/x86/kernel/cpu/common.c | 86 +++++- arch/x86/kernel/cpu/perf_event_intel_ds.c | 57 +++- arch/x86/kernel/entry_64.S | 170 +++++++++-- arch/x86/kernel/espfix_64.c | 10 + arch/x86/kernel/head_64.S | 35 ++- arch/x86/kernel/irq.c | 3 +- arch/x86/kernel/irqinit.c | 2 +- arch/x86/kernel/ldt.c | 25 +- arch/x86/kernel/paravirt_patch_64.c | 2 - arch/x86/kernel/process.c | 2 +- arch/x86/kernel/process_32.c | 5 +- arch/x86/kernel/process_64.c | 3 - arch/x86/kernel/reboot.c | 4 + arch/x86/kernel/setup.c | 7 + arch/x86/kernel/smpboot.c | 2 - arch/x86/kernel/tracepoint.c | 2 + arch/x86/kernel/vm86_32.c | 2 +- arch/x86/kvm/x86.c | 3 +- arch/x86/lib/cmdline.c | 105 +++++++ arch/x86/mm/Makefile | 4 +- arch/x86/mm/init.c | 4 +- arch/x86/mm/init_64.c | 10 + arch/x86/mm/kaiser.c | 449 ++++++++++++++++++++++++++++ arch/x86/mm/pageattr.c | 63 +++- arch/x86/mm/pgtable.c | 16 +- arch/x86/mm/tlb.c | 194 ++++++++---- arch/x86/platform/efi/efi_64.c | 6 + arch/x86/realmode/init.c | 4 +- arch/x86/realmode/rm/trampoline_64.S | 3 +- arch/x86/xen/enlighten.c | 6 + arch/x86/xen/xen-asm_64.S | 6 +- include/asm-generic/vmlinux.lds.h | 7 + include/linux/kaiser.h | 52 ++++ include/linux/mmu_context.h | 7 + include/linux/mmzone.h | 3 +- include/linux/percpu-defs.h | 32 +- init/main.c | 2 + kernel/fork.c | 6 + kernel/sched/core.c | 4 +- mm/mmu_context.c | 2 +- mm/vmstat.c | 1 + security/Kconfig | 10 + 63 files changed, 1687 insertions(+), 372 deletions(-) create mode 100644 arch/x86/include/asm/kaiser.h create mode 100644 arch/x86/mm/kaiser.c create mode 100644 include/linux/kaiser.h -- 2.16.2

7 years, 6 months

2
66
0 0

[PATCH 4/7] ext4: eliminate sleep from shutdown ioctl

by Theodore Ts'o

The msleep() when processing EXT4_GOING_FLAGS_NOLOGFLUSH was a hack to avoid some races (that are now fixed), but in fact it introduced its own race. Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Cc: stable(a)vger.kernel.org --- fs/ext4/ioctl.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c index 4d1b1575f8ac..16d3d1325f5b 100644 --- a/fs/ext4/ioctl.c +++ b/fs/ext4/ioctl.c @@ -498,10 +498,8 @@ static int ext4_shutdown(struct super_block *sb, unsigned long arg) break; case EXT4_GOING_FLAGS_NOLOGFLUSH: set_bit(EXT4_FLAGS_SHUTDOWN, &sbi->s_ext4_flags); - if (sbi->s_journal && !is_journal_aborted(sbi->s_journal)) { - msleep(100); + if (sbi->s_journal && !is_journal_aborted(sbi->s_journal)) jbd2_journal_abort(sbi->s_journal, 0); - } break; default: return -EINVAL; -- 2.16.1.72.g5be1f00a9a

7 years, 6 months

2
1
0 0

[PATCH 6/7] jbd2: if the journal is aborted then don't allow update of the log tail

by Theodore Ts'o

This updates the jbd2 superblock unnecessarily, and on an abort we shouldn't truncate the log. Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Cc: stable(a)vger.kernel.org --- fs/jbd2/journal.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c index efa0c72a0b9f..dfb057900e79 100644 --- a/fs/jbd2/journal.c +++ b/fs/jbd2/journal.c @@ -974,7 +974,7 @@ int __jbd2_update_log_tail(journal_t *journal, tid_t tid, unsigned long block) } /* - * This is a variaon of __jbd2_update_log_tail which checks for validity of + * This is a variation of __jbd2_update_log_tail which checks for validity of * provided log tail and locks j_checkpoint_mutex. So it is safe against races * with other threads updating log tail. */ @@ -1417,6 +1417,9 @@ int jbd2_journal_update_sb_log_tail(journal_t *journal, tid_t tail_tid, journal_superblock_t *sb = journal->j_superblock; int ret; + if (is_journal_aborted(journal)) + return -EIO; + BUG_ON(!mutex_is_locked(&journal->j_checkpoint_mutex)); jbd_debug(1, "JBD2: updating superblock (start %lu, seq %u)\n", tail_block, tail_tid); -- 2.16.1.72.g5be1f00a9a

7 years, 6 months

2
1
0 0

Re: dm-bufio: avoid false-positive Wmaybe-uninitialized warning

by Arnd Bergmann

On Thu, Feb 22, 2018 at 5:04 PM, Mike Snitzer <snitzer(a)redhat.com> wrote: > On Thu, Feb 22 2018 at 10:56am -0500, > Arnd Bergmann <arnd(a)arndb.de> wrote: > > Mikulas already sent a fix for this: > https://patchwork.kernel.org/patch/10211631/ > > But I like yours a bit better, though I'll likely move the declaration > of 'noio_flag' temporary inside the conditional. > > Anyway, I'll get this fixed up shortly, thanks. I see the fix made it into linux-next on the same day, but the build bots still report the warning for mainline kernels and now also for stable kernels that got a backport of the patch that introduced it on arm64. I assume you had not planned to send it for mainline, any chance you could change that and send it as a bugfix with a 'Cc: stable(a)vger.kernel.org' tag to restore a clean build? Arnd

7 years, 6 months

2
2
0 0

[RESEND][PATCH] cpuidle/powernv : Restore different PSSCR for idle and hotplug

by Akshay Adiga

commit 1e1601b38e6e ("powerpc/powernv/idle: Restore SPRs for deep idle states via stop API.") uses stop-api provided by the firmware to restore PSSCR. PSSCR restore is required for handling special wakeup. When special wakeup is completed, the core enters stop state based on restored PSSCR. Currently PSSCR is restored to deepest available stop state, causing a idle cpu to enter deeper stop state on a special wakeup, which causes the cpu to hang on wakeup. A "sensors" command which reads temperature (through DTS sensors) on idle cpu can trigger special wakeup. Failed Scenario : Request restore of PSSCR with RL = 11 cpu enters idle state (stop5) user triggers "sensors" command Assert special wakeup on cpu Restores PSSCR with RL = 11 <---- Done by firmware Read DTS sensor Deassert special wakeup cpu enters idle state (stop11) <-- Instead of stop5 Cpu hang is caused because cpu ended up in a deeper state than it requested This patch fixes instability caused by special wakeup when stop11 is enabled. Requests restore of PSSCR to deepest stop state used by cpuidle. Only when offlining cpu, request restore of PSSCR to deepest stop state. On onlining cpu, request restore of PSSCR to deepest stop state used by cpuidle. Cc: <stable(a)vger.kernel.org> # v4.14+ Fixes : 1e1601b38e6e ("powerpc/powernv/idle: Restore SPRs for deep idle states via stop API.") Reported-by: Pridhiviraj Paidipeddi <ppaidipe(a)linux.vnet.ibm.com> Signed-off-by: Akshay Adiga <akshay.adiga(a)linux.vnet.ibm.com> --- arch/powerpc/include/asm/cpuidle.h | 2 ++ arch/powerpc/platforms/powernv/idle.c | 46 ++++++++++++++++++++++++++++++++--- drivers/cpuidle/cpuidle-powernv.c | 1 - 3 files changed, 45 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/cpuidle.h b/arch/powerpc/include/asm/cpuidle.h index e210a83..f52e9f1 100644 --- a/arch/powerpc/include/asm/cpuidle.h +++ b/arch/powerpc/include/asm/cpuidle.h @@ -67,6 +67,8 @@ #define ERR_EC_ESL_MISMATCH -1 #define ERR_DEEP_STATE_ESL_MISMATCH -2 +#define POWERNV_THRESHOLD_LATENCY_NS 200000 + #ifndef __ASSEMBLY__ /* Additional SPRs that need to be saved/restored during stop */ struct stop_sprs { diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c index 443d5ca..4b0c7d24 100644 --- a/arch/powerpc/platforms/powernv/idle.c +++ b/arch/powerpc/platforms/powernv/idle.c @@ -56,8 +56,11 @@ u64 pnv_first_deep_stop_state = MAX_STOP_STATE; */ static u64 pnv_deepest_stop_psscr_val; static u64 pnv_deepest_stop_psscr_mask; +static u64 pnv_deepest_cpuidle_psscr_val; +static u64 pnv_deepest_cpuidle_psscr_mask; static u64 pnv_deepest_stop_flag; static bool deepest_stop_found; +static bool deepest_cpuidle_found; static int pnv_save_sprs_for_deep_states(void) { @@ -76,7 +79,14 @@ static int pnv_save_sprs_for_deep_states(void) uint64_t hid5_val = mfspr(SPRN_HID5); uint64_t hmeer_val = mfspr(SPRN_HMEER); uint64_t msr_val = MSR_IDLE; - uint64_t psscr_val = pnv_deepest_stop_psscr_val; + + /* + * Pick deepest cpuidle psscr as the value to be + * restored through wakeup engine. + * We will request a deeper state to be restored + * in hotplug path + */ + uint64_t psscr_val = pnv_deepest_cpuidle_psscr_val; for_each_possible_cpu(cpu) { uint64_t pir = get_hard_smp_processor_id(cpu); @@ -409,7 +419,7 @@ static void pnv_program_cpu_hotplug_lpcr(unsigned int cpu, u64 lpcr_val) */ unsigned long pnv_cpu_offline(unsigned int cpu) { - unsigned long srr1; + u64 srr1; u32 idle_states = pnv_get_supported_cpuidle_states(); u64 lpcr_val; @@ -429,12 +439,18 @@ unsigned long pnv_cpu_offline(unsigned int cpu) __ppc64_runlatch_off(); if (cpu_has_feature(CPU_FTR_ARCH_300) && deepest_stop_found) { - unsigned long psscr; + u64 psscr; + u64 pir = get_hard_smp_processor_id(cpu); psscr = mfspr(SPRN_PSSCR); psscr = (psscr & ~pnv_deepest_stop_psscr_mask) | pnv_deepest_stop_psscr_val; + if (pnv_deepest_stop_psscr_val != pnv_deepest_cpuidle_psscr_val) + opal_slw_set_reg(pir, P9_STOP_SPR_PSSCR, psscr); srr1 = power9_idle_stop(psscr); + psscr = (psscr & ~pnv_deepest_cpuidle_psscr_mask) | + pnv_deepest_cpuidle_psscr_val; + opal_slw_set_reg(pir, P9_STOP_SPR_PSSCR, psscr); } else if ((idle_states & OPAL_PM_WINKLE_ENABLED) && (idle_states & OPAL_PM_LOSE_FULL_CONTEXT)) { @@ -555,6 +571,7 @@ static int __init pnv_power9_idle_init(struct device_node *np, u32 *flags, u64 *psscr_val = NULL; u64 *psscr_mask = NULL; u32 *residency_ns = NULL; + u32 *latency_ns = NULL; u64 max_residency_ns = 0; int rc = 0, i; @@ -562,6 +579,8 @@ static int __init pnv_power9_idle_init(struct device_node *np, u32 *flags, psscr_mask = kcalloc(dt_idle_states, sizeof(*psscr_mask), GFP_KERNEL); residency_ns = kcalloc(dt_idle_states, sizeof(*residency_ns), GFP_KERNEL); + latency_ns = kcalloc(dt_idle_states, sizeof(*latency_ns), + GFP_KERNEL); if (!psscr_val || !psscr_mask || !residency_ns) { rc = -1; @@ -591,6 +610,13 @@ static int __init pnv_power9_idle_init(struct device_node *np, u32 *flags, rc = -1; goto out; } + if (of_property_read_u32_array(np, + "ibm,cpu-idle-state-latencies-ns", + latency_ns, dt_idle_states)) { + pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-latency-ns in DT\n"); + rc = -1; + goto out; + } /* * Set pnv_first_deep_stop_state, pnv_deepest_stop_psscr_{val,mask}, @@ -621,6 +647,12 @@ static int __init pnv_power9_idle_init(struct device_node *np, u32 *flags, continue; } + if (latency_ns[i] <= POWERNV_THRESHOLD_LATENCY_NS) { + pnv_deepest_cpuidle_psscr_val = psscr_val[i]; + pnv_deepest_cpuidle_psscr_mask = psscr_mask[i]; + deepest_cpuidle_found = true; + } + if (max_residency_ns < residency_ns[i]) { max_residency_ns = residency_ns[i]; pnv_deepest_stop_psscr_val = psscr_val[i]; @@ -653,6 +685,14 @@ static int __init pnv_power9_idle_init(struct device_node *np, u32 *flags, pnv_deepest_stop_psscr_mask); } + if (unlikely(!deepest_cpuidle_found)) { + pr_warn("cpuidle-powernv: No suitable deepest CPU-idle state found"); + } else { + pr_info("cpuidle-powernv: Deepest cpuidle: psscr = 0x%016llx,mask=0x%016llx\n", + pnv_deepest_cpuidle_psscr_val, + pnv_deepest_cpuidle_psscr_mask); + } + pr_info("cpuidle-powernv: Requested Level (RL) value of first deep stop = 0x%llx\n", pnv_first_deep_stop_state); out: diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c index 1a8234e..620765d 100644 --- a/drivers/cpuidle/cpuidle-powernv.c +++ b/drivers/cpuidle/cpuidle-powernv.c @@ -26,7 +26,6 @@ * Expose only those Hardware idle states via the cpuidle framework * that have latency value below POWERNV_THRESHOLD_LATENCY_NS. */ -#define POWERNV_THRESHOLD_LATENCY_NS 200000 static struct cpuidle_driver powernv_idle_driver = { .name = "powernv_idle", -- 2.5.5

7 years, 6 months

3
2
0 0

Re: [PATCH 0/29] arm meltdown fix backporting review for lts 4.9

by Greg KH

On Tue, Mar 06, 2018 at 02:26:34PM +0000, Mark Brown wrote: > On Mon, Mar 05, 2018 at 02:08:59PM +0100, Greg KH wrote: > > > I know there is lots more than Android to ARM, but the huge majority by > > quantity is Android. > > > What I'm saying here is look at all of the backports that were required > > to get this working in the android tree. It was non-trivial by a long > > shot, and based on that work, this series feels really "small" and I'm > > really worried that it's not really working or solving the problem here. > > Unfortunately what's been coming over was just the bit about using > android-common, not the bit about why you're worried about the code. :( Sorry, it's been a long few months, my ability to communicate well about this topic is tough at times without assuming everyone else has been dealing with it for as long as some of us have. > > There are major features that were backported to the android trees for > > ARM that the upstream features for Spectre and Meltdown built on top of > > to get their solution. To not backport all of that is a huge risk, > > right? > > I'm not far enough into the details to comment on the specifics here; > there's other people in the CCs who are. Let's let people look at the > code and see if they think some of the fixes are useful in LTS. The > Android tree does have things beyond what's in LTS and there's been more > time for analysis since the changes were made there. I suggest looking at the backports in the android-common tree that are needed for this "feature" to work properly, and pull them out and test them if you really want it in your Linaro trees. If you think some of them should be added to the LTS kernels, I'll be glad to consider them, but don't do a hack to try to work around the lack of these features, otherwise you will not be happy in the long-run. Again, look at the mess we have for x86 in 4.4.y and 4.9.y. You do not want that for ARM for the simple reason that ARM systems usually last "longer" with those old kernels than the x86 systems do. > > So that's why I keep pointing people at the android trees. Look at what > > they did there. There's nothing stoping anyone who is really insistant > > on staying on these old kernel versions from pulling from those branches > > to get these bugfixes in a known stable, and tested, implementation. > > I think there's enough stuff going on in the Android tree to make that > unpalatable for a good segment of users. Really? Like what? Last I looked it's only about 300 or so patches. Something like less than .5% of the normal SoC backport size for any ARM system recently. There were some numbers published a few months ago about the real count, I can dig them up if you are curious. > > Or just move to 4.14.y. Seriously, that's probably the safest thing in > > the long run for anyone here. And when you realize you can't do that, > > go yell at your SoC for forcing you into the nightmare that they conned > > you into by their 3+ million lines added to their kernel tree. You were > > always living on borowed time, and it looks like that time is finally > > up... > > Yes, there are some people who are stuck with enormous out of tree patch > sets on most architectures (just look at the enterprise distros!) - but > there are also people who are at or very close to vanilla and just > trying to control their validation costs by not changing too much when > they don't need to. Great, then move to 4.14.y :) And before someone says "but it takes more to validate a new kernel version than it does to just validate a core backport for the architecture code", well... > There's a good discussion to be had about it being sensible for people > to accept more change in that segment of the market but equally those > same attitudes have been an important part of the pressure that's been > placed on vendors long term to get things in mainline. > > > [1] It's also why I keep doing the LTS merges into the android-common > > trees within days of the upstream LTS release (today being an > > exception). That way once you do a pull/merge, you can just keep > > always merging to keep a secure device that is always up to date > > with the latest LTS releases in a simple way. How much easier can I > > make it for the ARM ecosystem here, really? > > That's great for the Android ecosystem, it's fantastic work and is doing > a lot to overcome resistances people had there to merging up the LTS > which is going to help many people. While that's a very large part of > ARM ecosystem it's not all of it, there are also chip vendors and system > integrators who have made deliberate choices to minimize out of tree > code just as we've been encouraging them to. Again great, go use 4.14.y for those systems please. It's better in the long run. thanks, greg k-h

7 years, 6 months

2
1
0 0

Patch "nospec: Allow index argument to have const-qualified type" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nospec: Allow index argument to have const-qualified type to the 4.9-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: nospec-allow-index-argument-to-have-const-qualified-type.patch and it can be found in the queue-4.9 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 b98c6a160a057d5686a8c54c79cc6c8c94a7d0c8 Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Date: Fri, 16 Feb 2018 13:20:48 -0800 Subject: nospec: Allow index argument to have const-qualified type From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> commit b98c6a160a057d5686a8c54c79cc6c8c94a7d0c8 upstream. The last expression in a statement expression need not be a bare variable, quoting gcc docs The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the entire construct. and we already use that in e.g. the min/max macros which end with a ternary expression. This way, we can allow index to have const-qualified type, which will in some cases avoid the need for introducing a local copy of index of non-const qualified type. That, in turn, can prevent readers not familiar with the internals of array_index_nospec from wondering about the seemingly redundant extra variable, and I think that's worthwhile considering how confusing the whole _nospec business is. The expression _i&_mask has type unsigned long (since that is the type of _mask, and the BUILD_BUG_ONs guarantee that _i will get promoted to that), so in order not to change the type of the whole expression, add a cast back to typeof(_i). Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Acked-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Arjan van de Ven <arjan(a)linux.intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: David Woodhouse <dwmw2(a)infradead.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Will Deacon <will.deacon(a)arm.com> Cc: linux-arch(a)vger.kernel.org Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/151881604837.17395.10812767547837568328.stgit@dwil… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/nospec.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/include/linux/nospec.h +++ b/include/linux/nospec.h @@ -72,7 +72,6 @@ static inline unsigned long array_index_ BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \ BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \ \ - _i &= _mask; \ - _i; \ + (typeof(_i)) (_i & _mask); \ }) #endif /* _LINUX_NOSPEC_H */ Patches currently in stable-queue which might be from linux(a)rasmusvillemoes.dk are queue-4.9/nospec-allow-index-argument-to-have-const-qualified-type.patch

7 years, 6 months

1
0
0 0

Patch "media: m88ds3103: don't call a non-initalized function" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: m88ds3103: don't call a non-initalized function to the 4.9-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: media-m88ds3103-don-t-call-a-non-initalized-function.patch and it can be found in the queue-4.9 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 b9c97c67fd19262c002d94ced2bfb513083e161e Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Date: Sat, 10 Feb 2018 06:14:10 -0500 Subject: media: m88ds3103: don't call a non-initalized function From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> commit b9c97c67fd19262c002d94ced2bfb513083e161e upstream. If m88d3103 chip ID is not recognized, the device is not initialized. However, it returns from probe without any error, causing this OOPS: [ 7.689289] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 7.689297] pgd = 7b0bd7a7 [ 7.689302] [00000000] *pgd=00000000 [ 7.689318] Internal error: Oops: 80000005 [#1] SMP ARM [ 7.689322] Modules linked in: dvb_usb_dvbsky(+) m88ds3103 dvb_usb_v2 dvb_core videobuf2_vmalloc videobuf2_memops videobuf2_core crc32_arm_ce videodev media [ 7.689358] CPU: 3 PID: 197 Comm: systemd-udevd Not tainted 4.15.0-mcc+ #23 [ 7.689361] Hardware name: BCM2835 [ 7.689367] PC is at 0x0 [ 7.689382] LR is at m88ds3103_attach+0x194/0x1d0 [m88ds3103] [ 7.689386] pc : [<00000000>] lr : [<bf0ae1ec>] psr: 60000013 [ 7.689391] sp : ed8e5c20 ip : ed8c1e00 fp : ed8945c0 [ 7.689395] r10: ed894000 r9 : ed894378 r8 : eda736c0 [ 7.689400] r7 : ed894070 r6 : ed8e5c44 r5 : bf0bb040 r4 : eda77600 [ 7.689405] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : eda77600 [ 7.689412] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 7.689417] Control: 10c5383d Table: 2d8e806a DAC: 00000051 [ 7.689423] Process systemd-udevd (pid: 197, stack limit = 0xe9dbfb63) [ 7.689428] Stack: (0xed8e5c20 to 0xed8e6000) [ 7.689439] 5c20: ed853a80 eda73640 ed894000 ed8942c0 ed853a80 bf0b9e98 ed894070 bf0b9f10 [ 7.689449] 5c40: 00000000 00000000 bf08c17c c08dfc50 00000000 00000000 00000000 00000000 [ 7.689459] 5c60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.689468] 5c80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.689479] 5ca0: 00000000 00000000 ed8945c0 ed8942c0 ed894000 ed894830 bf0b9e98 00000000 [ 7.689490] 5cc0: ed894378 bf0a3cb4 bf0bc3b0 0000533b ed920540 00000000 00000034 bf0a6434 [ 7.689500] 5ce0: ee952070 ed826600 bf0a7038 bf0a2dd8 00000001 bf0a6768 bf0a2f90 ed8943c0 [ 7.689511] 5d00: 00000000 c08eca68 ed826620 ed826620 00000000 ee952070 bf0bc034 ee952000 [ 7.689521] 5d20: ed826600 bf0bb080 ffffffed c0aa9e9c c0aa9dac ed826620 c16edf6c c168c2c8 [ 7.689531] 5d40: c16edf70 00000000 bf0bc034 0000000d 00000000 c08e268c bf0bb080 ed826600 [ 7.689541] 5d60: bf0bc034 ed826654 ed826620 bf0bc034 c164c8bc 00000000 00000001 00000000 [ 7.689553] 5d80: 00000028 c08e2948 00000000 bf0bc034 c08e2848 c08e0778 ee9f0a58 ed88bab4 [ 7.689563] 5da0: bf0bc034 ed90ba80 c168c1f0 c08e1934 bf0bb3bc c17045ac bf0bc034 c164c8bc [ 7.689574] 5dc0: bf0bc034 bf0bb3bc ed91f564 c08e34ec bf0bc000 c164c8bc bf0bc034 c0aa8dc4 [ 7.689584] 5de0: ffffe000 00000000 bf0bf000 ed91f600 ed91f564 c03021e4 00000001 00000000 [ 7.689595] 5e00: c166e040 8040003f ed853a80 bf0bc448 00000000 c1678174 ed853a80 f0f22000 [ 7.689605] 5e20: f0f21fff 8040003f 014000c0 ed91e700 ed91e700 c16d8e68 00000001 ed91e6c0 [ 7.689615] 5e40: bf0bc400 00000001 bf0bc400 ed91f564 00000001 00000000 00000028 c03c9a24 [ 7.689625] 5e60: 00000001 c03c8c94 ed8e5f50 ed8e5f50 00000001 bf0bc400 ed91f540 c03c8cb0 [ 7.689637] 5e80: bf0bc40c 00007fff bf0bc400 c03c60b0 00000000 bf0bc448 00000028 c0e09684 [ 7.689647] 5ea0: 00000002 bf0bc530 c1234bf8 bf0bc5dc bf0bc514 c10ebbe8 ffffe000 bf000000 [ 7.689657] 5ec0: 00011538 00000000 ed8e5f48 00000000 00000000 00000000 00000000 00000000 [ 7.689666] 5ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.689676] 5f00: 00000000 00000000 7fffffff 00000000 00000013 b6e55a18 0000017b c0309104 [ 7.689686] 5f20: ed8e4000 00000000 00510af0 c03c9430 7fffffff 00000000 00000003 00000000 [ 7.689697] 5f40: 00000000 f0f0f000 00011538 00000000 f0f107b0 f0f0f000 00011538 f0f1fdb8 [ 7.689707] 5f60: f0f1fbe8 f0f1b974 00004000 000041e0 bf0bc3d0 00000001 00000000 000024c4 [ 7.689717] 5f80: 0000002d 0000002e 00000019 00000000 00000010 00000000 16894000 00000000 [ 7.689727] 5fa0: 00000000 c0308f20 16894000 00000000 00000013 b6e55a18 00000000 b6e5652c [ 7.689737] 5fc0: 16894000 00000000 00000000 0000017b 00020000 00508110 00000000 00510af0 [ 7.689748] 5fe0: bef68948 bef68938 b6e4d3d0 b6d32590 60000010 00000013 00000000 00000000 [ 7.689790] [<bf0ae1ec>] (m88ds3103_attach [m88ds3103]) from [<bf0b9f10>] (dvbsky_s960c_attach+0x78/0x280 [dvb_usb_dvbsky]) [ 7.689821] [<bf0b9f10>] (dvbsky_s960c_attach [dvb_usb_dvbsky]) from [<bf0a3cb4>] (dvb_usbv2_probe+0xa3c/0x1024 [dvb_usb_v2]) [ 7.689849] [<bf0a3cb4>] (dvb_usbv2_probe [dvb_usb_v2]) from [<c0aa9e9c>] (usb_probe_interface+0xf0/0x2a8) [ 7.689869] [<c0aa9e9c>] (usb_probe_interface) from [<c08e268c>] (driver_probe_device+0x2f8/0x4b4) [ 7.689881] [<c08e268c>] (driver_probe_device) from [<c08e2948>] (__driver_attach+0x100/0x11c) [ 7.689895] [<c08e2948>] (__driver_attach) from [<c08e0778>] (bus_for_each_dev+0x4c/0x9c) [ 7.689909] [<c08e0778>] (bus_for_each_dev) from [<c08e1934>] (bus_add_driver+0x1c0/0x264) [ 7.689919] [<c08e1934>] (bus_add_driver) from [<c08e34ec>] (driver_register+0x78/0xf4) [ 7.689931] [<c08e34ec>] (driver_register) from [<c0aa8dc4>] (usb_register_driver+0x70/0x134) [ 7.689946] [<c0aa8dc4>] (usb_register_driver) from [<c03021e4>] (do_one_initcall+0x44/0x168) [ 7.689963] [<c03021e4>] (do_one_initcall) from [<c03c9a24>] (do_init_module+0x64/0x1f4) [ 7.689979] [<c03c9a24>] (do_init_module) from [<c03c8cb0>] (load_module+0x20a0/0x25c8) [ 7.689993] [<c03c8cb0>] (load_module) from [<c03c9430>] (SyS_finit_module+0xb4/0xec) [ 7.690007] [<c03c9430>] (SyS_finit_module) from [<c0308f20>] (ret_fast_syscall+0x0/0x54) [ 7.690018] Code: bad PC value This may happen on normal circumstances, if, for some reason, the demod hangs and start returning an invalid chip ID: [ 10.394395] m88ds3103 3-0068: Unknown device. Chip_id=00 So, change the logic to cause probe to fail with -ENODEV, preventing the OOPS. Detected while testing DVB MMAP patches on Raspberry Pi 3 with DVBSky S960CI. Cc: stable(a)vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/dvb-frontends/m88ds3103.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/media/dvb-frontends/m88ds3103.c +++ b/drivers/media/dvb-frontends/m88ds3103.c @@ -1262,11 +1262,12 @@ static int m88ds3103_select(struct i2c_m * New users must use I2C client binding directly! */ struct dvb_frontend *m88ds3103_attach(const struct m88ds3103_config *cfg, - struct i2c_adapter *i2c, struct i2c_adapter **tuner_i2c_adapter) + struct i2c_adapter *i2c, + struct i2c_adapter **tuner_i2c_adapter) { struct i2c_client *client; struct i2c_board_info board_info; - struct m88ds3103_platform_data pdata; + struct m88ds3103_platform_data pdata = {}; pdata.clk = cfg->clock; pdata.i2c_wr_max = cfg->i2c_wr_max; @@ -1409,6 +1410,8 @@ static int m88ds3103_probe(struct i2c_cl case M88DS3103_CHIP_ID: break; default: + ret = -ENODEV; + dev_err(&client->dev, "Unknown device. Chip_id=%02x\n", dev->chip_id); goto err_kfree; } Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are queue-4.9/media-m88ds3103-don-t-call-a-non-initalized-function.patch

7 years, 6 months

1
0
0 0

Patch "KVM/x86: Remove indirect MSR op calls from SPEC_CTRL" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM/x86: Remove indirect MSR op calls from SPEC_CTRL to the 4.9-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: kvm-x86-remove-indirect-msr-op-calls-from-spec_ctrl.patch and it can be found in the queue-4.9 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 ecb586bd29c99fb4de599dec388658e74388daad Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Thu, 22 Feb 2018 16:43:17 +0100 Subject: KVM/x86: Remove indirect MSR op calls from SPEC_CTRL MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Paolo Bonzini <pbonzini(a)redhat.com> commit ecb586bd29c99fb4de599dec388658e74388daad upstream. Having a paravirt indirect call in the IBRS restore path is not a good idea, since we are trying to protect from speculative execution of bogus indirect branch targets. It is also slower, so use native_wrmsrl() on the vmentry path too. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Reviewed-by: Jim Mattson <jmattson(a)google.com> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Cc: KarimAllah Ahmed <karahmed(a)amazon.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: kvm(a)vger.kernel.org Cc: stable(a)vger.kernel.org Fixes: d28b387fb74da95d69d2615732f50cceb38e9a4d Link: http://lkml.kernel.org/r/20180222154318.20361-2-pbonzini@redhat.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/svm.c | 7 ++++--- arch/x86/kvm/vmx.c | 7 ++++--- 2 files changed, 8 insertions(+), 6 deletions(-) --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -44,6 +44,7 @@ #include <asm/debugreg.h> #include <asm/kvm_para.h> #include <asm/irq_remapping.h> +#include <asm/microcode.h> #include <asm/nospec-branch.h> #include <asm/virtext.h> @@ -4919,7 +4920,7 @@ static void svm_vcpu_run(struct kvm_vcpu * being speculatively taken. */ if (svm->spec_ctrl) - wrmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl); + native_wrmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl); asm volatile ( "push %%" _ASM_BP "; \n\t" @@ -5029,10 +5030,10 @@ static void svm_vcpu_run(struct kvm_vcpu * save it. */ if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)) - rdmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl); + svm->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL); if (svm->spec_ctrl) - wrmsrl(MSR_IA32_SPEC_CTRL, 0); + native_wrmsrl(MSR_IA32_SPEC_CTRL, 0); /* Eliminate branch target predictions from guest mode */ vmexit_fill_RSB(); --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -49,6 +49,7 @@ #include <asm/kexec.h> #include <asm/apic.h> #include <asm/irq_remapping.h> +#include <asm/microcode.h> #include <asm/nospec-branch.h> #include "trace.h" @@ -8906,7 +8907,7 @@ static void __noclone vmx_vcpu_run(struc * being speculatively taken. */ if (vmx->spec_ctrl) - wrmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl); + native_wrmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl); vmx->__launched = vmx->loaded_vmcs->launched; asm( @@ -9042,10 +9043,10 @@ static void __noclone vmx_vcpu_run(struc * save it. */ if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)) - rdmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl); + vmx->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL); if (vmx->spec_ctrl) - wrmsrl(MSR_IA32_SPEC_CTRL, 0); + native_wrmsrl(MSR_IA32_SPEC_CTRL, 0); /* Eliminate branch target predictions from guest mode */ vmexit_fill_RSB(); Patches currently in stable-queue which might be from pbonzini(a)redhat.com are queue-4.9/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch queue-4.9/kvm-x86-remove-indirect-msr-op-calls-from-spec_ctrl.patch queue-4.9/kvm-mmu-fix-overlap-between-public-and-private-memslots.patch queue-4.9/kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch

7 years, 6 months

1
0
0 0

Patch "KVM: X86: Fix SMRAM accessing even if VM is shutdown" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: X86: Fix SMRAM accessing even if VM is shutdown to the 4.9-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: kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch and it can be found in the queue-4.9 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 95e057e25892eaa48cad1e2d637b80d0f1a4fac5 Mon Sep 17 00:00:00 2001 From: Wanpeng Li <wanpengli(a)tencent.com> Date: Thu, 8 Feb 2018 15:32:45 +0800 Subject: KVM: X86: Fix SMRAM accessing even if VM is shutdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Wanpeng Li <wanpengli(a)tencent.com> commit 95e057e25892eaa48cad1e2d637b80d0f1a4fac5 upstream. Reported by syzkaller: WARNING: CPU: 6 PID: 2434 at arch/x86/kvm/vmx.c:6660 handle_ept_misconfig+0x54/0x1e0 [kvm_intel] CPU: 6 PID: 2434 Comm: repro_test Not tainted 4.15.0+ #4 RIP: 0010:handle_ept_misconfig+0x54/0x1e0 [kvm_intel] Call Trace: vmx_handle_exit+0xbd/0xe20 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xdaf/0x1d50 [kvm] kvm_vcpu_ioctl+0x3e9/0x720 [kvm] do_vfs_ioctl+0xa4/0x6a0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x25/0x9c The testcase creates a first thread to issue KVM_SMI ioctl, and then creates a second thread to mmap and operate on the same vCPU. This triggers a race condition when running the testcase with multiple threads. Sometimes one thread exits with a triple fault while another thread mmaps and operates on the same vCPU. Because CS=0x3000/IP=0x8000 is not mapped, accessing the SMI handler results in an EPT misconfig. This patch fixes it by returning RET_PF_EMULATE in kvm_handle_bad_page(), which will go on to cause an emulation failure and an exit with KVM_EXIT_INTERNAL_ERROR. Reported-by: syzbot+c1d9517cab094dae65e446c0c5b4de6c40f4dc58(a)syzkaller.appspotmail.com Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -2808,7 +2808,7 @@ static int kvm_handle_bad_page(struct kv return 0; } - return -EFAULT; + return RET_PF_EMULATE; } static void transparent_hugepage_adjust(struct kvm_vcpu *vcpu, Patches currently in stable-queue which might be from wanpengli(a)tencent.com are queue-4.9/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch

7 years, 6 months

1
0
0 0

Patch "KVM/VMX: Optimize vmx_vcpu_run() and svm_vcpu_run() by marking the RDMSR path as unlikely()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM/VMX: Optimize vmx_vcpu_run() and svm_vcpu_run() by marking the RDMSR path as unlikely() to the 4.9-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: kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch and it can be found in the queue-4.9 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 946fbbc13dce68902f64515b610eeb2a6c3d7a64 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Thu, 22 Feb 2018 16:43:18 +0100 Subject: KVM/VMX: Optimize vmx_vcpu_run() and svm_vcpu_run() by marking the RDMSR path as unlikely() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Paolo Bonzini <pbonzini(a)redhat.com> commit 946fbbc13dce68902f64515b610eeb2a6c3d7a64 upstream. vmx_vcpu_run() and svm_vcpu_run() are large functions, and giving branch hints to the compiler can actually make a substantial cycle difference by keeping the fast path contiguous in memory. With this optimization, the retpoline-guest/retpoline-host case is about 50 cycles faster. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Reviewed-by: Jim Mattson <jmattson(a)google.com> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Cc: KarimAllah Ahmed <karahmed(a)amazon.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: kvm(a)vger.kernel.org Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/20180222154318.20361-3-pbonzini@redhat.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/svm.c | 2 +- arch/x86/kvm/vmx.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -5029,7 +5029,7 @@ static void svm_vcpu_run(struct kvm_vcpu * If the L02 MSR bitmap does not intercept the MSR, then we need to * save it. */ - if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)) + if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))) svm->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL); if (svm->spec_ctrl) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -9042,7 +9042,7 @@ static void __noclone vmx_vcpu_run(struc * If the L02 MSR bitmap does not intercept the MSR, then we need to * save it. */ - if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)) + if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))) vmx->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL); if (vmx->spec_ctrl) Patches currently in stable-queue which might be from pbonzini(a)redhat.com are queue-4.9/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch queue-4.9/kvm-x86-remove-indirect-msr-op-calls-from-spec_ctrl.patch queue-4.9/kvm-mmu-fix-overlap-between-public-and-private-memslots.patch queue-4.9/kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch

7 years, 6 months

1
0
0 0

Patch "ARM: mvebu: Fix broken PL310_ERRATA_753970 selects" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: mvebu: Fix broken PL310_ERRATA_753970 selects to the 4.9-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: arm-mvebu-fix-broken-pl310_errata_753970-selects.patch and it can be found in the queue-4.9 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 8aa36a8dcde3183d84db7b0d622ffddcebb61077 Mon Sep 17 00:00:00 2001 From: Ulf Magnusson <ulfalizer(a)gmail.com> Date: Mon, 5 Feb 2018 02:21:13 +0100 Subject: ARM: mvebu: Fix broken PL310_ERRATA_753970 selects From: Ulf Magnusson <ulfalizer(a)gmail.com> commit 8aa36a8dcde3183d84db7b0d622ffddcebb61077 upstream. The MACH_ARMADA_375 and MACH_ARMADA_38X boards select ARM_ERRATA_753970, but it was renamed to PL310_ERRATA_753970 by commit fa0ce4035d48 ("ARM: 7162/1: errata: tidy up Kconfig options for PL310 errata workarounds"). Fix the selects to use the new name. Discovered with the https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined… script. Fixes: fa0ce4035d48 ("ARM: 7162/1: errata: tidy up Kconfig options for PL310 errata workarounds" cc: stable(a)vger.kernel.org Signed-off-by: Ulf Magnusson <ulfalizer(a)gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/mach-mvebu/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -42,7 +42,7 @@ config MACH_ARMADA_375 depends on ARCH_MULTI_V7 select ARMADA_370_XP_IRQ select ARM_ERRATA_720789 - select ARM_ERRATA_753970 + select PL310_ERRATA_753970 select ARM_GIC select ARMADA_375_CLK select HAVE_ARM_SCU @@ -58,7 +58,7 @@ config MACH_ARMADA_38X bool "Marvell Armada 380/385 boards" depends on ARCH_MULTI_V7 select ARM_ERRATA_720789 - select ARM_ERRATA_753970 + select PL310_ERRATA_753970 select ARM_GIC select ARMADA_370_XP_IRQ select ARMADA_38X_CLK Patches currently in stable-queue which might be from ulfalizer(a)gmail.com are queue-4.9/arm-mvebu-fix-broken-pl310_errata_753970-selects.patch

7 years, 6 months

1
0
0 0

Patch "KVM: mmu: Fix overlap between public and private memslots" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: mmu: Fix overlap between public and private memslots to the 4.9-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: kvm-mmu-fix-overlap-between-public-and-private-memslots.patch and it can be found in the queue-4.9 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 b28676bb8ae4569cced423dc2a88f7cb319d5379 Mon Sep 17 00:00:00 2001 From: Wanpeng Li <wanpeng.li(a)hotmail.com> Date: Tue, 13 Feb 2018 15:36:00 +0100 Subject: KVM: mmu: Fix overlap between public and private memslots MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Wanpeng Li <wanpeng.li(a)hotmail.com> commit b28676bb8ae4569cced423dc2a88f7cb319d5379 upstream. Reported by syzkaller: pte_list_remove: ffff9714eb1f8078 0->BUG ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/mmu.c:1157! invalid opcode: 0000 [#1] SMP RIP: 0010:pte_list_remove+0x11b/0x120 [kvm] Call Trace: drop_spte+0x83/0xb0 [kvm] mmu_page_zap_pte+0xcc/0xe0 [kvm] kvm_mmu_prepare_zap_page+0x81/0x4a0 [kvm] kvm_mmu_invalidate_zap_all_pages+0x159/0x220 [kvm] kvm_arch_flush_shadow_all+0xe/0x10 [kvm] kvm_mmu_notifier_release+0x6c/0xa0 [kvm] ? kvm_mmu_notifier_release+0x5/0xa0 [kvm] __mmu_notifier_release+0x79/0x110 ? __mmu_notifier_release+0x5/0x110 exit_mmap+0x15a/0x170 ? do_exit+0x281/0xcb0 mmput+0x66/0x160 do_exit+0x2c9/0xcb0 ? __context_tracking_exit.part.5+0x4a/0x150 do_group_exit+0x50/0xd0 SyS_exit_group+0x14/0x20 do_syscall_64+0x73/0x1f0 entry_SYSCALL64_slow_path+0x25/0x25 The reason is that when creates new memslot, there is no guarantee for new memslot not overlap with private memslots. This can be triggered by the following program: #include <fcntl.h> #include <pthread.h> #include <setjmp.h> #include <signal.h> #include <stddef.h> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/ioctl.h> #include <sys/stat.h> #include <sys/syscall.h> #include <sys/types.h> #include <unistd.h> #include <linux/kvm.h> long r[16]; int main() { void *p = valloc(0x4000); r[2] = open("/dev/kvm", 0); r[3] = ioctl(r[2], KVM_CREATE_VM, 0x0ul); uint64_t addr = 0xf000; ioctl(r[3], KVM_SET_IDENTITY_MAP_ADDR, &addr); r[6] = ioctl(r[3], KVM_CREATE_VCPU, 0x0ul); ioctl(r[3], KVM_SET_TSS_ADDR, 0x0ul); ioctl(r[6], KVM_RUN, 0); ioctl(r[6], KVM_RUN, 0); struct kvm_userspace_memory_region mr = { .slot = 0, .flags = KVM_MEM_LOG_DIRTY_PAGES, .guest_phys_addr = 0xf000, .memory_size = 0x4000, .userspace_addr = (uintptr_t) p }; ioctl(r[3], KVM_SET_USER_MEMORY_REGION, &mr); return 0; } This patch fixes the bug by not adding a new memslot even if it overlaps with private memslots. Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Eric Biggers <ebiggers3(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com> --- virt/kvm/kvm_main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -976,8 +976,7 @@ int __kvm_set_memory_region(struct kvm * /* Check for overlaps */ r = -EEXIST; kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) { - if ((slot->id >= KVM_USER_MEM_SLOTS) || - (slot->id == id)) + if (slot->id == id) continue; if (!((base_gfn + npages <= slot->base_gfn) || (base_gfn >= slot->base_gfn + slot->npages))) Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are queue-4.9/kvm-mmu-fix-overlap-between-public-and-private-memslots.patch

7 years, 6 months

1
0
0 0

Patch "ARM: kvm: fix building with gcc-8" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: kvm: fix building with gcc-8 to the 4.9-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: arm-kvm-fix-building-with-gcc-8.patch and it can be found in the queue-4.9 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 67870eb1204223598ea6d8a4467b482e9f5875b5 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Fri, 2 Feb 2018 16:07:34 +0100 Subject: ARM: kvm: fix building with gcc-8 From: Arnd Bergmann <arnd(a)arndb.de> commit 67870eb1204223598ea6d8a4467b482e9f5875b5 upstream. In banked-sr.c, we use a top-level '__asm__(".arch_extension virt")' statement to allow compilation of a multi-CPU kernel for ARMv6 and older ARMv7-A that don't normally support access to the banked registers. This is considered to be a programming error by the gcc developers and will no longer work in gcc-8, where we now get a build error: /tmp/cc4Qy7GR.s:34: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_usr' /tmp/cc4Qy7GR.s:41: Error: Banked registers are not available with this architecture. -- `mrs r3,ELR_hyp' /tmp/cc4Qy7GR.s:55: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_svc' /tmp/cc4Qy7GR.s:62: Error: Banked registers are not available with this architecture. -- `mrs r3,LR_svc' /tmp/cc4Qy7GR.s:69: Error: Banked registers are not available with this architecture. -- `mrs r3,SPSR_svc' /tmp/cc4Qy7GR.s:76: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_abt' Passign the '-march-armv7ve' flag to gcc works, and is ok here, because we know the functions won't ever be called on pre-ARMv7VE machines. Unfortunately, older compiler versions (4.8 and earlier) do not understand that flag, so we still need to keep the asm around. Backporting to stable kernels (4.6+) is needed to allow those to be built with future compilers as well. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84129 Fixes: 33280b4cd1dc ("ARM: KVM: Add banked registers save/restore") Cc: stable(a)vger.kernel.org Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/kvm/hyp/Makefile | 5 +++++ arch/arm/kvm/hyp/banked-sr.c | 4 ++++ 2 files changed, 9 insertions(+) --- a/arch/arm/kvm/hyp/Makefile +++ b/arch/arm/kvm/hyp/Makefile @@ -6,6 +6,8 @@ ccflags-y += -fno-stack-protector -DDISA KVM=../../../../virt/kvm +CFLAGS_ARMV7VE :=$(call cc-option, -march=armv7ve) + obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v3-sr.o obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/timer-sr.o @@ -14,7 +16,10 @@ obj-$(CONFIG_KVM_ARM_HOST) += tlb.o obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o obj-$(CONFIG_KVM_ARM_HOST) += vfp.o obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o +CFLAGS_banked-sr.o += $(CFLAGS_ARMV7VE) + obj-$(CONFIG_KVM_ARM_HOST) += entry.o obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o obj-$(CONFIG_KVM_ARM_HOST) += switch.o +CFLAGS_switch.o += $(CFLAGS_ARMV7VE) obj-$(CONFIG_KVM_ARM_HOST) += s2-setup.o --- a/arch/arm/kvm/hyp/banked-sr.c +++ b/arch/arm/kvm/hyp/banked-sr.c @@ -20,6 +20,10 @@ #include <asm/kvm_hyp.h> +/* + * gcc before 4.9 doesn't understand -march=armv7ve, so we have to + * trick the assembler. + */ __asm__(".arch_extension virt"); void __hyp_text __banked_save_state(struct kvm_cpu_context *ctxt) Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.9/tpm-constify-transmit-data-pointers.patch queue-4.9/arm-kvm-fix-building-with-gcc-8.patch

7 years, 6 months

1
0
0 0

Patch "nospec: Allow index argument to have const-qualified type" 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 nospec: Allow index argument to have const-qualified type 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: nospec-allow-index-argument-to-have-const-qualified-type.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 b98c6a160a057d5686a8c54c79cc6c8c94a7d0c8 Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Date: Fri, 16 Feb 2018 13:20:48 -0800 Subject: nospec: Allow index argument to have const-qualified type From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> commit b98c6a160a057d5686a8c54c79cc6c8c94a7d0c8 upstream. The last expression in a statement expression need not be a bare variable, quoting gcc docs The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the entire construct. and we already use that in e.g. the min/max macros which end with a ternary expression. This way, we can allow index to have const-qualified type, which will in some cases avoid the need for introducing a local copy of index of non-const qualified type. That, in turn, can prevent readers not familiar with the internals of array_index_nospec from wondering about the seemingly redundant extra variable, and I think that's worthwhile considering how confusing the whole _nospec business is. The expression _i&_mask has type unsigned long (since that is the type of _mask, and the BUILD_BUG_ONs guarantee that _i will get promoted to that), so in order not to change the type of the whole expression, add a cast back to typeof(_i). Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Acked-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Arjan van de Ven <arjan(a)linux.intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: David Woodhouse <dwmw2(a)infradead.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Will Deacon <will.deacon(a)arm.com> Cc: linux-arch(a)vger.kernel.org Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/151881604837.17395.10812767547837568328.stgit@dwil… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/nospec.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/include/linux/nospec.h +++ b/include/linux/nospec.h @@ -66,7 +66,6 @@ static inline unsigned long array_index_ BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \ BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \ \ - _i &= _mask; \ - _i; \ + (typeof(_i)) (_i & _mask); \ }) #endif /* _LINUX_NOSPEC_H */ Patches currently in stable-queue which might be from linux(a)rasmusvillemoes.dk are queue-4.4/nospec-allow-index-argument-to-have-const-qualified-type.patch

7 years, 6 months

1
0
0 0

Patch "media: m88ds3103: don't call a non-initalized function" 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 media: m88ds3103: don't call a non-initalized function 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: media-m88ds3103-don-t-call-a-non-initalized-function.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 b9c97c67fd19262c002d94ced2bfb513083e161e Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Date: Sat, 10 Feb 2018 06:14:10 -0500 Subject: media: m88ds3103: don't call a non-initalized function From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> commit b9c97c67fd19262c002d94ced2bfb513083e161e upstream. If m88d3103 chip ID is not recognized, the device is not initialized. However, it returns from probe without any error, causing this OOPS: [ 7.689289] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 7.689297] pgd = 7b0bd7a7 [ 7.689302] [00000000] *pgd=00000000 [ 7.689318] Internal error: Oops: 80000005 [#1] SMP ARM [ 7.689322] Modules linked in: dvb_usb_dvbsky(+) m88ds3103 dvb_usb_v2 dvb_core videobuf2_vmalloc videobuf2_memops videobuf2_core crc32_arm_ce videodev media [ 7.689358] CPU: 3 PID: 197 Comm: systemd-udevd Not tainted 4.15.0-mcc+ #23 [ 7.689361] Hardware name: BCM2835 [ 7.689367] PC is at 0x0 [ 7.689382] LR is at m88ds3103_attach+0x194/0x1d0 [m88ds3103] [ 7.689386] pc : [<00000000>] lr : [<bf0ae1ec>] psr: 60000013 [ 7.689391] sp : ed8e5c20 ip : ed8c1e00 fp : ed8945c0 [ 7.689395] r10: ed894000 r9 : ed894378 r8 : eda736c0 [ 7.689400] r7 : ed894070 r6 : ed8e5c44 r5 : bf0bb040 r4 : eda77600 [ 7.689405] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : eda77600 [ 7.689412] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 7.689417] Control: 10c5383d Table: 2d8e806a DAC: 00000051 [ 7.689423] Process systemd-udevd (pid: 197, stack limit = 0xe9dbfb63) [ 7.689428] Stack: (0xed8e5c20 to 0xed8e6000) [ 7.689439] 5c20: ed853a80 eda73640 ed894000 ed8942c0 ed853a80 bf0b9e98 ed894070 bf0b9f10 [ 7.689449] 5c40: 00000000 00000000 bf08c17c c08dfc50 00000000 00000000 00000000 00000000 [ 7.689459] 5c60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.689468] 5c80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.689479] 5ca0: 00000000 00000000 ed8945c0 ed8942c0 ed894000 ed894830 bf0b9e98 00000000 [ 7.689490] 5cc0: ed894378 bf0a3cb4 bf0bc3b0 0000533b ed920540 00000000 00000034 bf0a6434 [ 7.689500] 5ce0: ee952070 ed826600 bf0a7038 bf0a2dd8 00000001 bf0a6768 bf0a2f90 ed8943c0 [ 7.689511] 5d00: 00000000 c08eca68 ed826620 ed826620 00000000 ee952070 bf0bc034 ee952000 [ 7.689521] 5d20: ed826600 bf0bb080 ffffffed c0aa9e9c c0aa9dac ed826620 c16edf6c c168c2c8 [ 7.689531] 5d40: c16edf70 00000000 bf0bc034 0000000d 00000000 c08e268c bf0bb080 ed826600 [ 7.689541] 5d60: bf0bc034 ed826654 ed826620 bf0bc034 c164c8bc 00000000 00000001 00000000 [ 7.689553] 5d80: 00000028 c08e2948 00000000 bf0bc034 c08e2848 c08e0778 ee9f0a58 ed88bab4 [ 7.689563] 5da0: bf0bc034 ed90ba80 c168c1f0 c08e1934 bf0bb3bc c17045ac bf0bc034 c164c8bc [ 7.689574] 5dc0: bf0bc034 bf0bb3bc ed91f564 c08e34ec bf0bc000 c164c8bc bf0bc034 c0aa8dc4 [ 7.689584] 5de0: ffffe000 00000000 bf0bf000 ed91f600 ed91f564 c03021e4 00000001 00000000 [ 7.689595] 5e00: c166e040 8040003f ed853a80 bf0bc448 00000000 c1678174 ed853a80 f0f22000 [ 7.689605] 5e20: f0f21fff 8040003f 014000c0 ed91e700 ed91e700 c16d8e68 00000001 ed91e6c0 [ 7.689615] 5e40: bf0bc400 00000001 bf0bc400 ed91f564 00000001 00000000 00000028 c03c9a24 [ 7.689625] 5e60: 00000001 c03c8c94 ed8e5f50 ed8e5f50 00000001 bf0bc400 ed91f540 c03c8cb0 [ 7.689637] 5e80: bf0bc40c 00007fff bf0bc400 c03c60b0 00000000 bf0bc448 00000028 c0e09684 [ 7.689647] 5ea0: 00000002 bf0bc530 c1234bf8 bf0bc5dc bf0bc514 c10ebbe8 ffffe000 bf000000 [ 7.689657] 5ec0: 00011538 00000000 ed8e5f48 00000000 00000000 00000000 00000000 00000000 [ 7.689666] 5ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.689676] 5f00: 00000000 00000000 7fffffff 00000000 00000013 b6e55a18 0000017b c0309104 [ 7.689686] 5f20: ed8e4000 00000000 00510af0 c03c9430 7fffffff 00000000 00000003 00000000 [ 7.689697] 5f40: 00000000 f0f0f000 00011538 00000000 f0f107b0 f0f0f000 00011538 f0f1fdb8 [ 7.689707] 5f60: f0f1fbe8 f0f1b974 00004000 000041e0 bf0bc3d0 00000001 00000000 000024c4 [ 7.689717] 5f80: 0000002d 0000002e 00000019 00000000 00000010 00000000 16894000 00000000 [ 7.689727] 5fa0: 00000000 c0308f20 16894000 00000000 00000013 b6e55a18 00000000 b6e5652c [ 7.689737] 5fc0: 16894000 00000000 00000000 0000017b 00020000 00508110 00000000 00510af0 [ 7.689748] 5fe0: bef68948 bef68938 b6e4d3d0 b6d32590 60000010 00000013 00000000 00000000 [ 7.689790] [<bf0ae1ec>] (m88ds3103_attach [m88ds3103]) from [<bf0b9f10>] (dvbsky_s960c_attach+0x78/0x280 [dvb_usb_dvbsky]) [ 7.689821] [<bf0b9f10>] (dvbsky_s960c_attach [dvb_usb_dvbsky]) from [<bf0a3cb4>] (dvb_usbv2_probe+0xa3c/0x1024 [dvb_usb_v2]) [ 7.689849] [<bf0a3cb4>] (dvb_usbv2_probe [dvb_usb_v2]) from [<c0aa9e9c>] (usb_probe_interface+0xf0/0x2a8) [ 7.689869] [<c0aa9e9c>] (usb_probe_interface) from [<c08e268c>] (driver_probe_device+0x2f8/0x4b4) [ 7.689881] [<c08e268c>] (driver_probe_device) from [<c08e2948>] (__driver_attach+0x100/0x11c) [ 7.689895] [<c08e2948>] (__driver_attach) from [<c08e0778>] (bus_for_each_dev+0x4c/0x9c) [ 7.689909] [<c08e0778>] (bus_for_each_dev) from [<c08e1934>] (bus_add_driver+0x1c0/0x264) [ 7.689919] [<c08e1934>] (bus_add_driver) from [<c08e34ec>] (driver_register+0x78/0xf4) [ 7.689931] [<c08e34ec>] (driver_register) from [<c0aa8dc4>] (usb_register_driver+0x70/0x134) [ 7.689946] [<c0aa8dc4>] (usb_register_driver) from [<c03021e4>] (do_one_initcall+0x44/0x168) [ 7.689963] [<c03021e4>] (do_one_initcall) from [<c03c9a24>] (do_init_module+0x64/0x1f4) [ 7.689979] [<c03c9a24>] (do_init_module) from [<c03c8cb0>] (load_module+0x20a0/0x25c8) [ 7.689993] [<c03c8cb0>] (load_module) from [<c03c9430>] (SyS_finit_module+0xb4/0xec) [ 7.690007] [<c03c9430>] (SyS_finit_module) from [<c0308f20>] (ret_fast_syscall+0x0/0x54) [ 7.690018] Code: bad PC value This may happen on normal circumstances, if, for some reason, the demod hangs and start returning an invalid chip ID: [ 10.394395] m88ds3103 3-0068: Unknown device. Chip_id=00 So, change the logic to cause probe to fail with -ENODEV, preventing the OOPS. Detected while testing DVB MMAP patches on Raspberry Pi 3 with DVBSky S960CI. Cc: stable(a)vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/dvb-frontends/m88ds3103.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/media/dvb-frontends/m88ds3103.c +++ b/drivers/media/dvb-frontends/m88ds3103.c @@ -1281,11 +1281,12 @@ static int m88ds3103_select(struct i2c_a * New users must use I2C client binding directly! */ struct dvb_frontend *m88ds3103_attach(const struct m88ds3103_config *cfg, - struct i2c_adapter *i2c, struct i2c_adapter **tuner_i2c_adapter) + struct i2c_adapter *i2c, + struct i2c_adapter **tuner_i2c_adapter) { struct i2c_client *client; struct i2c_board_info board_info; - struct m88ds3103_platform_data pdata; + struct m88ds3103_platform_data pdata = {}; pdata.clk = cfg->clock; pdata.i2c_wr_max = cfg->i2c_wr_max; @@ -1428,6 +1429,8 @@ static int m88ds3103_probe(struct i2c_cl case M88DS3103_CHIP_ID: break; default: + ret = -ENODEV; + dev_err(&client->dev, "Unknown device. Chip_id=%02x\n", dev->chip_id); goto err_kfree; } Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are queue-4.4/media-m88ds3103-don-t-call-a-non-initalized-function.patch

7 years, 6 months

1
0
0 0

Patch "KVM: X86: Fix SMRAM accessing even if VM is shutdown" 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 KVM: X86: Fix SMRAM accessing even if VM is shutdown 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: kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.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 95e057e25892eaa48cad1e2d637b80d0f1a4fac5 Mon Sep 17 00:00:00 2001 From: Wanpeng Li <wanpengli(a)tencent.com> Date: Thu, 8 Feb 2018 15:32:45 +0800 Subject: KVM: X86: Fix SMRAM accessing even if VM is shutdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Wanpeng Li <wanpengli(a)tencent.com> commit 95e057e25892eaa48cad1e2d637b80d0f1a4fac5 upstream. Reported by syzkaller: WARNING: CPU: 6 PID: 2434 at arch/x86/kvm/vmx.c:6660 handle_ept_misconfig+0x54/0x1e0 [kvm_intel] CPU: 6 PID: 2434 Comm: repro_test Not tainted 4.15.0+ #4 RIP: 0010:handle_ept_misconfig+0x54/0x1e0 [kvm_intel] Call Trace: vmx_handle_exit+0xbd/0xe20 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xdaf/0x1d50 [kvm] kvm_vcpu_ioctl+0x3e9/0x720 [kvm] do_vfs_ioctl+0xa4/0x6a0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x25/0x9c The testcase creates a first thread to issue KVM_SMI ioctl, and then creates a second thread to mmap and operate on the same vCPU. This triggers a race condition when running the testcase with multiple threads. Sometimes one thread exits with a triple fault while another thread mmaps and operates on the same vCPU. Because CS=0x3000/IP=0x8000 is not mapped, accessing the SMI handler results in an EPT misconfig. This patch fixes it by returning RET_PF_EMULATE in kvm_handle_bad_page(), which will go on to cause an emulation failure and an exit with KVM_EXIT_INTERNAL_ERROR. Reported-by: syzbot+c1d9517cab094dae65e446c0c5b4de6c40f4dc58(a)syzkaller.appspotmail.com Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -2775,7 +2775,7 @@ static int kvm_handle_bad_page(struct kv return 0; } - return -EFAULT; + return RET_PF_EMULATE; } static void transparent_hugepage_adjust(struct kvm_vcpu *vcpu, Patches currently in stable-queue which might be from wanpengli(a)tencent.com are queue-4.4/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch

7 years, 6 months

1
0
0 0

Patch "KVM: mmu: Fix overlap between public and private memslots" 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 KVM: mmu: Fix overlap between public and private memslots 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: kvm-mmu-fix-overlap-between-public-and-private-memslots.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 b28676bb8ae4569cced423dc2a88f7cb319d5379 Mon Sep 17 00:00:00 2001 From: Wanpeng Li <wanpeng.li(a)hotmail.com> Date: Tue, 13 Feb 2018 15:36:00 +0100 Subject: KVM: mmu: Fix overlap between public and private memslots MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Wanpeng Li <wanpeng.li(a)hotmail.com> commit b28676bb8ae4569cced423dc2a88f7cb319d5379 upstream. Reported by syzkaller: pte_list_remove: ffff9714eb1f8078 0->BUG ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/mmu.c:1157! invalid opcode: 0000 [#1] SMP RIP: 0010:pte_list_remove+0x11b/0x120 [kvm] Call Trace: drop_spte+0x83/0xb0 [kvm] mmu_page_zap_pte+0xcc/0xe0 [kvm] kvm_mmu_prepare_zap_page+0x81/0x4a0 [kvm] kvm_mmu_invalidate_zap_all_pages+0x159/0x220 [kvm] kvm_arch_flush_shadow_all+0xe/0x10 [kvm] kvm_mmu_notifier_release+0x6c/0xa0 [kvm] ? kvm_mmu_notifier_release+0x5/0xa0 [kvm] __mmu_notifier_release+0x79/0x110 ? __mmu_notifier_release+0x5/0x110 exit_mmap+0x15a/0x170 ? do_exit+0x281/0xcb0 mmput+0x66/0x160 do_exit+0x2c9/0xcb0 ? __context_tracking_exit.part.5+0x4a/0x150 do_group_exit+0x50/0xd0 SyS_exit_group+0x14/0x20 do_syscall_64+0x73/0x1f0 entry_SYSCALL64_slow_path+0x25/0x25 The reason is that when creates new memslot, there is no guarantee for new memslot not overlap with private memslots. This can be triggered by the following program: #include <fcntl.h> #include <pthread.h> #include <setjmp.h> #include <signal.h> #include <stddef.h> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/ioctl.h> #include <sys/stat.h> #include <sys/syscall.h> #include <sys/types.h> #include <unistd.h> #include <linux/kvm.h> long r[16]; int main() { void *p = valloc(0x4000); r[2] = open("/dev/kvm", 0); r[3] = ioctl(r[2], KVM_CREATE_VM, 0x0ul); uint64_t addr = 0xf000; ioctl(r[3], KVM_SET_IDENTITY_MAP_ADDR, &addr); r[6] = ioctl(r[3], KVM_CREATE_VCPU, 0x0ul); ioctl(r[3], KVM_SET_TSS_ADDR, 0x0ul); ioctl(r[6], KVM_RUN, 0); ioctl(r[6], KVM_RUN, 0); struct kvm_userspace_memory_region mr = { .slot = 0, .flags = KVM_MEM_LOG_DIRTY_PAGES, .guest_phys_addr = 0xf000, .memory_size = 0x4000, .userspace_addr = (uintptr_t) p }; ioctl(r[3], KVM_SET_USER_MEMORY_REGION, &mr); return 0; } This patch fixes the bug by not adding a new memslot even if it overlaps with private memslots. Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Eric Biggers <ebiggers3(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com> --- virt/kvm/kvm_main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -902,8 +902,7 @@ int __kvm_set_memory_region(struct kvm * /* Check for overlaps */ r = -EEXIST; kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) { - if ((slot->id >= KVM_USER_MEM_SLOTS) || - (slot->id == id)) + if (slot->id == id) continue; if (!((base_gfn + npages <= slot->base_gfn) || (base_gfn >= slot->base_gfn + slot->npages))) Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are queue-4.4/kvm-mmu-fix-overlap-between-public-and-private-memslots.patch

7 years, 6 months

1
0
0 0

Patch "ARM: mvebu: Fix broken PL310_ERRATA_753970 selects" 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 ARM: mvebu: Fix broken PL310_ERRATA_753970 selects 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: arm-mvebu-fix-broken-pl310_errata_753970-selects.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 8aa36a8dcde3183d84db7b0d622ffddcebb61077 Mon Sep 17 00:00:00 2001 From: Ulf Magnusson <ulfalizer(a)gmail.com> Date: Mon, 5 Feb 2018 02:21:13 +0100 Subject: ARM: mvebu: Fix broken PL310_ERRATA_753970 selects From: Ulf Magnusson <ulfalizer(a)gmail.com> commit 8aa36a8dcde3183d84db7b0d622ffddcebb61077 upstream. The MACH_ARMADA_375 and MACH_ARMADA_38X boards select ARM_ERRATA_753970, but it was renamed to PL310_ERRATA_753970 by commit fa0ce4035d48 ("ARM: 7162/1: errata: tidy up Kconfig options for PL310 errata workarounds"). Fix the selects to use the new name. Discovered with the https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined… script. Fixes: fa0ce4035d48 ("ARM: 7162/1: errata: tidy up Kconfig options for PL310 errata workarounds" cc: stable(a)vger.kernel.org Signed-off-by: Ulf Magnusson <ulfalizer(a)gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/mach-mvebu/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -37,7 +37,7 @@ config MACH_ARMADA_370 config MACH_ARMADA_375 bool "Marvell Armada 375 boards" if ARCH_MULTI_V7 select ARM_ERRATA_720789 - select ARM_ERRATA_753970 + select PL310_ERRATA_753970 select ARM_GIC select ARMADA_375_CLK select HAVE_ARM_SCU @@ -52,7 +52,7 @@ config MACH_ARMADA_375 config MACH_ARMADA_38X bool "Marvell Armada 380/385 boards" if ARCH_MULTI_V7 select ARM_ERRATA_720789 - select ARM_ERRATA_753970 + select PL310_ERRATA_753970 select ARM_GIC select ARMADA_38X_CLK select HAVE_ARM_SCU Patches currently in stable-queue which might be from ulfalizer(a)gmail.com are queue-4.4/arm-mvebu-fix-broken-pl310_errata_753970-selects.patch

7 years, 6 months

1
0
0 0

Patch "x86/mm: Fix {pmd, pud}_{set, clear}_flags()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mm: Fix {pmd,pud}_{set,clear}_flags() to the 4.15-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: x86-mm-fix-pmd-pud-_-set-clear-_flags.patch and it can be found in the queue-4.15 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 842cef9113c2120f74f645111ded1e020193d84c Mon Sep 17 00:00:00 2001 From: Jan Beulich <JBeulich(a)suse.com> Date: Mon, 19 Feb 2018 07:48:11 -0700 Subject: x86/mm: Fix {pmd,pud}_{set,clear}_flags() From: Jan Beulich <JBeulich(a)suse.com> commit 842cef9113c2120f74f645111ded1e020193d84c upstream. Just like pte_{set,clear}_flags() their PMD and PUD counterparts should not do any address translation. This was outright wrong under Xen (causing a dead boot with no useful output on "suitable" systems), and produced needlessly more complicated code (even if just slightly) when paravirt was enabled. Signed-off-by: Jan Beulich <jbeulich(a)suse.com> Reviewed-by: Juergen Gross <jgross(a)suse.com> Acked-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/5A8AF1BB02000078001A91C3@prv-mh.provo.novell.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/pgtable.h | 8 ++++---- arch/x86/include/asm/pgtable_types.h | 10 ++++++++++ 2 files changed, 14 insertions(+), 4 deletions(-) --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -350,14 +350,14 @@ static inline pmd_t pmd_set_flags(pmd_t { pmdval_t v = native_pmd_val(pmd); - return __pmd(v | set); + return native_make_pmd(v | set); } static inline pmd_t pmd_clear_flags(pmd_t pmd, pmdval_t clear) { pmdval_t v = native_pmd_val(pmd); - return __pmd(v & ~clear); + return native_make_pmd(v & ~clear); } static inline pmd_t pmd_mkold(pmd_t pmd) @@ -409,14 +409,14 @@ static inline pud_t pud_set_flags(pud_t { pudval_t v = native_pud_val(pud); - return __pud(v | set); + return native_make_pud(v | set); } static inline pud_t pud_clear_flags(pud_t pud, pudval_t clear) { pudval_t v = native_pud_val(pud); - return __pud(v & ~clear); + return native_make_pud(v & ~clear); } static inline pud_t pud_mkold(pud_t pud) --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -323,6 +323,11 @@ static inline pudval_t native_pud_val(pu #else #include <asm-generic/pgtable-nopud.h> +static inline pud_t native_make_pud(pudval_t val) +{ + return (pud_t) { .p4d.pgd = native_make_pgd(val) }; +} + static inline pudval_t native_pud_val(pud_t pud) { return native_pgd_val(pud.p4d.pgd); @@ -344,6 +349,11 @@ static inline pmdval_t native_pmd_val(pm #else #include <asm-generic/pgtable-nopmd.h> +static inline pmd_t native_make_pmd(pmdval_t val) +{ + return (pmd_t) { .pud.p4d.pgd = native_make_pgd(val) }; +} + static inline pmdval_t native_pmd_val(pmd_t pmd) { return native_pgd_val(pmd.pud.p4d.pgd); Patches currently in stable-queue which might be from JBeulich(a)suse.com are queue-4.15/x86-mm-fix-pmd-pud-_-set-clear-_flags.patch

7 years, 6 months

1
0
0 0

Patch "nospec: Allow index argument to have const-qualified type" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nospec: Allow index argument to have const-qualified type to the 4.15-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: nospec-allow-index-argument-to-have-const-qualified-type.patch and it can be found in the queue-4.15 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 b98c6a160a057d5686a8c54c79cc6c8c94a7d0c8 Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Date: Fri, 16 Feb 2018 13:20:48 -0800 Subject: nospec: Allow index argument to have const-qualified type From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> commit b98c6a160a057d5686a8c54c79cc6c8c94a7d0c8 upstream. The last expression in a statement expression need not be a bare variable, quoting gcc docs The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the entire construct. and we already use that in e.g. the min/max macros which end with a ternary expression. This way, we can allow index to have const-qualified type, which will in some cases avoid the need for introducing a local copy of index of non-const qualified type. That, in turn, can prevent readers not familiar with the internals of array_index_nospec from wondering about the seemingly redundant extra variable, and I think that's worthwhile considering how confusing the whole _nospec business is. The expression _i&_mask has type unsigned long (since that is the type of _mask, and the BUILD_BUG_ONs guarantee that _i will get promoted to that), so in order not to change the type of the whole expression, add a cast back to typeof(_i). Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Acked-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Arjan van de Ven <arjan(a)linux.intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: David Woodhouse <dwmw2(a)infradead.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Will Deacon <will.deacon(a)arm.com> Cc: linux-arch(a)vger.kernel.org Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/151881604837.17395.10812767547837568328.stgit@dwil… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/nospec.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/include/linux/nospec.h +++ b/include/linux/nospec.h @@ -72,7 +72,6 @@ static inline unsigned long array_index_ BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \ BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \ \ - _i &= _mask; \ - _i; \ + (typeof(_i)) (_i & _mask); \ }) #endif /* _LINUX_NOSPEC_H */ Patches currently in stable-queue which might be from linux(a)rasmusvillemoes.dk are queue-4.15/nospec-allow-index-argument-to-have-const-qualified-type.patch

7 years, 6 months

1
0
0 0

Patch "media: m88ds3103: don't call a non-initalized function" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: m88ds3103: don't call a non-initalized function to the 4.15-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: media-m88ds3103-don-t-call-a-non-initalized-function.patch and it can be found in the queue-4.15 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 b9c97c67fd19262c002d94ced2bfb513083e161e Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Date: Sat, 10 Feb 2018 06:14:10 -0500 Subject: media: m88ds3103: don't call a non-initalized function From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> commit b9c97c67fd19262c002d94ced2bfb513083e161e upstream. If m88d3103 chip ID is not recognized, the device is not initialized. However, it returns from probe without any error, causing this OOPS: [ 7.689289] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 7.689297] pgd = 7b0bd7a7 [ 7.689302] [00000000] *pgd=00000000 [ 7.689318] Internal error: Oops: 80000005 [#1] SMP ARM [ 7.689322] Modules linked in: dvb_usb_dvbsky(+) m88ds3103 dvb_usb_v2 dvb_core videobuf2_vmalloc videobuf2_memops videobuf2_core crc32_arm_ce videodev media [ 7.689358] CPU: 3 PID: 197 Comm: systemd-udevd Not tainted 4.15.0-mcc+ #23 [ 7.689361] Hardware name: BCM2835 [ 7.689367] PC is at 0x0 [ 7.689382] LR is at m88ds3103_attach+0x194/0x1d0 [m88ds3103] [ 7.689386] pc : [<00000000>] lr : [<bf0ae1ec>] psr: 60000013 [ 7.689391] sp : ed8e5c20 ip : ed8c1e00 fp : ed8945c0 [ 7.689395] r10: ed894000 r9 : ed894378 r8 : eda736c0 [ 7.689400] r7 : ed894070 r6 : ed8e5c44 r5 : bf0bb040 r4 : eda77600 [ 7.689405] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : eda77600 [ 7.689412] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 7.689417] Control: 10c5383d Table: 2d8e806a DAC: 00000051 [ 7.689423] Process systemd-udevd (pid: 197, stack limit = 0xe9dbfb63) [ 7.689428] Stack: (0xed8e5c20 to 0xed8e6000) [ 7.689439] 5c20: ed853a80 eda73640 ed894000 ed8942c0 ed853a80 bf0b9e98 ed894070 bf0b9f10 [ 7.689449] 5c40: 00000000 00000000 bf08c17c c08dfc50 00000000 00000000 00000000 00000000 [ 7.689459] 5c60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.689468] 5c80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.689479] 5ca0: 00000000 00000000 ed8945c0 ed8942c0 ed894000 ed894830 bf0b9e98 00000000 [ 7.689490] 5cc0: ed894378 bf0a3cb4 bf0bc3b0 0000533b ed920540 00000000 00000034 bf0a6434 [ 7.689500] 5ce0: ee952070 ed826600 bf0a7038 bf0a2dd8 00000001 bf0a6768 bf0a2f90 ed8943c0 [ 7.689511] 5d00: 00000000 c08eca68 ed826620 ed826620 00000000 ee952070 bf0bc034 ee952000 [ 7.689521] 5d20: ed826600 bf0bb080 ffffffed c0aa9e9c c0aa9dac ed826620 c16edf6c c168c2c8 [ 7.689531] 5d40: c16edf70 00000000 bf0bc034 0000000d 00000000 c08e268c bf0bb080 ed826600 [ 7.689541] 5d60: bf0bc034 ed826654 ed826620 bf0bc034 c164c8bc 00000000 00000001 00000000 [ 7.689553] 5d80: 00000028 c08e2948 00000000 bf0bc034 c08e2848 c08e0778 ee9f0a58 ed88bab4 [ 7.689563] 5da0: bf0bc034 ed90ba80 c168c1f0 c08e1934 bf0bb3bc c17045ac bf0bc034 c164c8bc [ 7.689574] 5dc0: bf0bc034 bf0bb3bc ed91f564 c08e34ec bf0bc000 c164c8bc bf0bc034 c0aa8dc4 [ 7.689584] 5de0: ffffe000 00000000 bf0bf000 ed91f600 ed91f564 c03021e4 00000001 00000000 [ 7.689595] 5e00: c166e040 8040003f ed853a80 bf0bc448 00000000 c1678174 ed853a80 f0f22000 [ 7.689605] 5e20: f0f21fff 8040003f 014000c0 ed91e700 ed91e700 c16d8e68 00000001 ed91e6c0 [ 7.689615] 5e40: bf0bc400 00000001 bf0bc400 ed91f564 00000001 00000000 00000028 c03c9a24 [ 7.689625] 5e60: 00000001 c03c8c94 ed8e5f50 ed8e5f50 00000001 bf0bc400 ed91f540 c03c8cb0 [ 7.689637] 5e80: bf0bc40c 00007fff bf0bc400 c03c60b0 00000000 bf0bc448 00000028 c0e09684 [ 7.689647] 5ea0: 00000002 bf0bc530 c1234bf8 bf0bc5dc bf0bc514 c10ebbe8 ffffe000 bf000000 [ 7.689657] 5ec0: 00011538 00000000 ed8e5f48 00000000 00000000 00000000 00000000 00000000 [ 7.689666] 5ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.689676] 5f00: 00000000 00000000 7fffffff 00000000 00000013 b6e55a18 0000017b c0309104 [ 7.689686] 5f20: ed8e4000 00000000 00510af0 c03c9430 7fffffff 00000000 00000003 00000000 [ 7.689697] 5f40: 00000000 f0f0f000 00011538 00000000 f0f107b0 f0f0f000 00011538 f0f1fdb8 [ 7.689707] 5f60: f0f1fbe8 f0f1b974 00004000 000041e0 bf0bc3d0 00000001 00000000 000024c4 [ 7.689717] 5f80: 0000002d 0000002e 00000019 00000000 00000010 00000000 16894000 00000000 [ 7.689727] 5fa0: 00000000 c0308f20 16894000 00000000 00000013 b6e55a18 00000000 b6e5652c [ 7.689737] 5fc0: 16894000 00000000 00000000 0000017b 00020000 00508110 00000000 00510af0 [ 7.689748] 5fe0: bef68948 bef68938 b6e4d3d0 b6d32590 60000010 00000013 00000000 00000000 [ 7.689790] [<bf0ae1ec>] (m88ds3103_attach [m88ds3103]) from [<bf0b9f10>] (dvbsky_s960c_attach+0x78/0x280 [dvb_usb_dvbsky]) [ 7.689821] [<bf0b9f10>] (dvbsky_s960c_attach [dvb_usb_dvbsky]) from [<bf0a3cb4>] (dvb_usbv2_probe+0xa3c/0x1024 [dvb_usb_v2]) [ 7.689849] [<bf0a3cb4>] (dvb_usbv2_probe [dvb_usb_v2]) from [<c0aa9e9c>] (usb_probe_interface+0xf0/0x2a8) [ 7.689869] [<c0aa9e9c>] (usb_probe_interface) from [<c08e268c>] (driver_probe_device+0x2f8/0x4b4) [ 7.689881] [<c08e268c>] (driver_probe_device) from [<c08e2948>] (__driver_attach+0x100/0x11c) [ 7.689895] [<c08e2948>] (__driver_attach) from [<c08e0778>] (bus_for_each_dev+0x4c/0x9c) [ 7.689909] [<c08e0778>] (bus_for_each_dev) from [<c08e1934>] (bus_add_driver+0x1c0/0x264) [ 7.689919] [<c08e1934>] (bus_add_driver) from [<c08e34ec>] (driver_register+0x78/0xf4) [ 7.689931] [<c08e34ec>] (driver_register) from [<c0aa8dc4>] (usb_register_driver+0x70/0x134) [ 7.689946] [<c0aa8dc4>] (usb_register_driver) from [<c03021e4>] (do_one_initcall+0x44/0x168) [ 7.689963] [<c03021e4>] (do_one_initcall) from [<c03c9a24>] (do_init_module+0x64/0x1f4) [ 7.689979] [<c03c9a24>] (do_init_module) from [<c03c8cb0>] (load_module+0x20a0/0x25c8) [ 7.689993] [<c03c8cb0>] (load_module) from [<c03c9430>] (SyS_finit_module+0xb4/0xec) [ 7.690007] [<c03c9430>] (SyS_finit_module) from [<c0308f20>] (ret_fast_syscall+0x0/0x54) [ 7.690018] Code: bad PC value This may happen on normal circumstances, if, for some reason, the demod hangs and start returning an invalid chip ID: [ 10.394395] m88ds3103 3-0068: Unknown device. Chip_id=00 So, change the logic to cause probe to fail with -ENODEV, preventing the OOPS. Detected while testing DVB MMAP patches on Raspberry Pi 3 with DVBSky S960CI. Cc: stable(a)vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/dvb-frontends/m88ds3103.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/media/dvb-frontends/m88ds3103.c +++ b/drivers/media/dvb-frontends/m88ds3103.c @@ -1262,11 +1262,12 @@ static int m88ds3103_select(struct i2c_m * New users must use I2C client binding directly! */ struct dvb_frontend *m88ds3103_attach(const struct m88ds3103_config *cfg, - struct i2c_adapter *i2c, struct i2c_adapter **tuner_i2c_adapter) + struct i2c_adapter *i2c, + struct i2c_adapter **tuner_i2c_adapter) { struct i2c_client *client; struct i2c_board_info board_info; - struct m88ds3103_platform_data pdata; + struct m88ds3103_platform_data pdata = {}; pdata.clk = cfg->clock; pdata.i2c_wr_max = cfg->i2c_wr_max; @@ -1409,6 +1410,8 @@ static int m88ds3103_probe(struct i2c_cl case M88DS3103_CHIP_ID: break; default: + ret = -ENODEV; + dev_err(&client->dev, "Unknown device. Chip_id=%02x\n", dev->chip_id); goto err_kfree; } Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are queue-4.15/media-m88ds3103-don-t-call-a-non-initalized-function.patch

7 years, 6 months

1
0
0 0

Patch "KVM/x86: Remove indirect MSR op calls from SPEC_CTRL" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM/x86: Remove indirect MSR op calls from SPEC_CTRL to the 4.15-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: kvm-x86-remove-indirect-msr-op-calls-from-spec_ctrl.patch and it can be found in the queue-4.15 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 ecb586bd29c99fb4de599dec388658e74388daad Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Thu, 22 Feb 2018 16:43:17 +0100 Subject: KVM/x86: Remove indirect MSR op calls from SPEC_CTRL MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Paolo Bonzini <pbonzini(a)redhat.com> commit ecb586bd29c99fb4de599dec388658e74388daad upstream. Having a paravirt indirect call in the IBRS restore path is not a good idea, since we are trying to protect from speculative execution of bogus indirect branch targets. It is also slower, so use native_wrmsrl() on the vmentry path too. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Reviewed-by: Jim Mattson <jmattson(a)google.com> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Cc: KarimAllah Ahmed <karahmed(a)amazon.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: kvm(a)vger.kernel.org Cc: stable(a)vger.kernel.org Fixes: d28b387fb74da95d69d2615732f50cceb38e9a4d Link: http://lkml.kernel.org/r/20180222154318.20361-2-pbonzini@redhat.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/svm.c | 7 ++++--- arch/x86/kvm/vmx.c | 7 ++++--- 2 files changed, 8 insertions(+), 6 deletions(-) --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -45,6 +45,7 @@ #include <asm/debugreg.h> #include <asm/kvm_para.h> #include <asm/irq_remapping.h> +#include <asm/microcode.h> #include <asm/nospec-branch.h> #include <asm/virtext.h> @@ -5029,7 +5030,7 @@ static void svm_vcpu_run(struct kvm_vcpu * being speculatively taken. */ if (svm->spec_ctrl) - wrmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl); + native_wrmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl); asm volatile ( "push %%" _ASM_BP "; \n\t" @@ -5139,10 +5140,10 @@ static void svm_vcpu_run(struct kvm_vcpu * save it. */ if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)) - rdmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl); + svm->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL); if (svm->spec_ctrl) - wrmsrl(MSR_IA32_SPEC_CTRL, 0); + native_wrmsrl(MSR_IA32_SPEC_CTRL, 0); /* Eliminate branch target predictions from guest mode */ vmexit_fill_RSB(); --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -51,6 +51,7 @@ #include <asm/apic.h> #include <asm/irq_remapping.h> #include <asm/mmu_context.h> +#include <asm/microcode.h> #include <asm/nospec-branch.h> #include "trace.h" @@ -9443,7 +9444,7 @@ static void __noclone vmx_vcpu_run(struc * being speculatively taken. */ if (vmx->spec_ctrl) - wrmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl); + native_wrmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl); vmx->__launched = vmx->loaded_vmcs->launched; asm( @@ -9579,10 +9580,10 @@ static void __noclone vmx_vcpu_run(struc * save it. */ if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)) - rdmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl); + vmx->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL); if (vmx->spec_ctrl) - wrmsrl(MSR_IA32_SPEC_CTRL, 0); + native_wrmsrl(MSR_IA32_SPEC_CTRL, 0); /* Eliminate branch target predictions from guest mode */ vmexit_fill_RSB(); Patches currently in stable-queue which might be from pbonzini(a)redhat.com are queue-4.15/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch queue-4.15/kvm-x86-remove-indirect-msr-op-calls-from-spec_ctrl.patch queue-4.15/kvm-x86-move-lapic-initialization-after-vmcs-creation.patch queue-4.15/kvm-mmu-fix-overlap-between-public-and-private-memslots.patch queue-4.15/kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch

7 years, 6 months

1
0
0 0

Patch "KVM: x86: move LAPIC initialization after VMCS creation" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: move LAPIC initialization after VMCS creation to the 4.15-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: kvm-x86-move-lapic-initialization-after-vmcs-creation.patch and it can be found in the queue-4.15 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 0b2e9904c15963e715d33e5f3f1387f17d19333a Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Fri, 23 Feb 2018 23:29:32 +0100 Subject: KVM: x86: move LAPIC initialization after VMCS creation From: Paolo Bonzini <pbonzini(a)redhat.com> commit 0b2e9904c15963e715d33e5f3f1387f17d19333a upstream. The initial reset of the local APIC is performed before the VMCS has been created, but it tries to do a vmwrite: vmwrite error: reg 810 value 4a00 (err 18944) CPU: 54 PID: 38652 Comm: qemu-kvm Tainted: G W I 4.16.0-0.rc2.git0.1.fc28.x86_64 #1 Hardware name: Intel Corporation S2600CW/S2600CW, BIOS SE5C610.86B.01.01.0003.090520141303 09/05/2014 Call Trace: vmx_set_rvi [kvm_intel] vmx_hwapic_irr_update [kvm_intel] kvm_lapic_reset [kvm] kvm_create_lapic [kvm] kvm_arch_vcpu_init [kvm] kvm_vcpu_init [kvm] vmx_create_vcpu [kvm_intel] kvm_vm_ioctl [kvm] Move it later, after the VMCS has been created. Fixes: 4191db26b714 ("KVM: x86: Update APICv on APIC reset") Cc: stable(a)vger.kernel.org Cc: Liran Alon <liran.alon(a)oracle.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/lapic.c | 1 - arch/x86/kvm/x86.c | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2156,7 +2156,6 @@ int kvm_create_lapic(struct kvm_vcpu *vc */ vcpu->arch.apic_base = MSR_IA32_APICBASE_ENABLE; static_key_slow_inc(&apic_sw_disabled.key); /* sw disabled at reset */ - kvm_lapic_reset(vcpu, false); kvm_iodevice_init(&apic->dev, &apic_mmio_ops); return 0; --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7793,6 +7793,7 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu if (r) return r; kvm_vcpu_reset(vcpu, false); + kvm_lapic_reset(vcpu, false); kvm_mmu_setup(vcpu); vcpu_put(vcpu); return r; Patches currently in stable-queue which might be from pbonzini(a)redhat.com are queue-4.15/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch queue-4.15/kvm-x86-remove-indirect-msr-op-calls-from-spec_ctrl.patch queue-4.15/kvm-x86-move-lapic-initialization-after-vmcs-creation.patch queue-4.15/kvm-mmu-fix-overlap-between-public-and-private-memslots.patch queue-4.15/kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch

7 years, 6 months

1
0
0 0

Patch "KVM: X86: Fix SMRAM accessing even if VM is shutdown" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: X86: Fix SMRAM accessing even if VM is shutdown to the 4.15-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: kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch and it can be found in the queue-4.15 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 95e057e25892eaa48cad1e2d637b80d0f1a4fac5 Mon Sep 17 00:00:00 2001 From: Wanpeng Li <wanpengli(a)tencent.com> Date: Thu, 8 Feb 2018 15:32:45 +0800 Subject: KVM: X86: Fix SMRAM accessing even if VM is shutdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Wanpeng Li <wanpengli(a)tencent.com> commit 95e057e25892eaa48cad1e2d637b80d0f1a4fac5 upstream. Reported by syzkaller: WARNING: CPU: 6 PID: 2434 at arch/x86/kvm/vmx.c:6660 handle_ept_misconfig+0x54/0x1e0 [kvm_intel] CPU: 6 PID: 2434 Comm: repro_test Not tainted 4.15.0+ #4 RIP: 0010:handle_ept_misconfig+0x54/0x1e0 [kvm_intel] Call Trace: vmx_handle_exit+0xbd/0xe20 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xdaf/0x1d50 [kvm] kvm_vcpu_ioctl+0x3e9/0x720 [kvm] do_vfs_ioctl+0xa4/0x6a0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x25/0x9c The testcase creates a first thread to issue KVM_SMI ioctl, and then creates a second thread to mmap and operate on the same vCPU. This triggers a race condition when running the testcase with multiple threads. Sometimes one thread exits with a triple fault while another thread mmaps and operates on the same vCPU. Because CS=0x3000/IP=0x8000 is not mapped, accessing the SMI handler results in an EPT misconfig. This patch fixes it by returning RET_PF_EMULATE in kvm_handle_bad_page(), which will go on to cause an emulation failure and an exit with KVM_EXIT_INTERNAL_ERROR. Reported-by: syzbot+c1d9517cab094dae65e446c0c5b4de6c40f4dc58(a)syzkaller.appspotmail.com Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -3017,7 +3017,7 @@ static int kvm_handle_bad_page(struct kv return RET_PF_RETRY; } - return -EFAULT; + return RET_PF_EMULATE; } static void transparent_hugepage_adjust(struct kvm_vcpu *vcpu, Patches currently in stable-queue which might be from wanpengli(a)tencent.com are queue-4.15/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch

7 years, 6 months

1
0
0 0

Patch "KVM: s390: take care of clock-comparator sign control" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: s390: take care of clock-comparator sign control to the 4.15-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: kvm-s390-take-care-of-clock-comparator-sign-control.patch and it can be found in the queue-4.15 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 5fe01793dd953ab947fababe8abaf5ed5258c8df Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Wed, 7 Feb 2018 12:46:42 +0100 Subject: KVM: s390: take care of clock-comparator sign control From: David Hildenbrand <david(a)redhat.com> commit 5fe01793dd953ab947fababe8abaf5ed5258c8df upstream. Missed when enabling the Multiple-epoch facility. If the facility is installed and the control is set, a sign based comaprison has to be performed. Right now we would inject wrong interrupts and ignore interrupt conditions. Also the sleep time is calculated in a wrong way. Signed-off-by: David Hildenbrand <david(a)redhat.com> Message-Id: <20180207114647.6220-2-david(a)redhat.com> Fixes: 8fa1696ea781 ("KVM: s390: Multiple Epoch Facility support") Cc: stable(a)vger.kernel.org Reviewed-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/kvm/interrupt.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) --- a/arch/s390/kvm/interrupt.c +++ b/arch/s390/kvm/interrupt.c @@ -170,8 +170,15 @@ static int ckc_interrupts_enabled(struct static int ckc_irq_pending(struct kvm_vcpu *vcpu) { - if (vcpu->arch.sie_block->ckc >= kvm_s390_get_tod_clock_fast(vcpu->kvm)) + const u64 now = kvm_s390_get_tod_clock_fast(vcpu->kvm); + const u64 ckc = vcpu->arch.sie_block->ckc; + + if (vcpu->arch.sie_block->gcr[0] & 0x0020000000000000ul) { + if ((s64)ckc >= (s64)now) + return 0; + } else if (ckc >= now) { return 0; + } return ckc_interrupts_enabled(vcpu); } @@ -1011,13 +1018,19 @@ int kvm_cpu_has_pending_timer(struct kvm static u64 __calculate_sltime(struct kvm_vcpu *vcpu) { - u64 now, cputm, sltime = 0; + const u64 now = kvm_s390_get_tod_clock_fast(vcpu->kvm); + const u64 ckc = vcpu->arch.sie_block->ckc; + u64 cputm, sltime = 0; if (ckc_interrupts_enabled(vcpu)) { - now = kvm_s390_get_tod_clock_fast(vcpu->kvm); - sltime = tod_to_ns(vcpu->arch.sie_block->ckc - now); - /* already expired or overflow? */ - if (!sltime || vcpu->arch.sie_block->ckc <= now) + if (vcpu->arch.sie_block->gcr[0] & 0x0020000000000000ul) { + if ((s64)now < (s64)ckc) + sltime = tod_to_ns((s64)ckc - (s64)now); + } else if (now < ckc) { + sltime = tod_to_ns(ckc - now); + } + /* already expired */ + if (!sltime) return 0; if (cpu_timer_interrupts_enabled(vcpu)) { cputm = kvm_s390_get_cpu_timer(vcpu); Patches currently in stable-queue which might be from david(a)redhat.com are queue-4.15/kvm-s390-take-care-of-clock-comparator-sign-control.patch queue-4.15/kvm-s390-provide-only-a-single-function-for-setting-the-tod-fix-sck.patch queue-4.15/kvm-s390-consider-epoch-index-on-tod-clock-syncs.patch queue-4.15/kvm-s390-consider-epoch-index-on-hotplugged-cpus.patch

7 years, 6 months

1
0
0 0

Patch "KVM/VMX: Optimize vmx_vcpu_run() and svm_vcpu_run() by marking the RDMSR path as unlikely()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM/VMX: Optimize vmx_vcpu_run() and svm_vcpu_run() by marking the RDMSR path as unlikely() to the 4.15-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: kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch and it can be found in the queue-4.15 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 946fbbc13dce68902f64515b610eeb2a6c3d7a64 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Thu, 22 Feb 2018 16:43:18 +0100 Subject: KVM/VMX: Optimize vmx_vcpu_run() and svm_vcpu_run() by marking the RDMSR path as unlikely() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Paolo Bonzini <pbonzini(a)redhat.com> commit 946fbbc13dce68902f64515b610eeb2a6c3d7a64 upstream. vmx_vcpu_run() and svm_vcpu_run() are large functions, and giving branch hints to the compiler can actually make a substantial cycle difference by keeping the fast path contiguous in memory. With this optimization, the retpoline-guest/retpoline-host case is about 50 cycles faster. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Reviewed-by: Jim Mattson <jmattson(a)google.com> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Cc: KarimAllah Ahmed <karahmed(a)amazon.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: kvm(a)vger.kernel.org Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/20180222154318.20361-3-pbonzini@redhat.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/svm.c | 2 +- arch/x86/kvm/vmx.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -5139,7 +5139,7 @@ static void svm_vcpu_run(struct kvm_vcpu * If the L02 MSR bitmap does not intercept the MSR, then we need to * save it. */ - if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)) + if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))) svm->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL); if (svm->spec_ctrl) --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -9579,7 +9579,7 @@ static void __noclone vmx_vcpu_run(struc * If the L02 MSR bitmap does not intercept the MSR, then we need to * save it. */ - if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)) + if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))) vmx->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL); if (vmx->spec_ctrl) Patches currently in stable-queue which might be from pbonzini(a)redhat.com are queue-4.15/kvm-x86-fix-smram-accessing-even-if-vm-is-shutdown.patch queue-4.15/kvm-x86-remove-indirect-msr-op-calls-from-spec_ctrl.patch queue-4.15/kvm-x86-move-lapic-initialization-after-vmcs-creation.patch queue-4.15/kvm-mmu-fix-overlap-between-public-and-private-memslots.patch queue-4.15/kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch

7 years, 6 months

1
0
0 0

Patch "KVM: s390: provide only a single function for setting the tod (fix SCK)" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: s390: provide only a single function for setting the tod (fix SCK) to the 4.15-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: kvm-s390-provide-only-a-single-function-for-setting-the-tod-fix-sck.patch and it can be found in the queue-4.15 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 0e7def5fb0dc53ddbb9f62a497d15f1e11ccdc36 Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Wed, 7 Feb 2018 12:46:43 +0100 Subject: KVM: s390: provide only a single function for setting the tod (fix SCK) From: David Hildenbrand <david(a)redhat.com> commit 0e7def5fb0dc53ddbb9f62a497d15f1e11ccdc36 upstream. Right now, SET CLOCK called in the guest does not properly take care of the epoch index, as the call goes via the old kvm_s390_set_tod_clock() interface. So the epoch index is neither reset to 0, if required, nor properly set to e.g. 0xff on negative values. Fix this by providing a single kvm_s390_set_tod_clock() function. Move Multiple-epoch facility handling into it. Signed-off-by: David Hildenbrand <david(a)redhat.com> Message-Id: <20180207114647.6220-3-david(a)redhat.com> Reviewed-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Fixes: 8fa1696ea781 ("KVM: s390: Multiple Epoch Facility support") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/kvm/kvm-s390.c | 46 +++++++++++++++------------------------------- arch/s390/kvm/kvm-s390.h | 5 ++--- arch/s390/kvm/priv.c | 9 +++++---- 3 files changed, 22 insertions(+), 38 deletions(-) --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -889,12 +889,9 @@ static int kvm_s390_set_tod_ext(struct k if (copy_from_user(&gtod, (void __user *)attr->addr, sizeof(gtod))) return -EFAULT; - if (test_kvm_facility(kvm, 139)) - kvm_s390_set_tod_clock_ext(kvm, &gtod); - else if (gtod.epoch_idx == 0) - kvm_s390_set_tod_clock(kvm, gtod.tod); - else + if (!test_kvm_facility(kvm, 139) && gtod.epoch_idx) return -EINVAL; + kvm_s390_set_tod_clock(kvm, &gtod); VM_EVENT(kvm, 3, "SET: TOD extension: 0x%x, TOD base: 0x%llx", gtod.epoch_idx, gtod.tod); @@ -919,13 +916,14 @@ static int kvm_s390_set_tod_high(struct static int kvm_s390_set_tod_low(struct kvm *kvm, struct kvm_device_attr *attr) { - u64 gtod; + struct kvm_s390_vm_tod_clock gtod = { 0 }; - if (copy_from_user(&gtod, (void __user *)attr->addr, sizeof(gtod))) + if (copy_from_user(&gtod.tod, (void __user *)attr->addr, + sizeof(gtod.tod))) return -EFAULT; - kvm_s390_set_tod_clock(kvm, gtod); - VM_EVENT(kvm, 3, "SET: TOD base: 0x%llx", gtod); + kvm_s390_set_tod_clock(kvm, &gtod); + VM_EVENT(kvm, 3, "SET: TOD base: 0x%llx", gtod.tod); return 0; } @@ -2947,8 +2945,8 @@ retry: return 0; } -void kvm_s390_set_tod_clock_ext(struct kvm *kvm, - const struct kvm_s390_vm_tod_clock *gtod) +void kvm_s390_set_tod_clock(struct kvm *kvm, + const struct kvm_s390_vm_tod_clock *gtod) { struct kvm_vcpu *vcpu; struct kvm_s390_tod_clock_ext htod; @@ -2960,10 +2958,12 @@ void kvm_s390_set_tod_clock_ext(struct k get_tod_clock_ext((char *)&htod); kvm->arch.epoch = gtod->tod - htod.tod; - kvm->arch.epdx = gtod->epoch_idx - htod.epoch_idx; - - if (kvm->arch.epoch > gtod->tod) - kvm->arch.epdx -= 1; + kvm->arch.epdx = 0; + if (test_kvm_facility(kvm, 139)) { + kvm->arch.epdx = gtod->epoch_idx - htod.epoch_idx; + if (kvm->arch.epoch > gtod->tod) + kvm->arch.epdx -= 1; + } kvm_s390_vcpu_block_all(kvm); kvm_for_each_vcpu(i, vcpu, kvm) { @@ -2974,22 +2974,6 @@ void kvm_s390_set_tod_clock_ext(struct k kvm_s390_vcpu_unblock_all(kvm); preempt_enable(); mutex_unlock(&kvm->lock); -} - -void kvm_s390_set_tod_clock(struct kvm *kvm, u64 tod) -{ - struct kvm_vcpu *vcpu; - int i; - - mutex_lock(&kvm->lock); - preempt_disable(); - kvm->arch.epoch = tod - get_tod_clock(); - kvm_s390_vcpu_block_all(kvm); - kvm_for_each_vcpu(i, vcpu, kvm) - vcpu->arch.sie_block->epoch = kvm->arch.epoch; - kvm_s390_vcpu_unblock_all(kvm); - preempt_enable(); - mutex_unlock(&kvm->lock); } /** --- a/arch/s390/kvm/kvm-s390.h +++ b/arch/s390/kvm/kvm-s390.h @@ -268,9 +268,8 @@ int kvm_s390_handle_sigp(struct kvm_vcpu int kvm_s390_handle_sigp_pei(struct kvm_vcpu *vcpu); /* implemented in kvm-s390.c */ -void kvm_s390_set_tod_clock_ext(struct kvm *kvm, - const struct kvm_s390_vm_tod_clock *gtod); -void kvm_s390_set_tod_clock(struct kvm *kvm, u64 tod); +void kvm_s390_set_tod_clock(struct kvm *kvm, + const struct kvm_s390_vm_tod_clock *gtod); long kvm_arch_fault_in_page(struct kvm_vcpu *vcpu, gpa_t gpa, int writable); int kvm_s390_store_status_unloaded(struct kvm_vcpu *vcpu, unsigned long addr); int kvm_s390_vcpu_store_status(struct kvm_vcpu *vcpu, unsigned long addr); --- a/arch/s390/kvm/priv.c +++ b/arch/s390/kvm/priv.c @@ -81,9 +81,10 @@ int kvm_s390_handle_e3(struct kvm_vcpu * /* Handle SCK (SET CLOCK) interception */ static int handle_set_clock(struct kvm_vcpu *vcpu) { + struct kvm_s390_vm_tod_clock gtod = { 0 }; int rc; u8 ar; - u64 op2, val; + u64 op2; if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE) return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP); @@ -91,12 +92,12 @@ static int handle_set_clock(struct kvm_v op2 = kvm_s390_get_base_disp_s(vcpu, &ar); if (op2 & 7) /* Operand must be on a doubleword boundary */ return kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION); - rc = read_guest(vcpu, op2, ar, &val, sizeof(val)); + rc = read_guest(vcpu, op2, ar, &gtod.tod, sizeof(gtod.tod)); if (rc) return kvm_s390_inject_prog_cond(vcpu, rc); - VCPU_EVENT(vcpu, 3, "SCK: setting guest TOD to 0x%llx", val); - kvm_s390_set_tod_clock(vcpu->kvm, val); + VCPU_EVENT(vcpu, 3, "SCK: setting guest TOD to 0x%llx", gtod.tod); + kvm_s390_set_tod_clock(vcpu->kvm, &gtod); kvm_s390_set_psw_cc(vcpu, 0); return 0; Patches currently in stable-queue which might be from david(a)redhat.com are queue-4.15/kvm-s390-take-care-of-clock-comparator-sign-control.patch queue-4.15/kvm-s390-provide-only-a-single-function-for-setting-the-tod-fix-sck.patch queue-4.15/kvm-s390-consider-epoch-index-on-tod-clock-syncs.patch queue-4.15/kvm-s390-consider-epoch-index-on-hotplugged-cpus.patch

7 years, 6 months

1
0
0 0

Patch "KVM: s390: consider epoch index on TOD clock syncs" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: s390: consider epoch index on TOD clock syncs to the 4.15-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: kvm-s390-consider-epoch-index-on-tod-clock-syncs.patch and it can be found in the queue-4.15 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 1575767ef3cf5326701d2ae3075b7732cbc855e4 Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Wed, 7 Feb 2018 12:46:45 +0100 Subject: KVM: s390: consider epoch index on TOD clock syncs From: David Hildenbrand <david(a)redhat.com> commit 1575767ef3cf5326701d2ae3075b7732cbc855e4 upstream. For now, we don't take care of over/underflows. Especially underflows are critical: Assume the epoch is currently 0 and we get a sync request for delta=1, meaning the TOD is moved forward by 1 and we have to fix it up by subtracting 1 from the epoch. Right now, this will leave the epoch index untouched, resulting in epoch=-1, epoch_idx=0, which is wrong. We have to take care of over and underflows, also for the VSIE case. So let's factor out calculation into a separate function. Signed-off-by: David Hildenbrand <david(a)redhat.com> Message-Id: <20180207114647.6220-5-david(a)redhat.com> Reviewed-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Fixes: 8fa1696ea781 ("KVM: s390: Multiple Epoch Facility support") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com> [use u8 for idx] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/kvm/kvm-s390.c | 32 +++++++++++++++++++++++++++++--- 1 file changed, 29 insertions(+), 3 deletions(-) --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -166,6 +166,28 @@ int kvm_arch_hardware_enable(void) static void kvm_gmap_notifier(struct gmap *gmap, unsigned long start, unsigned long end); +static void kvm_clock_sync_scb(struct kvm_s390_sie_block *scb, u64 delta) +{ + u8 delta_idx = 0; + + /* + * The TOD jumps by delta, we have to compensate this by adding + * -delta to the epoch. + */ + delta = -delta; + + /* sign-extension - we're adding to signed values below */ + if ((s64)delta < 0) + delta_idx = -1; + + scb->epoch += delta; + if (scb->ecd & ECD_MEF) { + scb->epdx += delta_idx; + if (scb->epoch < delta) + scb->epdx += 1; + } +} + /* * This callback is executed during stop_machine(). All CPUs are therefore * temporarily stopped. In order not to change guest behavior, we have to @@ -181,13 +203,17 @@ static int kvm_clock_sync(struct notifie unsigned long long *delta = v; list_for_each_entry(kvm, &vm_list, vm_list) { - kvm->arch.epoch -= *delta; kvm_for_each_vcpu(i, vcpu, kvm) { - vcpu->arch.sie_block->epoch -= *delta; + kvm_clock_sync_scb(vcpu->arch.sie_block, *delta); + if (i == 0) { + kvm->arch.epoch = vcpu->arch.sie_block->epoch; + kvm->arch.epdx = vcpu->arch.sie_block->epdx; + } if (vcpu->arch.cputm_enabled) vcpu->arch.cputm_start += *delta; if (vcpu->arch.vsie_block) - vcpu->arch.vsie_block->epoch -= *delta; + kvm_clock_sync_scb(vcpu->arch.vsie_block, + *delta); } } return NOTIFY_OK; Patches currently in stable-queue which might be from david(a)redhat.com are queue-4.15/kvm-s390-take-care-of-clock-comparator-sign-control.patch queue-4.15/kvm-s390-provide-only-a-single-function-for-setting-the-tod-fix-sck.patch queue-4.15/kvm-s390-consider-epoch-index-on-tod-clock-syncs.patch queue-4.15/kvm-s390-consider-epoch-index-on-hotplugged-cpus.patch

7 years, 6 months

1
0
0 0

Patch "KVM: mmu: Fix overlap between public and private memslots" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: mmu: Fix overlap between public and private memslots to the 4.15-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: kvm-mmu-fix-overlap-between-public-and-private-memslots.patch and it can be found in the queue-4.15 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 b28676bb8ae4569cced423dc2a88f7cb319d5379 Mon Sep 17 00:00:00 2001 From: Wanpeng Li <wanpeng.li(a)hotmail.com> Date: Tue, 13 Feb 2018 15:36:00 +0100 Subject: KVM: mmu: Fix overlap between public and private memslots MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Wanpeng Li <wanpeng.li(a)hotmail.com> commit b28676bb8ae4569cced423dc2a88f7cb319d5379 upstream. Reported by syzkaller: pte_list_remove: ffff9714eb1f8078 0->BUG ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/mmu.c:1157! invalid opcode: 0000 [#1] SMP RIP: 0010:pte_list_remove+0x11b/0x120 [kvm] Call Trace: drop_spte+0x83/0xb0 [kvm] mmu_page_zap_pte+0xcc/0xe0 [kvm] kvm_mmu_prepare_zap_page+0x81/0x4a0 [kvm] kvm_mmu_invalidate_zap_all_pages+0x159/0x220 [kvm] kvm_arch_flush_shadow_all+0xe/0x10 [kvm] kvm_mmu_notifier_release+0x6c/0xa0 [kvm] ? kvm_mmu_notifier_release+0x5/0xa0 [kvm] __mmu_notifier_release+0x79/0x110 ? __mmu_notifier_release+0x5/0x110 exit_mmap+0x15a/0x170 ? do_exit+0x281/0xcb0 mmput+0x66/0x160 do_exit+0x2c9/0xcb0 ? __context_tracking_exit.part.5+0x4a/0x150 do_group_exit+0x50/0xd0 SyS_exit_group+0x14/0x20 do_syscall_64+0x73/0x1f0 entry_SYSCALL64_slow_path+0x25/0x25 The reason is that when creates new memslot, there is no guarantee for new memslot not overlap with private memslots. This can be triggered by the following program: #include <fcntl.h> #include <pthread.h> #include <setjmp.h> #include <signal.h> #include <stddef.h> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/ioctl.h> #include <sys/stat.h> #include <sys/syscall.h> #include <sys/types.h> #include <unistd.h> #include <linux/kvm.h> long r[16]; int main() { void *p = valloc(0x4000); r[2] = open("/dev/kvm", 0); r[3] = ioctl(r[2], KVM_CREATE_VM, 0x0ul); uint64_t addr = 0xf000; ioctl(r[3], KVM_SET_IDENTITY_MAP_ADDR, &addr); r[6] = ioctl(r[3], KVM_CREATE_VCPU, 0x0ul); ioctl(r[3], KVM_SET_TSS_ADDR, 0x0ul); ioctl(r[6], KVM_RUN, 0); ioctl(r[6], KVM_RUN, 0); struct kvm_userspace_memory_region mr = { .slot = 0, .flags = KVM_MEM_LOG_DIRTY_PAGES, .guest_phys_addr = 0xf000, .memory_size = 0x4000, .userspace_addr = (uintptr_t) p }; ioctl(r[3], KVM_SET_USER_MEMORY_REGION, &mr); return 0; } This patch fixes the bug by not adding a new memslot even if it overlaps with private memslots. Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Radim Krčmář <rkrcmar(a)redhat.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Eric Biggers <ebiggers3(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com> --- virt/kvm/kvm_main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -974,8 +974,7 @@ int __kvm_set_memory_region(struct kvm * /* Check for overlaps */ r = -EEXIST; kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) { - if ((slot->id >= KVM_USER_MEM_SLOTS) || - (slot->id == id)) + if (slot->id == id) continue; if (!((base_gfn + npages <= slot->base_gfn) || (base_gfn >= slot->base_gfn + slot->npages))) Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are queue-4.15/kvm-mmu-fix-overlap-between-public-and-private-memslots.patch

7 years, 6 months

1
0
0 0

Patch "KVM: s390: consider epoch index on hotplugged CPUs" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: s390: consider epoch index on hotplugged CPUs to the 4.15-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: kvm-s390-consider-epoch-index-on-hotplugged-cpus.patch and it can be found in the queue-4.15 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 d16b52cb9cdb6f06dea8ab2f0a428e7d7f0b0a81 Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Wed, 7 Feb 2018 12:46:44 +0100 Subject: KVM: s390: consider epoch index on hotplugged CPUs From: David Hildenbrand <david(a)redhat.com> commit d16b52cb9cdb6f06dea8ab2f0a428e7d7f0b0a81 upstream. We must copy both, the epoch and the epoch_idx. Signed-off-by: David Hildenbrand <david(a)redhat.com> Message-Id: <20180207114647.6220-4-david(a)redhat.com> Fixes: 8fa1696ea781 ("KVM: s390: Multiple Epoch Facility support") Reviewed-by: Cornelia Huck <cohuck(a)redhat.com> Reviewed-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Fixes: 8fa1696ea781 ("KVM: s390: Multiple Epoch Facility support") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/kvm/kvm-s390.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -2359,6 +2359,7 @@ void kvm_arch_vcpu_postcreate(struct kvm mutex_lock(&vcpu->kvm->lock); preempt_disable(); vcpu->arch.sie_block->epoch = vcpu->kvm->arch.epoch; + vcpu->arch.sie_block->epdx = vcpu->kvm->arch.epdx; preempt_enable(); mutex_unlock(&vcpu->kvm->lock); if (!kvm_is_ucontrol(vcpu->kvm)) { Patches currently in stable-queue which might be from david(a)redhat.com are queue-4.15/kvm-s390-take-care-of-clock-comparator-sign-control.patch queue-4.15/kvm-s390-provide-only-a-single-function-for-setting-the-tod-fix-sck.patch queue-4.15/kvm-s390-consider-epoch-index-on-tod-clock-syncs.patch queue-4.15/kvm-s390-consider-epoch-index-on-hotplugged-cpus.patch

7 years, 6 months

1
0
0 0

Patch "EDAC, sb_edac: Fix out of bound writes during DIMM configuration on KNL" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled EDAC, sb_edac: Fix out of bound writes during DIMM configuration on KNL to the 4.15-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: edac-sb_edac-fix-out-of-bound-writes-during-dimm-configuration-on-knl.patch and it can be found in the queue-4.15 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 bf8486709ac7fad99e4040dea73fe466c57a4ae1 Mon Sep 17 00:00:00 2001 From: Anna Karbownik <anna.karbownik(a)intel.com> Date: Thu, 22 Feb 2018 16:18:13 +0100 Subject: EDAC, sb_edac: Fix out of bound writes during DIMM configuration on KNL From: Anna Karbownik <anna.karbownik(a)intel.com> commit bf8486709ac7fad99e4040dea73fe466c57a4ae1 upstream. Commit 3286d3eb906c ("EDAC, sb_edac: Drop NUM_CHANNELS from 8 back to 4") decreased NUM_CHANNELS from 8 to 4, but this is not enough for Knights Landing which supports up to 6 channels. This caused out-of-bounds writes to pvt->mirror_mode and pvt->tolm variables which don't pay critical role on KNL code path, so the memory corruption wasn't causing any visible driver failures. The easiest way of fixing it is to change NUM_CHANNELS to 6. Do that. An alternative solution would be to restructure the KNL part of the driver to 2MC/3channel representation. Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Anna Karbownik <anna.karbownik(a)intel.com> Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org> Cc: Tony Luck <tony.luck(a)intel.com> Cc: jim.m.snow(a)intel.com Cc: krzysztof.paliswiat(a)intel.com Cc: lukasz.odzioba(a)intel.com Cc: qiuxu.zhuo(a)intel.com Cc: linux-edac <linux-edac(a)vger.kernel.org> Cc: <stable(a)vger.kernel.org> Fixes: 3286d3eb906c ("EDAC, sb_edac: Drop NUM_CHANNELS from 8 back to 4") Link: http://lkml.kernel.org/r/1519312693-4789-1-git-send-email-anna.karbownik@in… [ Massage commit message. ] Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/edac/sb_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/edac/sb_edac.c +++ b/drivers/edac/sb_edac.c @@ -279,7 +279,7 @@ static const u32 correrrthrsld[] = { * sbridge structs */ -#define NUM_CHANNELS 4 /* Max channels per MC */ +#define NUM_CHANNELS 6 /* Max channels per MC */ #define MAX_DIMMS 3 /* Max DIMMS per channel */ #define KNL_MAX_CHAS 38 /* KNL max num. of Cache Home Agents */ #define KNL_MAX_CHANNELS 6 /* KNL max num. of PCI channels */ Patches currently in stable-queue which might be from anna.karbownik(a)intel.com are queue-4.15/edac-sb_edac-fix-out-of-bound-writes-during-dimm-configuration-on-knl.patch

7 years, 6 months

1
0
0 0

Patch "blk-mq: don't call io sched's .requeue_request when requeueing rq to ->dispatch" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled blk-mq: don't call io sched's .requeue_request when requeueing rq to ->dispatch to the 4.15-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: blk-mq-don-t-call-io-sched-s-.requeue_request-when-requeueing-rq-to-dispatch.patch and it can be found in the queue-4.15 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 105976f517791aed3b11f8f53b308a2069d42055 Mon Sep 17 00:00:00 2001 From: Ming Lei <ming.lei(a)redhat.com> Date: Fri, 23 Feb 2018 23:36:56 +0800 Subject: blk-mq: don't call io sched's .requeue_request when requeueing rq to ->dispatch From: Ming Lei <ming.lei(a)redhat.com> commit 105976f517791aed3b11f8f53b308a2069d42055 upstream. __blk_mq_requeue_request() covers two cases: - one is that the requeued request is added to hctx->dispatch, such as blk_mq_dispatch_rq_list() - another case is that the request is requeued to io scheduler, such as blk_mq_requeue_request(). We should call io sched's .requeue_request callback only for the 2nd case. Cc: Paolo Valente <paolo.valente(a)linaro.org> Cc: Omar Sandoval <osandov(a)fb.com> Fixes: bd166ef183c2 ("blk-mq-sched: add framework for MQ capable IO schedulers") Cc: stable(a)vger.kernel.org Reviewed-by: Bart Van Assche <bart.vanassche(a)wdc.com> Acked-by: Paolo Valente <paolo.valente(a)linaro.org> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-mq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -655,7 +655,6 @@ static void __blk_mq_requeue_request(str trace_block_rq_requeue(q, rq); wbt_requeue(q->rq_wb, &rq->issue_stat); - blk_mq_sched_requeue_request(rq); if (test_and_clear_bit(REQ_ATOM_STARTED, &rq->atomic_flags)) { if (q->dma_drain_size && blk_rq_bytes(rq)) @@ -667,6 +666,9 @@ void blk_mq_requeue_request(struct reque { __blk_mq_requeue_request(rq); + /* this request will be re-inserted to io scheduler queue */ + blk_mq_sched_requeue_request(rq); + BUG_ON(blk_queued_rq(rq)); blk_mq_add_to_requeue_list(rq, true, kick_requeue_list); } Patches currently in stable-queue which might be from ming.lei(a)redhat.com are queue-4.15/block-pass-inclusive-lend-parameter-to-truncate_inode_pages_range.patch queue-4.15/blk-mq-don-t-call-io-sched-s-.requeue_request-when-requeueing-rq-to-dispatch.patch queue-4.15/block-kyber-fix-domain-token-leak-during-requeue.patch

7 years, 6 months

1
0
0 0

Patch "ARM: orion: fix orion_ge00_switch_board_info initialization" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: orion: fix orion_ge00_switch_board_info initialization to the 4.15-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: arm-orion-fix-orion_ge00_switch_board_info-initialization.patch and it can be found in the queue-4.15 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 8337d083507b9827dfb36d545538b7789df834fd Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 21 Feb 2018 13:18:49 +0100 Subject: ARM: orion: fix orion_ge00_switch_board_info initialization From: Arnd Bergmann <arnd(a)arndb.de> commit 8337d083507b9827dfb36d545538b7789df834fd upstream. A section type mismatch warning shows up when building with LTO, since orion_ge00_mvmdio_bus_name was put in __initconst but not marked const itself: include/linux/of.h: In function 'spear_setup_of_timer': arch/arm/mach-spear/time.c:207:34: error: 'timer_of_match' causes a section type conflict with 'orion_ge00_mvmdio_bus_name' static const struct of_device_id timer_of_match[] __initconst = { ^ arch/arm/plat-orion/common.c:475:32: note: 'orion_ge00_mvmdio_bus_name' was declared here static __initconst const char *orion_ge00_mvmdio_bus_name = "orion-mii"; ^ As pointed out by Andrew Lunn, it should in fact be 'const' but not '__initconst' because the string is never copied but may be accessed after the init sections are freed. To fix that, I get rid of the extra symbol and rewrite the initialization in a simpler way that assigns both the bus_id and modalias statically. I spotted another theoretical bug in the same place, where d->netdev[i] may be an out of bounds access, this can be fixed by moving the device assignment into the loop. Cc: stable(a)vger.kernel.org Reviewed-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/plat-orion/common.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) --- a/arch/arm/plat-orion/common.c +++ b/arch/arm/plat-orion/common.c @@ -472,28 +472,27 @@ void __init orion_ge11_init(struct mv643 /***************************************************************************** * Ethernet switch ****************************************************************************/ -static __initconst const char *orion_ge00_mvmdio_bus_name = "orion-mii"; -static __initdata struct mdio_board_info - orion_ge00_switch_board_info; +static __initdata struct mdio_board_info orion_ge00_switch_board_info = { + .bus_id = "orion-mii", + .modalias = "mv88e6085", +}; void __init orion_ge00_switch_init(struct dsa_chip_data *d) { - struct mdio_board_info *bd; unsigned int i; if (!IS_BUILTIN(CONFIG_PHYLIB)) return; - for (i = 0; i < ARRAY_SIZE(d->port_names); i++) - if (!strcmp(d->port_names[i], "cpu")) + for (i = 0; i < ARRAY_SIZE(d->port_names); i++) { + if (!strcmp(d->port_names[i], "cpu")) { + d->netdev[i] = &orion_ge00.dev; break; + } + } - bd = &orion_ge00_switch_board_info; - bd->bus_id = orion_ge00_mvmdio_bus_name; - bd->mdio_addr = d->sw_addr; - d->netdev[i] = &orion_ge00.dev; - strcpy(bd->modalias, "mv88e6085"); - bd->platform_data = d; + orion_ge00_switch_board_info.mdio_addr = d->sw_addr; + orion_ge00_switch_board_info.platform_data = d; mdiobus_register_board_info(&orion_ge00_switch_board_info, 1); } Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.15/ipv6-sit-work-around-bogus-gcc-8-wrestrict-warning.patch queue-4.15/arm-kvm-fix-building-with-gcc-8.patch queue-4.15/arm-orion-fix-orion_ge00_switch_board_info-initialization.patch

7 years, 6 months

1
0
0 0

Patch "ARM: mvebu: Fix broken PL310_ERRATA_753970 selects" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: mvebu: Fix broken PL310_ERRATA_753970 selects to the 4.15-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: arm-mvebu-fix-broken-pl310_errata_753970-selects.patch and it can be found in the queue-4.15 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 8aa36a8dcde3183d84db7b0d622ffddcebb61077 Mon Sep 17 00:00:00 2001 From: Ulf Magnusson <ulfalizer(a)gmail.com> Date: Mon, 5 Feb 2018 02:21:13 +0100 Subject: ARM: mvebu: Fix broken PL310_ERRATA_753970 selects From: Ulf Magnusson <ulfalizer(a)gmail.com> commit 8aa36a8dcde3183d84db7b0d622ffddcebb61077 upstream. The MACH_ARMADA_375 and MACH_ARMADA_38X boards select ARM_ERRATA_753970, but it was renamed to PL310_ERRATA_753970 by commit fa0ce4035d48 ("ARM: 7162/1: errata: tidy up Kconfig options for PL310 errata workarounds"). Fix the selects to use the new name. Discovered with the https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined… script. Fixes: fa0ce4035d48 ("ARM: 7162/1: errata: tidy up Kconfig options for PL310 errata workarounds" cc: stable(a)vger.kernel.org Signed-off-by: Ulf Magnusson <ulfalizer(a)gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/mach-mvebu/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -42,7 +42,7 @@ config MACH_ARMADA_375 depends on ARCH_MULTI_V7 select ARMADA_370_XP_IRQ select ARM_ERRATA_720789 - select ARM_ERRATA_753970 + select PL310_ERRATA_753970 select ARM_GIC select ARMADA_375_CLK select HAVE_ARM_SCU @@ -58,7 +58,7 @@ config MACH_ARMADA_38X bool "Marvell Armada 380/385 boards" depends on ARCH_MULTI_V7 select ARM_ERRATA_720789 - select ARM_ERRATA_753970 + select PL310_ERRATA_753970 select ARM_GIC select ARM_GLOBAL_TIMER select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK Patches currently in stable-queue which might be from ulfalizer(a)gmail.com are queue-4.15/arm-mvebu-fix-broken-pl310_errata_753970-selects.patch

7 years, 6 months

1
0
0 0

Patch "ARM: kvm: fix building with gcc-8" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: kvm: fix building with gcc-8 to the 4.15-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: arm-kvm-fix-building-with-gcc-8.patch and it can be found in the queue-4.15 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 67870eb1204223598ea6d8a4467b482e9f5875b5 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Fri, 2 Feb 2018 16:07:34 +0100 Subject: ARM: kvm: fix building with gcc-8 From: Arnd Bergmann <arnd(a)arndb.de> commit 67870eb1204223598ea6d8a4467b482e9f5875b5 upstream. In banked-sr.c, we use a top-level '__asm__(".arch_extension virt")' statement to allow compilation of a multi-CPU kernel for ARMv6 and older ARMv7-A that don't normally support access to the banked registers. This is considered to be a programming error by the gcc developers and will no longer work in gcc-8, where we now get a build error: /tmp/cc4Qy7GR.s:34: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_usr' /tmp/cc4Qy7GR.s:41: Error: Banked registers are not available with this architecture. -- `mrs r3,ELR_hyp' /tmp/cc4Qy7GR.s:55: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_svc' /tmp/cc4Qy7GR.s:62: Error: Banked registers are not available with this architecture. -- `mrs r3,LR_svc' /tmp/cc4Qy7GR.s:69: Error: Banked registers are not available with this architecture. -- `mrs r3,SPSR_svc' /tmp/cc4Qy7GR.s:76: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_abt' Passign the '-march-armv7ve' flag to gcc works, and is ok here, because we know the functions won't ever be called on pre-ARMv7VE machines. Unfortunately, older compiler versions (4.8 and earlier) do not understand that flag, so we still need to keep the asm around. Backporting to stable kernels (4.6+) is needed to allow those to be built with future compilers as well. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84129 Fixes: 33280b4cd1dc ("ARM: KVM: Add banked registers save/restore") Cc: stable(a)vger.kernel.org Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/kvm/hyp/Makefile | 5 +++++ arch/arm/kvm/hyp/banked-sr.c | 4 ++++ 2 files changed, 9 insertions(+) --- a/arch/arm/kvm/hyp/Makefile +++ b/arch/arm/kvm/hyp/Makefile @@ -7,6 +7,8 @@ ccflags-y += -fno-stack-protector -DDISA KVM=../../../../virt/kvm +CFLAGS_ARMV7VE :=$(call cc-option, -march=armv7ve) + obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v3-sr.o obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/timer-sr.o @@ -15,7 +17,10 @@ obj-$(CONFIG_KVM_ARM_HOST) += tlb.o obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o obj-$(CONFIG_KVM_ARM_HOST) += vfp.o obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o +CFLAGS_banked-sr.o += $(CFLAGS_ARMV7VE) + obj-$(CONFIG_KVM_ARM_HOST) += entry.o obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o obj-$(CONFIG_KVM_ARM_HOST) += switch.o +CFLAGS_switch.o += $(CFLAGS_ARMV7VE) obj-$(CONFIG_KVM_ARM_HOST) += s2-setup.o --- a/arch/arm/kvm/hyp/banked-sr.c +++ b/arch/arm/kvm/hyp/banked-sr.c @@ -20,6 +20,10 @@ #include <asm/kvm_hyp.h> +/* + * gcc before 4.9 doesn't understand -march=armv7ve, so we have to + * trick the assembler. + */ __asm__(".arch_extension virt"); void __hyp_text __banked_save_state(struct kvm_cpu_context *ctxt) Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.15/ipv6-sit-work-around-bogus-gcc-8-wrestrict-warning.patch queue-4.15/arm-kvm-fix-building-with-gcc-8.patch queue-4.15/arm-orion-fix-orion_ge00_switch_board_info-initialization.patch

7 years, 6 months

1
0
0 0

Patch "ARM: dts: rockchip: Remove 1.8 GHz operation point from phycore som" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: rockchip: Remove 1.8 GHz operation point from phycore som to the 4.15-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: arm-dts-rockchip-remove-1.8-ghz-operation-point-from-phycore-som.patch and it can be found in the queue-4.15 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 5ce0bad4ccd04c8a989e94d3c89e4e796ac22e48 Mon Sep 17 00:00:00 2001 From: Daniel Schultz <d.schultz(a)phytec.de> Date: Tue, 13 Feb 2018 10:44:32 +0100 Subject: ARM: dts: rockchip: Remove 1.8 GHz operation point from phycore som From: Daniel Schultz <d.schultz(a)phytec.de> commit 5ce0bad4ccd04c8a989e94d3c89e4e796ac22e48 upstream. Rockchip recommends to run the CPU cores only with operations points of 1.6 GHz or lower. Removed the cpu0 node with too high operation points and use the default values instead. Fixes: 903d31e34628 ("ARM: dts: rockchip: Add support for phyCORE-RK3288 SoM") Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Schultz <d.schultz(a)phytec.de> Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/rk3288-phycore-som.dtsi | 20 -------------------- 1 file changed, 20 deletions(-) --- a/arch/arm/boot/dts/rk3288-phycore-som.dtsi +++ b/arch/arm/boot/dts/rk3288-phycore-som.dtsi @@ -110,26 +110,6 @@ }; }; -&cpu0 { - cpu0-supply = <&vdd_cpu>; - operating-points = < - /* KHz uV */ - 1800000 1400000 - 1608000 1350000 - 1512000 1300000 - 1416000 1200000 - 1200000 1100000 - 1008000 1050000 - 816000 1000000 - 696000 950000 - 600000 900000 - 408000 900000 - 312000 900000 - 216000 900000 - 126000 900000 - >; -}; - &emmc { status = "okay"; bus-width = <8>; Patches currently in stable-queue which might be from d.schultz(a)phytec.de are queue-4.15/arm-dts-rockchip-remove-1.8-ghz-operation-point-from-phycore-som.patch

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror