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

Patch "tracing: Fix parsing of globs with a wildcard at the beginning" 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 tracing: Fix parsing of globs with a wildcard at the beginning 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: tracing-fix-parsing-of-globs-with-a-wildcard-at-the-beginning.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 07234021410bbc27b7c86c18de98616c29fbe667 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> Date: Mon, 5 Feb 2018 22:18:11 -0500 Subject: tracing: Fix parsing of globs with a wildcard at the beginning From: Steven Rostedt (VMware) <rostedt(a)goodmis.org> commit 07234021410bbc27b7c86c18de98616c29fbe667 upstream. Al Viro reported: For substring - sure, but what about something like "*a*b" and "a*b"? AFAICS, filter_parse_regex() ends up with identical results in both cases - MATCH_GLOB and *search = "a*b". And no way for the caller to tell one from another. Testing this with the following: # cd /sys/kernel/tracing # echo '*raw*lock' > set_ftrace_filter bash: echo: write error: Invalid argument With this patch: # echo '*raw*lock' > set_ftrace_filter # cat set_ftrace_filter _raw_read_trylock _raw_write_trylock _raw_read_unlock _raw_spin_unlock _raw_write_unlock _raw_spin_trylock _raw_spin_lock _raw_write_lock _raw_read_lock Al recommended not setting the search buffer to skip the first '*' unless we know we are not using MATCH_GLOB. This implements his suggested logic. Link: http://lkml.kernel.org/r/20180127170748.GF13338@ZenIV.linux.org.uk Cc: stable(a)vger.kernel.org Fixes: 60f1d5e3bac44 ("ftrace: Support full glob matching") Reviewed-by: Masami Hiramatsu <mhiramat(a)kernel.org> Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk> Suggsted-by: Al Viro <viro(a)ZenIV.linux.org.uk> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/trace/trace_events_filter.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/kernel/trace/trace_events_filter.c +++ b/kernel/trace/trace_events_filter.c @@ -400,7 +400,6 @@ enum regex_type filter_parse_regex(char for (i = 0; i < len; i++) { if (buff[i] == '*') { if (!i) { - *search = buff + 1; type = MATCH_END_ONLY; } else if (i == len - 1) { if (type == MATCH_END_ONLY) @@ -410,14 +409,14 @@ enum regex_type filter_parse_regex(char buff[i] = 0; break; } else { /* pattern continues, use full glob */ - type = MATCH_GLOB; - break; + return MATCH_GLOB; } } else if (strchr("[?\\", buff[i])) { - type = MATCH_GLOB; - break; + return MATCH_GLOB; } } + if (buff[0] == '*') + *search = buff + 1; return type; } Patches currently in stable-queue which might be from rostedt(a)goodmis.org are queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch queue-4.14/tracing-fix-parsing-of-globs-with-a-wildcard-at-the-beginning.patch

7 years, 4 months

1
0
0 0

Patch "seq_file: fix incomplete reset on read from zero offset" 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 seq_file: fix incomplete reset on read from zero offset 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: seq_file-fix-incomplete-reset-on-read-from-zero-offset.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 cf5eebae2cd28d37581507668605f4d23cd7218d Mon Sep 17 00:00:00 2001 From: Miklos Szeredi <mszeredi(a)redhat.com> Date: Wed, 15 Nov 2017 11:34:58 +0100 Subject: seq_file: fix incomplete reset on read from zero offset From: Miklos Szeredi <mszeredi(a)redhat.com> commit cf5eebae2cd28d37581507668605f4d23cd7218d upstream. When resetting iterator on a zero offset we need to discard any data already in the buffer (count), and private state of the iterator (version). For example this bug results in first line being repeated in /proc/mounts if doing a zero size read before a non-zero size read. Reported-by: Rich Felker <dalias(a)libc.org> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Fixes: e522751d605d ("seq_file: reset iterator to first record for zero offset") Cc: <stable(a)vger.kernel.org> # v4.10 Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/seq_file.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/fs/seq_file.c +++ b/fs/seq_file.c @@ -181,8 +181,11 @@ ssize_t seq_read(struct file *file, char * if request is to read from zero offset, reset iterator to first * record as it might have been already advanced by previous requests */ - if (*ppos == 0) + if (*ppos == 0) { m->index = 0; + m->version = 0; + m->count = 0; + } /* Don't assume *ppos is where we left it */ if (unlikely(*ppos != m->read_pos)) { Patches currently in stable-queue which might be from mszeredi(a)redhat.com are queue-4.14/seq_file-fix-incomplete-reset-on-read-from-zero-offset.patch

