Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code").
The bot has tested the following trees: v5.8.9, v5.4.65.
v5.8.9: Build OK!
v5.4.65: Failed to apply! Possible dependencies:
051a7a94aaa9 ("arm64: hibernate: use get_safe_page directly")
13373f0e6580 ("arm64: hibernate: rename dst to page in create_safe_exec_page")
48c963e31bc6 ("KVM: arm/arm64: Release kvm->mmu_lock in loop to prevent starvation")
68ecabd0e680 ("arm64/mm: Use phys_to_page() to access pgtable memory")
8a0af66b35f8 ("arm: mm: add p?d_leaf() definitions")
974b9b2c68f3 ("mm: consolidate pte_index() and pte_offset_*() definitions")
a2c2e67923ec ("arm64: hibernate: add trans_pgd public functions")
a89d7ff933b0 ("arm64: hibernate: remove gotos as they are not needed")
d234332c2815 ("arm64: hibernate: pass the allocated pgdp to ttbr0")
e9f6376858b9 ("arm64: add support for folded p4d page tables")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
On 8/25/20 6:50 PM, Ranjani Sridharan wrote:
> From: Jaska Uimonen <jaska.uimonen(a)linux.intel.com>
>
> Currently the dmic check code supports only devices with 2 or 4 dmics.
> With other dmic counts the function will return 0. Lately we've seen
> devices with only 1 dmic thus enable also configurations with 1, and
> possibly 3, dmics. Add also topology postfix -1ch and -3ch for new dmic
> configuration.
>
> Signed-off-by: Jaska Uimonen <jaska.uimonen(a)linux.intel.com>
> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
> Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com>
we now have multiple reports of devices with a single microphone where
audio is broken without this patch, e.g.
https://github.com/thesofproject/linux/issues/2451
This patch should be applied to -stable versions all the way to 5.6. It
would be desirable for 5.5 and 5.4 as well but it will not apply
cleanly. It's be trivial to provide a modified patch for these earlier
kernel versions but I don't know what the process might be here?
NULL pointer dereference is observed while exporting the dmabuf but
failed to allocate the 'struct file' which results into the dropping of
the allocated dentry corresponding to this file in the dmabuf fs, which
is ending up in dma_buf_release() and accessing the uninitialzed
dentry->d_fsdata.
Call stack on 5.4 is below:
dma_buf_release+0x2c/0x254 drivers/dma-buf/dma-buf.c:88
__dentry_kill+0x294/0x31c fs/dcache.c:584
dentry_kill fs/dcache.c:673 [inline]
dput+0x250/0x380 fs/dcache.c:859
path_put+0x24/0x40 fs/namei.c:485
alloc_file_pseudo+0x1a4/0x200 fs/file_table.c:235
dma_buf_getfile drivers/dma-buf/dma-buf.c:473 [inline]
dma_buf_export+0x25c/0x3ec drivers/dma-buf/dma-buf.c:585
Fix this by checking for the valid pointer in the dentry->d_fsdata.
Fixes: 4ab59c3c638c ("dma-buf: Move dma_buf_release() from fops to dentry_ops")
Cc: <stable(a)vger.kernel.org> [5.7+]
Signed-off-by: Charan Teja Reddy <charante(a)codeaurora.org>
---
drivers/dma-buf/dma-buf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 58564d82..844967f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -59,6 +59,8 @@ static void dma_buf_release(struct dentry *dentry)
struct dma_buf *dmabuf;
dmabuf = dentry->d_fsdata;
+ if (unlikely(!dmabuf))
+ return;
BUG_ON(dmabuf->vmapping_counter);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
On Wed, Sep 09, 2020 at 06:48:15PM +0300, Andy Shevchenko wrote:
> On Wed, Sep 09, 2020 at 04:31:01PM +0200, Johan Hovold wrote:
> > Fix the port-lock initialisation regression introduced by commit
> > a3cb39d258ef ("serial: core: Allow detach and attach serial device for
> > console") by making sure that the lock is again initialised during
> > console setup.
> >
> > The console may be registered before the serial controller has been
> > probed in which case the port lock needs to be initialised during
> > console setup by a call to uart_set_options(). The console-detach
> > changes introduced a regression in several drivers by effectively
> > removing that initialisation by not initialising the lock when the port
> > is used as a console (which is always the case during console setup).
> >
> > Add back the early lock initialisation and instead use a new
> > console-reinit flag to handle the case where a console is being
> > re-attached through sysfs.
> >
> > The question whether the console-detach interface should have been added
> > in the first place is left for another discussion.
>
> It was discussed in [1]. TL;DR: OMAP would like to keep runtime PM available
> for UART while at the same time we disable it for kernel consoles in
> bedb404e91bb.
>
> [1]: https://lists.openwall.net/linux-kernel/2018/09/29/65
Yeah, I remember that. My fear is just that the new interface opens up a
can of worms as it removes the earlier assumption that the console would
essentially never be deregistered without really fixing all those
drivers, and core functions, written under that assumption. Just to
mention a few issues; we have drivers enabling clocks and other
resources during console setup which can now be done repeatedly, and
several drivers whose setup callbacks are marked __init and will oops
the minute you reattach the console. And what about power management
which was the reason for wanting this on OMAP in the first place; tty
core never calls shutdown() for a console port, not even when it's been
detached using the new interface.
I know, the console setup is all a mess, but this still seems a little
rushed to me. I'm even inclined to suggest a revert until the above and
similar issues have been addressed properly rather keeping a known buggy
interface.
> > Note that the console-enabled check in uart_set_options() is not
> > redundant because of kgdboc, which can end up reinitialising an already
> > enabled console (see commit 42b6a1baa3ec ("serial_core: Don't
> > re-initialize a previously initialized spinlock.")).
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
> Thank you!
>
> One question below, though.
>
> > Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console")
> > Cc: stable <stable(a)vger.kernel.org> # 5.7
> > Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
> > Signed-off-by: Johan Hovold <johan(a)kernel.org>
> > ---
> > drivers/tty/serial/serial_core.c | 32 +++++++++++++++-----------------
> > include/linux/serial_core.h | 1 +
> > 2 files changed, 16 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> > index 53b79e1fcbc8..124524ecfe26 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -1916,24 +1916,12 @@ static inline bool uart_console_enabled(struct uart_port *port)
> > return uart_console(port) && (port->cons->flags & CON_ENABLED);
> > }
> >
> > -static void __uart_port_spin_lock_init(struct uart_port *port)
> > +static void uart_port_spin_lock_init(struct uart_port *port)
> > {
> > spin_lock_init(&port->lock);
> > lockdep_set_class(&port->lock, &port_lock_key);
> > }
> >
> > -/*
> > - * Ensure that the serial console lock is initialised early.
> > - * If this port is a console, then the spinlock is already initialised.
> > - */
> > -static inline void uart_port_spin_lock_init(struct uart_port *port)
> > -{
>
> > - if (uart_console(port))
>
> I'm wondering if we may revert this line to be uart_console_enabled() and use a
> helper below twice.
I didn't do that on purpose as the rationale for why the
uart_console_enabled() check is there is different in the two paths so
merging the two comments, and moving it away from the call sites, wasn't
really a good idea to begin with.
> > - return;
> > -
> > - __uart_port_spin_lock_init(port);
> > -}
> > -
> > #if defined(CONFIG_SERIAL_CORE_CONSOLE) || defined(CONFIG_CONSOLE_POLL)
> > /**
> > * uart_console_write - write a console message to a serial port
> > @@ -2086,7 +2074,15 @@ uart_set_options(struct uart_port *port, struct console *co,
> > struct ktermios termios;
> > static struct ktermios dummy;
> >
> > - uart_port_spin_lock_init(port);
> > + /*
> > + * Ensure that the serial-console lock is initialised early.
> > + *
> > + * Note that the console-enabled check is needed because of kgdboc,
> > + * which can end up calling uart_set_options() for an already enabled
> > + * console via tty_find_polling_driver() and uart_poll_init().
> > + */
> > + if (!uart_console_enabled(port) && !port->console_reinit)
> > + uart_port_spin_lock_init(port);
> >
> > memset(&termios, 0, sizeof(struct ktermios));
> >
> > @@ -2794,10 +2790,12 @@ static ssize_t console_store(struct device *dev,
> > if (oldconsole && !newconsole) {
> > ret = unregister_console(uport->cons);
> > } else if (!oldconsole && newconsole) {
> > - if (uart_console(uport))
> > + if (uart_console(uport)) {
> > + uport->console_reinit = 1;
> > register_console(uport->cons);
> > - else
> > + } else {
> > ret = -ENOENT;
> > + }
> > }
> > } else {
> > ret = -ENXIO;
> > @@ -2898,7 +2896,7 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
> > * initialised.
> > */
> > if (!uart_console_enabled(uport))
> > - __uart_port_spin_lock_init(uport);
> > + uart_port_spin_lock_init(uport);
> >
> > if (uport->cons && uport->dev)
> > of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
> > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> > index 01fc4d9c9c54..8a99279a579b 100644
> > --- a/include/linux/serial_core.h
> > +++ b/include/linux/serial_core.h
> > @@ -248,6 +248,7 @@ struct uart_port {
> >
> > unsigned char hub6; /* this should be in the 8250 driver */
> > unsigned char suspended;
> > + unsigned char console_reinit;
> > const char *name; /* port name */
> > struct attribute_group *attr_group; /* port specific attributes */
> > const struct attribute_group **tty_groups; /* all attributes (serial core use only) */
> > --
> > 2.26.2
Johan
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: b72053072c0b ("block: allow partitions on host aware zone devices").
The bot has tested the following trees: v5.8.9.
v5.8.9: Failed to apply! Possible dependencies:
a3d8a2573687 ("scsi: sd_zbc: Improve zone revalidation")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha