Per discussion with David at netconf 2018, let's clarify
DaveM's position of handling stable backports in netdev-FAQ.
This is important for people relying on upstream -stable
releases.
Cc: stable(a)vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
---
Documentation/networking/netdev-FAQ.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt
index 2a3278d5cf35..6dde6686c870 100644
--- a/Documentation/networking/netdev-FAQ.txt
+++ b/Documentation/networking/netdev-FAQ.txt
@@ -179,6 +179,15 @@ A: No. See above answer. In short, if you think it really belongs in
dash marker line as described in Documentation/process/submitting-patches.rst to
temporarily embed that information into the patch that you send.
+Q: Are all networking bug fixes backported to all stable releases?
+
+A: Due to capacity, Dave could only take care of the backports for the last
+ 3 stable releases. For earlier stable releases, each stable branch maintainer
+ is supposed to take care of them. If you find any patch is missing from an
+ earlier stable branch, please notify stable(a)vger.kernel.org with either a
+ commit ID or a formal patch backported, and CC Dave and other relevant
+ networking developers.
+
Q: Someone said that the comment style and coding convention is different
for the networking content. Is this true?
--
2.13.0
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: uvcvideo: Prevent setting unavailable flags
Author: Kieran Bingham <kieran.bingham(a)ideasonboard.com>
Date: Wed Mar 21 11:43:08 2018 -0400
The addition of an extra operation to use the GET_INFO command
overwrites all existing flags from the uvc_ctrls table. This includes
setting all controls as supporting GET_MIN, GET_MAX, GET_RES, and
GET_DEF regardless of whether they do or not.
Move the initialisation of these control capabilities directly to the
uvc_ctrl_fill_xu_info() call where they were originally located in that
use case, and ensure that the new functionality in uvc_ctrl_get_flags()
will only set flags based on their reported capability from the GET_INFO
call.
Fixes: 859086ae3636 ("media: uvcvideo: Apply flags from device to actual properties")
Cc: stable(a)vger.kernel.org
Signed-off-by: Kieran Bingham <kieran.bingham(a)ideasonboard.com>
Tested-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)intel.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org>
drivers/media/usb/uvc/uvc_ctrl.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
---
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 102594ec3e97..a36b4fb949fa 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -1607,14 +1607,12 @@ static int uvc_ctrl_get_flags(struct uvc_device *dev,
ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum,
info->selector, data, 1);
if (!ret)
- info->flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX
- | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF
- | (data[0] & UVC_CONTROL_CAP_GET ?
- UVC_CTRL_FLAG_GET_CUR : 0)
- | (data[0] & UVC_CONTROL_CAP_SET ?
- UVC_CTRL_FLAG_SET_CUR : 0)
- | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ?
- UVC_CTRL_FLAG_AUTO_UPDATE : 0);
+ info->flags |= (data[0] & UVC_CONTROL_CAP_GET ?
+ UVC_CTRL_FLAG_GET_CUR : 0)
+ | (data[0] & UVC_CONTROL_CAP_SET ?
+ UVC_CTRL_FLAG_SET_CUR : 0)
+ | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ?
+ UVC_CTRL_FLAG_AUTO_UPDATE : 0);
kfree(data);
return ret;
@@ -1689,6 +1687,9 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
info->size = le16_to_cpup((__le16 *)data);
+ info->flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX
+ | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF;
+
ret = uvc_ctrl_get_flags(dev, ctrl, info);
if (ret < 0) {
uvc_trace(UVC_TRACE_CONTROL,
In file included from scripts/kconfig/zconf.tab.c:2485:
scripts/kconfig/confdata.c: In function ‘conf_write’:
scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
sprintf(newname, "%s%s", dirname, basename);
^~
scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes
sprintf(newname, "%s%s", dirname, basename);
^~~~~~
scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097
sprintf(newname, "%s%s", dirname, basename);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
^~~~~~~~~~~
scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097
sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Increase the size of tmpname and newname to make GCC happy.
Cc: stable(a)vger.kernel.org
Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com>
---
scripts/kconfig/confdata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 5f87ad561b08..39e20974f4a3 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -720,7 +720,7 @@ int conf_write(const char *name)
struct menu *menu;
const char *basename;
const char *str;
- char dirname[PATH_MAX+1], tmpname[PATH_MAX+1], newname[PATH_MAX+1];
+ char dirname[PATH_MAX+1], tmpname[PATH_MAX+22], newname[PATH_MAX+8];
char *env;
dirname[0] = 0;
--
2.17.1
Hi Thomas,
At 06/04/2018 11:33 PM, Thomas Gleixner wrote:
> The generic pending interrupt mechanism moves interrupts from the interrupt
> handler on the original target CPU to the new destination CPU. This is
> required for x86 and ia64 due to the way the interrupt delivery and
> acknowledge works if the interrupts are not remapped.
>
> However that update can fail for various reasons. Some of them are valid
> reasons to discard the pending update, but the case, when the previous move
> has not been fully cleaned up is not a legit reason to fail.
>
> Check the return value of irq_do_set_affinity() for -EBUSY, which indicates
> a pending cleanup, and rearm the pending move in the irq dexcriptor so it's
s/dexcriptor/descriptor
> tried again when the next interrupt arrives.
>
> Fixes: 996c591227d9 ("x86/irq: Plug vector cleanup race")
> Signed-off-by: Thomas Gleixner<tglx(a)linutronix.de>
> Cc:stable@vger.kernel.org
> ---
> kernel/irq/migration.c | 24 ++++++++++++++++++------
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> --- a/kernel/irq/migration.c
> +++ b/kernel/irq/migration.c
> @@ -38,17 +38,18 @@ bool irq_fixup_move_pending(struct irq_d
> void irq_move_masked_irq(struct irq_data *idata)
> {
> struct irq_desc *desc = irq_data_to_desc(idata);
> - struct irq_chip *chip = desc->irq_data.chip;
> + struct irq_data *data = &desc->irq_data;
> + struct irq_chip *chip = data->chip;
>
> - if (likely(!irqd_is_setaffinity_pending(&desc->irq_data)))
> + if (likely(!irqd_is_setaffinity_pending(data)))
> return;
>
> - irqd_clr_move_pending(&desc->irq_data);
> + irqd_clr_move_pending(data);
>
> /*
> * Paranoia: cpu-local interrupts shouldn't be calling in here anyway.
> */
> - if (irqd_is_per_cpu(&desc->irq_data)) {
> + if (irqd_is_per_cpu(data)) {
> WARN_ON(1);
> return;
> }
> @@ -73,9 +74,20 @@ void irq_move_masked_irq(struct irq_data
> * For correct operation this depends on the caller
> * masking the irqs.
> */
> - if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids)
> - irq_do_set_affinity(&desc->irq_data, desc->pending_mask, false);
> + if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids) {
> + int ret;
>
> + ret = irq_do_set_affinity(data, desc->pending_mask, false);
> + /*
> + * If the there is a cleanup pending in the underlying
s/If the there is/If there is/
Thanks,
dou
On Mon, Jun 04, 2018 at 04:13:06PM -0700, Kevin Hilman wrote:
> > defconfig
> > synquacer-acpi: 1 failed lab
> This is a newly added board, and hasn't ever passed on v4.9 yet.
> @Matt Hart: Is this board expected to work as far bask as v4.9? or
> should we blacklist it?
Should be blacklisted.
From: Aleksey Makarov <aleksey.makarov(a)linaro.org>
Commit 10879ae5f12e9cab3c4e8e9504c1aaa8a033bde7 upstream.
This patch adds function pl011_console_match() that implements
method match of struct console. It allows to match consoles against
data specified in a string, for example taken from command line or
compiled by ACPI SPCR table handler.
This patch was merged to tty-next but then reverted because of
conflict with
commit 46e36683f433 ("serial: earlycon: Extend earlycon command line option to support 64-bit addresses")
Now it is fixed.
Signed-off-by: Aleksey Makarov <aleksey.makarov(a)linaro.org>
Reviewed-by: Peter Hurley <peter(a)hurleysoftware.com>
Acked-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Tested-by: Christopher Covington <cov(a)codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
---
Please consider for v4.9-stable. It is the missing puzzle piece for SPCR
support on arm64 ACPI systems, which got merged for v4.9 [0]. Now that more
systems are becoming available to people working in the kernel community, it
turns out that v4.9 distro installers (e.g., Debian Stretch) won't work
unless you pass a 'console=' parameter explicitly, which is annoying.
Given that it was clearly the intent to include this code at the time,
I hope it will be considered for backporting.
[0] To quote the tty maintainer:
Also in here is the long-suffering ACPI SPCR patchset, which was
passed around from maintainer to maintainer like a hot-potato. Seems I
was the sucker^Wlucky one. All of those patches have been acked by the
various subsystem maintainers as well.
drivers/tty/serial/amba-pl011.c | 55 ++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index b42d7f1c9089..6b1863293fe1 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2320,12 +2320,67 @@ static int __init pl011_console_setup(struct console *co, char *options)
return uart_set_options(&uap->port, co, baud, parity, bits, flow);
}
+/**
+ * pl011_console_match - non-standard console matching
+ * @co: registering console
+ * @name: name from console command line
+ * @idx: index from console command line
+ * @options: ptr to option string from console command line
+ *
+ * Only attempts to match console command lines of the form:
+ * console=pl011,mmio|mmio32,<addr>[,<options>]
+ * console=pl011,0x<addr>[,<options>]
+ * This form is used to register an initial earlycon boot console and
+ * replace it with the amba_console at pl011 driver init.
+ *
+ * Performs console setup for a match (as required by interface)
+ * If no <options> are specified, then assume the h/w is already setup.
+ *
+ * Returns 0 if console matches; otherwise non-zero to use default matching
+ */
+static int __init pl011_console_match(struct console *co, char *name, int idx,
+ char *options)
+{
+ unsigned char iotype;
+ resource_size_t addr;
+ int i;
+
+ if (strcmp(name, "pl011") != 0)
+ return -ENODEV;
+
+ if (uart_parse_earlycon(options, &iotype, &addr, &options))
+ return -ENODEV;
+
+ if (iotype != UPIO_MEM && iotype != UPIO_MEM32)
+ return -ENODEV;
+
+ /* try to match the port specified on the command line */
+ for (i = 0; i < ARRAY_SIZE(amba_ports); i++) {
+ struct uart_port *port;
+
+ if (!amba_ports[i])
+ continue;
+
+ port = &amba_ports[i]->port;
+
+ if (port->mapbase != addr)
+ continue;
+
+ co->index = i;
+ port->cons = co;
+ return pl011_console_setup(co, options);
+ }
+
+ return -ENODEV;
+}
+
static struct uart_driver amba_reg;
static struct console amba_console = {
.name = "ttyAMA",
.write = pl011_console_write,
.device = uart_console_device,
.setup = pl011_console_setup,
+ .match = pl011_console_match,
.flags = CON_PRINTBUFFER,
.index = -1,
.data = &amba_reg,
--
2.17.0
Patch 4b433924b275 ("scsi: sd_zbc: Fix potential memory leak") was added in
4.16 and 4.15 stable but did not make it to long term stable 4.14 (as far as I
can tell).
Patch ccce20fc7968 ("scsi: sd_zbc: Avoid that resetting a zone fails
sporadically") is included in 4.16 but does not apply to 4.15 stable nor to
4.14 long term stable and requires extensive modifications.
This small series provides a backport of both patches against 4.14. Please
consider these patches for inclusion in this long term stable kernel.
Bart Van Assche (1):
scsi: sd_zbc: Avoid that resetting a zone fails sporadically
Damien Le Moal (1):
scsi: sd_zbc: Fix potential memory leak
drivers/scsi/sd_zbc.c | 128 +++++++++++++++++++++++++-----------------
1 file changed, 76 insertions(+), 52 deletions(-)
Changes from v1:
* Fixed upstream commit reference in the first patch commit message
--
2.17.0