7 years, 4 months

1
0
0 0

Patch "rtc-opal: Fix handling of firmware error codes, prevent busy loops" 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 rtc-opal: Fix handling of firmware error codes, prevent busy loops 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: rtc-opal-fix-handling-of-firmware-error-codes-prevent-busy-loops.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 5b8b58063029f02da573120ef4dc9079822e3cda Mon Sep 17 00:00:00 2001 From: Stewart Smith <stewart(a)linux.vnet.ibm.com> Date: Tue, 2 Aug 2016 11:50:16 +1000 Subject: rtc-opal: Fix handling of firmware error codes, prevent busy loops From: Stewart Smith <stewart(a)linux.vnet.ibm.com> commit 5b8b58063029f02da573120ef4dc9079822e3cda upstream. According to the OPAL docs: skiboot-5.2.5/doc/opal-api/opal-rtc-read-3.txt skiboot-5.2.5/doc/opal-api/opal-rtc-write-4.txt OPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and this indicates either a transient or permanent error. Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a permanent error particularly well, in that you could end up in a busy loop. This was not too hard to trigger on an AMI BMC based OpenPOWER machine doing a continuous "ipmitool mc reset cold" to the BMC, the result of that being that we'd get stuck in an infinite loop in opal_get_rtc_time(). We now retry a few times before returning the error higher up the stack. Fixes: 16b1d26e77b1 ("rtc/tpo: Driver to support rtc and wakeup on PowerNV platform") Cc: stable(a)vger.kernel.org # v3.19+ Signed-off-by: Stewart Smith <stewart(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rtc/rtc-opal.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/drivers/rtc/rtc-opal.c +++ b/drivers/rtc/rtc-opal.c @@ -58,6 +58,7 @@ static void tm_to_opal(struct rtc_time * static int opal_get_rtc_time(struct device *dev, struct rtc_time *tm) { long rc = OPAL_BUSY; + int retries = 10; u32 y_m_d; u64 h_m_s_ms; __be32 __y_m_d; @@ -67,8 +68,11 @@ static int opal_get_rtc_time(struct devi rc = opal_rtc_read(&__y_m_d, &__h_m_s_ms); if (rc == OPAL_BUSY_EVENT) opal_poll_events(NULL); - else + else if (retries-- && (rc == OPAL_HARDWARE + || rc == OPAL_INTERNAL_ERROR)) msleep(10); + else if (rc != OPAL_BUSY && rc != OPAL_BUSY_EVENT) + break; } if (rc != OPAL_SUCCESS) @@ -84,6 +88,7 @@ static int opal_get_rtc_time(struct devi static int opal_set_rtc_time(struct device *dev, struct rtc_time *tm) { long rc = OPAL_BUSY; + int retries = 10; u32 y_m_d = 0; u64 h_m_s_ms = 0; @@ -92,8 +97,11 @@ static int opal_set_rtc_time(struct devi rc = opal_rtc_write(y_m_d, h_m_s_ms); if (rc == OPAL_BUSY_EVENT) opal_poll_events(NULL); - else + else if (retries-- && (rc == OPAL_HARDWARE + || rc == OPAL_INTERNAL_ERROR)) msleep(10); + else if (rc != OPAL_BUSY && rc != OPAL_BUSY_EVENT) + break; } return rc == OPAL_SUCCESS ? 0 : -EIO; Patches currently in stable-queue which might be from stewart(a)linux.vnet.ibm.com are queue-4.14/rtc-opal-fix-handling-of-firmware-error-codes-prevent-busy-loops.patch

7 years, 4 months

1
0
0 0

Patch "Revert "mmc: meson-gx: include tx phase in the tuning process"" 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 Revert "mmc: meson-gx: include tx phase in the tuning process" 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: revert-mmc-meson-gx-include-tx-phase-in-the-tuning-process.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 fe0e58048f005fdce315eb4d185e5c160be4ac01 Mon Sep 17 00:00:00 2001 From: Jerome Brunet <jbrunet(a)baylibre.com> Date: Mon, 12 Feb 2018 14:13:59 +0100 Subject: Revert "mmc: meson-gx: include tx phase in the tuning process" From: Jerome Brunet <jbrunet(a)baylibre.com> commit fe0e58048f005fdce315eb4d185e5c160be4ac01 upstream. This reverts commit 0a44697627d17a66d7dc98f17aeca07ca79c5c20. This commit was initially intended to fix problems with hs200 and hs400 on some boards, mainly the odroid-c2. The OC2 (Rev 0.2) I have performs well in this modes, so I could not confirm these issues. We've had several reports about the issues being still present on (some) OC2, so apparently, this change does not do what it was supposed to do. Maybe the eMMC signal quality is on the edge on the board. This may explain the variability we see in term of stability, but this is just a guess. Lowering the max_frequency to 100Mhz seems to do trick for those affected by the issue Worse, the commit created new issues (CRC errors and hangs) on other boards, such as the kvim 1 and 2, the p200 or the libretech-cc. According to amlogic, the Tx phase should not be tuned and left in its default configuration, so it is best to just revert the commit. Fixes: 0a44697627d1 ("mmc: meson-gx: include tx phase in the tuning process") Cc: <stable(a)vger.kernel.org> # 4.14+ Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/meson-gx-mmc.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-) --- a/drivers/mmc/host/meson-gx-mmc.c +++ b/drivers/mmc/host/meson-gx-mmc.c @@ -716,22 +716,6 @@ static int meson_mmc_clk_phase_tuning(st static int meson_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode) { struct meson_host *host = mmc_priv(mmc); - int ret; - - /* - * If this is the initial tuning, try to get a sane Rx starting - * phase before doing the actual tuning. - */ - if (!mmc->doing_retune) { - ret = meson_mmc_clk_phase_tuning(mmc, opcode, host->rx_clk); - - if (ret) - return ret; - } - - ret = meson_mmc_clk_phase_tuning(mmc, opcode, host->tx_clk); - if (ret) - return ret; return meson_mmc_clk_phase_tuning(mmc, opcode, host->rx_clk); } @@ -762,9 +746,8 @@ static void meson_mmc_set_ios(struct mmc if (!IS_ERR(mmc->supply.vmmc)) mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, ios->vdd); - /* Reset phases */ + /* Reset rx phase */ clk_set_phase(host->rx_clk, 0); - clk_set_phase(host->tx_clk, 270); break; Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are queue-4.14/revert-mmc-meson-gx-include-tx-phase-in-the-tuning-process.patch

7 years, 4 months

1
0
0 0

Patch "Revert "apple-gmux: lock iGP IO to protect from vgaarb changes"" 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 Revert "apple-gmux: lock iGP IO to protect from vgaarb changes" 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: revert-apple-gmux-lock-igp-io-to-protect-from-vgaarb-changes.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 d6fa7588fd7a8def4c747c0c574ce85d453e3788 Mon Sep 17 00:00:00 2001 From: Lukas Wunner <lukas(a)wunner.de> Date: Wed, 24 Jan 2018 19:35:45 +0100 Subject: Revert "apple-gmux: lock iGP IO to protect from vgaarb changes" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Lukas Wunner <lukas(a)wunner.de> commit d6fa7588fd7a8def4c747c0c574ce85d453e3788 upstream. Commit 4eebd5a4e726 ("apple-gmux: lock iGP IO to protect from vgaarb changes") amended this driver's ->probe hook to lock decoding of normal (non-legacy) I/O space accesses to the integrated GPU on dual-GPU MacBook Pros. The lock stays in place until the driver is unbound. The change was made to work around an issue with the out-of-tree nvidia graphics driver (available at http://www.nvidia.com/object/unix.html). It contains the following sequence in nvidia/nv.c: #if defined(CONFIG_VGA_ARB) && !defined(NVCPU_PPC64LE) #if defined(VGA_DEFAULT_DEVICE) vga_tryget(VGA_DEFAULT_DEVICE, VGA_RSRC_LEGACY_MASK); #endif vga_set_legacy_decoding(dev, VGA_RSRC_NONE); #endif This code was reported to cause deadlocks with VFIO already in 2013: https://devtalk.nvidia.com/default/topic/545560 I've reported the issue to Nvidia developers once more in 2017: https://www.spinics.net/lists/dri-devel/msg138754.html On the MacBookPro10,1, this code apparently breaks backlight control (which is handled by apple-gmux via an I/O region starting at 0x700), as reported by Petri Hodju: https://bugzilla.kernel.org/show_bug.cgi?id=86121 I tried to replicate Petri's observations on my MacBook9,1, which uses the same Intel Ivy Bridge + Nvidia GeForce GT 650M architecture, to no avail. On my machine apple-gmux' I/O region remains accessible even with the nvidia driver loaded and commit 4eebd5a4e726 reverted. Petri reported that apple-gmux becomes accessible again after a suspend/resume cycle because the BIOS changed the VGA routing on the root port to the Nvidia GPU. Perhaps this is a BIOS issue after all that can be fixed with an update? In any case, the change made by commit 4eebd5a4e726 has turned out to cause two new issues: * Wilfried Klaebe reports a deadlock when launching Xorg because it opens /dev/vga_arbiter and calls vga_get(), but apple-gmux is holding a lock on I/O space indefinitely. It looks like apple-gmux' current behavior is an abuse of the vgaarb API as locks are not meant to be held for longer periods: https://bugzilla.kernel.org/show_bug.cgi?id=88861#c11 https://bugzilla.kernel.org/attachment.cgi?id=217541 * On dual GPU MacBook Pros introduced since 2013, the integrated GPU is powergated on boot und thus becomes invisible to Linux unless a custom EFI protocol is used to leave it powered on. (A patch exists but is not in mainline yet due to several negative side effects.) On these machines, locking I/O to the integrated GPU (as done by 4eebd5a4e726) fails and backlight control is therefore broken: https://bugzilla.kernel.org/show_bug.cgi?id=105051 So let's revert commit 4eebd5a4e726 please. Users experiencing the issue with the proprietary nvidia driver can comment out the above- quoted problematic code as a workaround (or try updating the BIOS). Cc: Petri Hodju <petrihodju(a)yahoo.com> Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: Bruno Prémont <bonbons(a)linux-vserver.org> Cc: Andy Ritger <aritger(a)nvidia.com> Cc: Ronald Tschalär <ronald(a)innovation.ch> Tested-by: Wilfried Klaebe <linux-kernel(a)lebenslange-mailadresse.de> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Cc: stable(a)vger.kernel.org Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/apple-gmux.c | 48 -------------------------------------- 1 file changed, 1 insertion(+), 47 deletions(-) --- a/drivers/platform/x86/apple-gmux.c +++ b/drivers/platform/x86/apple-gmux.c @@ -24,7 +24,6 @@ #include <linux/delay.h> #include <linux/pci.h> #include <linux/vga_switcheroo.h> -#include <linux/vgaarb.h> #include <acpi/video.h> #include <asm/io.h> @@ -54,7 +53,6 @@ struct apple_gmux_data { bool indexed; struct mutex index_lock; - struct pci_dev *pdev; struct backlight_device *bdev; /* switcheroo data */ @@ -599,23 +597,6 @@ static int gmux_resume(struct device *de return 0; } -static struct pci_dev *gmux_get_io_pdev(void) -{ - struct pci_dev *pdev = NULL; - - while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev))) { - u16 cmd; - - pci_read_config_word(pdev, PCI_COMMAND, &cmd); - if (!(cmd & PCI_COMMAND_IO)) - continue; - - return pdev; - } - - return NULL; -} - static int is_thunderbolt(struct device *dev, void *data) { return to_pci_dev(dev)->is_thunderbolt; @@ -631,7 +612,6 @@ static int gmux_probe(struct pnp_dev *pn int ret = -ENXIO; acpi_status status; unsigned long long gpe; - struct pci_dev *pdev = NULL; if (apple_gmux_data) return -EBUSY; @@ -682,7 +662,7 @@ static int gmux_probe(struct pnp_dev *pn ver_minor = (version >> 16) & 0xff; ver_release = (version >> 8) & 0xff; } else { - pr_info("gmux device not present or IO disabled\n"); + pr_info("gmux device not present\n"); ret = -ENODEV; goto err_release; } @@ -690,23 +670,6 @@ static int gmux_probe(struct pnp_dev *pn pr_info("Found gmux version %d.%d.%d [%s]\n", ver_major, ver_minor, ver_release, (gmux_data->indexed ? "indexed" : "classic")); - /* - * Apple systems with gmux are EFI based and normally don't use - * VGA. In addition changing IO+MEM ownership between IGP and dGPU - * disables IO/MEM used for backlight control on some systems. - * Lock IO+MEM to GPU with active IO to prevent switch. - */ - pdev = gmux_get_io_pdev(); - if (pdev && vga_tryget(pdev, - VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) { - pr_err("IO+MEM vgaarb-locking for PCI:%s failed\n", - pci_name(pdev)); - ret = -EBUSY; - goto err_release; - } else if (pdev) - pr_info("locked IO for PCI:%s\n", pci_name(pdev)); - gmux_data->pdev = pdev; - memset(&props, 0, sizeof(props)); props.type = BACKLIGHT_PLATFORM; props.max_brightness = gmux_read32(gmux_data, GMUX_PORT_MAX_BRIGHTNESS); @@ -822,10 +785,6 @@ err_enable_gpe: err_notify: backlight_device_unregister(bdev); err_release: - if (gmux_data->pdev) - vga_put(gmux_data->pdev, - VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM); - pci_dev_put(pdev); release_region(gmux_data->iostart, gmux_data->iolen); err_free: kfree(gmux_data); @@ -845,11 +804,6 @@ static void gmux_remove(struct pnp_dev * &gmux_notify_handler); } - if (gmux_data->pdev) { - vga_put(gmux_data->pdev, - VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM); - pci_dev_put(gmux_data->pdev); - } backlight_device_unregister(gmux_data->bdev); release_region(gmux_data->iostart, gmux_data->iolen); Patches currently in stable-queue which might be from lukas(a)wunner.de are queue-4.14/pm-runtime-update-links_count-also-if-config_srcu.patch queue-4.14/revert-apple-gmux-lock-igp-io-to-protect-from-vgaarb-changes.patch

