File /sys/kernel/debug/kprobes/blacklist displays random addresses:
[root@s8360046 linux]# cat /sys/kernel/debug/kprobes/blacklist
0x0000000047149a90-0x00000000bfcb099a print_type_x8
....
This breaks 'perf probe' which uses the blacklist file to prohibit
probes on certain functions by checking the address range.
Fix this by printing the correct (unhashed) address.
The file mode is read all but this is not an issue as the file
hierarchy points out:
# ls -ld /sys/ /sys/kernel/ /sys/kernel/debug/ /sys/kernel/debug/kprobes/
/sys/kernel/debug/kprobes/blacklist
dr-xr-xr-x 12 root root 0 Apr 19 07:56 /sys/
drwxr-xr-x 8 root root 0 Apr 19 07:56 /sys/kernel/
drwx------ 16 root root 0 Apr 19 06:56 /sys/kernel/debug/
drwxr-xr-x 2 root root 0 Apr 19 06:56 /sys/kernel/debug/kprobes/
-r--r--r-- 1 root root 0 Apr 19 06:56 /sys/kernel/debug/kprobes/blacklist
Everything in and below /sys/kernel/debug is rwx to root only,
no group or others have access.
Background:
Directory /sys/kernel/debug/kprobes is created by debugfs_create_dir()
which sets the mode bits to rwxr-xr-x. Maybe change that to use the
parent's directory mode bits instead?
Fixes: ad67b74d2469 ("printk: hash addresses printed with %p")
Cc: <stable(a)vger.kernel.org> # v4.15+
Cc: <linux-kernel(a)vger.kernel.org>
To: Ananth N Mavinakayanahalli <ananth(a)linux.vnet.ibm.com>
To: Anil S Keshavamurthy <anil.s.keshavamurthy(a)intel.com>
To: David S Miller <davem(a)davemloft.net>
To: Masami Hiramatsu <mhiramat(a)kernel.org>
To: Andrew Morton <akpm(a)linux-foundation.org>
To: acme(a)kernel.org
To: Steven Rostedt <rostedt(a)goodmis.org>
Signed-off-by: Thomas Richter <tmricht(a)linux.ibm.com>
---
kernel/kprobes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 102160ff5c66..ea619021d901 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2428,7 +2428,7 @@ static int kprobe_blacklist_seq_show(struct seq_file *m, void *v)
struct kprobe_blacklist_entry *ent =
list_entry(v, struct kprobe_blacklist_entry, list);
- seq_printf(m, "0x%p-0x%p\t%ps\n", (void *)ent->start_addr,
+ seq_printf(m, "0x%px-0x%px\t%ps\n", (void *)ent->start_addr,
(void *)ent->end_addr, (void *)ent->start_addr);
return 0;
}
--
2.14.3
This is a note to let you know that I've just added the patch titled
ARM: amba: Fix race condition with driver_override
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-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 6b614a87f3f477571e319281e84dba11e0ea0a76 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Tue, 10 Apr 2018 15:21:44 +0200
Subject: ARM: amba: Fix race condition with driver_override
The driver_override implementation is susceptible to a race condition
when different threads are reading vs storing a different driver
override. Add locking to avoid this race condition.
Cfr. commits 6265539776a0810b ("driver core: platform: fix race
condition with driver_override") and 9561475db680f714 ("PCI: Fix race
condition with driver_override").
Fixes: 3cf385713460eb2b ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Reviewed-by: Todd Kjos <tkjos(a)google.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/amba/bus.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228d2f02..c77eb6e65646 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -69,11 +69,15 @@ static ssize_t driver_override_show(struct device *_dev,
struct device_attribute *attr, char *buf)
{
struct amba_device *dev = to_amba_device(_dev);
+ ssize_t len;
if (!dev->driver_override)
return 0;
- return sprintf(buf, "%s\n", dev->driver_override);
+ device_lock(_dev);
+ len = sprintf(buf, "%s\n", dev->driver_override);
+ device_unlock(_dev);
+ return len;
}
static ssize_t driver_override_store(struct device *_dev,
@@ -81,7 +85,7 @@ static ssize_t driver_override_store(struct device *_dev,
const char *buf, size_t count)
{
struct amba_device *dev = to_amba_device(_dev);
- char *driver_override, *old = dev->driver_override, *cp;
+ char *driver_override, *old, *cp;
if (count > PATH_MAX)
return -EINVAL;
@@ -94,12 +98,15 @@ static ssize_t driver_override_store(struct device *_dev,
if (cp)
*cp = '\0';
+ device_lock(_dev);
+ old = dev->driver_override;
if (strlen(driver_override)) {
dev->driver_override = driver_override;
} else {
kfree(driver_override);
dev->driver_override = NULL;
}
+ device_unlock(_dev);
kfree(old);
--
2.17.0
This is a note to let you know that I've just added the patch titled
usb: do not reset if a low-speed or full-speed device timed out
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-next 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 also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 6e01827ed93947895680fbdad68c072a0f4e2450 Mon Sep 17 00:00:00 2001
From: Maxim Moseychuk <franchesko.salias.hudro.pedros(a)gmail.com>
Date: Thu, 4 Jan 2018 21:43:03 +0300
Subject: usb: do not reset if a low-speed or full-speed device timed out
Some low-speed and full-speed devices (for example, bluetooth)
do not have time to initialize. For them, ETIMEDOUT is a valid error.
We need to give them another try. Otherwise, they will
never be initialized correctly and in dmesg will be messages
"Bluetooth: hci0 command 0x1002 tx timeout" or similars.
Fixes: 264904ccc33c ("usb: retry reset if a device times out")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Maxim Moseychuk <franchesko.salias.hudro.pedros(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/hub.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 92378594a86e..a86591772352 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4555,7 +4555,9 @@ hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1,
* reset. But only on the first attempt,
* lest we get into a time out/reset loop
*/
- if (r == 0 || (r == -ETIMEDOUT && retries == 0))
+ if (r == 0 || (r == -ETIMEDOUT &&
+ retries == 0 &&
+ udev->speed > USB_SPEED_FULL))
break;
}
udev->descriptor.bMaxPacketSize0 =
--
2.17.0
This is the start of the stable review cycle for the 4.16.5 release.
There are 26 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Fri Apr 27 10:33:04 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.5-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.16.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.16.5-rc1
Sean Christopherson <sean.j.christopherson(a)intel.com>
Revert "KVM: X86: Fix SMRAM accessing even if VM is shutdown"
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/mlx5: Fix NULL dereference while accessing XRC_TGT QPs
Jiri Olsa <jolsa(a)kernel.org>
perf: Return proper values for user stack errors
Jiri Olsa <jolsa(a)kernel.org>
perf: Fix sample_max_stack maximum check
Florian Westphal <fw(a)strlen.de>
netfilter: x_tables: limit allocation requests for blob rule heads
Florian Westphal <fw(a)strlen.de>
netfilter: compat: reject huge allocation requests
Florian Westphal <fw(a)strlen.de>
netfilter: compat: prepare xt_compat_init_offsets to return errors
Florian Westphal <fw(a)strlen.de>
netfilter: x_tables: add counters allocation wrapper
Florian Westphal <fw(a)strlen.de>
netfilter: x_tables: cap allocations at 512 mbyte
Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
mm,vmscan: Allow preallocating memory for register_shrinker().
Thomas Gleixner <tglx(a)linutronix.de>
alarmtimer: Init nanosleep alarm timer on stack
Imre Deak <imre.deak(a)intel.com>
drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state
Xidong Wang <wangxidong_97(a)163.com>
drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value
Gaurav K Singh <gaurav.k.singh(a)intel.com>
drm/i915/audio: Fix audio detection issue on GLK
Jani Nikula <jani.nikula(a)intel.com>
drm/i915/bios: filter out invalid DDC pins from VBT child devices
Tina Zhang <tina.zhang(a)intel.com>
drm/i915/gvt: Add drm_format_mod update
Gerd Hoffmann <kraxel(a)redhat.com>
drm/i915/gvt: throw error on unhandled vfio ioctls
Daniel J Blueman <daniel(a)quora.org>
drm/vc4: Fix memory leak during BO teardown
Xiaoming Gao <gxm.linux.kernel(a)gmail.com>
x86/tsc: Prevent 32bit truncation in calc_hpet_ref()
Laura Abbott <labbott(a)redhat.com>
posix-cpu-timers: Ensure set_process_cpu_timer is always evaluated
Anson Huang <Anson.Huang(a)nxp.com>
clocksource/imx-tpm: Correct -ETIME return condition check
Dou Liyang <douly.fnst(a)cn.fujitsu.com>
x86/acpi: Prevent X2APIC id 0xffffffff from being accounted
Nikolay Borisov <nborisov(a)suse.com>
btrfs: Fix race condition between delayed refs and blockgroup removal
David Sterba <dsterba(a)suse.com>
btrfs: fix unaligned access in readdir
Steve French <smfrench(a)gmail.com>
cifs: do not allow creating sockets except with SMB1 posix exensions
Long Li <longli(a)microsoft.com>
cifs: smbd: Check for iov length on sending the last iov
-------------
Diffstat:
Makefile | 4 +--
arch/x86/kernel/acpi/boot.c | 4 +++
arch/x86/kernel/tsc.c | 2 +-
arch/x86/kvm/mmu.c | 2 +-
drivers/clocksource/timer-imx-tpm.c | 2 +-
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 39 +++++++++++++++++++----
drivers/gpu/drm/i915/gvt/dmabuf.c | 1 +
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_audio.c | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 13 +++++---
drivers/gpu/drm/vc4/vc4_bo.c | 2 ++
drivers/gpu/drm/vc4/vc4_validate_shaders.c | 1 +
drivers/infiniband/hw/mlx5/qp.c | 3 +-
fs/btrfs/delayed-ref.c | 19 ++++++++---
fs/btrfs/delayed-ref.h | 1 +
fs/btrfs/extent-tree.c | 16 +++++++---
fs/btrfs/inode.c | 20 +++++++-----
fs/cifs/dir.c | 9 +++---
fs/cifs/smbdirect.c | 2 ++
fs/super.c | 9 +++---
include/linux/netfilter/x_tables.h | 3 +-
include/linux/shrinker.h | 7 ++--
kernel/events/callchain.c | 21 ++++++------
kernel/events/core.c | 4 +--
kernel/time/alarmtimer.c | 34 +++++++++++++++-----
kernel/time/posix-cpu-timers.c | 4 ++-
mm/vmscan.c | 21 +++++++++++-
net/bridge/netfilter/ebtables.c | 10 ++++--
net/ipv4/netfilter/arp_tables.c | 12 ++++---
net/ipv4/netfilter/ip_tables.c | 10 ++++--
net/ipv6/netfilter/ip6_tables.c | 12 ++++---
net/netfilter/x_tables.c | 51 ++++++++++++++++++++++++------
33 files changed, 250 insertions(+), 94 deletions(-)
From: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
commit 36268223c1e9981d6cfc33aff8520b3bde4b8114 upstream.
As:
1) It's known that hypervisors lie about the environment anyhow (host
mismatch)
2) Even if the hypervisor (Xen, KVM, VMWare, etc) provided a valid
"correct" value, it all gets to be very murky when migration happens
(do you provide the "new" microcode of the machine?).
And in reality the cloud vendors are the ones that should make sure that
the microcode that is running is correct and we should just sing lalalala
and trust them.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Wanpeng Li <kernellwp(a)gmail.com>
Cc: kvm <kvm(a)vger.kernel.org>
Cc: Krčmář <rkrcmar(a)redhat.com>
Cc: Borislav Petkov <bp(a)alien8.de>
CC: "H. Peter Anvin" <hpa(a)zytor.com>
CC: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/20180226213019.GE9497@char.us.oracle.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
[Yi Sun: cherry pick to 4.4]
Signed-off-by: Yi Sun <yi.y.sun(a)linux.intel.com>
---
arch/x86/kernel/cpu/intel.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index af28610..221c030 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -71,6 +71,13 @@ static bool bad_spectre_microcode(struct cpuinfo_x86 *c)
{
int i;
+ /*
+ * We know that the hypervisor lie to us on the microcode version so
+ * we may as well hope that it is running the correct version.
+ */
+ if (cpu_has(c, X86_FEATURE_HYPERVISOR))
+ return false;
+
for (i = 0; i < ARRAY_SIZE(spectre_bad_microcodes); i++) {
if (c->x86_model == spectre_bad_microcodes[i].model &&
c->x86_mask == spectre_bad_microcodes[i].stepping)
--
1.9.1
This patch adds the correct platform data information for the Caroline
Chromebook, so that the mouse button does not get stuck in pressed state
after the first click.
The Samus button keymap and platform data definition are the correct
ones for Caroline, so they have been reused here.
v2: updated patch offset after 20180409 changes.
Cc: stable(a)vger.kernel.org
Signed-off-by: Vittorio Gambaletta <linuxbugs(a)vittgam.net>
Signed-off-by: Salvatore Bellizzi <lkml(a)seppia.net>
---
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -3035,6 +3035,15 @@
.driver_data = samus_platform_data,
},
{
+ /* Samsung Chromebook Pro */
+ .ident = "Samsung Chromebook Pro",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Caroline"),
+ },
+ .driver_data = samus_platform_data,
+ },
+ {
/* Other Google Chromebooks */
.ident = "Chromebook",
.matches = {
> Hi,
>
> I've just booted Linux 4.16.4 and I am getting approximately 1900
> `random: get_random_u32 called from` messages at boot time. I can apply
> the patch to rate limit them, but thought you may be interested in the
> system I am running on, since I saw your message to Paul Menzel on lkml
> (I'm not subscribed to lkml so can't simply reply to your message).
Thanks for the report. It's become clear to me that we need to have
the rate limiting patch backported to stable series ASAP. I'll
be pushing the patch to mainline shortly.
- Ted
This is a note to let you know that I've just added the patch titled
ARM: amba: Don't read past the end of sysfs "driver_override" buffer
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-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 d2ffed5185df9d8d9ccd150e4340e3b6f96a8381 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Tue, 10 Apr 2018 15:21:45 +0200
Subject: ARM: amba: Don't read past the end of sysfs "driver_override" buffer
When printing the driver_override parameter when it is 4095 and 4094
bytes long, the printing code would access invalid memory because we
need count + 1 bytes for printing.
Cfr. commits 4efe874aace57dba ("PCI: Don't read past the end of sysfs
"driver_override" buffer") and bf563b01c2895a4b ("driver core: platform:
Don't read past the end of "driver_override" buffer").
Fixes: 3cf385713460eb2b ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Reviewed-by: Todd Kjos <tkjos(a)google.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/amba/bus.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index c77eb6e65646..8e6ac3031662 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -87,7 +87,8 @@ static ssize_t driver_override_store(struct device *_dev,
struct amba_device *dev = to_amba_device(_dev);
char *driver_override, *old, *cp;
- if (count > PATH_MAX)
+ /* We need to keep extra room for a newline */
+ if (count >= (PAGE_SIZE - 1))
return -EINVAL;
driver_override = kstrndup(buf, count, GFP_KERNEL);
--
2.17.0
Hi Greg,
I see that commit 7dac4a1726a9 ("ext4: add validity checks for bitmap block numbers")
is marked for stable, but I don't see it queued for any stable branches. Other ext4
patches from the same time frame (end of March) already made their way into stable.
Did this patch get lost, or is it still in your queue ?
Thanks,
Guenter
pm_runtime handles sdio power on and power off transitions.
An old workaround for trying to control the power explicitly from the
driver was in fact causing failures on suspend/resume as the mmc layer
already power the module on resume.
In case of resume pm_runtime_get sync returns a positive device's usage
count causing the driver to try an re-initialize an already initialized
device. This was causing sdio bus failure on resume.
Remove this manual power on/off sequence as it is in-fact not needed.
Signed-off-by: Eyal Reizer <eyalr(a)ti.com>
Cc: stable(a)vger.kernel.org
---
drivers/net/wireless/ti/wlcore/sdio.c | 27 ++++++---------------------
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 1f727ba..6dbe61d 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -155,17 +155,11 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue *glue)
struct mmc_card *card = func->card;
ret = pm_runtime_get_sync(&card->dev);
- if (ret) {
- /*
- * Runtime PM might be temporarily disabled, or the device
- * might have a positive reference counter. Make sure it is
- * really powered on.
- */
- ret = mmc_power_restore_host(card->host);
- if (ret < 0) {
- pm_runtime_put_sync(&card->dev);
- goto out;
- }
+ if (ret < 0) {
+ pm_runtime_put_noidle(&card->dev);
+ dev_err(glue->dev, "%s: failed to get_sync(%d)\n",
+ __func__, ret);
+ goto out;
}
sdio_claim_host(func);
@@ -178,7 +172,6 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue *glue)
static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue *glue)
{
- int ret;
struct sdio_func *func = dev_to_sdio_func(glue->dev);
struct mmc_card *card = func->card;
@@ -186,16 +179,8 @@ static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue *glue)
sdio_disable_func(func);
sdio_release_host(func);
- /* Power off the card manually in case it wasn't powered off above */
- ret = mmc_power_save_host(card->host);
- if (ret < 0)
- goto out;
-
/* Let runtime PM know the card is powered off */
- pm_runtime_put_sync(&card->dev);
-
-out:
- return ret;
+ return pm_runtime_put_sync(&card->dev);
}
static int wl12xx_sdio_set_power(struct device *child, bool enable)
--
2.7.4
pm_runtime handles sdio power on and power off transitions.
An old workaround for trying to control the power explicitly from the
driver was in fact causing failures on suspend/resume as the mmc layer
already power the module on resume.
In case of resume pm_runtime_get sync returns a positive device's usage
count causing the driver to try an re-initialize an already initialized
device. This was causing sdio bus failure on resume.
Remove this manual power on/off sequence as it is in-fact not needed.
Signed-off-by: Eyal Reizer <eyalr(a)ti.com>
Cc: stable(a)vger.kernel.org
---
drivers/net/wireless/ti/wlcore/sdio.c | 27 ++++++---------------------
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 1f727ba..6dbe61d 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -155,17 +155,11 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue *glue)
struct mmc_card *card = func->card;
ret = pm_runtime_get_sync(&card->dev);
- if (ret) {
- /*
- * Runtime PM might be temporarily disabled, or the device
- * might have a positive reference counter. Make sure it is
- * really powered on.
- */
- ret = mmc_power_restore_host(card->host);
- if (ret < 0) {
- pm_runtime_put_sync(&card->dev);
- goto out;
- }
+ if (ret < 0) {
+ pm_runtime_put_noidle(&card->dev);
+ dev_err(glue->dev, "%s: failed to get_sync(%d)\n",
+ __func__, ret);
+ goto out;
}
sdio_claim_host(func);
@@ -178,7 +172,6 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue *glue)
static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue *glue)
{
- int ret;
struct sdio_func *func = dev_to_sdio_func(glue->dev);
struct mmc_card *card = func->card;
@@ -186,16 +179,8 @@ static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue *glue)
sdio_disable_func(func);
sdio_release_host(func);
- /* Power off the card manually in case it wasn't powered off above */
- ret = mmc_power_save_host(card->host);
- if (ret < 0)
- goto out;
-
/* Let runtime PM know the card is powered off */
- pm_runtime_put_sync(&card->dev);
-
-out:
- return ret;
+ return pm_runtime_put_sync(&card->dev);
}
static int wl12xx_sdio_set_power(struct device *child, bool enable)
--
2.7.4
This is a note to let you know that I've just added the patch titled
tty: Use __GFP_NOFAIL for tty_ldisc_get()
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-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 bcdd0ca8cb8730573afebcaae4138f8f4c8eaa20 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Date: Wed, 25 Apr 2018 20:12:31 +0900
Subject: tty: Use __GFP_NOFAIL for tty_ldisc_get()
syzbot is reporting crashes triggered by memory allocation fault injection
at tty_ldisc_get() [1]. As an attempt to handle OOM in a graceful way, we
have tried commit 5362544bebe85071 ("tty: don't panic on OOM in
tty_set_ldisc()"). But we reverted that attempt by commit a8983d01f9b7d600
("Revert "tty: don't panic on OOM in tty_set_ldisc()"") due to reproducible
crash. We should spend resource for finding and fixing race condition bugs
rather than complicate error paths for 2 * sizeof(void *) bytes allocation
failure.
[1] https://syzkaller.appspot.com/bug?id=489d33fa386453859ead58ff5171d43772b13a…
Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Reported-by: syzbot <syzbot+40b7287c2dc987c48c81(a)syzkaller.appspotmail.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Vegard Nossum <vegard.nossum(a)gmail.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Jiri Slaby <jslaby(a)suse.com>
Cc: Peter Hurley <peter(a)hurleysoftware.com>
Cc: One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/tty_ldisc.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 8a88a7787cfe..fb7329ab2b37 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -176,12 +176,11 @@ static struct tty_ldisc *tty_ldisc_get(struct tty_struct *tty, int disc)
return ERR_CAST(ldops);
}
- ld = kmalloc(sizeof(struct tty_ldisc), GFP_KERNEL);
- if (ld == NULL) {
- put_ldops(ldops);
- return ERR_PTR(-ENOMEM);
- }
-
+ /*
+ * There is no way to handle allocation failure of only 16 bytes.
+ * Let's simplify error handling and save more memory.
+ */
+ ld = kmalloc(sizeof(struct tty_ldisc), GFP_KERNEL | __GFP_NOFAIL);
ld->ops = ldops;
ld->tty = tty;
--
2.17.0
commit 8cfd36a0b53aeb4ec21d81eb79706697b84dfc3d upstream.
When destroying a net namespace, all hwsim interfaces, which are not
created in default namespace are deleted. But the async deletion of the
interfaces could last longer than the actual destruction of the
namespace, which results to an use after free bug. Therefore use
synchronous deletion in this case.
Fixes: 100cb9ff40e0 ("mac80211_hwsim: Allow managing radios from
non-initial namespaces")
Reported-by: syzbot+70ce058e01259de7bb1d(a)syzkaller.appspotmail.com
Signed-off-by: Benjamin Beichler <benjamin.beichler(a)uni-rostock.de>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
---
This patch is prepared for linux-4.16.y branch
drivers/net/wireless/mac80211_hwsim.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 35b21f8152bb..20af54378cc0 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3484,8 +3484,11 @@ static void __net_exit hwsim_exit_net(struct net *net)
list_del(&data->list);
rhashtable_remove_fast(&hwsim_radios_rht, &data->rht,
hwsim_rht_params);
- INIT_WORK(&data->destroy_work, destroy_radio);
- queue_work(hwsim_wq, &data->destroy_work);
+ spin_unlock_bh(&hwsim_radio_lock);
+ mac80211_hwsim_del_radio(data,
+ wiphy_name(data->hw->wiphy),
+ NULL);
+ spin_lock_bh(&hwsim_radio_lock);
}
spin_unlock_bh(&hwsim_radio_lock);
}
--
2.17.0
For both the old bindings and the new bindings the same logic was
applied to retrieve the number of CS lines: using of_get_property() to
get a size in bytes, converted in the actual number of lines by dividing
it per sizeof(u32) (4 bytes).
This is fine for the 'reg' property which is a list of the CS IDs but
not for the 'num-cs' property which is directly the value of the number
of CS.
Anyway, no existing DT uses another value than 'num-cs = <1>' and no
other value has ever been supported by the old driver (pxa3xx_nand.c).
Remove this condition and apply a number of 1 CS anyway, as already
described in the bindings.
Fixes: 02f26ecf8c772 ("mtd: nand: add reworked Marvell NAND controller driver")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
---
drivers/mtd/nand/raw/marvell_nand.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c
index 2a467c72bbfb..c33ebc2cc024 100644
--- a/drivers/mtd/nand/raw/marvell_nand.c
+++ b/drivers/mtd/nand/raw/marvell_nand.c
@@ -2299,29 +2299,23 @@ static int marvell_nand_chip_init(struct device *dev, struct marvell_nfc *nfc,
/*
* The legacy "num-cs" property indicates the number of CS on the only
* chip connected to the controller (legacy bindings does not support
- * more than one chip). CS are only incremented one by one while the RB
- * pin is always the #0.
+ * more than one chip). The CS and RB pins are always the #0.
*
* When not using legacy bindings, a couple of "reg" and "nand-rb"
* properties must be filled. For each chip, expressed as a subnode,
* "reg" points to the CS lines and "nand-rb" to the RB line.
*/
- if (pdata) {
+ if (pdata || nfc->caps->legacy_of_bindings) {
nsels = 1;
- } else if (nfc->caps->legacy_of_bindings) {
- if (!of_get_property(np, "num-cs", &nsels)) {
- dev_err(dev, "missing num-cs property\n");
- return -EINVAL;
- }
} else {
if (!of_get_property(np, "reg", &nsels)) {
dev_err(dev, "missing reg property\n");
return -EINVAL;
}
- }
- if (!pdata)
nsels /= sizeof(u32);
+ }
+
if (!nsels) {
dev_err(dev, "invalid reg property size\n");
return -EINVAL;
--
2.14.1
The block responsible of parsing the DT for the number of chip-select
lines uses an 'if/else if/else if' block. The content of the second and
third 'else if' conditions are:
1/ the actual condition to enter the sub-block and
2/ the operation to do in this sub-block.
[...]
else if (condition1_to_enter && action1() == failed)
raise_error();
else if (condition2_to_enter && action2() == failed)
raise_error();
[...]
In case of failure, the sub-block is entered and an error raised.
Otherwise, in case of success, the code would continue erroneously in
the next 'else if' statement because it did not failed (and did not
enter the first 'else if' sub-block).
The first 'else if' refers to legacy bindings while the second 'else if'
refers to new bindings. The second 'else if', which is entered
erroneously, checks for the 'reg' property, which, for old bindings,
does not mean anything because it would not be the number of CS
available, but the regular register map of almost any DT node. This
being said, the content of the 'reg' property being the register map
offset and length, it has '2' values, so the number of CS in this
situation is assumed to be '2'.
When running nand_scan_ident() with 2 CS, the core will check for an
array of chips. It will first issue a RESET and then a READ_ID. Of
course this will trigger two timeouts because there is no chip in front
of the second CS:
[ 1.367460] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000080)
[ 1.474292] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000280)
Indeed, this is harmless and the core will then assume there is only one
valid CS.
Fix the logic in the whole block by entering each sub-block just on the
'is legacy' condition, doing the action inside the sub-block. This way,
when the action succeeds, the whole block is left.
Fixes: 02f26ecf8c772 ("mtd: nand: add reworked Marvell NAND controller driver")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
---
drivers/mtd/nand/raw/marvell_nand.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c
index 10e953218948..2a467c72bbfb 100644
--- a/drivers/mtd/nand/raw/marvell_nand.c
+++ b/drivers/mtd/nand/raw/marvell_nand.c
@@ -2308,13 +2308,16 @@ static int marvell_nand_chip_init(struct device *dev, struct marvell_nfc *nfc,
*/
if (pdata) {
nsels = 1;
- } else if (nfc->caps->legacy_of_bindings &&
- !of_get_property(np, "num-cs", &nsels)) {
- dev_err(dev, "missing num-cs property\n");
- return -EINVAL;
- } else if (!of_get_property(np, "reg", &nsels)) {
- dev_err(dev, "missing reg property\n");
- return -EINVAL;
+ } else if (nfc->caps->legacy_of_bindings) {
+ if (!of_get_property(np, "num-cs", &nsels)) {
+ dev_err(dev, "missing num-cs property\n");
+ return -EINVAL;
+ }
+ } else {
+ if (!of_get_property(np, "reg", &nsels)) {
+ dev_err(dev, "missing reg property\n");
+ return -EINVAL;
+ }
}
if (!pdata)
--
2.14.1
This is a note to let you know that I've just added the patch titled
usb: do not reset if a low-speed or full-speed device timed out
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-testing 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 be merged to the usb-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 6e01827ed93947895680fbdad68c072a0f4e2450 Mon Sep 17 00:00:00 2001
From: Maxim Moseychuk <franchesko.salias.hudro.pedros(a)gmail.com>
Date: Thu, 4 Jan 2018 21:43:03 +0300
Subject: usb: do not reset if a low-speed or full-speed device timed out
Some low-speed and full-speed devices (for example, bluetooth)
do not have time to initialize. For them, ETIMEDOUT is a valid error.
We need to give them another try. Otherwise, they will
never be initialized correctly and in dmesg will be messages
"Bluetooth: hci0 command 0x1002 tx timeout" or similars.
Fixes: 264904ccc33c ("usb: retry reset if a device times out")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Maxim Moseychuk <franchesko.salias.hudro.pedros(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/hub.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 92378594a86e..a86591772352 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4555,7 +4555,9 @@ hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1,
* reset. But only on the first attempt,
* lest we get into a time out/reset loop
*/
- if (r == 0 || (r == -ETIMEDOUT && retries == 0))
+ if (r == 0 || (r == -ETIMEDOUT &&
+ retries == 0 &&
+ udev->speed > USB_SPEED_FULL))
break;
}
udev->descriptor.bMaxPacketSize0 =
--
2.17.0
The patch below does not apply to the 4.9-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 0803d7befa15cab5717d667a97a66214d2a4c083 Mon Sep 17 00:00:00 2001
From: Chris Chiu <chiu(a)endlessm.com>
Date: Tue, 20 Mar 2018 15:36:40 +0800
Subject: [PATCH] tpm: self test failure should not cause suspend to fail
The Acer Acer Veriton X4110G has a TPM device detected as:
tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71)
After the first S3 suspend, the following error appears during resume:
tpm tpm0: A TPM error(38) occurred continue selftest
Any following S3 suspend attempts will now fail with this error:
tpm tpm0: Error (38) sending savestate before suspend
PM: Device 00:0b failed to suspend: error 38
Error 38 is TPM_ERR_INVALID_POSTINIT which means the TPM is
not in the correct state. This indicates that the platform BIOS
is not sending the usual TPM_Startup command during S3 resume.
>From this point onwards, all TPM commands will fail.
The same issue was previously reported on Foxconn 6150BK8MC and
Sony Vaio TX3.
The platform behaviour seems broken here, but we should not break
suspend/resume because of this.
When the unexpected TPM state is encountered, set a flag to skip the
affected TPM_SaveState command on later suspends.
Cc: stable(a)vger.kernel.org
Signed-off-by: Chris Chiu <chiu(a)endlessm.com>
Signed-off-by: Daniel Drake <drake(a)endlessm.com>
Link: http://lkml.kernel.org/r/CAB4CAwfSCvj1cudi+MWaB5g2Z67d9DwY1o475YOZD64ma23Ui…
Link: https://lkml.org/lkml/2011/3/28/192
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591031
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 47aacecdc85c..22288ff70a0b 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1002,6 +1002,10 @@ int tpm_do_selftest(struct tpm_chip *chip)
loops = jiffies_to_msecs(duration) / delay_msec;
rc = tpm_continue_selftest(chip);
+ if (rc == TPM_ERR_INVALID_POSTINIT) {
+ chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED;
+ dev_info(&chip->dev, "TPM not ready (%d)\n", rc);
+ }
/* This may fail if there was no TPM driver during a suspend/resume
* cycle; some may return 10 (BAD_ORDINAL), others 28 (FAILEDSELFTEST)
*/
gpstate_timer_handler() uses synchronous smp_call to set the pstate
on the requested core. This causes the below hard lockup:
[c000003fe566b320] [c0000000001d5340] smp_call_function_single+0x110/0x180 (unreliable)
[c000003fe566b390] [c0000000001d55e0] smp_call_function_any+0x180/0x250
[c000003fe566b3f0] [c000000000acd3e8] gpstate_timer_handler+0x1e8/0x580
[c000003fe566b4a0] [c0000000001b46b0] call_timer_fn+0x50/0x1c0
[c000003fe566b520] [c0000000001b4958] expire_timers+0x138/0x1f0
[c000003fe566b590] [c0000000001b4bf8] run_timer_softirq+0x1e8/0x270
[c000003fe566b630] [c000000000d0d6c8] __do_softirq+0x158/0x3e4
[c000003fe566b710] [c000000000114be8] irq_exit+0xe8/0x120
[c000003fe566b730] [c000000000024d0c] timer_interrupt+0x9c/0xe0
[c000003fe566b760] [c000000000009014] decrementer_common+0x114/0x120
-- interrupt: 901 at doorbell_global_ipi+0x34/0x50
LR = arch_send_call_function_ipi_mask+0x120/0x130
[c000003fe566ba50] [c00000000004876c]
arch_send_call_function_ipi_mask+0x4c/0x130
[c000003fe566ba90] [c0000000001d59f0] smp_call_function_many+0x340/0x450
[c000003fe566bb00] [c000000000075f18] pmdp_invalidate+0x98/0xe0
[c000003fe566bb30] [c0000000003a1120] change_huge_pmd+0xe0/0x270
[c000003fe566bba0] [c000000000349278] change_protection_range+0xb88/0xe40
[c000003fe566bcf0] [c0000000003496c0] mprotect_fixup+0x140/0x340
[c000003fe566bdb0] [c000000000349a74] SyS_mprotect+0x1b4/0x350
[c000003fe566be30] [c00000000000b184] system_call+0x58/0x6c
One way to avoid this is removing the smp-call. We can ensure that the timer
always runs on one of the policy-cpus. If the timer gets migrated to a
cpu outside the policy then re-queue it back on the policy->cpus. This way
we can get rid of the smp-call which was being used to set the pstate
on the policy->cpus.
Fixes: 7bc54b652f13 (timers, cpufreq/powernv: Initialize the gpstate timer as pinned)
Cc: <stable(a)vger.kernel.org> [4.8+]
Reported-by: Nicholas Piggin <npiggin(a)gmail.com>
Reported-by: Pridhiviraj Paidipeddi <ppaidipe(a)linux.vnet.ibm.com>
Signed-off-by: Shilpasri G Bhat <shilpa.bhat(a)linux.vnet.ibm.com>
---
Changes from V1:
- Remove smp_call in the pstate handler.
drivers/cpufreq/powernv-cpufreq.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index 71f8682..dc8ffb5 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -679,6 +679,25 @@ void gpstate_timer_handler(struct timer_list *t)
if (!spin_trylock(&gpstates->gpstate_lock))
return;
+ /*
+ * If the timer has migrated to the different cpu then bring
+ * it back to one of the policy->cpus
+ */
+ if (!cpumask_test_cpu(raw_smp_processor_id(), policy->cpus)) {
+ /*
+ * Timer should be deleted if policy is inactive.
+ * If policy is active then re-queue on one of the
+ * policy->cpus.
+ */
+ if (!cpumask_empty(policy->cpus)) {
+ gpstates->timer.expires = jiffies +
+ msecs_to_jiffies(1);
+ add_timer_on(&gpstates->timer,
+ cpumask_first(policy->cpus));
+ }
+ spin_unlock(&gpstates->gpstate_lock);
+ return;
+ }
/*
* If PMCR was last updated was using fast_swtich then
@@ -718,10 +737,8 @@ void gpstate_timer_handler(struct timer_list *t)
if (gpstate_idx != gpstates->last_lpstate_idx)
queue_gpstate_timer(gpstates);
+ set_pstate(&freq_data);
spin_unlock(&gpstates->gpstate_lock);
-
- /* Timer may get migrated to a different cpu on cpu hot unplug */
- smp_call_function_any(policy->cpus, set_pstate, &freq_data, 1);
}
/*
--
1.8.3.1
The patch below does not apply to the 4.16-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 bcb0b981c5571744ac446a6c906aa05a28d21446 Mon Sep 17 00:00:00 2001
From: Ben Crocker <bcrocker(a)redhat.com>
Date: Thu, 22 Feb 2018 17:52:19 -0500
Subject: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE
In radeon_device_init, set the need_dma32 flag for Cedar chips
(e.g. FirePro 2270). This fixes, or at least works around, a bug
on PowerPC exposed by last year's commits
8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)
and
253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)
which enabled the 64-bit DMA iommu bypass.
This caused the device to freeze, in some cases unrecoverably, and is
the subject of several bug reports internal to Red Hat.
Signed-off-by: Ben Crocker <bcrocker(a)redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index 7f40c6f7c4dd..e415d2c097a7 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1366,6 +1366,10 @@ int radeon_device_init(struct radeon_device *rdev,
if ((rdev->flags & RADEON_IS_PCI) &&
(rdev->family <= CHIP_RS740))
rdev->need_dma32 = true;
+#ifdef CONFIG_PPC64
+ if (rdev->family == CHIP_CEDAR)
+ rdev->need_dma32 = true;
+#endif
dma_bits = rdev->need_dma32 ? 32 : 40;
r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
On Tue, Apr 24, 2018 at 11:13:25PM +0200, Hans de Goede wrote:
> FWIW this has gotten into 4.15 without it having a Cc: stable or a
> Fixes: tag, I think it was picked up by the new magic scripts scripts
> which try to find commits which should have a Cc: stable but are lacking
> one.
>
> In this case I deliberately did not add a Cc: stable as what gets fixed
> is not that important, whereas the possible regression this might cause
> (and actually seems to be causing) is sorta bad.
This isn't the first time I've seen patches backported that simply don't
need to be, or shouldn't be. In one case a few years back the patch had
a fixes tag, but it still wasn't important to backport, which is why I
left off the Cc stable, and in fact it broke something.
TBH its a bit distracting having to review such patches, which I've
already looked at before, determined there's no need for a backport, and
subsequently paged out of my head.
Stable folk: is there already (and should there be) a defined mechanism
to record that a given patch is:
1) not suitable/worthwhile to backport (e.g. even though it might have a
Fixes tag or use the word "fix").
2) OR it would require a bit more human effort to backport (perhaps it
applies cleanly but would be expected not to build/work) and probably
shouldn't be attempted automatically.
3) OR it probably isn't worth backporting and is risky to do so, and so
should only be carefully attempted if somebody actually complains.
other than simply stating it in prose in the commit message?
Cheers
James