7 years, 4 months

1
0
0 0

Patch "rbd: whitelist RBD_FEATURE_OPERATIONS feature bit" 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 rbd: whitelist RBD_FEATURE_OPERATIONS feature bit 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: rbd-whitelist-rbd_feature_operations-feature-bit.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 e573427a440fd67d3f522357d7ac901d59281948 Mon Sep 17 00:00:00 2001 From: Ilya Dryomov <idryomov(a)gmail.com> Date: Tue, 16 Jan 2018 15:41:54 +0100 Subject: rbd: whitelist RBD_FEATURE_OPERATIONS feature bit From: Ilya Dryomov <idryomov(a)gmail.com> commit e573427a440fd67d3f522357d7ac901d59281948 upstream. This feature bit restricts older clients from performing certain maintenance operations against an image (e.g. clone, snap create). krbd does not perform maintenance operations. Cc: stable(a)vger.kernel.org Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Reviewed-by: Jason Dillaman <dillaman(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/block/rbd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -124,11 +124,13 @@ static int atomic_dec_return_safe(atomic #define RBD_FEATURE_STRIPINGV2 (1ULL<<1) #define RBD_FEATURE_EXCLUSIVE_LOCK (1ULL<<2) #define RBD_FEATURE_DATA_POOL (1ULL<<7) +#define RBD_FEATURE_OPERATIONS (1ULL<<8) #define RBD_FEATURES_ALL (RBD_FEATURE_LAYERING | \ RBD_FEATURE_STRIPINGV2 | \ RBD_FEATURE_EXCLUSIVE_LOCK | \ - RBD_FEATURE_DATA_POOL) + RBD_FEATURE_DATA_POOL | \ + RBD_FEATURE_OPERATIONS) /* Features supported by this (client software) implementation. */ Patches currently in stable-queue which might be from idryomov(a)gmail.com are queue-4.14/rbd-whitelist-rbd_feature_operations-feature-bit.patch

7 years, 4 months

1
0
0 0

Patch "PCI: keystone: Fix interrupt-controller-node lookup" 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: keystone: Fix interrupt-controller-node lookup 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-keystone-fix-interrupt-controller-node-lookup.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 eac56aa3bc8af3d9b9850345d0f2da9d83529134 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Fri, 17 Nov 2017 14:38:31 +0100 Subject: PCI: keystone: Fix interrupt-controller-node lookup From: Johan Hovold <johan(a)kernel.org> commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream. Fix child-node lookup during initialisation which was using the wrong OF-helper and ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent pci node could end up being prematurely freed as of_find_node_by_name() drops a reference to its first argument. Any matching child interrupt-controller node was also leaked. Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver") Cc: stable <stable(a)vger.kernel.org> # 3.18 Acked-by: Murali Karicheri <m-karicheri2(a)ti.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> [lorenzo.pieralisi(a)arm.com: updated commit subject] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/dwc/pci-keystone.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/pci/dwc/pci-keystone.c +++ b/drivers/pci/dwc/pci-keystone.c @@ -178,7 +178,7 @@ static int ks_pcie_get_irq_controller_in } /* interrupt controller is in a child node */ - *np_temp = of_find_node_by_name(np_pcie, controller); + *np_temp = of_get_child_by_name(np_pcie, controller); if (!(*np_temp)) { dev_err(dev, "Node for %s is absent\n", controller); return -EINVAL; @@ -187,6 +187,7 @@ static int ks_pcie_get_irq_controller_in temp = of_irq_count(*np_temp); if (!temp) { dev_err(dev, "No IRQ entries in %s\n", controller); + of_node_put(*np_temp); return -EINVAL; } @@ -204,6 +205,8 @@ static int ks_pcie_get_irq_controller_in break; } + of_node_put(*np_temp); + if (temp) { *num_irqs = temp; return 0; Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.14/pci-keystone-fix-interrupt-controller-node-lookup.patch queue-4.14/video-fbdev-atmel_lcdfb-fix-display-timings-lookup.patch

7 years, 4 months

1
0
0 0

Patch "PCI: iproc: Fix NULL pointer dereference for BCMA" 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: iproc: Fix NULL pointer dereference for BCMA 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-iproc-fix-null-pointer-dereference-for-bcma.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 3b65ca50d24ce33cb92d88840e289135c92b40ed Mon Sep 17 00:00:00 2001 From: Ray Jui <ray.jui(a)broadcom.com> Date: Thu, 11 Jan 2018 12:36:16 -0800 Subject: PCI: iproc: Fix NULL pointer dereference for BCMA MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ray Jui <ray.jui(a)broadcom.com> commit 3b65ca50d24ce33cb92d88840e289135c92b40ed upstream. With the inbound DMA mapping supported added, the iProc PCIe driver parses DT property "dma-ranges" through call to "of_pci_dma_range_parser_init()". In the case of BCMA, this results in a NULL pointer deference due to a missing of_node. Fix this by adding a guard in pcie-iproc-platform.c to only enable the inbound DMA mapping logic when DT property "dma-ranges" is present. Fixes: dd9d4e7498de3 ("PCI: iproc: Add inbound DMA mapping support") Reported-by: Rafał Miłecki <rafal(a)milecki.pl> Signed-off-by: Ray Jui <ray.jui(a)broadcom.com> [lorenzo.pieralisi(a)arm.com: updated commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Tested-by: Rafał Miłecki <rafal(a)milecki.pl> cc: <stable(a)vger.kernel.org> # 4.10+ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/host/pcie-iproc-platform.c | 7 +++++++ drivers/pci/host/pcie-iproc.c | 8 +++++--- drivers/pci/host/pcie-iproc.h | 2 ++ 3 files changed, 14 insertions(+), 3 deletions(-) --- a/drivers/pci/host/pcie-iproc-platform.c +++ b/drivers/pci/host/pcie-iproc-platform.c @@ -92,6 +92,13 @@ static int iproc_pcie_pltfm_probe(struct pcie->need_ob_cfg = true; } + /* + * DT nodes are not used by all platforms that use the iProc PCIe + * core driver. For platforms that require explict inbound mapping + * configuration, "dma-ranges" would have been present in DT + */ + pcie->need_ib_cfg = of_property_read_bool(np, "dma-ranges"); + /* PHY use is optional */ pcie->phy = devm_phy_get(dev, "pcie-phy"); if (IS_ERR(pcie->phy)) { --- a/drivers/pci/host/pcie-iproc.c +++ b/drivers/pci/host/pcie-iproc.c @@ -1396,9 +1396,11 @@ int iproc_pcie_setup(struct iproc_pcie * } } - ret = iproc_pcie_map_dma_ranges(pcie); - if (ret && ret != -ENOENT) - goto err_power_off_phy; + if (pcie->need_ib_cfg) { + ret = iproc_pcie_map_dma_ranges(pcie); + if (ret && ret != -ENOENT) + goto err_power_off_phy; + } #ifdef CONFIG_ARM pcie->sysdata.private_data = pcie; --- a/drivers/pci/host/pcie-iproc.h +++ b/drivers/pci/host/pcie-iproc.h @@ -74,6 +74,7 @@ struct iproc_msi; * @ob: outbound mapping related parameters * @ob_map: outbound mapping related parameters specific to the controller * + * @need_ib_cfg: indicates SW needs to configure the inbound mapping window * @ib: inbound mapping related parameters * @ib_map: outbound mapping region related parameters * @@ -101,6 +102,7 @@ struct iproc_pcie { struct iproc_pcie_ob ob; const struct iproc_pcie_ob_map *ob_map; + bool need_ib_cfg; struct iproc_pcie_ib ib; const struct iproc_pcie_ib_map *ib_map; Patches currently in stable-queue which might be from ray.jui(a)broadcom.com are queue-4.14/pci-iproc-fix-null-pointer-dereference-for-bcma.patch

7 years, 4 months

1
0
0 0

Patch "PCI: Disable MSI for HiSilicon Hip06/Hip07 only in Root Port mode" 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: Disable MSI for HiSilicon Hip06/Hip07 only in Root Port mode 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-disable-msi-for-hisilicon-hip06-hip07-only-in-root-port-mode.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 deb86999323661c019ef2740eb9d479d1e526b5c Mon Sep 17 00:00:00 2001 From: Dongdong Liu <liudongdong3(a)huawei.com> Date: Thu, 28 Dec 2017 17:53:32 +0800 Subject: PCI: Disable MSI for HiSilicon Hip06/Hip07 only in Root Port mode From: Dongdong Liu <liudongdong3(a)huawei.com> commit deb86999323661c019ef2740eb9d479d1e526b5c upstream. HiSilicon Hip06/Hip07 can operate as either a Root Port or an Endpoint. It always advertises an MSI capability, but it can only generate MSIs when in Endpoint mode. The device has the same Vendor and Device IDs in both modes, so check the Class Code and disable MSI only when operating as a Root Port. [bhelgaas: changelog] Fixes: 72f2ff0deb87 ("PCI: Disable MSI for HiSilicon Hip06/Hip07 Root Ports") Signed-off-by: Dongdong Liu <liudongdong3(a)huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Reviewed-by: Zhou Wang <wangzhou1(a)hisilicon.com> Cc: stable(a)vger.kernel.org # v4.11+ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/quirks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1636,8 +1636,8 @@ static void quirk_pcie_mch(struct pci_de DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7520_MCH, quirk_pcie_mch); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7320_MCH, quirk_pcie_mch); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7525_MCH, quirk_pcie_mch); -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0x1610, quirk_pcie_mch); +DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_HUAWEI, 0x1610, PCI_CLASS_BRIDGE_PCI, 8, quirk_pcie_mch); /* * It's possible for the MSI to get corrupted if shpc and acpi Patches currently in stable-queue which might be from liudongdong3(a)huawei.com are queue-4.14/pci-disable-msi-for-hisilicon-hip06-hip07-only-in-root-port-mode.patch

7 years, 4 months

1
0
0 0

Patch "mpls, nospec: Sanitize array index in mpls_label_ok()" 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 mpls, nospec: Sanitize array index in mpls_label_ok() 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: mpls-nospec-sanitize-array-index-in-mpls_label_ok.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 3968523f855050b8195134da951b87c20bd66130 Mon Sep 17 00:00:00 2001 From: Dan Williams <dan.j.williams(a)intel.com> Date: Wed, 7 Feb 2018 22:34:24 -0800 Subject: mpls, nospec: Sanitize array index in mpls_label_ok() From: Dan Williams <dan.j.williams(a)intel.com> commit 3968523f855050b8195134da951b87c20bd66130 upstream. mpls_label_ok() validates that the 'platform_label' array index from a userspace netlink message payload is valid. Under speculation the mpls_label_ok() result may not resolve in the CPU pipeline until after the index is used to access an array element. Sanitize the index to zero to prevent userspace-controlled arbitrary out-of-bounds speculation, a precursor for a speculative execution side channel vulnerability. Cc: <stable(a)vger.kernel.org> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Eric W. Biederman <ebiederm(a)xmission.com> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mpls/af_mpls.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) --- a/net/mpls/af_mpls.c +++ b/net/mpls/af_mpls.c @@ -8,6 +8,7 @@ #include <linux/ipv6.h> #include <linux/mpls.h> #include <linux/netconf.h> +#include <linux/nospec.h> #include <linux/vmalloc.h> #include <linux/percpu.h> #include <net/ip.h> @@ -904,24 +905,27 @@ errout: return err; } -static bool mpls_label_ok(struct net *net, unsigned int index, +static bool mpls_label_ok(struct net *net, unsigned int *index, struct netlink_ext_ack *extack) { + bool is_ok = true; + /* Reserved labels may not be set */ - if (index < MPLS_LABEL_FIRST_UNRESERVED) { + if (*index < MPLS_LABEL_FIRST_UNRESERVED) { NL_SET_ERR_MSG(extack, "Invalid label - must be MPLS_LABEL_FIRST_UNRESERVED or higher"); - return false; + is_ok = false; } /* The full 20 bit range may not be supported. */ - if (index >= net->mpls.platform_labels) { + if (is_ok && *index >= net->mpls.platform_labels) { NL_SET_ERR_MSG(extack, "Label >= configured maximum in platform_labels"); - return false; + is_ok = false; } - return true; + *index = array_index_nospec(*index, net->mpls.platform_labels); + return is_ok; } static int mpls_route_add(struct mpls_route_config *cfg, @@ -944,7 +948,7 @@ static int mpls_route_add(struct mpls_ro index = find_free_label(net); } - if (!mpls_label_ok(net, index, extack)) + if (!mpls_label_ok(net, &index, extack)) goto errout; /* Append makes no sense with mpls */ @@ -1021,7 +1025,7 @@ static int mpls_route_del(struct mpls_ro index = cfg->rc_label; - if (!mpls_label_ok(net, index, extack)) + if (!mpls_label_ok(net, &index, extack)) goto errout; mpls_route_update(net, index, NULL, &cfg->rc_nlinfo); @@ -1779,7 +1783,7 @@ static int rtm_to_route_config(struct sk goto errout; if (!mpls_label_ok(cfg->rc_nlinfo.nl_net, - cfg->rc_label, extack)) + &cfg->rc_label, extack)) goto errout; break; } @@ -2106,7 +2110,7 @@ static int mpls_getroute(struct sk_buff goto errout; } - if (!mpls_label_ok(net, in_label, extack)) { + if (!mpls_label_ok(net, &in_label, extack)) { err = -EINVAL; goto errout; } Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are queue-4.14/x86-entry-64-interleave-xor-register-clearing-with-push-instructions.patch queue-4.14/nospec-move-array_index_nospec-parameter-checking-into-separate-macro.patch queue-4.14/x86-entry-64-merge-the-pop_c_regs-and-pop_extra_regs-macros-into-a-single-pop_regs-macro.patch queue-4.14/kvm-nvmx-set-the-cpu_based_use_msr_bitmaps-if-we-have-a-valid-l02-msr-bitmap.patch queue-4.14/x86-nvmx-properly-set-spec_ctrl-and-pred_cmd-before-merging-msrs.patch queue-4.14/x86-speculation-add-asm-msr-index.h-dependency.patch queue-4.14/mm-fix-memory-size-alignment-in-devm_memremap_pages_release.patch queue-4.14/x86-entry-64-use-push_and_clean_regs-in-more-cases.patch queue-4.14/x86-speculation-update-speculation-control-microcode-blacklist.patch queue-4.14/x86-entry-64-clear-registers-for-exceptions-interrupts-to-reduce-speculation-attack-surface.patch queue-4.14/x86-speculation-correct-speculation-control-microcode-blacklist-again.patch queue-4.14/x86-entry-64-merge-save_c_regs-and-save_extra_regs-remove-unused-extensions.patch queue-4.14/x86-entry-64-indent-push_and_clear_regs-and-pop_regs-properly.patch queue-4.14/x86-speculation-fix-up-array_index_nospec_mask-asm-constraint.patch queue-4.14/x86-entry-64-clear-extra-registers-beyond-syscall-arguments-to-reduce-speculation-attack-surface.patch queue-4.14/kvm-x86-reduce-retpoline-performance-impact-in-slot_handle_level_range-by-always-inlining-iterator-helper-methods.patch queue-4.14/x86-mm-pti-fix-pti-comment-in-entry_syscall_64.patch queue-4.14/x86-entry-64-get-rid-of-the-alloc_pt_gpregs_on_stack-and-save_and_clear_regs-macros.patch queue-4.14/mpls-nospec-sanitize-array-index-in-mpls_label_ok.patch queue-4.14/x86-speculation-clean-up-various-spectre-related-details.patch queue-4.14/x86-entry-64-introduce-the-push_and_clean_regs-macro.patch queue-4.14/revert-x86-speculation-simplify-indirect_branch_prediction_barrier.patch queue-4.14/x86-entry-64-compat-clear-registers-for-compat-syscalls-to-reduce-speculation-attack-surface.patch queue-4.14/x86-entry-64-fix-cr3-restore-in-paranoid_exit.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror