[PATCH AUTOSEL 4.9 55/90] serial: 8250: 8250_omap: Terminate DMA before pushing data on RX timeout
From: Vignesh Raghavendra [ Upstream commit 7cf4df30a98175033e9849f7f16c46e96ba47f41 ] Terminate and flush DMA internal buffers, before pushing RX data to higher layer. Otherwise, this will lead to data corruption, as driver would end up pushing stale buffer data to higher layer while actual data is still stuck inside DMA hardware and has yet not arrived at the memory. While at that, replace deprecated dmaengine_terminate_all() with dmaengine_terminate_async(). Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20200319110344.21348-2-vigne...@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- drivers/tty/serial/8250/8250_omap.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c index 7d4680ef5307d..d41be02abced2 100644 --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -773,7 +773,10 @@ static void __dma_rx_do_complete(struct uart_8250_port *p) dmaengine_tx_status(dma->rxchan, dma->rx_cookie, ); count = dma->rx_size - state.residue; - + if (count < dma->rx_size) + dmaengine_terminate_async(dma->rxchan); + if (!count) + goto unlock; ret = tty_insert_flip_string(tty_port, dma->rx_buf, count); p->port.icount.rx += ret; @@ -811,7 +814,6 @@ static void omap_8250_rx_dma_flush(struct uart_8250_port *p) spin_unlock_irqrestore(>rx_dma_lock, flags); __dma_rx_do_complete(p); - dmaengine_terminate_all(dma->rxchan); } static int omap_8250_rx_dma(struct uart_8250_port *p) -- 2.25.1
[PATCH AUTOSEL 4.9 51/90] tpm: ibmvtpm: Wait for buffer to be set before proceeding
From: Stefan Berger
[ Upstream commit d8d74ea3c00214aee1e1826ca18e77944812b9b4 ]
Synchronize with the results from the CRQs before continuing with
the initialization. This avoids trying to send TPM commands while
the rtce buffer has not been allocated, yet.
This patch fixes an existing race condition that may occurr if the
hypervisor does not quickly respond to the VTPM_GET_RTCE_BUFFER_SIZE
request sent during initialization and therefore the ibmvtpm->rtce_buf
has not been allocated at the time the first TPM command is sent.
Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM
vTPM")
Signed-off-by: Stefan Berger
Acked-by: Nayna Jain
Tested-by: Nayna Jain
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Sasha Levin
---
drivers/char/tpm/tpm_ibmvtpm.c | 9 +
drivers/char/tpm/tpm_ibmvtpm.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 84eca4f93b828..0fad6cf37bab4 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -550,6 +550,7 @@ static irqreturn_t ibmvtpm_interrupt(int irq, void
*vtpm_instance)
*/
while ((crq = ibmvtpm_crq_get_next(ibmvtpm)) != NULL) {
ibmvtpm_crq_process(crq, ibmvtpm);
+ wake_up_interruptible(>crq_queue.wq);
crq->valid = 0;
smp_wmb();
}
@@ -596,6 +597,7 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
}
crq_q->num_entry = CRQ_RES_BUF_SIZE / sizeof(*crq_q->crq_addr);
+ init_waitqueue_head(_q->wq);
ibmvtpm->crq_dma_handle = dma_map_single(dev, crq_q->crq_addr,
CRQ_RES_BUF_SIZE,
DMA_BIDIRECTIONAL);
@@ -648,6 +650,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
if (rc)
goto init_irq_cleanup;
+ if (!wait_event_timeout(ibmvtpm->crq_queue.wq,
+ ibmvtpm->rtce_buf != NULL,
+ HZ)) {
+ dev_err(dev, "CRQ response timed out\n");
+ goto init_irq_cleanup;
+ }
+
return tpm_chip_register(chip);
init_irq_cleanup:
do {
diff --git a/drivers/char/tpm/tpm_ibmvtpm.h b/drivers/char/tpm/tpm_ibmvtpm.h
index 91dfe766d0800..4f6a124601db4 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.h
+++ b/drivers/char/tpm/tpm_ibmvtpm.h
@@ -31,6 +31,7 @@ struct ibmvtpm_crq_queue {
struct ibmvtpm_crq *crq_addr;
u32 index;
u32 num_entry;
+ wait_queue_head_t wq;
};
struct ibmvtpm_dev {
--
2.25.1
[PATCH AUTOSEL 4.9 56/90] cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_work_fn
From: Pratik Rajesh Sampat
[ Upstream commit d95fe371ecd28901f11256c610b988ed44e36ee2 ]
The patch avoids allocating cpufreq_policy on stack hence fixing frame
size overflow in 'powernv_cpufreq_work_fn'
Fixes: 227942809b52 ("cpufreq: powernv: Restore cpu frequency to policy->cur on
unthrottling")
Signed-off-by: Pratik Rajesh Sampat
Reviewed-by: Daniel Axtens
Signed-off-by: Michael Ellerman
Link: https://lore.kernel.org/r/20200316135743.57735-1-psam...@linux.ibm.com
Signed-off-by: Sasha Levin
---
drivers/cpufreq/powernv-cpufreq.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index b4fc65512aad3..c3b05676e0dbe 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -802,6 +802,7 @@ static struct notifier_block powernv_cpufreq_reboot_nb = {
void powernv_cpufreq_work_fn(struct work_struct *work)
{
struct chip *chip = container_of(work, struct chip, throttle);
+ struct cpufreq_policy *policy;
unsigned int cpu;
cpumask_t mask;
@@ -816,12 +817,14 @@ void powernv_cpufreq_work_fn(struct work_struct *work)
chip->restore = false;
for_each_cpu(cpu, ) {
int index;
- struct cpufreq_policy policy;
- cpufreq_get_policy(, cpu);
- index = cpufreq_table_find_index_c(, policy.cur);
- powernv_cpufreq_target_index(, index);
- cpumask_andnot(, , policy.cpus);
+ policy = cpufreq_cpu_get(cpu);
+ if (!policy)
+ continue;
+ index = cpufreq_table_find_index_c(policy, policy->cur);
+ powernv_cpufreq_target_index(policy, index);
+ cpumask_andnot(, , policy->cpus);
+ cpufreq_cpu_put(policy);
}
out:
put_online_cpus();
--
2.25.1
Re: [linux-next PATCH] rapidio: Fix error handling path
Hi Dan,
On Thu, Sep 17, 2020 at 6:10 PM Dan Carpenter wrote:
>
> On Wed, Sep 16, 2020 at 01:02:32PM +0300, Dan Carpenter wrote:
> > On Wed, Sep 16, 2020 at 09:12:17AM +0530, Souptick Joarder wrote:
> > > There is an error when pin_user_pages_fast() returns -ERRNO and
> > > inside error handling path driver end up calling unpin_user_pages()
> > > with -ERRNO which is not correct.
> > >
> > > This patch will fix the problem.
> >
> > There are a few ways we could prevent bug in the future.
> >
> > 1) This could have been caught with existing static analysis tools
> >which warn about when a value is set but not used.
> >
> > 2) I've created a Smatch check which warngs about:
> >
> > drivers/rapidio/devices/rio_mport_cdev.c:955 rio_dma_transfer() warn:
> > unpinning negative pages 'nr_pages'
> >
> >I'll test it out tonight and see how well it works. I don't
> >immediately see any other bugs allthough Smatch doesn't like the code
> >in siw_umem_release(). It uses "min_t(int" which suggests that
> >negative pages are okay.
> >
> > int to_free = min_t(int, PAGES_PER_CHUNK, num_pages);
> >
>
> I only found one bug but I'm going to add unpin_user_pages_dirty_lock()
> to the mix a retest. There were a few other false positives. In
> reviewing the code, I noticed that orangefs_bufmap_map() is also buggy.
>
> I sort of feel like returning partial successes is not working. We
> could easily make a wrapper which either pins everything or it returns
> an error code.
>
> drivers/misc/mic/scif/scif_rma.c:1399 __scif_pin_pages() warn: unpinning
> negative pages 'pinned_pages->nr_pages'
>
> drivers/misc/mic/scif/scif_rma.c
> 1355 vmalloc_addr = true;
> 1356
> 1357 for (i = 0; i < nr_pages; i++) {
> 1358 if (vmalloc_addr)
> 1359 pinned_pages->pages[i] =
> 1360 vmalloc_to_page(addr + (i *
> PAGE_SIZE));
> 1361 else
> 1362 pinned_pages->pages[i] =
> 1363 virt_to_page(addr + (i *
> PAGE_SIZE));
> 1364 }
> 1365 pinned_pages->nr_pages = nr_pages;
> 1366 pinned_pages->map_flags = SCIF_MAP_KERNEL;
> 1367 } else {
> 1368 /*
> 1369 * SCIF supports registration caching. If a
> registration has
> 1370 * been requested with read only permissions, then we
> try
> 1371 * to pin the pages with RW permissions so that a
> subsequent
> 1372 * transfer with RW permission can hit the cache
> instead of
> 1373 * invalidating it. If the upgrade fails with RW then
> we
> 1374 * revert back to R permission and retry
> 1375 */
> 1376 if (prot == SCIF_PROT_READ)
> 1377 try_upgrade = true;
> 1378 prot |= SCIF_PROT_WRITE;
> 1379 retry:
> 1380 mm = current->mm;
> 1381 if (ulimit) {
> 1382 err = __scif_check_inc_pinned_vm(mm,
> nr_pages);
> 1383 if (err) {
> 1384 pinned_pages->nr_pages = 0;
> 1385 goto error_unmap;
> 1386 }
> 1387 }
> 1388
> 1389 pinned_pages->nr_pages = pin_user_pages_fast(
> 1390 (u64)addr,
> 1391 nr_pages,
> 1392 (prot & SCIF_PROT_WRITE) ? FOLL_WRITE
> : 0,
> 1393 pinned_pages->pages);
> 1394 if (nr_pages != pinned_pages->nr_pages) {
> 1395 if (try_upgrade) {
> 1396 if (ulimit)
> 1397 __scif_dec_pinned_vm_lock(mm,
> nr_pages);
> 1398 /* Roll back any pinned pages */
> 1399 unpin_user_pages(pinned_pages->pages,
> 1400
> pinned_pages->nr_pages);
>
> ^^
> Negative.
>
> 1401 prot &= ~SCIF_PROT_WRITE;
> 1402 try_upgrade = false;
> 1403 goto retry;
> 1404 }
> 1405 }
> 1406 pinned_pages->map_flags = 0;
> 1407 }
> 1408
> 1409 if (pinned_pages->nr_pages < nr_pages) {
> ^
> These are both signed so it negative ->nr_pages are
[PATCH AUTOSEL 4.9 57/90] tools: gpio-hammer: Avoid potential overflow in main
From: Gabriel Ravier
[ Upstream commit d1ee7e1f5c9191afb69ce46cc7752e4257340a31 ]
If '-o' was used more than 64 times in a single invocation of gpio-hammer,
this could lead to an overflow of the 'lines' array. This commit fixes
this by avoiding the overflow and giving a proper diagnostic back to the
user
Signed-off-by: Gabriel Ravier
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Sasha Levin
---
tools/gpio/gpio-hammer.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/tools/gpio/gpio-hammer.c b/tools/gpio/gpio-hammer.c
index 37b3f141053df..85f45800f881f 100644
--- a/tools/gpio/gpio-hammer.c
+++ b/tools/gpio/gpio-hammer.c
@@ -171,7 +171,14 @@ int main(int argc, char **argv)
device_name = optarg;
break;
case 'o':
- lines[i] = strtoul(optarg, NULL, 10);
+ /*
+* Avoid overflow. Do not immediately error, we want to
+* be able to accurately report on the amount of times
+* '-o' was given to give an accurate error message
+*/
+ if (i < GPIOHANDLES_MAX)
+ lines[i] = strtoul(optarg, NULL, 10);
+
i++;
break;
case '?':
@@ -179,6 +186,14 @@ int main(int argc, char **argv)
return -1;
}
}
+
+ if (i >= GPIOHANDLES_MAX) {
+ fprintf(stderr,
+ "Only %d occurences of '-o' are allowed, %d were
found\n",
+ GPIOHANDLES_MAX, i + 1);
+ return -1;
+ }
+
nlines = i;
if (!device_name || !nlines) {
--
2.25.1
[PATCH AUTOSEL 4.9 65/90] KVM: Remove CREATE_IRQCHIP/SET_PIT2 race
From: Steve Rutherford
[ Upstream commit 7289fdb5dcdbc5155b5531529c44105868a762f2 ]
Fixes a NULL pointer dereference, caused by the PIT firing an interrupt
before the interrupt table has been initialized.
SET_PIT2 can race with the creation of the IRQchip. In particular,
if SET_PIT2 is called with a low PIT timer period (after the creation of
the IOAPIC, but before the instantiation of the irq routes), the PIT can
fire an interrupt at an uninitialized table.
Signed-off-by: Steve Rutherford
Signed-off-by: Jon Cargille
Reviewed-by: Jim Mattson
Message-Id: <20200416191152.259434-1-jcarg...@google.com>
Signed-off-by: Paolo Bonzini
Signed-off-by: Sasha Levin
---
arch/x86/kvm/x86.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6b7faa14c27bb..3c0f9be107e42 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4263,10 +4263,13 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = -EFAULT;
if (copy_from_user(, argp, sizeof u.ps))
goto out;
+ mutex_lock(>lock);
r = -ENXIO;
if (!kvm->arch.vpit)
- goto out;
+ goto set_pit_out;
r = kvm_vm_ioctl_set_pit(kvm, );
+set_pit_out:
+ mutex_unlock(>lock);
break;
}
case KVM_GET_PIT2: {
@@ -4286,10 +4289,13 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = -EFAULT;
if (copy_from_user(, argp, sizeof(u.ps2)))
goto out;
+ mutex_lock(>lock);
r = -ENXIO;
if (!kvm->arch.vpit)
- goto out;
+ goto set_pit2_out;
r = kvm_vm_ioctl_set_pit2(kvm, );
+set_pit2_out:
+ mutex_unlock(>lock);
break;
}
case KVM_REINJECT_CONTROL: {
--
2.25.1
[PATCH AUTOSEL 4.9 64/90] serial: uartps: Wait for tx_empty in console setup
From: Raviteja Narayanam [ Upstream commit 42e11948ddf68b9f799cad8c0ddeab0a39da33e8 ] On some platforms, the log is corrupted while console is being registered. It is observed that when set_termios is called, there are still some bytes in the FIFO to be transmitted. So, wait for tx_empty inside cdns_uart_console_setup before calling set_termios. Signed-off-by: Raviteja Narayanam Reviewed-by: Shubhrajyoti Datta Link: https://lore.kernel.org/r/1586413563-29125-2-git-send-email-raviteja.naraya...@xilinx.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- drivers/tty/serial/xilinx_uartps.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index eb61a07fcbbc3..07ea71a611678 100644 --- a/drivers/tty/serial/xilinx_uartps.c +++ b/drivers/tty/serial/xilinx_uartps.c @@ -1268,6 +1268,7 @@ static int cdns_uart_console_setup(struct console *co, char *options) int bits = 8; int parity = 'n'; int flow = 'n'; + unsigned long time_out; if (co->index < 0 || co->index >= CDNS_UART_NR_PORTS) return -EINVAL; @@ -1281,6 +1282,13 @@ static int cdns_uart_console_setup(struct console *co, char *options) if (options) uart_parse_options(options, , , , ); + /* Wait for tx_empty before setting up the console */ + time_out = jiffies + usecs_to_jiffies(TX_TIMEOUT); + + while (time_before(jiffies, time_out) && + cdns_uart_tx_empty(port) != TIOCSER_TEMT) + cpu_relax(); + return uart_set_options(port, co, baud, parity, bits, flow); } -- 2.25.1
[PATCH AUTOSEL 4.9 61/90] ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor
From: Andreas Steinmetz
[ Upstream commit 5c6cd7021a05a02fcf37f360592d7c18d4d807fb ]
The Miditech MIDIFACE 16x16 (USB ID 1290:1749) has more than one extra
endpoint descriptor.
The first extra descriptor is: 0x06 0x30 0x00 0x00 0x00 0x00
As the code in snd_usbmidi_get_ms_info() looks only at the
first extra descriptor to find USB_DT_CS_ENDPOINT the device
as such is recognized but there is neither input nor output
configured.
The patch iterates through the extra descriptors to find the
proper one. With this patch the device is correctly configured.
Signed-off-by: Andreas Steinmetz
Link:
https://lore.kernel.org/r/1c3b431a86f69e1d60745b6110cdb93c299f120b.ca...@domdv.de
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/usb/midi.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/sound/usb/midi.c b/sound/usb/midi.c
index 0676e7d485def..b8d4b5b3e54a1 100644
--- a/sound/usb/midi.c
+++ b/sound/usb/midi.c
@@ -1805,6 +1805,28 @@ static int snd_usbmidi_create_endpoints(struct
snd_usb_midi *umidi,
return 0;
}
+static struct usb_ms_endpoint_descriptor *find_usb_ms_endpoint_descriptor(
+ struct usb_host_endpoint *hostep)
+{
+ unsigned char *extra = hostep->extra;
+ int extralen = hostep->extralen;
+
+ while (extralen > 3) {
+ struct usb_ms_endpoint_descriptor *ms_ep =
+ (struct usb_ms_endpoint_descriptor *)extra;
+
+ if (ms_ep->bLength > 3 &&
+ ms_ep->bDescriptorType == USB_DT_CS_ENDPOINT &&
+ ms_ep->bDescriptorSubtype == UAC_MS_GENERAL)
+ return ms_ep;
+ if (!extra[0])
+ break;
+ extralen -= extra[0];
+ extra += extra[0];
+ }
+ return NULL;
+}
+
/*
* Returns MIDIStreaming device capabilities.
*/
@@ -1842,11 +1864,8 @@ static int snd_usbmidi_get_ms_info(struct snd_usb_midi
*umidi,
ep = get_ep_desc(hostep);
if (!usb_endpoint_xfer_bulk(ep) && !usb_endpoint_xfer_int(ep))
continue;
- ms_ep = (struct usb_ms_endpoint_descriptor *)hostep->extra;
- if (hostep->extralen < 4 ||
- ms_ep->bLength < 4 ||
- ms_ep->bDescriptorType != USB_DT_CS_ENDPOINT ||
- ms_ep->bDescriptorSubtype != UAC_MS_GENERAL)
+ ms_ep = find_usb_ms_endpoint_descriptor(hostep);
+ if (!ms_ep)
continue;
if (usb_endpoint_dir_out(ep)) {
if (endpoints[epidx].out_ep) {
--
2.25.1
[PATCH AUTOSEL 4.9 60/90] ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len
From: Liu Song
[ Upstream commit acc5af3efa303d5f36cc8c0f61716161f6ca1384 ]
In “ubifs_check_node”, when the value of "node_len" is abnormal,
the code will goto label of "out_len" for execution. Then, in the
following "ubifs_dump_node", if inode type is "UBIFS_DATA_NODE",
in "print_hex_dump", an out-of-bounds access may occur due to the
wrong "ch->len".
Therefore, when the value of "node_len" is abnormal, data length
should to be adjusted to a reasonable safe range. At this time,
structured data is not credible, so dump the corrupted data directly
for analysis.
Signed-off-by: Liu Song
Signed-off-by: Richard Weinberger
Signed-off-by: Sasha Levin
---
fs/ubifs/io.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c
index 97be412153328..9213a9e046ae0 100644
--- a/fs/ubifs/io.c
+++ b/fs/ubifs/io.c
@@ -237,7 +237,7 @@ int ubifs_is_mapped(const struct ubifs_info *c, int lnum)
int ubifs_check_node(const struct ubifs_info *c, const void *buf, int lnum,
int offs, int quiet, int must_chk_crc)
{
- int err = -EINVAL, type, node_len;
+ int err = -EINVAL, type, node_len, dump_node = 1;
uint32_t crc, node_crc, magic;
const struct ubifs_ch *ch = buf;
@@ -290,10 +290,22 @@ int ubifs_check_node(const struct ubifs_info *c, const
void *buf, int lnum,
out_len:
if (!quiet)
ubifs_err(c, "bad node length %d", node_len);
+ if (type == UBIFS_DATA_NODE && node_len > UBIFS_DATA_NODE_SZ)
+ dump_node = 0;
out:
if (!quiet) {
ubifs_err(c, "bad node at LEB %d:%d", lnum, offs);
- ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\tprevent out-of-bounds memory access\n");
+ pr_err("\ttruncated data node length %d\n",
safe_len);
+ pr_err("\tcorrupted data node:\n");
+ print_hex_dump(KERN_ERR, "\t", DUMP_PREFIX_OFFSET, 32,
1,
+ buf, safe_len, 0);
+ }
dump_stack();
}
return err;
--
2.25.1
[PATCH AUTOSEL 4.9 77/90] e1000: Do not perform reset in reset_task if we are already down
From: Alexander Duyck
[ Upstream commit 49ee3c2ab5234757bfb56a0b3a3cb422f427e3a3 ]
We are seeing a deadlock in e1000 down when NAPI is being disabled. Looking
over the kernel function trace of the system it appears that the interface
is being closed and then a reset is hitting which deadlocks the interface
as the NAPI interface is already disabled.
To prevent this from happening I am disabling the reset task when
__E1000_DOWN is already set. In addition code has been added so that we set
the __E1000_DOWN while holding the __E1000_RESET flag in e1000_close in
order to guarantee that the reset task will not run after we have started
the close call.
Signed-off-by: Alexander Duyck
Tested-by: Maxim Zhukov
Signed-off-by: Jeff Kirsher
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 3b16ee0de246e..c30792b761ee3 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -568,8 +568,13 @@ void e1000_reinit_locked(struct e1000_adapter *adapter)
WARN_ON(in_interrupt());
while (test_and_set_bit(__E1000_RESETTING, >flags))
msleep(1);
- e1000_down(adapter);
- e1000_up(adapter);
+
+ /* only run the task if not already down */
+ if (!test_bit(__E1000_DOWN, >flags)) {
+ e1000_down(adapter);
+ e1000_up(adapter);
+ }
+
clear_bit(__E1000_RESETTING, >flags);
}
@@ -1456,10 +1461,15 @@ int e1000_close(struct net_device *netdev)
struct e1000_hw *hw = >hw;
int count = E1000_CHECK_RESET_COUNT;
- while (test_bit(__E1000_RESETTING, >flags) && count--)
+ while (test_and_set_bit(__E1000_RESETTING, >flags) && count--)
usleep_range(1, 2);
- WARN_ON(test_bit(__E1000_RESETTING, >flags));
+ WARN_ON(count < 0);
+
+ /* signal that we're down so that the reset task will no longer run */
+ set_bit(__E1000_DOWN, >flags);
+ clear_bit(__E1000_RESETTING, >flags);
+
e1000_down(adapter);
e1000_power_down_phy(adapter);
e1000_free_irq(adapter);
--
2.25.1
[PATCH AUTOSEL 4.9 67/90] drivers: char: tlclk.c: Avoid data race between init and interrupt handler
From: Madhuparna Bhowmik
[ Upstream commit 44b8fb6eaa7c3fb770bf1e37619cdb3902cca1fc ]
After registering character device the file operation callbacks can be
called. The open callback registers interrupt handler.
Therefore interrupt handler can execute in parallel with rest of the init
function. To avoid such data race initialize telclk_interrupt variable
and struct alarm_events before registering character device.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Madhuparna Bhowmik
Link:
https://lore.kernel.org/r/20200417153451.1551-1-madhuparnabhowmi...@gmail.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/char/tlclk.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/char/tlclk.c b/drivers/char/tlclk.c
index 100cd1de9939d..59e1e94d12c01 100644
--- a/drivers/char/tlclk.c
+++ b/drivers/char/tlclk.c
@@ -777,17 +777,21 @@ static int __init tlclk_init(void)
{
int ret;
+ telclk_interrupt = (inb(TLCLK_REG7) & 0x0f);
+
+ alarm_events = kzalloc( sizeof(struct tlclk_alarms), GFP_KERNEL);
+ if (!alarm_events) {
+ ret = -ENOMEM;
+ goto out1;
+ }
+
ret = register_chrdev(tlclk_major, "telco_clock", _fops);
if (ret < 0) {
printk(KERN_ERR "tlclk: can't get major %d.\n", tlclk_major);
+ kfree(alarm_events);
return ret;
}
tlclk_major = ret;
- alarm_events = kzalloc( sizeof(struct tlclk_alarms), GFP_KERNEL);
- if (!alarm_events) {
- ret = -ENOMEM;
- goto out1;
- }
/* Read telecom clock IRQ number (Set by BIOS) */
if (!request_region(TLCLK_BASE, 8, "telco_clock")) {
@@ -796,7 +800,6 @@ static int __init tlclk_init(void)
ret = -EBUSY;
goto out2;
}
- telclk_interrupt = (inb(TLCLK_REG7) & 0x0f);
if (0x0F == telclk_interrupt ) { /* not MCPBL0010 ? */
printk(KERN_ERR "telclk_interrupt = 0x%x non-mcpbl0010 hw.\n",
@@ -837,8 +840,8 @@ out3:
release_region(TLCLK_BASE, 8);
out2:
kfree(alarm_events);
-out1:
unregister_chrdev(tlclk_major, "telco_clock");
+out1:
return ret;
}
--
2.25.1
[PATCH AUTOSEL 4.9 71/90] Bluetooth: Handle Inquiry Cancel error after Inquiry Complete
From: Sonny Sasaka
[ Upstream commit adf1d6926444029396861413aba8a0f2a805742a ]
After sending Inquiry Cancel command to the controller, it is possible
that Inquiry Complete event comes before Inquiry Cancel command complete
event. In this case the Inquiry Cancel command will have status of
Command Disallowed since there is no Inquiry session to be cancelled.
This case should not be treated as error, otherwise we can reach an
inconsistent state.
Example of a btmon trace when this happened:
< HCI Command: Inquiry Cancel (0x01|0x0002) plen 0
> HCI Event: Inquiry Complete (0x01) plen 1
Status: Success (0x00)
> HCI Event: Command Complete (0x0e) plen 4
Inquiry Cancel (0x01|0x0002) ncmd 1
Status: Command Disallowed (0x0c)
Signed-off-by: Sonny Sasaka
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
---
net/bluetooth/hci_event.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 700a2eb161490..d6da119f5082e 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -41,12 +41,27 @@
/* Handle HCI Event packets */
-static void hci_cc_inquiry_cancel(struct hci_dev *hdev, struct sk_buff *skb)
+static void hci_cc_inquiry_cancel(struct hci_dev *hdev, struct sk_buff *skb,
+ u8 *new_status)
{
__u8 status = *((__u8 *) skb->data);
BT_DBG("%s status 0x%2.2x", hdev->name, status);
+ /* It is possible that we receive Inquiry Complete event right
+* before we receive Inquiry Cancel Command Complete event, in
+* which case the latter event should have status of Command
+* Disallowed (0x0c). This should not be treated as error, since
+* we actually achieve what Inquiry Cancel wants to achieve,
+* which is to end the last Inquiry session.
+*/
+ if (status == 0x0c && !test_bit(HCI_INQUIRY, >flags)) {
+ bt_dev_warn(hdev, "Ignoring error of Inquiry Cancel command");
+ status = 0x00;
+ }
+
+ *new_status = status;
+
if (status)
return;
@@ -2772,7 +2787,7 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev,
struct sk_buff *skb,
switch (*opcode) {
case HCI_OP_INQUIRY_CANCEL:
- hci_cc_inquiry_cancel(hdev, skb);
+ hci_cc_inquiry_cancel(hdev, skb, status);
break;
case HCI_OP_PERIODIC_INQ:
--
2.25.1
[PATCH AUTOSEL 4.9 69/90] atm: fix a memory leak of vcc->user_back
From: Cong Wang
[ Upstream commit 8d9f73c0ad2f20e9fed5380de0a3097825859d03 ]
In lec_arp_clear_vccs() only entry->vcc is freed, but vcc
could be installed on entry->recv_vcc too in lec_vcc_added().
This fixes the following memory leak:
unreferenced object 0x8880d9266b90 (size 16):
comm "atm2", pid 425, jiffies 4294907980 (age 23.488s)
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 6b 6b 6b a5 kkk.
backtrace:
[<(ptrval)>] kmem_cache_alloc_trace+0x10e/0x151
[<(ptrval)>] lane_ioctl+0x4b3/0x569
[<(ptrval)>] do_vcc_ioctl+0x1ea/0x236
[<(ptrval)>] svc_ioctl+0x17d/0x198
[<(ptrval)>] sock_do_ioctl+0x47/0x12f
[<(ptrval)>] sock_ioctl+0x2f9/0x322
[<(ptrval)>] vfs_ioctl+0x1e/0x2b
[<(ptrval)>] ksys_ioctl+0x61/0x80
[<(ptrval)>] __x64_sys_ioctl+0x16/0x19
[<(ptrval)>] do_syscall_64+0x57/0x65
[<(ptrval)>] entry_SYSCALL_64_after_hwframe+0x49/0xb3
Cc: Gengming Liu
Signed-off-by: Cong Wang
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
net/atm/lec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 704892d79bf19..756429c95e859 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -1290,6 +1290,12 @@ static void lec_arp_clear_vccs(struct lec_arp_table
*entry)
entry->vcc = NULL;
}
if (entry->recv_vcc) {
+ struct atm_vcc *vcc = entry->recv_vcc;
+ struct lec_vcc_priv *vpriv = LEC_VCC_PRIV(vcc);
+
+ kfree(vpriv);
+ vcc->user_back = NULL;
+
entry->recv_vcc->push = entry->old_recv_push;
vcc_release_async(entry->recv_vcc, -EPIPE);
entry->recv_vcc = NULL;
--
2.25.1
[PATCH AUTOSEL 4.9 75/90] fuse: don't check refcount after stealing page
From: Miklos Szeredi
[ Upstream commit 32f98877c57bee6bc27f443a96f49678a2cd6a50 ]
page_count() is unstable. Unless there has been an RCU grace period
between when the page was removed from the page cache and now, a
speculative reference may exist from the page cache.
Reported-by: Matthew Wilcox
Signed-off-by: Miklos Szeredi
Signed-off-by: Sasha Levin
---
fs/fuse/dev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index b99225e117120..f0129c033bd66 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -825,7 +825,6 @@ static int fuse_check_page(struct page *page)
{
if (page_mapcount(page) ||
page->mapping != NULL ||
- page_count(page) != 1 ||
(page->flags & PAGE_FLAGS_CHECK_AT_PREP &
~(1 << PG_locked |
1 << PG_referenced |
--
2.25.1
[PATCH AUTOSEL 4.9 76/90] USB: EHCI: ehci-mv: fix less than zero comparison of an unsigned int
From: Colin Ian King
[ Upstream commit a7f40c233a6b0540d28743267560df9cfb571ca9 ]
The comparison of hcd->irq to less than zero for an error check will
never be true because hcd->irq is an unsigned int. Fix this by
assigning the int retval to the return of platform_get_irq and checking
this for the -ve error condition and assigning hcd->irq to retval.
Addresses-Coverity: ("Unsigned compared against 0")
Fixes: c856b4b0fdb5 ("USB: EHCI: ehci-mv: fix error handling in
mv_ehci_probe()")
Signed-off-by: Colin Ian King
Link: https://lore.kernel.org/r/20200515165453.104028-1-colin.k...@canonical.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/usb/host/ehci-mv.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 273736e1d33fa..b29610899c9f6 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -196,11 +196,10 @@ static int mv_ehci_probe(struct platform_device *pdev)
hcd->rsrc_len = resource_size(r);
hcd->regs = ehci_mv->op_regs;
- hcd->irq = platform_get_irq(pdev, 0);
- if (hcd->irq < 0) {
- retval = hcd->irq;
+ retval = platform_get_irq(pdev, 0);
+ if (retval < 0)
goto err_disable_clk;
- }
+ hcd->irq = retval;
ehci = hcd_to_ehci(hcd);
ehci->caps = (struct ehci_caps *) ehci_mv->cap_regs;
--
2.25.1
[PATCH AUTOSEL 4.9 66/90] bdev: Reduce time holding bd_mutex in sync in blkdev_close()
From: Douglas Anderson
[ Upstream commit b849dd84b6ccfe32622988b79b7b073861fcf9f7 ]
While trying to "dd" to the block device for a USB stick, I
encountered a hung task warning (blocked for > 120 seconds). I
managed to come up with an easy way to reproduce this on my system
(where /dev/sdb is the block device for my USB stick) with:
while true; do dd if=/dev/zero of=/dev/sdb bs=4M; done
With my reproduction here are the relevant bits from the hung task
detector:
INFO: task udevd:294 blocked for more than 122 seconds.
...
udevd D0 294 1 0x0048
Call trace:
...
mutex_lock_nested+0x40/0x50
__blkdev_get+0x7c/0x3d4
blkdev_get+0x118/0x138
blkdev_open+0x94/0xa8
do_dentry_open+0x268/0x3a0
vfs_open+0x34/0x40
path_openat+0x39c/0xdf4
do_filp_open+0x90/0x10c
do_sys_open+0x150/0x3c8
...
...
Showing all locks held in the system:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (>bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
write_cache_pages+0x194/0x500
generic_writepages+0x64/0xa4
blkdev_writepages+0x24/0x30
do_writepages+0x48/0xa8
__filemap_fdatawrite_range+0xac/0xd8
filemap_write_and_wait+0x30/0x84
__blkdev_put+0x88/0x204
blkdev_put+0xc4/0xe4
blkdev_close+0x28/0x38
__fput+0xe0/0x238
fput+0x1c/0x28
task_work_run+0xb0/0xe4
do_notify_resume+0xfc0/0x14bc
work_pending+0x8/0x14
The problem appears related to the fact that my USB disk is terribly
slow and that I have a lot of RAM in my system to cache things.
Specifically my writes seem to be happening at ~15 MB/s and I've got
~4 GB of RAM in my system that can be used for buffering. To write 4
GB of buffer to disk thus takes ~4000 MB / ~15 MB/s = ~267 seconds.
The 267 second number is a problem because in __blkdev_put() we call
sync_blockdev() while holding the bd_mutex. Any other callers who
want the bd_mutex will be blocked for the whole time.
The problem is made worse because I believe blkdev_put() specifically
tells other tasks (namely udev) to go try to access the device at right
around the same time we're going to hold the mutex for a long time.
Putting some traces around this (after disabling the hung task detector),
I could confirm:
dd:437.608600: __blkdev_put() right before sync_blockdev() for sdb
udevd: 437.623901: blkdev_open() right before blkdev_get() for sdb
dd:661.468451: __blkdev_put() right after sync_blockdev() for sdb
udevd: 663.820426: blkdev_open() right after blkdev_get() for sdb
A simple fix for this is to realize that sync_blockdev() works fine if
you're not holding the mutex. Also, it's not the end of the world if
you sync a little early (though it can have performance impacts).
Thus we can make a guess that we're going to need to do the sync and
then do it without holding the mutex. We still do one last sync with
the mutex but it should be much, much faster.
With this, my hung task warnings for my test case are gone.
Signed-off-by: Douglas Anderson
Reviewed-by: Guenter Roeck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
fs/block_dev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 06f7cbe201326..98b37e77683d3 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1586,6 +1586,16 @@ static void __blkdev_put(struct block_device *bdev,
fmode_t mode, int for_part)
struct gendisk *disk = bdev->bd_disk;
struct block_device *victim = NULL;
+ /*
+* Sync early if it looks like we're the last one. If someone else
+* opens the block device between now and the decrement of bd_openers
+* then we did a sync that we didn't need to, but that's not the end
+* of the world and we want to avoid long (could be several minute)
+* syncs while holding the mutex.
+*/
+ if (bdev->bd_openers == 1)
+ sync_blockdev(bdev);
+
mutex_lock_nested(>bd_mutex, for_part);
if (for_part)
bdev->bd_part_count--;
--
2.25.1
[PATCH AUTOSEL 4.9 78/90] printk: handle blank console arguments passed in.
From: Shreyas Joshi [ Upstream commit 48021f98130880dd74286459a1ef48b5e9bc374f ] If uboot passes a blank string to console_setup then it results in a trashed memory. Ultimately, the kernel crashes during freeing up the memory. This fix checks if there is a blank parameter being passed to console_setup from uboot. In case it detects that the console parameter is blank then it doesn't setup the serial device and it gracefully exits. Link: https://lore.kernel.org/r/20200522065306.83-1-shreyas.jo...@biamp.com Signed-off-by: Shreyas Joshi Acked-by: Sergey Senozhatsky [pmla...@suse.com: Better format the commit message and code, remove unnecessary brackets.] Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin --- kernel/printk/printk.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index c1873d325ebda..7acae2f2478d9 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2035,6 +2035,9 @@ static int __init console_setup(char *str) char *s, *options, *brl_options = NULL; int idx; + if (str[0] == 0) + return 1; + if (_braille_console_setup(, _options)) return 1; -- 2.25.1
[PATCH AUTOSEL 4.9 81/90] perf util: Fix memory leak of prefix_if_not_in
From: Xie XiuQi [ Upstream commit 07e9a6f538cbeecaf5c55b6f2991416f873cdcbd ] Need to free "str" before return when asprintf() failed to avoid memory leak. Signed-off-by: Xie XiuQi Cc: Alexander Shishkin Cc: Hongbo Yao Cc: Jiri Olsa Cc: Li Bin Cc: Mark Rutland Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/20200521133218.30150-4-liwei...@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin --- tools/perf/util/sort.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c index 031e64ce71564..013e3f5102258 100644 --- a/tools/perf/util/sort.c +++ b/tools/perf/util/sort.c @@ -2532,7 +2532,7 @@ static char *prefix_if_not_in(const char *pre, char *str) return str; if (asprintf(, "%s,%s", pre, str) < 0) - return NULL; + n = NULL; free(str); return n; -- 2.25.1
[PATCH AUTOSEL 4.4 01/64] scsi: aacraid: fix illegal IO beyond last LBA
From: Balsundar P [ Upstream commit c86fbe484c10b2cd1e770770db2d6b2c88801c1d ] The driver fails to handle data when read or written beyond device reported LBA, which triggers kernel panic Link: https://lore.kernel.org/r/1571120524-6037-2-git-send-email-balsunda...@microsemi.com Signed-off-by: Balsundar P Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin --- drivers/scsi/aacraid/aachba.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c index de33801ca31ea..0614d05a990a6 100644 --- a/drivers/scsi/aacraid/aachba.c +++ b/drivers/scsi/aacraid/aachba.c @@ -1938,13 +1938,13 @@ static int aac_read(struct scsi_cmnd * scsicmd) scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8 | SAM_STAT_CHECK_CONDITION; set_sense(>fsa_dev[cid].sense_data, - HARDWARE_ERROR, SENCODE_INTERNAL_TARGET_FAILURE, + ILLEGAL_REQUEST, SENCODE_LBA_OUT_OF_RANGE, ASENCODE_INTERNAL_TARGET_FAILURE, 0, 0); memcpy(scsicmd->sense_buffer, >fsa_dev[cid].sense_data, min_t(size_t, sizeof(dev->fsa_dev[cid].sense_data), SCSI_SENSE_BUFFERSIZE)); scsicmd->scsi_done(scsicmd); - return 1; + return 0; } dprintk((KERN_DEBUG "aac_read[cpu %d]: lba = %llu, t = %ld.\n", @@ -2035,13 +2035,13 @@ static int aac_write(struct scsi_cmnd * scsicmd) scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8 | SAM_STAT_CHECK_CONDITION; set_sense(>fsa_dev[cid].sense_data, - HARDWARE_ERROR, SENCODE_INTERNAL_TARGET_FAILURE, + ILLEGAL_REQUEST, SENCODE_LBA_OUT_OF_RANGE, ASENCODE_INTERNAL_TARGET_FAILURE, 0, 0); memcpy(scsicmd->sense_buffer, >fsa_dev[cid].sense_data, min_t(size_t, sizeof(dev->fsa_dev[cid].sense_data), SCSI_SENSE_BUFFERSIZE)); scsicmd->scsi_done(scsicmd); - return 1; + return 0; } dprintk((KERN_DEBUG "aac_write[cpu %d]: lba = %llu, t = %ld.\n", -- 2.25.1
[PATCH AUTOSEL 4.9 74/90] ALSA: hda: Fix potential race in unsol event handler
From: Takashi Iwai
[ Upstream commit c637fa151259c0f74665fde7cba5b7eac1417ae5 ]
The unsol event handling code has a loop retrieving the read/write
indices and the arrays without locking while the append to the array
may happen concurrently. This may lead to some inconsistency.
Although there hasn't been any proof of this bad results, it's still
safer to protect the racy accesses.
This patch adds the spinlock protection around the unsol handling loop
for addressing it. Here we take bus->reg_lock as the writer side
snd_hdac_bus_queue_event() is also protected by that lock.
Link: https://lore.kernel.org/r/20200516062556.30951-1-ti...@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/hda/hdac_bus.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/hda/hdac_bus.c b/sound/hda/hdac_bus.c
index 0e81ea89a5965..e3f68a76d90eb 100644
--- a/sound/hda/hdac_bus.c
+++ b/sound/hda/hdac_bus.c
@@ -155,6 +155,7 @@ static void process_unsol_events(struct work_struct *work)
struct hdac_driver *drv;
unsigned int rp, caddr, res;
+ spin_lock_irq(>reg_lock);
while (bus->unsol_rp != bus->unsol_wp) {
rp = (bus->unsol_rp + 1) % HDA_UNSOL_QUEUE_SIZE;
bus->unsol_rp = rp;
@@ -166,10 +167,13 @@ static void process_unsol_events(struct work_struct *work)
codec = bus->caddr_tbl[caddr & 0x0f];
if (!codec || !codec->dev.driver)
continue;
+ spin_unlock_irq(>reg_lock);
drv = drv_to_hdac_driver(codec->dev.driver);
if (drv->unsol_event)
drv->unsol_event(codec, res);
+ spin_lock_irq(>reg_lock);
}
+ spin_unlock_irq(>reg_lock);
}
/**
--
2.25.1
[PATCH AUTOSEL 4.9 79/90] btrfs: don't force read-only after error in drop snapshot
From: David Sterba
[ Upstream commit 7c09c03091ac562ddca2b393e5d65c1d37da79f1 ]
Deleting a subvolume on a full filesystem leads to ENOSPC followed by a
forced read-only. This is not a transaction abort and the filesystem is
otherwise ok, so the error should be just propagated to the callers.
This is caused by unnecessary call to btrfs_handle_fs_error for all
errors, except EAGAIN. This does not make sense as the standard
transaction abort mechanism is in btrfs_drop_snapshot so all relevant
failures are handled.
Originally in commit cb1b69f4508a ("Btrfs: forced readonly when
btrfs_drop_snapshot() fails") there was no return value at all, so the
btrfs_std_error made some sense but once the error handling and
propagation has been implemented we don't need it anymore.
Signed-off-by: David Sterba
Signed-off-by: Sasha Levin
---
fs/btrfs/extent-tree.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index c0033a0d00787..b5bff1e760a34 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -9435,8 +9435,6 @@ out:
*/
if (!for_reloc && root_dropped == false)
btrfs_add_dead_root(root);
- if (err && err != -EAGAIN)
- btrfs_handle_fs_error(fs_info, err, NULL);
return err;
}
--
2.25.1
[PATCH AUTOSEL 4.9 80/90] vfio/pci: fix memory leaks of eventfd ctx
From: Qian Cai [ Upstream commit 1518ac272e789cae8c555d69951b032a275b7602 ] Finished a qemu-kvm (-device vfio-pci,host=0001:01:00.0) triggers a few memory leaks after a while because vfio_pci_set_ctx_trigger_single() calls eventfd_ctx_fdget() without the matching eventfd_ctx_put() later. Fix it by calling eventfd_ctx_put() for those memory in vfio_pci_release() before vfio_device_release(). unreferenced object 0xebff008981cc2b00 (size 128): comm "qemu-kvm", pid 4043, jiffies 4294994816 (age 9796.310s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff backtrace: [<917e8f8d>] slab_post_alloc_hook+0x74/0x9c [] kmem_cache_alloc_trace+0x2b4/0x3d4 [<5fcec025>] do_eventfd+0x54/0x1ac [<82791a69>] __arm64_sys_eventfd2+0x34/0x44 [ ] do_el0_svc+0x128/0x1dc [ ] el0_sync_handler+0xd0/0x268 [ ] el0_sync+0x164/0x180 unreferenced object 0x29ff008981cc4180 (size 128): comm "qemu-kvm", pid 4043, jiffies 4294994818 (age 9796.290s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff backtrace: [<917e8f8d>] slab_post_alloc_hook+0x74/0x9c [ ] kmem_cache_alloc_trace+0x2b4/0x3d4 [<5fcec025>] do_eventfd+0x54/0x1ac [<82791a69>] __arm64_sys_eventfd2+0x34/0x44 [ ] do_el0_svc+0x128/0x1dc [ ] el0_sync_handler+0xd0/0x268 [ ] el0_sync+0x164/0x180 Signed-off-by: Qian Cai Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin --- drivers/vfio/pci/vfio_pci.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c index 2254c281cc766..c9c0af9a571f6 100644 --- a/drivers/vfio/pci/vfio_pci.c +++ b/drivers/vfio/pci/vfio_pci.c @@ -392,6 +392,10 @@ static void vfio_pci_release(void *device_data) if (!(--vdev->refcnt)) { vfio_spapr_pci_eeh_release(vdev->pdev); vfio_pci_disable(vdev); + if (vdev->err_trigger) + eventfd_ctx_put(vdev->err_trigger); + if (vdev->req_trigger) + eventfd_ctx_put(vdev->req_trigger); } mutex_unlock(_lock); -- 2.25.1
[PATCH AUTOSEL 4.9 89/90] selftests/x86/syscall_nt: Clear weird flags after each test
From: Andy Lutomirski
[ Upstream commit a61fa2799ef9bf6c4f54cf7295036577cececc72 ]
Clear the weird flags before logging to improve strace output --
logging results while, say, TF is set does no one any favors.
Signed-off-by: Andy Lutomirski
Signed-off-by: Thomas Gleixner
Link:
https://lkml.kernel.org/r/907bfa5a42d4475b8245e18b67a04b13ca51ffdb.1593191971.git.l...@kernel.org
Signed-off-by: Sasha Levin
---
tools/testing/selftests/x86/syscall_nt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/x86/syscall_nt.c
b/tools/testing/selftests/x86/syscall_nt.c
index 43fcab367fb0a..74e6b3fc2d09e 100644
--- a/tools/testing/selftests/x86/syscall_nt.c
+++ b/tools/testing/selftests/x86/syscall_nt.c
@@ -67,6 +67,7 @@ static void do_it(unsigned long extraflags)
set_eflags(get_eflags() | extraflags);
syscall(SYS_getpid);
flags = get_eflags();
+ set_eflags(X86_EFLAGS_IF | X86_EFLAGS_FIXED);
if ((flags & extraflags) == extraflags) {
printf("[OK]\tThe syscall worked and flags are still set\n");
} else {
--
2.25.1
[PATCH AUTOSEL 4.9 88/90] cifs: Fix double add page to memcg when cifs_readpages
From: Zhang Xiaoxu
[ Upstream commit 95a3d8f3af9b0d63b43f221b630beaab9739d13a ]
When xfstests generic/451, there is an BUG at mm/memcontrol.c:
page:ea000560f2c0 refcount:2 mapcount:0 mapping:8544e0ea
index:0xf
mapping->aops:cifs_addr_ops dentry name:"tst-aio-dio-cycle-write.451"
flags: 0x2f8001(locked)
raw: 002f8001 c90002023c50 ea0005280088 88815cda0210
raw: 000f 0002 88817287d000
page dumped because: VM_BUG_ON_PAGE(page->mem_cgroup)
page->mem_cgroup:88817287d000
[ cut here ]
kernel BUG at mm/memcontrol.c:2659!
invalid opcode: [#1] SMP
CPU: 2 PID: 2038 Comm: xfs_io Not tainted 5.8.0-rc1 #44
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_
073836-buildvm-ppc64le-16.ppc.4
RIP: 0010:commit_charge+0x35/0x50
Code: 0d 48 83 05 54 b2 02 05 01 48 89 77 38 c3 48 c7
c6 78 4a ea ba 48 83 05 38 b2 02 05 01 e8 63 0d9
RSP: 0018:c90002023a50 EFLAGS: 00010202
RAX: RBX: 88817287d000 RCX:
RDX: RSI: 88817ac97ea0 RDI: 88817ac97ea0
RBP: ea000560f2c0 R08: 0203 R09: 0005
R10: 0030 R11: c900020237a8 R12:
R13: 0001 R14: 0001 R15: 88815a1272c0
FS: 7f5071ab0800() GS:88817ac8() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 55efcd5ca000 CR3: 00015d312000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
mem_cgroup_charge+0x166/0x4f0
__add_to_page_cache_locked+0x4a9/0x710
add_to_page_cache_locked+0x15/0x20
cifs_readpages+0x217/0x1270
read_pages+0x29a/0x670
page_cache_readahead_unbounded+0x24f/0x390
__do_page_cache_readahead+0x3f/0x60
ondemand_readahead+0x1f1/0x470
page_cache_async_readahead+0x14c/0x170
generic_file_buffered_read+0x5df/0x1100
generic_file_read_iter+0x10c/0x1d0
cifs_strict_readv+0x139/0x170
new_sync_read+0x164/0x250
__vfs_read+0x39/0x60
vfs_read+0xb5/0x1e0
ksys_pread64+0x85/0xf0
__x64_sys_pread64+0x22/0x30
do_syscall_64+0x69/0x150
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f5071fcb1af
Code: Bad RIP value.
RSP: 002b:7ffde2cdb8e0 EFLAGS: 0293 ORIG_RAX: 0011
RAX: ffda RBX: 7ffde2cdb990 RCX: 7f5071fcb1af
RDX: 1000 RSI: 55efcd5ca000 RDI: 0003
RBP: 0003 R08: R09:
R10: 1000 R11: 0293 R12: 0001
R13: 0009f000 R14: R15: 1000
Modules linked in:
---[ end trace 725fa14a3e1af65c ]---
Since commit 3fea5a499d57 ("mm: memcontrol: convert page cache to a new
mem_cgroup_charge() API") not cancel the page charge, the pages maybe
double add to pagecache:
thread1 | thread2
cifs_readpages
readpages_get_pages
add_to_page_cache_locked(head,index=n)=0
| readpages_get_pages
| add_to_page_cache_locked(head,index=n+1)=0
add_to_page_cache_locked(head, index=n+1)=-EEXIST
then, will next loop with list head page's
index=n+1 and the page->mapping not NULL
readpages_get_pages
add_to_page_cache_locked(head, index=n+1)
commit_charge
VM_BUG_ON_PAGE
So, we should not do the next loop when any page add to page cache
failed.
Reported-by: Hulk Robot
Signed-off-by: Zhang Xiaoxu
Signed-off-by: Steve French
Acked-by: Ronnie Sahlberg
Signed-off-by: Sasha Levin
---
fs/cifs/file.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index dca78b6e9ea32..24508b69e78b7 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -3531,7 +3531,8 @@ readpages_get_pages(struct address_space *mapping, struct
list_head *page_list,
break;
__SetPageLocked(page);
- if (add_to_page_cache_locked(page, mapping, page->index, gfp)) {
+ rc = add_to_page_cache_locked(page, mapping, page->index, gfp);
+ if (rc) {
__ClearPageLocked(page);
break;
}
@@ -3547,6 +3548,7 @@ static int cifs_readpages(struct file *file, struct
address_space *mapping,
struct list_head *page_list, unsigned num_pages)
{
int rc;
+ int err = 0;
struct list_head tmplist;
struct cifsFileInfo *open_file = file->private_data;
struct cifs_sb_info *cifs_sb = CIFS_FILE_SB(file);
@@ -3587,7 +3589,7 @@ static int cifs_readpages(struct file *file, struct
address_space *mapping,
* the order of declining indexes. When we put the pages in
* the rdata->pages,
[PATCH AUTOSEL 4.9 87/90] vfio/pci: Clear error and request eventfd ctx after releasing
From: Alex Williamson
[ Upstream commit 5c5866c593bbd444d0339ede6a8fb5f14ff66d72 ]
The next use of the device will generate an underflow from the
stale reference.
Cc: Qian Cai
Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx")
Reported-by: Daniel Wagner
Reviewed-by: Cornelia Huck
Tested-by: Daniel Wagner
Signed-off-by: Alex Williamson
Signed-off-by: Sasha Levin
---
drivers/vfio/pci/vfio_pci.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index c9c0af9a571f6..c08cff0ca08df 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -392,10 +392,14 @@ static void vfio_pci_release(void *device_data)
if (!(--vdev->refcnt)) {
vfio_spapr_pci_eeh_release(vdev->pdev);
vfio_pci_disable(vdev);
- if (vdev->err_trigger)
+ if (vdev->err_trigger) {
eventfd_ctx_put(vdev->err_trigger);
- if (vdev->req_trigger)
+ vdev->err_trigger = NULL;
+ }
+ if (vdev->req_trigger) {
eventfd_ctx_put(vdev->req_trigger);
+ vdev->req_trigger = NULL;
+ }
}
mutex_unlock(_lock);
--
2.25.1
[PATCH AUTOSEL 4.9 85/90] mtd: parser: cmdline: Support MTD names containing one or more colons
From: Boris Brezillon
[ Upstream commit eb13fa0227417e84aecc3bd9c029d376e33474d3 ]
Looks like some drivers define MTD names with a colon in it, thus
making mtdpart= parsing impossible. Let's fix the parser to gracefully
handle that case: the last ':' in a partition definition sequence is
considered instead of the first one.
Signed-off-by: Boris Brezillon
Signed-off-by: Ron Minnich
Tested-by: Ron Minnich
Signed-off-by: Richard Weinberger
Signed-off-by: Sasha Levin
---
drivers/mtd/cmdlinepart.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c
index fbd5affc0acfe..04fd845de05fb 100644
--- a/drivers/mtd/cmdlinepart.c
+++ b/drivers/mtd/cmdlinepart.c
@@ -228,12 +228,29 @@ static int mtdpart_setup_real(char *s)
struct cmdline_mtd_partition *this_mtd;
struct mtd_partition *parts;
int mtd_id_len, num_parts;
- char *p, *mtd_id;
+ char *p, *mtd_id, *semicol;
+
+ /*
+* Replace the first ';' by a NULL char so strrchr can work
+* properly.
+*/
+ semicol = strchr(s, ';');
+ if (semicol)
+ *semicol = '\0';
mtd_id = s;
- /* fetch */
- p = strchr(s, ':');
+ /*
+* fetch . We use strrchr to ignore all ':' that could
+* be present in the MTD name, only the last one is interpreted
+* as an / separator.
+*/
+ p = strrchr(s, ':');
+
+ /* Restore the ';' now. */
+ if (semicol)
+ *semicol = ';';
+
if (!p) {
pr_err("no mtd-id\n");
return -EINVAL;
--
2.25.1
[PATCH AUTOSEL 4.4 02/64] m68k: q40: Fix info-leak in rtc_ioctl
From: Fuqian Huang
[ Upstream commit 7cf78b6b12fd5550545e4b73b35dca18bd46b44c ]
When the option is RTC_PLL_GET, pll will be copied to userland
via copy_to_user. pll is initialized using mach_get_rtc_pll indirect
call and mach_get_rtc_pll is only assigned with function
q40_get_rtc_pll in arch/m68k/q40/config.c.
In function q40_get_rtc_pll, the field pll_ctrl is not initialized.
This will leak uninitialized stack content to userland.
Fix this by zeroing the uninitialized field.
Signed-off-by: Fuqian Huang
Link: https://lore.kernel.org/r/20190927121544.7650-1-huangfq.dax...@gmail.com
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Sasha Levin
---
arch/m68k/q40/config.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/q40/config.c b/arch/m68k/q40/config.c
index e90fe903613ea..4e5f04d333188 100644
--- a/arch/m68k/q40/config.c
+++ b/arch/m68k/q40/config.c
@@ -303,6 +303,7 @@ static int q40_get_rtc_pll(struct rtc_pll_info *pll)
{
int tmp = Q40_RTC_CTRL;
+ pll->pll_ctrl = 0;
pll->pll_value = tmp & Q40_RTC_PLL_MASK;
if (tmp & Q40_RTC_PLL_SIGN)
pll->pll_value = -pll->pll_value;
--
2.25.1
[PATCH AUTOSEL 4.9 82/90] perf kcore_copy: Fix module map when there are no modules loaded
From: Adrian Hunter
[ Upstream commit 61f82e3fb697a8e85f22fdec786528af73dc36d1 ]
In the absence of any modules, no "modules" map is created, but there
are other executable pages to map, due to eBPF JIT, kprobe or ftrace.
Map them by recognizing that the first "module" symbol is not
necessarily from a module, and adjust the map accordingly.
Signed-off-by: Adrian Hunter
Cc: Alexander Shishkin
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Jiri Olsa
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Peter Zijlstra
Cc: Steven Rostedt (VMware)
Cc: x...@kernel.org
Link: http://lore.kernel.org/lkml/20200512121922.8997-10-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/util/symbol-elf.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 5a50326c8158f..e155783c601ab 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1421,6 +1421,7 @@ struct kcore_copy_info {
u64 first_symbol;
u64 last_symbol;
u64 first_module;
+ u64 first_module_symbol;
u64 last_module_symbol;
struct phdr_data kernel_map;
struct phdr_data modules_map;
@@ -1435,6 +1436,8 @@ static int kcore_copy__process_kallsyms(void *arg, const
char *name, char type,
return 0;
if (strchr(name, '[')) {
+ if (!kci->first_module_symbol || start <
kci->first_module_symbol)
+ kci->first_module_symbol = start;
if (start > kci->last_module_symbol)
kci->last_module_symbol = start;
return 0;
@@ -1559,6 +1562,10 @@ static int kcore_copy__calc_maps(struct kcore_copy_info
*kci, const char *dir,
kci->etext += page_size;
}
+ if (kci->first_module_symbol &&
+ (!kci->first_module || kci->first_module_symbol <
kci->first_module))
+ kci->first_module = kci->first_module_symbol;
+
kci->first_module = round_down(kci->first_module, page_size);
if (kci->last_module_symbol) {
--
2.25.1
[PATCH AUTOSEL 4.4 03/64] gma/gma500: fix a memory disclosure bug due to uninitialized bytes
From: Kangjie Lu
[ Upstream commit 57a25a5f754ce27da2cfa6f413cfd366f878db76 ]
`best_clock` is an object that may be sent out. Object `clock`
contains uninitialized bytes that are copied to `best_clock`,
which leads to memory disclosure and information leak.
Signed-off-by: Kangjie Lu
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20191018042953.31099-1-k...@umn.edu
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 7d47b3d5cc0d0..54d554d720004 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -415,6 +415,8 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t
*limit,
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
struct gma_clock_t clock;
+ memset(, 0, sizeof(clock));
+
switch (refclk) {
case 27000:
if (target < 20) {
--
2.25.1
[PATCH AUTOSEL 4.9 84/90] ceph: fix potential race in ceph_check_caps
From: Jeff Layton
[ Upstream commit dc3da0461cc4b76f2d0c5b12247fcb3b520edbbf ]
Nothing ensures that session will still be valid by the time we
dereference the pointer. Take and put a reference.
In principle, we should always be able to get a reference here, but
throw a warning if that's ever not the case.
Signed-off-by: Jeff Layton
Signed-off-by: Ilya Dryomov
Signed-off-by: Sasha Levin
---
fs/ceph/caps.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index e11aacb35d6b5..cbd92dd89de16 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -1807,12 +1807,24 @@ ack:
if (mutex_trylock(>s_mutex) == 0) {
dout("inverting session/ino locks on %p\n",
session);
+ session = ceph_get_mds_session(session);
spin_unlock(>i_ceph_lock);
if (took_snap_rwsem) {
up_read(>snap_rwsem);
took_snap_rwsem = 0;
}
- mutex_lock(>s_mutex);
+ if (session) {
+ mutex_lock(>s_mutex);
+ ceph_put_mds_session(session);
+ } else {
+ /*
+* Because we take the reference while
+* holding the i_ceph_lock, it should
+* never be NULL. Throw a warning if it
+* ever is.
+*/
+ WARN_ON_ONCE(true);
+ }
goto retry;
}
}
--
2.25.1
[PATCH AUTOSEL 4.4 05/64] ata: sata_mv, avoid trigerrable BUG_ON
From: Jiri Slaby [ Upstream commit e9f691d899188679746eeb96e6cb520459eda9b4 ] There are several reports that the BUG_ON on unsupported command in mv_qc_prep can be triggered under some circumstances: https://bugzilla.suse.com/show_bug.cgi?id=1110252 https://serverfault.com/questions/97/raid-problems-after-power-outage https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652185 https://bugs.centos.org/view.php?id=14998 Let sata_mv handle the failure gracefully: warn about that incl. the failed command number and return an AC_ERR_INVALID error. We can do that now thanks to the previous patch. Remove also the long-standing FIXME. [v2] use %.2x as commands are defined as hexa. Signed-off-by: Jiri Slaby Cc: Jens Axboe Cc: linux-...@vger.kernel.org Cc: Sergei Shtylyov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- drivers/ata/sata_mv.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c index 729f26322095e..c24bbdb3f76c8 100644 --- a/drivers/ata/sata_mv.c +++ b/drivers/ata/sata_mv.c @@ -2113,12 +2113,10 @@ static void mv_qc_prep(struct ata_queued_cmd *qc) * non-NCQ mode are: [RW] STREAM DMA and W DMA FUA EXT, none * of which are defined/used by Linux. If we get here, this * driver needs work. -* -* FIXME: modify libata to give qc_prep a return value and -* return error here. */ - BUG_ON(tf->command); - break; + ata_port_err(ap, "%s: unsupported command: %.2x\n", __func__, + tf->command); + return AC_ERR_INVALID; } mv_crqb_pack_cmd(cw++, tf->nsect, ATA_REG_NSECT, 0); mv_crqb_pack_cmd(cw++, tf->hob_lbal, ATA_REG_LBAL, 0); -- 2.25.1
[PATCH AUTOSEL 4.4 08/64] mfd: mfd-core: Protect against NULL call-back function pointer
From: Lee Jones
[ Upstream commit b195e101580db390f50b0d587b7f66f241d2bc88 ]
If a child device calls mfd_cell_{en,dis}able() without an appropriate
call-back being set, we are likely to encounter a panic. Avoid this
by adding suitable checking.
Signed-off-by: Lee Jones
Reviewed-by: Daniel Thompson
Reviewed-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/mfd/mfd-core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 215bb5eeb5acf..c57e375fad6ed 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -31,6 +31,11 @@ int mfd_cell_enable(struct platform_device *pdev)
const struct mfd_cell *cell = mfd_get_cell(pdev);
int err = 0;
+ if (!cell->enable) {
+ dev_dbg(>dev, "No .enable() call-back registered\n");
+ return 0;
+ }
+
/* only call enable hook if the cell wasn't previously enabled */
if (atomic_inc_return(cell->usage_count) == 1)
err = cell->enable(pdev);
@@ -48,6 +53,11 @@ int mfd_cell_disable(struct platform_device *pdev)
const struct mfd_cell *cell = mfd_get_cell(pdev);
int err = 0;
+ if (!cell->disable) {
+ dev_dbg(>dev, "No .disable() call-back registered\n");
+ return 0;
+ }
+
/* only disable if no other clients are using it */
if (atomic_dec_return(cell->usage_count) == 0)
err = cell->disable(pdev);
--
2.25.1
Re: [PATCH 0/2] Update CascadelakeX and SkylakeX events list
Hi Ian, On 9/18/2020 9:36 AM, Ian Rogers wrote: On Thu, Sep 17, 2020, 6:21 PM Jin, Yao wrote: Hi Arnaldo, On 9/7/2020 4:01 PM, Jin, Yao wrote: Hi Arnaldo, On 7/17/2020 2:06 PM, Jin, Yao wrote: Hi, On 6/17/2020 3:38 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Jun 16, 2020 at 02:27:40PM +0800, Jin, Yao escreveu: On 6/16/2020 2:16 PM, Ian Rogers wrote: On Mon, Jun 15, 2020 at 6:00 PM Jin, Yao wrote: Can I get an ACK for this patchset? On 6/3/2020 10:18 AM, Jin Yao wrote: This patchset updates CascadelakeX events to v1.08 and updates SkylakeX events to v1.21. The events have been tested on CascadelakeX and SkylakeX servers with latest perf/core branch. could you rebase this on Arnaldo's tmp.perf/core tree? https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=tmp.perf/core I tried using git am but get: Applying: perf vendor events: Update CascadelakeX events to v1.08 error: patch fragment without header at line 279: @@ -213,14 +220,14 @@ error: could not build fake ancestor Patch failed at 0001 perf vendor events: Update CascadelakeX events to v1.08 Thanks, Ian The patchset are applied OK on perf/core branch. As far as I understand, the patch for posting should be based on perf/core branch, is it right? Sorry, I've been testing with using tmp.perf/core as a way to more quickly make available what I've processed, before I test it thoroughly both with container builds and with manual testing, so the bleeding edge is there, perf/core becoming a bit more stable, as I'll try not to rebase it like before. - Arnaldo Can this event update be accepted? Thanks Jin Yao Can this event list update be accepted? Thanks Jin Yao Ping again. :) Can this event update patchset be accepted? @Ian, I remembered you had tried this patchset and it's OK right? The previous patch didn't apply cleanly. I tested what I had and it solved a problem with metrics derived from recent the most recent tma metrics - which is great! I will retest with the latest patch. This patchset can be applied on perf/core. I double checked with the latest perf/core branch. Did you have a chance to look at the skylake parallel reads metric? The arb thresh modifier isn't present. There are issues with other metrics where the units are scaled twice. Have these been resolved? I will look at the SKL/KBL desktop metric issues. If it needs, I will post another patchset for desktop event update. Thanks Jin Yao Thanks! Ian Thanks Jin Yao
[PATCH AUTOSEL 4.4 04/64] ASoC: kirkwood: fix IRQ error handling
From: Russell King [ Upstream commit 175fc928198236037174e5c5c066fe3c4691903e ] Propagate the error code from request_irq(), rather than returning -EBUSY. Signed-off-by: Russell King Link: https://lore.kernel.org/r/e1iniqh-tw...@rmk-pc.armlinux.org.uk Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- sound/soc/kirkwood/kirkwood-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/kirkwood/kirkwood-dma.c b/sound/soc/kirkwood/kirkwood-dma.c index dbfdfe99c69df..231c7d97333c7 100644 --- a/sound/soc/kirkwood/kirkwood-dma.c +++ b/sound/soc/kirkwood/kirkwood-dma.c @@ -136,7 +136,7 @@ static int kirkwood_dma_open(struct snd_pcm_substream *substream) err = request_irq(priv->irq, kirkwood_dma_irq, IRQF_SHARED, "kirkwood-i2s", priv); if (err) - return -EBUSY; + return err; /* * Enable Error interrupts. We're only ack'ing them but -- 2.25.1
[PATCH AUTOSEL 4.4 17/64] tracing: Set kernel_stack's caller size properly
From: Josef Bacik
[ Upstream commit cbc3b92ce037f5e7536f6db157d185cd8b8f615c ]
I noticed when trying to use the trace-cmd python interface that reading the raw
buffer wasn't working for kernel_stack events. This is because it uses a
stubbed version of __dynamic_array that doesn't do the __data_loc trick and
encode the length of the array into the field. Instead it just shows up as a
size of 0. So change this to __array and set the len to FTRACE_STACK_ENTRIES
since this is what we actually do in practice and matches how user_stack_trace
works.
Link: http://lkml.kernel.org/r/1411589652-1318-1-git-send-email-jba...@fb.com
Signed-off-by: Josef Bacik
[ Pulled from the archeological digging of my INBOX ]
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Sasha Levin
---
kernel/trace/trace_entries.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_entries.h b/kernel/trace/trace_entries.h
index ee7b94a4810af..246db27dbdc99 100644
--- a/kernel/trace/trace_entries.h
+++ b/kernel/trace/trace_entries.h
@@ -178,7 +178,7 @@ FTRACE_ENTRY(kernel_stack, stack_entry,
F_STRUCT(
__field(int,size)
- __dynamic_array(unsigned long, caller )
+ __array(unsigned long, caller, FTRACE_STACK_ENTRIES
)
),
F_printk("\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n"
--
2.25.1
[PATCH AUTOSEL 4.4 13/64] neigh_stat_seq_next() should increase position index
From: Vasily Averin [ Upstream commit 1e3f9f073c47bee7c23e77316b07bc12338c5bba ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- net/core/neighbour.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 9849f1f4cf4f7..40d33431bc585 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -2798,6 +2798,7 @@ static void *neigh_stat_seq_next(struct seq_file *seq, void *v, loff_t *pos) *pos = cpu+1; return per_cpu_ptr(tbl->stats, cpu); } + (*pos)++; return NULL; } -- 2.25.1
[PATCH AUTOSEL 4.4 12/64] kernel/sys.c: avoid copying possible padding bytes in copy_to_user
From: Joe Perches
[ Upstream commit 5e1aada08cd19ea652b2d32a250501d09b02ff2e ]
Initialization is not guaranteed to zero padding bytes so use an
explicit memset instead to avoid leaking any kernel content in any
possible padding bytes.
Link:
http://lkml.kernel.org/r/dfa331c00881d61c8ee51577a082d8bebd61805c.ca...@perches.com
Signed-off-by: Joe Perches
Cc: Dan Carpenter
Cc: Julia Lawall
Cc: Thomas Gleixner
Cc: Kees Cook
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
kernel/sys.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index 1855f1bf113e4..e98664039cb23 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1183,11 +1183,13 @@ SYSCALL_DEFINE1(uname, struct old_utsname __user *,
name)
SYSCALL_DEFINE1(olduname, struct oldold_utsname __user *, name)
{
- struct oldold_utsname tmp = {};
+ struct oldold_utsname tmp;
if (!name)
return -EFAULT;
+ memset(, 0, sizeof(tmp));
+
down_read(_sem);
memcpy(, ()->sysname, __OLD_UTS_LEN);
memcpy(, ()->nodename, __OLD_UTS_LEN);
--
2.25.1
[PATCH AUTOSEL 4.4 10/64] bcache: fix a lost wake-up problem caused by mca_cannibalize_lock
From: Guoju Fang
[ Upstream commit 34cf78bf34d48dfeeadb44f9841d7864997a ]
This patch fix a lost wake-up problem caused by the race between
mca_cannibalize_lock and bch_cannibalize_unlock.
Consider two processes, A and B. Process A is executing
mca_cannibalize_lock, while process B takes c->btree_cache_alloc_lock
and is executing bch_cannibalize_unlock. The problem happens that after
process A executes cmpxchg and will execute prepare_to_wait. In this
timeslice process B executes wake_up, but after that process A executes
prepare_to_wait and set the state to TASK_INTERRUPTIBLE. Then process A
goes to sleep but no one will wake up it. This problem may cause bcache
device to dead.
Signed-off-by: Guoju Fang
Signed-off-by: Coly Li
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
drivers/md/bcache/bcache.h | 1 +
drivers/md/bcache/btree.c | 12
drivers/md/bcache/super.c | 1 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
index 7fe7df56fa334..f0939fc1cfe55 100644
--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -547,6 +547,7 @@ struct cache_set {
*/
wait_queue_head_t btree_cache_wait;
struct task_struct *btree_cache_alloc_lock;
+ spinlock_t btree_cannibalize_lock;
/*
* When we free a btree node, we increment the gen of the bucket the
diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
index 122d975220945..bdf6071c1b184 100644
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -841,15 +841,17 @@ out:
static int mca_cannibalize_lock(struct cache_set *c, struct btree_op *op)
{
- struct task_struct *old;
-
- old = cmpxchg(>btree_cache_alloc_lock, NULL, current);
- if (old && old != current) {
+ spin_lock(>btree_cannibalize_lock);
+ if (likely(c->btree_cache_alloc_lock == NULL)) {
+ c->btree_cache_alloc_lock = current;
+ } else if (c->btree_cache_alloc_lock != current) {
if (op)
prepare_to_wait(>btree_cache_wait, >wait,
TASK_UNINTERRUPTIBLE);
+ spin_unlock(>btree_cannibalize_lock);
return -EINTR;
}
+ spin_unlock(>btree_cannibalize_lock);
return 0;
}
@@ -884,10 +886,12 @@ static struct btree *mca_cannibalize(struct cache_set *c,
struct btree_op *op,
*/
static void bch_cannibalize_unlock(struct cache_set *c)
{
+ spin_lock(>btree_cannibalize_lock);
if (c->btree_cache_alloc_lock == current) {
c->btree_cache_alloc_lock = NULL;
wake_up(>btree_cache_wait);
}
+ spin_unlock(>btree_cannibalize_lock);
}
static struct btree *mca_alloc(struct cache_set *c, struct btree_op *op,
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index f7f8fb079d2a9..d73f9ea776861 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1511,6 +1511,7 @@ struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
sema_init(>sb_write_mutex, 1);
mutex_init(>bucket_lock);
init_waitqueue_head(>btree_cache_wait);
+ spin_lock_init(>btree_cannibalize_lock);
init_waitqueue_head(>bucket_wait);
init_waitqueue_head(>gc_wait);
sema_init(>uuid_write_mutex, 1);
--
2.25.1
[PATCH AUTOSEL 4.4 18/64] ext4: make dioread_nolock the default
From: Theodore Ts'o
[ Upstream commit 244adf6426ee31a83f397b700d964cff12a247d3 ]
This fixes the direct I/O versus writeback race which can reveal stale
data, and it improves the tail latency of commits on slow devices.
Link: https://lore.kernel.org/r/20200125022254.1101588-1-ty...@mit.edu
Signed-off-by: Theodore Ts'o
Signed-off-by: Sasha Levin
---
fs/ext4/super.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index aca086a25b2ef..5a623ea954882 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1251,6 +1251,7 @@ static const match_table_t tokens = {
{Opt_auto_da_alloc, "auto_da_alloc"},
{Opt_noauto_da_alloc, "noauto_da_alloc"},
{Opt_dioread_nolock, "dioread_nolock"},
+ {Opt_dioread_lock, "nodioread_nolock"},
{Opt_dioread_lock, "dioread_lock"},
{Opt_discard, "discard"},
{Opt_nodiscard, "nodiscard"},
@@ -3380,6 +3381,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
set_opt(sb, NO_UID32);
/* xattr user namespace & acls are now defaulted on */
set_opt(sb, XATTR_USER);
+ set_opt(sb, DIOREAD_NOLOCK);
#ifdef CONFIG_EXT4_FS_POSIX_ACL
set_opt(sb, POSIX_ACL);
#endif
@@ -3448,9 +3450,8 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
goto failed_mount;
if (test_opt(sb, DATA_FLAGS) == EXT4_MOUNT_JOURNAL_DATA) {
- printk_once(KERN_WARNING "EXT4-fs: Warning: mounting "
- "with data=journal disables delayed "
- "allocation and O_DIRECT support!\n");
+ printk_once(KERN_WARNING "EXT4-fs: Warning: mounting with
data=journal disables delayed allocation, dioread_nolock, and O_DIRECT
support!\n");
+ clear_opt(sb, DIOREAD_NOLOCK);
if (test_opt2(sb, EXPLICIT_DELALLOC)) {
ext4_msg(sb, KERN_ERR, "can't mount with "
"both data=journal and delalloc");
--
2.25.1
[PATCH AUTOSEL 4.4 15/64] seqlock: Require WRITE_ONCE surrounding raw_seqcount_barrier
From: Marco Elver
[ Upstream commit bf07132f96d426bcbf2098227fb680915cf44498 ]
This patch proposes to require marked atomic accesses surrounding
raw_write_seqcount_barrier. We reason that otherwise there is no way to
guarantee propagation nor atomicity of writes before/after the barrier
[1]. For example, consider the compiler tears stores either before or
after the barrier; in this case, readers may observe a partial value,
and because readers are unaware that writes are going on (writes are not
in a seq-writer critical section), will complete the seq-reader critical
section while having observed some partial state.
[1] https://lwn.net/Articles/793253/
This came up when designing and implementing KCSAN, because KCSAN would
flag these accesses as data-races. After careful analysis, our reasoning
as above led us to conclude that the best thing to do is to propose an
amendment to the raw_seqcount_barrier usage.
Signed-off-by: Marco Elver
Acked-by: Paul E. McKenney
Signed-off-by: Paul E. McKenney
Signed-off-by: Sasha Levin
---
include/linux/seqlock.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index e0582106ef4fa..a10f363784178 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -242,6 +242,13 @@ static inline void raw_write_seqcount_end(seqcount_t *s)
* usual consistency guarantee. It is one wmb cheaper, because we can
* collapse the two back-to-back wmb()s.
*
+ * Note that, writes surrounding the barrier should be declared atomic (e.g.
+ * via WRITE_ONCE): a) to ensure the writes become visible to other threads
+ * atomically, avoiding compiler optimizations; b) to document which writes are
+ * meant to propagate to the reader critical section. This is necessary because
+ * neither writes before and after the barrier are enclosed in a seq-writer
+ * critical section that would ensure readers are aware of ongoing writes.
+ *
* seqcount_t seq;
* bool X = true, Y = false;
*
@@ -261,11 +268,11 @@ static inline void raw_write_seqcount_end(seqcount_t *s)
*
* void write(void)
* {
- * Y = true;
+ * WRITE_ONCE(Y, true);
*
* raw_write_seqcount_barrier(seq);
*
- * X = false;
+ * WRITE_ONCE(X, false);
* }
*/
static inline void raw_write_seqcount_barrier(seqcount_t *s)
--
2.25.1
[PATCH AUTOSEL 4.4 09/64] tracing: Adding NULL checks for trace_array descriptor pointer
From: Divya Indi
[ Upstream commit 953ae45a0c25e09428d4a03d7654f97ab8a36647 ]
As part of commit f45d1225adb0 ("tracing: Kernel access to Ftrace
instances") we exported certain functions. Here, we are adding some additional
NULL checks to ensure safe usage by users of these APIs.
Link:
http://lkml.kernel.org/r/1565805327-579-4-git-send-email-divya.i...@oracle.com
Signed-off-by: Divya Indi
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Sasha Levin
---
kernel/trace/trace.c| 3 +++
kernel/trace/trace_events.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 06efd18bf3e38..17ea5f9d36b48 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2271,6 +2271,9 @@ int trace_array_printk(struct trace_array *tr,
if (!(global_trace.trace_flags & TRACE_ITER_PRINTK))
return 0;
+ if (!tr)
+ return -ENOENT;
+
va_start(ap, fmt);
ret = trace_array_vprintk(tr, ip, fmt, ap);
va_end(ap);
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index bd4c0bb61ad72..9d6e755d17546 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -755,6 +755,8 @@ static int ftrace_set_clr_event(struct trace_array *tr,
char *buf, int set)
char *event = NULL, *sub = NULL, *match;
int ret;
+ if (!tr)
+ return -ENOENT;
/*
* The buf format can be :
* *: means any event by that name.
--
2.25.1
Re: [PATCH v2 -next] vdpa: mlx5: change Kconfig depends to fix build errors
On 2020/9/18 上午3:45, Randy Dunlap wrote: From: Randy Dunlap drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so add a dependency on VHOST to eliminate build errors. ld: drivers/vdpa/mlx5/core/mr.o: in function `add_direct_chain': mr.c:(.text+0x106): undefined reference to `vhost_iotlb_itree_first' ld: mr.c:(.text+0x1cf): undefined reference to `vhost_iotlb_itree_next' ld: mr.c:(.text+0x30d): undefined reference to `vhost_iotlb_itree_first' ld: mr.c:(.text+0x3e8): undefined reference to `vhost_iotlb_itree_next' ld: drivers/vdpa/mlx5/core/mr.o: in function `_mlx5_vdpa_create_mr': mr.c:(.text+0x908): undefined reference to `vhost_iotlb_itree_first' ld: mr.c:(.text+0x9e6): undefined reference to `vhost_iotlb_itree_next' ld: drivers/vdpa/mlx5/core/mr.o: in function `mlx5_vdpa_handle_set_map': mr.c:(.text+0xf1d): undefined reference to `vhost_iotlb_itree_first' Signed-off-by: Randy Dunlap Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: virtualizat...@lists.linux-foundation.org Cc: Saeed Mahameed Cc: Leon Romanovsky Cc: net...@vger.kernel.org --- v2: change from select to depends (Saeed) drivers/vdpa/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200917.orig/drivers/vdpa/Kconfig +++ linux-next-20200917/drivers/vdpa/Kconfig @@ -31,7 +31,7 @@ config IFCVF config MLX5_VDPA bool "MLX5 VDPA support library for ConnectX devices" - depends on MLX5_CORE + depends on VHOST && MLX5_CORE It looks to me that depending on VHOST is too heavyweight. I guess what it really needs is VHOST_IOTLB. So we can use select VHOST_IOTLB here. Thanks default n help Support library for Mellanox VDPA drivers. Provides code that is
[PATCH AUTOSEL 4.4 21/64] mm: pagewalk: fix termination condition in walk_pte_range()
From: Steven Price [ Upstream commit c02a98753e0a36ba65a05818626fa6adeb4e7c97 ] If walk_pte_range() is called with a 'end' argument that is beyond the last page of memory (e.g. ~0UL) then the comparison between 'addr' and 'end' will always fail and the loop will be infinite. Instead change the comparison to >= while accounting for overflow. Link: http://lkml.kernel.org/r/20191218162402.45610-15-steven.pr...@arm.com Signed-off-by: Steven Price Cc: Albert Ou Cc: Alexandre Ghiti Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: Benjamin Herrenschmidt Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christian Borntraeger Cc: Dave Hansen Cc: David S. Miller Cc: Heiko Carstens Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: James Hogan Cc: James Morse Cc: Jerome Glisse Cc: "Liang, Kan" Cc: Mark Rutland Cc: Michael Ellerman Cc: Paul Burton Cc: Paul Mackerras Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Ralf Baechle Cc: Russell King Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Vineet Gupta Cc: Will Deacon Cc: Zong Li Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- mm/pagewalk.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/pagewalk.c b/mm/pagewalk.c index c2cbd26201696..a024667a9c041 100644 --- a/mm/pagewalk.c +++ b/mm/pagewalk.c @@ -14,9 +14,9 @@ static int walk_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, err = walk->pte_entry(pte, addr, addr + PAGE_SIZE, walk); if (err) break; - addr += PAGE_SIZE; - if (addr == end) + if (addr >= end - PAGE_SIZE) break; + addr += PAGE_SIZE; pte++; } -- 2.25.1
[PATCH AUTOSEL 4.4 16/64] ACPI: EC: Reference count query handlers under lock
From: "Rafael J. Wysocki"
[ Upstream commit 3df663a147fe077a6ee8444ec626738946e65547 ]
There is a race condition in acpi_ec_get_query_handler()
theoretically allowing query handlers to go away before refernce
counting them.
In order to avoid it, call kref_get() on query handlers under
ec->mutex.
Also simplify the code a bit while at it.
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
---
drivers/acpi/ec.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 43f20328f830e..3096c087b7328 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -943,29 +943,21 @@ void acpi_ec_unblock_transactions_early(void)
/* --
Event Management
--
*/
-static struct acpi_ec_query_handler *
-acpi_ec_get_query_handler(struct acpi_ec_query_handler *handler)
-{
- if (handler)
- kref_get(>kref);
- return handler;
-}
-
static struct acpi_ec_query_handler *
acpi_ec_get_query_handler_by_value(struct acpi_ec *ec, u8 value)
{
struct acpi_ec_query_handler *handler;
- bool found = false;
mutex_lock(>mutex);
list_for_each_entry(handler, >list, node) {
if (value == handler->query_bit) {
- found = true;
- break;
+ kref_get(>kref);
+ mutex_unlock(>mutex);
+ return handler;
}
}
mutex_unlock(>mutex);
- return found ? acpi_ec_get_query_handler(handler) : NULL;
+ return NULL;
}
static void acpi_ec_query_handler_release(struct kref *kref)
--
2.25.1
[PATCH AUTOSEL 4.4 11/64] xfs: fix attr leaf header freemap.size underflow
From: Brian Foster
[ Upstream commit 2a2b5932db67586bacc560cc065d62faece5b996 ]
The leaf format xattr addition helper xfs_attr3_leaf_add_work()
adjusts the block freemap in a couple places. The first update drops
the size of the freemap that the caller had already selected to
place the xattr name/value data. Before the function returns, it
also checks whether the entries array has encroached on a freemap
range by virtue of the new entry addition. This is necessary because
the entries array grows from the start of the block (but end of the
block header) towards the end of the block while the name/value data
grows from the end of the block in the opposite direction. If the
associated freemap is already empty, however, size is zero and the
subtraction underflows the field and causes corruption.
This is reproduced rarely by generic/070. The observed behavior is
that a smaller sized freemap is aligned to the end of the entries
list, several subsequent xattr additions land in larger freemaps and
the entries list expands into the smaller freemap until it is fully
consumed and then underflows. Note that it is not otherwise a
corruption for the entries array to consume an empty freemap because
the nameval list (i.e. the firstused pointer in the xattr header)
starts beyond the end of the corrupted freemap.
Update the freemap size modification to account for the fact that
the freemap entry can be empty and thus stale.
Signed-off-by: Brian Foster
Reviewed-by: Darrick J. Wong
Signed-off-by: Darrick J. Wong
Signed-off-by: Sasha Levin
---
fs/xfs/libxfs/xfs_attr_leaf.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c
index 445a3f2f871fb..d50f8183dda46 100644
--- a/fs/xfs/libxfs/xfs_attr_leaf.c
+++ b/fs/xfs/libxfs/xfs_attr_leaf.c
@@ -1326,7 +1326,9 @@ xfs_attr3_leaf_add_work(
for (i = 0; i < XFS_ATTR_LEAF_MAPSIZE; i++) {
if (ichdr->freemap[i].base == tmp) {
ichdr->freemap[i].base += sizeof(xfs_attr_leaf_entry_t);
- ichdr->freemap[i].size -= sizeof(xfs_attr_leaf_entry_t);
+ ichdr->freemap[i].size -=
+ min_t(uint16_t, ichdr->freemap[i].size,
+ sizeof(xfs_attr_leaf_entry_t));
}
}
ichdr->usedbytes += xfs_attr_leaf_entsize(leaf, args->index);
--
2.25.1
[PATCH AUTOSEL 4.4 30/64] Bluetooth: guard against controllers sending zero'd events
From: Alain Michaud
[ Upstream commit 08bb4da90150e2a225f35e0f642cdc463958d696 ]
Some controllers have been observed to send zero'd events under some
conditions. This change guards against this condition as well as adding
a trace to facilitate diagnosability of this condition.
Signed-off-by: Alain Michaud
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
---
net/bluetooth/hci_event.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 16cf5633eae3e..04c77747a768d 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -5230,6 +5230,11 @@ void hci_event_packet(struct hci_dev *hdev, struct
sk_buff *skb)
u8 status = 0, event = hdr->evt, req_evt = 0;
u16 opcode = HCI_OP_NOP;
+ if (!event) {
+ bt_dev_warn(hdev, "Received unexpected HCI Event ");
+ goto done;
+ }
+
if (hdev->sent_cmd && bt_cb(hdev->sent_cmd)->hci.req_event == event) {
struct hci_command_hdr *cmd_hdr = (void *) hdev->sent_cmd->data;
opcode = __le16_to_cpu(cmd_hdr->opcode);
@@ -5441,6 +5446,7 @@ void hci_event_packet(struct hci_dev *hdev, struct
sk_buff *skb)
req_complete_skb(hdev, status, opcode, orig_skb);
}
+done:
kfree_skb(orig_skb);
kfree_skb(skb);
hdev->stat.evt_rx++;
--
2.25.1
[PATCH AUTOSEL 4.4 29/64] media: go7007: Fix URB type for interrupt handling
From: Takashi Iwai
[ Upstream commit a3ea410cac41b19a5490aad7fe6d9a9a772e646e ]
Josef reported that his old-and-good Plextor ConvertX M402U video
converter spews lots of WARNINGs on the recent kernels, and it turned
out that the device uses a bulk endpoint for interrupt handling just
like 2250 board.
For fixing it, generalize the check with the proper verification of
the endpoint instead of hard-coded board type check.
Fixes: 7e5219d18e93 ("[media] go7007: Fix 2250 urb type")
Reported-and-tested-by: Josef Möllers
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1162583
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206427
Signed-off-by: Takashi Iwai
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/usb/go7007/go7007-usb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/go7007/go7007-usb.c
b/drivers/media/usb/go7007/go7007-usb.c
index 4857c467e76cd..4490786936a02 100644
--- a/drivers/media/usb/go7007/go7007-usb.c
+++ b/drivers/media/usb/go7007/go7007-usb.c
@@ -1052,6 +1052,7 @@ static int go7007_usb_probe(struct usb_interface *intf,
struct go7007_usb *usb;
const struct go7007_usb_board *board;
struct usb_device *usbdev = interface_to_usbdev(intf);
+ struct usb_host_endpoint *ep;
unsigned num_i2c_devs;
char *name;
int video_pipe, i, v_urb_len;
@@ -1147,7 +1148,8 @@ static int go7007_usb_probe(struct usb_interface *intf,
if (usb->intr_urb->transfer_buffer == NULL)
goto allocfail;
- if (go->board_id == GO7007_BOARDID_SENSORAY_2250)
+ ep = usb->usbdev->ep_in[4];
+ if (usb_endpoint_type(>desc) == USB_ENDPOINT_XFER_BULK)
usb_fill_bulk_urb(usb->intr_urb, usb->usbdev,
usb_rcvbulkpipe(usb->usbdev, 4),
usb->intr_urb->transfer_buffer, 2*sizeof(u16),
--
2.25.1
[PATCH AUTOSEL 4.4 22/64] Bluetooth: prefetch channel before killing sock
From: Hillf Danton
[ Upstream commit 2a154903cec20fb64ff4d7d617ca53c16f8fd53a ]
Prefetch channel before killing sock in order to fix UAF like
BUG: KASAN: use-after-free in l2cap_sock_release+0x24c/0x290
net/bluetooth/l2cap_sock.c:1212
Read of size 8 at addr 8880944904a0 by task syz-fuzzer/9751
Reported-by: syzbot+c3c5bdea786388611...@syzkaller.appspotmail.com
Fixes: 6c08fc896b60 ("Bluetooth: Fix refcount use-after-free issue")
Cc: Manish Mandlik
Signed-off-by: Hillf Danton
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
---
net/bluetooth/l2cap_sock.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index cb024c25530a3..e562385d9440e 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1189,6 +1189,7 @@ static int l2cap_sock_release(struct socket *sock)
{
struct sock *sk = sock->sk;
int err;
+ struct l2cap_chan *chan;
BT_DBG("sock %p, sk %p", sock, sk);
@@ -1198,15 +1199,16 @@ static int l2cap_sock_release(struct socket *sock)
bt_sock_unlink(_sk_list, sk);
err = l2cap_sock_shutdown(sock, 2);
+ chan = l2cap_pi(sk)->chan;
- l2cap_chan_hold(l2cap_pi(sk)->chan);
- l2cap_chan_lock(l2cap_pi(sk)->chan);
+ l2cap_chan_hold(chan);
+ l2cap_chan_lock(chan);
sock_orphan(sk);
l2cap_sock_kill(sk);
- l2cap_chan_unlock(l2cap_pi(sk)->chan);
- l2cap_chan_put(l2cap_pi(sk)->chan);
+ l2cap_chan_unlock(chan);
+ l2cap_chan_put(chan);
return err;
}
--
2.25.1
[PATCH AUTOSEL 4.4 28/64] dmaengine: tegra-apb: Prevent race conditions on channel's freeing
From: Dmitry Osipenko [ Upstream commit 8e84172e372bdca20c305d92d51d33640d2da431 ] It's incorrect to check the channel's "busy" state without taking a lock. That shouldn't cause any real troubles, nevertheless it's always better not to have any race conditions in the code. Signed-off-by: Dmitry Osipenko Acked-by: Jon Hunter Link: https://lore.kernel.org/r/20200209163356.6439-5-dig...@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin --- drivers/dma/tegra20-apb-dma.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c index b5cf5d36de2b4..68c460a2b16ea 100644 --- a/drivers/dma/tegra20-apb-dma.c +++ b/drivers/dma/tegra20-apb-dma.c @@ -1207,8 +1207,7 @@ static void tegra_dma_free_chan_resources(struct dma_chan *dc) dev_dbg(tdc2dev(tdc), "Freeing channel %d\n", tdc->id); - if (tdc->busy) - tegra_dma_terminate_all(dc); + tegra_dma_terminate_all(dc); spin_lock_irqsave(>lock, flags); list_splice_init(>pending_sg_req, _req_list); -- 2.25.1
[PATCH AUTOSEL 4.4 27/64] drm/omap: fix possible object reference leak
From: Wen Yang [ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ] The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang Reviewed-by: Laurent Pinchart Reviewed-by: Mukesh Ojha Cc: Tomi Valkeinen Cc: David Airlie Cc: Daniel Vetter Cc: Sebastian Reichel Cc: Laurent Pinchart Cc: dri-de...@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: Markus Elfring Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yan...@zte.com.cn Signed-off-by: Sasha Levin --- drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c index 8b6f6d5fdd68b..43186fa8a13c9 100644 --- a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c +++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c @@ -194,7 +194,7 @@ static int __init omapdss_boot_init(void) dss = of_find_matching_node(NULL, omapdss_of_match); if (dss == NULL || !of_device_is_available(dss)) - return 0; + goto put_node; omapdss_walk_device(dss, true); @@ -221,6 +221,8 @@ static int __init omapdss_boot_init(void) kfree(n); } +put_node: + of_node_put(dss); return 0; } -- 2.25.1
[PATCH AUTOSEL 4.4 31/64] drm/amdgpu: increase atombios cmd timeout
From: John Clements
[ Upstream commit 1b3460a8b19688ad3033b75237d40fa580a5a953 ]
mitigates race condition on BACO reset between GPU bootcode and driver reload
Reviewed-by: Hawking Zhang
Signed-off-by: John Clements
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 1b50e6c13fb3f..5fbf99d600587 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -748,8 +748,8 @@ static void atom_op_jump(atom_exec_context *ctx, int *ptr,
int arg)
cjiffies = jiffies;
if (time_after(cjiffies, ctx->last_jump_jiffies)) {
cjiffies -= ctx->last_jump_jiffies;
- if ((jiffies_to_msecs(cjiffies) > 5000)) {
- DRM_ERROR("atombios stuck in loop for
more than 5secs aborting\n");
+ if ((jiffies_to_msecs(cjiffies) > 1)) {
+ DRM_ERROR("atombios stuck in loop for
more than 10secs aborting\n");
ctx->abort = true;
}
} else {
--
2.25.1
[PATCH AUTOSEL 4.4 33/64] media: tda10071: fix unsigned sign extension overflow
From: Colin Ian King
[ Upstream commit a7463e2dc698075132de9905b89f495df888bb79 ]
The shifting of buf[3] by 24 bits to the left will be promoted to
a 32 bit signed int and then sign-extended to an unsigned long. In
the unlikely event that the the top bit of buf[3] is set then all
then all the upper bits end up as also being set because of
the sign-extension and this affect the ev->post_bit_error sum.
Fix this by using the temporary u32 variable bit_error to avoid
the sign-extension promotion. This also removes the need to do the
computation twice.
Addresses-Coverity: ("Unintended sign extension")
Fixes: 267897a4708f ("[media] tda10071: implement DVBv5 statistics")
Signed-off-by: Colin Ian King
Signed-off-by: Sean Young
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/dvb-frontends/tda10071.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-frontends/tda10071.c
b/drivers/media/dvb-frontends/tda10071.c
index 119d47596ac81..b81887c4f72a9 100644
--- a/drivers/media/dvb-frontends/tda10071.c
+++ b/drivers/media/dvb-frontends/tda10071.c
@@ -483,10 +483,11 @@ static int tda10071_read_status(struct dvb_frontend *fe,
enum fe_status *status)
goto error;
if (dev->delivery_system == SYS_DVBS) {
- dev->dvbv3_ber = buf[0] << 24 | buf[1] << 16 |
-buf[2] << 8 | buf[3] << 0;
- dev->post_bit_error += buf[0] << 24 | buf[1] << 16 |
- buf[2] << 8 | buf[3] << 0;
+ u32 bit_error = buf[0] << 24 | buf[1] << 16 |
+ buf[2] << 8 | buf[3] << 0;
+
+ dev->dvbv3_ber = bit_error;
+ dev->post_bit_error += bit_error;
c->post_bit_error.stat[0].scale = FE_SCALE_COUNTER;
c->post_bit_error.stat[0].uvalue = dev->post_bit_error;
dev->block_error += buf[4] << 8 | buf[5] << 0;
--
2.25.1
Re: [linux-next PATCH] rapidio: Fix error handling path
On Thu, Sep 17, 2020 at 11:17 PM John Hubbard wrote: > > On 9/17/20 10:34 AM, Ira Weiny wrote: > > On Thu, Sep 17, 2020 at 03:39:51PM +0300, Dan Carpenter wrote: > >> On Wed, Sep 16, 2020 at 01:02:32PM +0300, Dan Carpenter wrote: > >>> On Wed, Sep 16, 2020 at 09:12:17AM +0530, Souptick Joarder wrote: > There is an error when pin_user_pages_fast() returns -ERRNO and > inside error handling path driver end up calling unpin_user_pages() > with -ERRNO which is not correct. > > This patch will fix the problem. > >>> > >>> There are a few ways we could prevent bug in the future. > >>> > >>> 1) This could have been caught with existing static analysis tools > >>> which warn about when a value is set but not used. > >>> > >>> 2) I've created a Smatch check which warngs about: > >>> > >>> drivers/rapidio/devices/rio_mport_cdev.c:955 rio_dma_transfer() warn: > >>> unpinning negative pages 'nr_pages' > >>> > >>> I'll test it out tonight and see how well it works. I don't > >>> immediately see any other bugs allthough Smatch doesn't like the code > >>> in siw_umem_release(). It uses "min_t(int" which suggests that > >>> negative pages are okay. > >>> > >>>int to_free = min_t(int, PAGES_PER_CHUNK, num_pages); > >>> > >> > >> I only found one bug but I'm going to add unpin_user_pages_dirty_lock() > >> to the mix a retest. There were a few other false positives. In > >> reviewing the code, I noticed that orangefs_bufmap_map() is also buggy. > >> > >> I sort of feel like returning partial successes is not working. We > >> could easily make a wrapper which either pins everything or it returns > >> an error code. > > Yes we could. And I have the same feeling about this API. It's generated a > remarkable amount of bug fixes, several of which ended up being partial or > wrong in themselves. And mostly this is due to the complicated tristate > return code: instead of 0 or -ERRNO, it also can return "N pages that is > less than what you requested", and there are no standard helpers in the kernel > to make that easier to deal with There was some discussion on removing return value 0 from one of the gup variants [1]. I think it might be partially relevant to the current discussion. [1] https://patchwork.kernel.org/patch/11529795/ > > > > > I guess the question is are there drivers which will keep working (or limp > > along?) on partial pins? A quick search of a driver I thought did this does > > not apparently any more... So it sounds good to me from 30,000 feet! :-D > > It sounds good to me too--and from just a *few hundred feet* (having touched > most > of the call sites at some point)! haha :) > > I think the wrapper should be short-term, though, just until all the callers > are converted to the simpler API. Then change the core gup/pup calls to the > simpler > API. There are more than enough gup/pup API entry points as it is, that's for > sure. > > > thanks, > -- > John Hubbard > NVIDIA
[PATCH AUTOSEL 4.4 26/64] scsi: lpfc: Fix RQ buffer leakage when no IOCBs available
From: James Smart [ Upstream commit 39c4f1a965a9244c3ba60695e8ff8da065ec6ac4 ] The driver is occasionally seeing the following SLI Port error, requiring reset and reinit: Port Status Event: ... error 1=0x52004a01, error 2=0x218 The failure means an RQ timeout. That is, the adapter had received asynchronous receive frames, ran out of buffer slots to place the frames, and the driver did not replenish the buffer slots before a timeout occurred. The driver should not be so slow in replenishing buffers that a timeout can occur. When the driver received all the frames of a sequence, it allocates an IOCB to put the frames in. In a situation where there was no IOCB available for the frame of a sequence, the RQ buffer corresponding to the first frame of the sequence was not returned to the FW. Eventually, with enough traffic encountering the situation, the timeout occurred. Fix by releasing the buffer back to firmware whenever there is no IOCB for the first frame. [mkp: typo] Link: https://lore.kernel.org/r/20200128002312.16346-2-jsmart2...@gmail.com Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin --- drivers/scsi/lpfc/lpfc_sli.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c index 7a94c2d352390..97c0d79a2601f 100644 --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -15445,6 +15445,10 @@ lpfc_prep_seq(struct lpfc_vport *vport, struct hbq_dmabuf *seq_dmabuf) list_add_tail(>list, _iocbq->list); } } + /* Free the sequence's header buffer */ + if (!first_iocbq) + lpfc_in_buf_free(vport->phba, _dmabuf->dbuf); + return first_iocbq; } -- 2.25.1
[PATCH AUTOSEL 4.4 32/64] Bluetooth: L2CAP: handle l2cap config request during open state
From: Howard Chung [ Upstream commit 96298f640104e4cd9a913a6e50b0b981829b94ff ] According to Core Spec Version 5.2 | Vol 3, Part A 6.1.5, the incoming L2CAP_ConfigReq should be handled during OPEN state. The section below shows the btmon trace when running L2CAP/COS/CFD/BV-12-C before and after this change. === Before === ... > ACL Data RX: Handle 256 flags 0x02 dlen 12#22 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 1 (0x0001) Source CID: 65 < ACL Data TX: Handle 256 flags 0x00 dlen 16#23 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection successful (0x) Status: No further information available (0x) < ACL Data TX: Handle 256 flags 0x00 dlen 12#24 L2CAP: Configure Request (0x04) ident 2 len 4 Destination CID: 65 Flags: 0x > HCI Event: Number of Completed Packets (0x13) plen 5 #25 Num handles: 1 Handle: 256 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #26 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 16#27 L2CAP: Configure Request (0x04) ident 3 len 8 Destination CID: 64 Flags: 0x Option: Unknown (0x10) [hint] 01 00.. < ACL Data TX: Handle 256 flags 0x00 dlen 18#28 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x Result: Success (0x) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 672 > HCI Event: Number of Completed Packets (0x13) plen 5 #29 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 14#30 L2CAP: Configure Response (0x05) ident 2 len 6 Source CID: 64 Flags: 0x Result: Success (0x) > ACL Data RX: Handle 256 flags 0x02 dlen 20#31 L2CAP: Configure Request (0x04) ident 3 len 12 Destination CID: 64 Flags: 0x Option: Unknown (0x10) [hint] 01 00 91 02 11 11.. < ACL Data TX: Handle 256 flags 0x00 dlen 14#32 L2CAP: Command Reject (0x01) ident 3 len 6 Reason: Invalid CID in request (0x0002) Destination CID: 64 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 #33 Num handles: 1 Handle: 256 Count: 1 ... === After === ... > ACL Data RX: Handle 256 flags 0x02 dlen 12 #22 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 1 (0x0001) Source CID: 65 < ACL Data TX: Handle 256 flags 0x00 dlen 16 #23 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection successful (0x) Status: No further information available (0x) < ACL Data TX: Handle 256 flags 0x00 dlen 12 #24 L2CAP: Configure Request (0x04) ident 2 len 4 Destination CID: 65 Flags: 0x > HCI Event: Number of Completed Packets (0x13) plen 5 #25 Num handles: 1 Handle: 256 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #26 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 16 #27 L2CAP: Configure Request (0x04) ident 3 len 8 Destination CID: 64 Flags: 0x Option: Unknown (0x10) [hint] 01 00.. < ACL Data TX: Handle 256 flags 0x00 dlen 18 #28 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x Result: Success (0x) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 672 > HCI Event: Number of Completed Packets (0x13) plen 5 #29 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 14 #30 L2CAP: Configure Response (0x05) ident 2 len 6 Source CID: 64 Flags: 0x Result: Success (0x) > ACL Data RX: Handle 256 flags 0x02 dlen 20 #31 L2CAP: Configure Request (0x04) ident 3 len 12 Destination CID: 64 Flags: 0x Option: Unknown (0x10) [hint] 01 00 91 02 11 11. < ACL Data TX: Handle 256 flags 0x00 dlen 18 #32 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x Result: Success (0x) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 672 < ACL Data TX: Handle 256 flags 0x00 dlen 12 #33 L2CAP:
[PATCH AUTOSEL 4.4 34/64] tpm: ibmvtpm: Wait for buffer to be set before proceeding
From: Stefan Berger
[ Upstream commit d8d74ea3c00214aee1e1826ca18e77944812b9b4 ]
Synchronize with the results from the CRQs before continuing with
the initialization. This avoids trying to send TPM commands while
the rtce buffer has not been allocated, yet.
This patch fixes an existing race condition that may occurr if the
hypervisor does not quickly respond to the VTPM_GET_RTCE_BUFFER_SIZE
request sent during initialization and therefore the ibmvtpm->rtce_buf
has not been allocated at the time the first TPM command is sent.
Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM
vTPM")
Signed-off-by: Stefan Berger
Acked-by: Nayna Jain
Tested-by: Nayna Jain
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Sasha Levin
---
drivers/char/tpm/tpm_ibmvtpm.c | 9 +
drivers/char/tpm/tpm_ibmvtpm.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 3e6a22658b63b..d4cc1a1ac1f73 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -543,6 +543,7 @@ static irqreturn_t ibmvtpm_interrupt(int irq, void
*vtpm_instance)
*/
while ((crq = ibmvtpm_crq_get_next(ibmvtpm)) != NULL) {
ibmvtpm_crq_process(crq, ibmvtpm);
+ wake_up_interruptible(>crq_queue.wq);
crq->valid = 0;
smp_wmb();
}
@@ -589,6 +590,7 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
}
crq_q->num_entry = CRQ_RES_BUF_SIZE / sizeof(*crq_q->crq_addr);
+ init_waitqueue_head(_q->wq);
ibmvtpm->crq_dma_handle = dma_map_single(dev, crq_q->crq_addr,
CRQ_RES_BUF_SIZE,
DMA_BIDIRECTIONAL);
@@ -641,6 +643,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
if (rc)
goto init_irq_cleanup;
+ if (!wait_event_timeout(ibmvtpm->crq_queue.wq,
+ ibmvtpm->rtce_buf != NULL,
+ HZ)) {
+ dev_err(dev, "CRQ response timed out\n");
+ goto init_irq_cleanup;
+ }
+
return tpm_chip_register(chip);
init_irq_cleanup:
do {
diff --git a/drivers/char/tpm/tpm_ibmvtpm.h b/drivers/char/tpm/tpm_ibmvtpm.h
index 6af92890518f8..1a8c3b698f104 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.h
+++ b/drivers/char/tpm/tpm_ibmvtpm.h
@@ -31,6 +31,7 @@ struct ibmvtpm_crq_queue {
struct ibmvtpm_crq *crq_addr;
u32 index;
u32 num_entry;
+ wait_queue_head_t wq;
};
struct ibmvtpm_dev {
--
2.25.1
[PATCH AUTOSEL 4.4 43/64] KVM: Remove CREATE_IRQCHIP/SET_PIT2 race
From: Steve Rutherford
[ Upstream commit 7289fdb5dcdbc5155b5531529c44105868a762f2 ]
Fixes a NULL pointer dereference, caused by the PIT firing an interrupt
before the interrupt table has been initialized.
SET_PIT2 can race with the creation of the IRQchip. In particular,
if SET_PIT2 is called with a low PIT timer period (after the creation of
the IOAPIC, but before the instantiation of the irq routes), the PIT can
fire an interrupt at an uninitialized table.
Signed-off-by: Steve Rutherford
Signed-off-by: Jon Cargille
Reviewed-by: Jim Mattson
Message-Id: <20200416191152.259434-1-jcarg...@google.com>
Signed-off-by: Paolo Bonzini
Signed-off-by: Sasha Levin
---
arch/x86/kvm/x86.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 61fc92f92e0a0..ef920da075184 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4013,10 +4013,13 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = -EFAULT;
if (copy_from_user(, argp, sizeof u.ps))
goto out;
+ mutex_lock(>lock);
r = -ENXIO;
if (!kvm->arch.vpit)
- goto out;
+ goto set_pit_out;
r = kvm_vm_ioctl_set_pit(kvm, );
+set_pit_out:
+ mutex_unlock(>lock);
break;
}
case KVM_GET_PIT2: {
@@ -4036,10 +4039,13 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = -EFAULT;
if (copy_from_user(, argp, sizeof(u.ps2)))
goto out;
+ mutex_lock(>lock);
r = -ENXIO;
if (!kvm->arch.vpit)
- goto out;
+ goto set_pit2_out;
r = kvm_vm_ioctl_set_pit2(kvm, );
+set_pit2_out:
+ mutex_unlock(>lock);
break;
}
case KVM_REINJECT_CONTROL: {
--
2.25.1
[PATCH AUTOSEL 4.4 42/64] serial: uartps: Wait for tx_empty in console setup
From: Raviteja Narayanam [ Upstream commit 42e11948ddf68b9f799cad8c0ddeab0a39da33e8 ] On some platforms, the log is corrupted while console is being registered. It is observed that when set_termios is called, there are still some bytes in the FIFO to be transmitted. So, wait for tx_empty inside cdns_uart_console_setup before calling set_termios. Signed-off-by: Raviteja Narayanam Reviewed-by: Shubhrajyoti Datta Link: https://lore.kernel.org/r/1586413563-29125-2-git-send-email-raviteja.naraya...@xilinx.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- drivers/tty/serial/xilinx_uartps.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index 06efcef1b4953..5b446909a 100644 --- a/drivers/tty/serial/xilinx_uartps.c +++ b/drivers/tty/serial/xilinx_uartps.c @@ -1152,6 +1152,7 @@ static int cdns_uart_console_setup(struct console *co, char *options) int bits = 8; int parity = 'n'; int flow = 'n'; + unsigned long time_out; if (co->index < 0 || co->index >= CDNS_UART_NR_PORTS) return -EINVAL; @@ -1165,6 +1166,13 @@ static int cdns_uart_console_setup(struct console *co, char *options) if (options) uart_parse_options(options, , , , ); + /* Wait for tx_empty before setting up the console */ + time_out = jiffies + usecs_to_jiffies(TX_TIMEOUT); + + while (time_before(jiffies, time_out) && + cdns_uart_tx_empty(port) != TIOCSER_TEMT) + cpu_relax(); + return uart_set_options(port, co, baud, parity, bits, flow); } -- 2.25.1
[PATCH AUTOSEL 4.4 40/64] mm/filemap.c: clear page error before actual read
From: Xianting Tian
[ Upstream commit faffdfa04fa11ccf048cebdde73db41ede0679e0 ]
Mount failure issue happens under the scenario: Application forked dozens
of threads to mount the same number of cramfs images separately in docker,
but several mounts failed with high probability. Mount failed due to the
checking result of the page(read from the superblock of loop dev) is not
uptodate after wait_on_page_locked(page) returned in function cramfs_read:
wait_on_page_locked(page);
if (!PageUptodate(page)) {
...
}
The reason of the checking result of the page not uptodate: systemd-udevd
read the loopX dev before mount, because the status of loopX is Lo_unbound
at this time, so loop_make_request directly trigger the calling of io_end
handler end_buffer_async_read, which called SetPageError(page). So It
caused the page can't be set to uptodate in function
end_buffer_async_read:
if(page_uptodate && !PageError(page)) {
SetPageUptodate(page);
}
Then mount operation is performed, it used the same page which is just
accessed by systemd-udevd above, Because this page is not uptodate, it
will launch a actual read via submit_bh, then wait on this page by calling
wait_on_page_locked(page). When the I/O of the page done, io_end handler
end_buffer_async_read is called, because no one cleared the page
error(during the whole read path of mount), which is caused by
systemd-udevd reading, so this page is still in "PageError" status, which
can't be set to uptodate in function end_buffer_async_read, then caused
mount failure.
But sometimes mount succeed even through systemd-udeved read loopX dev
just before, The reason is systemd-udevd launched other loopX read just
between step 3.1 and 3.2, the steps as below:
1, loopX dev default status is Lo_unbound;
2, systemd-udved read loopX dev (page is set to PageError);
3, mount operation
1) set loopX status to Lo_bound;
==>systemd-udevd read loopX dev<==
2) read loopX dev(page has no error)
3) mount succeed
As the loopX dev status is set to Lo_bound after step 3.1, so the other
loopX dev read by systemd-udevd will go through the whole I/O stack, part
of the call trace as below:
SYS_read
vfs_read
do_sync_read
blkdev_aio_read
generic_file_aio_read
do_generic_file_read:
ClearPageError(page);
mapping->a_ops->readpage(filp, page);
here, mapping->a_ops->readpage() is blkdev_readpage. In latest kernel,
some function name changed, the call trace as below:
blkdev_read_iter
generic_file_read_iter
generic_file_buffered_read:
/*
* A previous I/O error may have been due to temporary
* failures, eg. mutipath errors.
* Pg_error will be set again if readpage fails.
*/
ClearPageError(page);
/* Start the actual read. The read will unlock the page*/
error=mapping->a_ops->readpage(flip, page);
We can see ClearPageError(page) is called before the actual read,
then the read in step 3.2 succeed.
This patch is to add the calling of ClearPageError just before the actual
read of read path of cramfs mount. Without the patch, the call trace as
below when performing cramfs mount:
do_mount
cramfs_read
cramfs_blkdev_read
read_cache_page
do_read_cache_page:
filler(data, page);
or
mapping->a_ops->readpage(data, page);
With the patch, the call trace as below when performing mount:
do_mount
cramfs_read
cramfs_blkdev_read
read_cache_page:
do_read_cache_page:
ClearPageError(page); <== new add
filler(data, page);
or
mapping->a_ops->readpage(data, page);
With the patch, mount operation trigger the calling of
ClearPageError(page) before the actual read, the page has no error if no
additional page error happen when I/O done.
Signed-off-by: Xianting Tian
Signed-off-by: Andrew Morton
Reviewed-by: Matthew Wilcox (Oracle)
Cc: Jan Kara
Cc:
Link:
http://lkml.kernel.org/r/1583318844-22971-1-git-send-email-xianting_t...@126.com
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
mm/filemap.c | 8
1 file changed, 8 insertions(+)
diff --git a/mm/filemap.c b/mm/filemap.c
index f217120973ebe..3d0a0e409cbf5 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2313,6 +2313,14 @@ filler:
unlock_page(page);
goto out;
}
+
+ /*
+* A previous I/O error may have been due to temporary
+* failures.
+* Clear page error before actual read, PG_error will be
+* set again if read page fails.
+*/
+ ClearPageError(page);
goto filler;
out:
--
2.25.1
[PATCH AUTOSEL 4.4 35/64] tracing: Use address-of operator on section symbols
From: Nathan Chancellor [ Upstream commit bf2cbe044da275021b2de5917240411a19e5c50d ] Clang warns: ../kernel/trace/trace.c:9335:33: warning: array comparison always evaluates to true [-Wtautological-compare] if (__stop___trace_bprintk_fmt != __start___trace_bprintk_fmt) ^ 1 warning generated. These are not true arrays, they are linker defined symbols, which are just addresses. Using the address of operator silences the warning and does not change the runtime result of the check (tested with some print statements compiled in with clang + ld.lld and gcc + ld.bfd in QEMU). Link: http://lkml.kernel.org/r/20200220051011.26113-1-natechancel...@gmail.com Link: https://github.com/ClangBuiltLinux/linux/issues/893 Suggested-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin --- kernel/trace/trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 17ea5f9d36b48..e4a0c0308b507 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -7263,7 +7263,7 @@ __init static int tracer_alloc_buffers(void) goto out_free_buffer_mask; /* Only allocate trace_printk buffers if a trace_printk exists */ - if (__stop___trace_bprintk_fmt != __start___trace_bprintk_fmt) + if (&__stop___trace_bprintk_fmt != &__start___trace_bprintk_fmt) /* Must be called before global_trace.buffer is allocated */ trace_printk_init_buffers(); -- 2.25.1
[PATCH AUTOSEL 4.4 41/64] mm/mmap.c: initialize align_offset explicitly for vm_unmapped_area
From: Jaewon Kim
[ Upstream commit 09ef5283fd96ac424ef0e569626f359bf9ab86c9 ]
On passing requirement to vm_unmapped_area, arch_get_unmapped_area and
arch_get_unmapped_area_topdown did not set align_offset. Internally on
both unmapped_area and unmapped_area_topdown, if info->align_mask is 0,
then info->align_offset was meaningless.
But commit df529cabb7a2 ("mm: mmap: add trace point of
vm_unmapped_area") always prints info->align_offset even though it is
uninitialized.
Fix this uninitialized value issue by setting it to 0 explicitly.
Before:
vm_unmapped_area: addr=0x755b155000 err=0 total_vm=0x15aaf0 flags=0x1
len=0x109000 lo=0x8000 hi=0x75eed48000 mask=0x0 ofs=0x4022
After:
vm_unmapped_area: addr=0x74a4ca1000 err=0 total_vm=0x168ab1 flags=0x1
len=0x9000 lo=0x8000 hi=0x753d94b000 mask=0x0 ofs=0x0
Signed-off-by: Jaewon Kim
Signed-off-by: Andrew Morton
Reviewed-by: Andrew Morton
Cc: Matthew Wilcox (Oracle)
Cc: Michel Lespinasse
Cc: Borislav Petkov
Link: http://lkml.kernel.org/r/20200409094035.19457-1-jaewon31@samsung.com
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
mm/mmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index 135e41f88..d48a654cbd237 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1993,6 +1993,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long
addr,
info.low_limit = mm->mmap_base;
info.high_limit = TASK_SIZE;
info.align_mask = 0;
+ info.align_offset = 0;
return vm_unmapped_area();
}
#endif
@@ -2034,6 +2035,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const
unsigned long addr0,
info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = mm->mmap_base;
info.align_mask = 0;
+ info.align_offset = 0;
addr = vm_unmapped_area();
/*
--
2.25.1
[PATCH AUTOSEL 4.4 46/64] dt-bindings: sound: wm8994: Correct required supplies based on actual implementaion
From: Krzysztof Kozlowski
[ Upstream commit 8c149b7d75e53be47648742f40fc90d9fc6fa63a ]
The required supplies in bindings were actually not matching
implementation making the bindings incorrect and misleading. The Linux
kernel driver requires all supplies to be present. Also for wlf,wm8994
uses just DBVDD-supply instead of DBVDDn-supply (n: <1,3>).
Reported-by: Jonathan Bakker
Signed-off-by: Krzysztof Kozlowski
Link: https://lore.kernel.org/r/20200501133534.6706-1-k...@kernel.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
.../devicetree/bindings/sound/wm8994.txt | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt
b/Documentation/devicetree/bindings/sound/wm8994.txt
index e045e90a0924b..0f03b8228d080 100644
--- a/Documentation/devicetree/bindings/sound/wm8994.txt
+++ b/Documentation/devicetree/bindings/sound/wm8994.txt
@@ -14,9 +14,15 @@ Required properties:
- #gpio-cells : Must be 2. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- - AVDD2-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply,
-SPKVDD1-supply, SPKVDD2-supply : power supplies for the device, as covered
-in Documentation/devicetree/bindings/regulator/regulator.txt
+ - power supplies for the device, as covered in
+Documentation/devicetree/bindings/regulator/regulator.txt, depending
+on compatible:
+- for wlf,wm1811 and wlf,wm8958:
+ AVDD1-supply, AVDD2-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply,
+ DCVDD-supply, CPVDD-supply, SPKVDD1-supply, SPKVDD2-supply
+- for wlf,wm8994:
+ AVDD1-supply, AVDD2-supply, DBVDD-supply, DCVDD-supply, CPVDD-supply,
+ SPKVDD1-supply, SPKVDD2-supply
Optional properties:
@@ -68,11 +74,11 @@ codec: wm8994@1a {
lineout1-se;
+ AVDD1-supply = <>;
AVDD2-supply = <>;
CPVDD-supply = <>;
- DBVDD1-supply = <>;
- DBVDD2-supply = <>;
- DBVDD3-supply = <>;
+ DBVDD-supply = <>;
+ DCVDD-supply = <>;
SPKVDD1-supply = <>;
SPKVDD2-supply = <>;
};
--
2.25.1
[PATCH AUTOSEL 4.4 44/64] bdev: Reduce time holding bd_mutex in sync in blkdev_close()
From: Douglas Anderson
[ Upstream commit b849dd84b6ccfe32622988b79b7b073861fcf9f7 ]
While trying to "dd" to the block device for a USB stick, I
encountered a hung task warning (blocked for > 120 seconds). I
managed to come up with an easy way to reproduce this on my system
(where /dev/sdb is the block device for my USB stick) with:
while true; do dd if=/dev/zero of=/dev/sdb bs=4M; done
With my reproduction here are the relevant bits from the hung task
detector:
INFO: task udevd:294 blocked for more than 122 seconds.
...
udevd D0 294 1 0x0048
Call trace:
...
mutex_lock_nested+0x40/0x50
__blkdev_get+0x7c/0x3d4
blkdev_get+0x118/0x138
blkdev_open+0x94/0xa8
do_dentry_open+0x268/0x3a0
vfs_open+0x34/0x40
path_openat+0x39c/0xdf4
do_filp_open+0x90/0x10c
do_sys_open+0x150/0x3c8
...
...
Showing all locks held in the system:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (>bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
write_cache_pages+0x194/0x500
generic_writepages+0x64/0xa4
blkdev_writepages+0x24/0x30
do_writepages+0x48/0xa8
__filemap_fdatawrite_range+0xac/0xd8
filemap_write_and_wait+0x30/0x84
__blkdev_put+0x88/0x204
blkdev_put+0xc4/0xe4
blkdev_close+0x28/0x38
__fput+0xe0/0x238
fput+0x1c/0x28
task_work_run+0xb0/0xe4
do_notify_resume+0xfc0/0x14bc
work_pending+0x8/0x14
The problem appears related to the fact that my USB disk is terribly
slow and that I have a lot of RAM in my system to cache things.
Specifically my writes seem to be happening at ~15 MB/s and I've got
~4 GB of RAM in my system that can be used for buffering. To write 4
GB of buffer to disk thus takes ~4000 MB / ~15 MB/s = ~267 seconds.
The 267 second number is a problem because in __blkdev_put() we call
sync_blockdev() while holding the bd_mutex. Any other callers who
want the bd_mutex will be blocked for the whole time.
The problem is made worse because I believe blkdev_put() specifically
tells other tasks (namely udev) to go try to access the device at right
around the same time we're going to hold the mutex for a long time.
Putting some traces around this (after disabling the hung task detector),
I could confirm:
dd:437.608600: __blkdev_put() right before sync_blockdev() for sdb
udevd: 437.623901: blkdev_open() right before blkdev_get() for sdb
dd:661.468451: __blkdev_put() right after sync_blockdev() for sdb
udevd: 663.820426: blkdev_open() right after blkdev_get() for sdb
A simple fix for this is to realize that sync_blockdev() works fine if
you're not holding the mutex. Also, it's not the end of the world if
you sync a little early (though it can have performance impacts).
Thus we can make a guess that we're going to need to do the sync and
then do it without holding the mutex. We still do one last sync with
the mutex but it should be much, much faster.
With this, my hung task warnings for my test case are gone.
Signed-off-by: Douglas Anderson
Reviewed-by: Guenter Roeck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
fs/block_dev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index b2ebfd96785b7..a71d442ef7d0e 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1515,6 +1515,16 @@ static void __blkdev_put(struct block_device *bdev,
fmode_t mode, int for_part)
struct gendisk *disk = bdev->bd_disk;
struct block_device *victim = NULL;
+ /*
+* Sync early if it looks like we're the last one. If someone else
+* opens the block device between now and the decrement of bd_openers
+* then we did a sync that we didn't need to, but that's not the end
+* of the world and we want to avoid long (could be several minute)
+* syncs while holding the mutex.
+*/
+ if (bdev->bd_openers == 1)
+ sync_blockdev(bdev);
+
mutex_lock_nested(>bd_mutex, for_part);
if (for_part)
bdev->bd_part_count--;
--
2.25.1
[PATCH AUTOSEL 4.4 45/64] drivers: char: tlclk.c: Avoid data race between init and interrupt handler
From: Madhuparna Bhowmik
[ Upstream commit 44b8fb6eaa7c3fb770bf1e37619cdb3902cca1fc ]
After registering character device the file operation callbacks can be
called. The open callback registers interrupt handler.
Therefore interrupt handler can execute in parallel with rest of the init
function. To avoid such data race initialize telclk_interrupt variable
and struct alarm_events before registering character device.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Madhuparna Bhowmik
Link:
https://lore.kernel.org/r/20200417153451.1551-1-madhuparnabhowmi...@gmail.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/char/tlclk.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/char/tlclk.c b/drivers/char/tlclk.c
index 100cd1de9939d..59e1e94d12c01 100644
--- a/drivers/char/tlclk.c
+++ b/drivers/char/tlclk.c
@@ -777,17 +777,21 @@ static int __init tlclk_init(void)
{
int ret;
+ telclk_interrupt = (inb(TLCLK_REG7) & 0x0f);
+
+ alarm_events = kzalloc( sizeof(struct tlclk_alarms), GFP_KERNEL);
+ if (!alarm_events) {
+ ret = -ENOMEM;
+ goto out1;
+ }
+
ret = register_chrdev(tlclk_major, "telco_clock", _fops);
if (ret < 0) {
printk(KERN_ERR "tlclk: can't get major %d.\n", tlclk_major);
+ kfree(alarm_events);
return ret;
}
tlclk_major = ret;
- alarm_events = kzalloc( sizeof(struct tlclk_alarms), GFP_KERNEL);
- if (!alarm_events) {
- ret = -ENOMEM;
- goto out1;
- }
/* Read telecom clock IRQ number (Set by BIOS) */
if (!request_region(TLCLK_BASE, 8, "telco_clock")) {
@@ -796,7 +800,6 @@ static int __init tlclk_init(void)
ret = -EBUSY;
goto out2;
}
- telclk_interrupt = (inb(TLCLK_REG7) & 0x0f);
if (0x0F == telclk_interrupt ) { /* not MCPBL0010 ? */
printk(KERN_ERR "telclk_interrupt = 0x%x non-mcpbl0010 hw.\n",
@@ -837,8 +840,8 @@ out3:
release_region(TLCLK_BASE, 8);
out2:
kfree(alarm_events);
-out1:
unregister_chrdev(tlclk_major, "telco_clock");
+out1:
return ret;
}
--
2.25.1
[PATCH AUTOSEL 4.4 47/64] atm: fix a memory leak of vcc->user_back
From: Cong Wang
[ Upstream commit 8d9f73c0ad2f20e9fed5380de0a3097825859d03 ]
In lec_arp_clear_vccs() only entry->vcc is freed, but vcc
could be installed on entry->recv_vcc too in lec_vcc_added().
This fixes the following memory leak:
unreferenced object 0x8880d9266b90 (size 16):
comm "atm2", pid 425, jiffies 4294907980 (age 23.488s)
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 6b 6b 6b a5 kkk.
backtrace:
[<(ptrval)>] kmem_cache_alloc_trace+0x10e/0x151
[<(ptrval)>] lane_ioctl+0x4b3/0x569
[<(ptrval)>] do_vcc_ioctl+0x1ea/0x236
[<(ptrval)>] svc_ioctl+0x17d/0x198
[<(ptrval)>] sock_do_ioctl+0x47/0x12f
[<(ptrval)>] sock_ioctl+0x2f9/0x322
[<(ptrval)>] vfs_ioctl+0x1e/0x2b
[<(ptrval)>] ksys_ioctl+0x61/0x80
[<(ptrval)>] __x64_sys_ioctl+0x16/0x19
[<(ptrval)>] do_syscall_64+0x57/0x65
[<(ptrval)>] entry_SYSCALL_64_after_hwframe+0x49/0xb3
Cc: Gengming Liu
Signed-off-by: Cong Wang
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
net/atm/lec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index e4afac94ff158..a38680e194436 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -1290,6 +1290,12 @@ static void lec_arp_clear_vccs(struct lec_arp_table
*entry)
entry->vcc = NULL;
}
if (entry->recv_vcc) {
+ struct atm_vcc *vcc = entry->recv_vcc;
+ struct lec_vcc_priv *vpriv = LEC_VCC_PRIV(vcc);
+
+ kfree(vpriv);
+ vcc->user_back = NULL;
+
entry->recv_vcc->push = entry->old_recv_push;
vcc_release_async(entry->recv_vcc, -EPIPE);
entry->recv_vcc = NULL;
--
2.25.1
[PATCH AUTOSEL 4.4 48/64] phy: samsung: s5pv210-usb2: Add delay after reset
From: Jonathan Bakker
[ Upstream commit 05942b8c36c7eb5d3fc5e375d4b0d0c49562e85d ]
The USB phy takes some time to reset, so make sure we give it to it. The
delay length was taken from the 4x12 phy driver.
This manifested in issues with the DWC2 driver since commit fe369e1826b3
("usb: dwc2: Make dwc2_readl/writel functions endianness-agnostic.")
where the endianness check would read the DWC ID as 0 due to the phy still
resetting, resulting in the wrong endian mode being chosen.
Signed-off-by: Jonathan Bakker
Link:
https://lore.kernel.org/r/bn6pr04mb06605d52502816e500683553a3...@bn6pr04mb0660.namprd04.prod.outlook.com
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Sasha Levin
---
drivers/phy/phy-s5pv210-usb2.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/phy/phy-s5pv210-usb2.c b/drivers/phy/phy-s5pv210-usb2.c
index 004d320767e4d..bb36cfd4e3e90 100644
--- a/drivers/phy/phy-s5pv210-usb2.c
+++ b/drivers/phy/phy-s5pv210-usb2.c
@@ -142,6 +142,10 @@ static void s5pv210_phy_pwr(struct
samsung_usb2_phy_instance *inst, bool on)
udelay(10);
rst &= ~rstbits;
writel(rst, drv->reg_phy + S5PV210_UPHYRST);
+ /* The following delay is necessary for the reset sequence to be
+* completed
+*/
+ udelay(80);
} else {
pwr = readl(drv->reg_phy + S5PV210_UPHYPWR);
pwr |= phypwr;
--
2.25.1
[PATCH AUTOSEL 4.4 39/64] ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor
From: Andreas Steinmetz
[ Upstream commit 5c6cd7021a05a02fcf37f360592d7c18d4d807fb ]
The Miditech MIDIFACE 16x16 (USB ID 1290:1749) has more than one extra
endpoint descriptor.
The first extra descriptor is: 0x06 0x30 0x00 0x00 0x00 0x00
As the code in snd_usbmidi_get_ms_info() looks only at the
first extra descriptor to find USB_DT_CS_ENDPOINT the device
as such is recognized but there is neither input nor output
configured.
The patch iterates through the extra descriptors to find the
proper one. With this patch the device is correctly configured.
Signed-off-by: Andreas Steinmetz
Link:
https://lore.kernel.org/r/1c3b431a86f69e1d60745b6110cdb93c299f120b.ca...@domdv.de
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/usb/midi.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/sound/usb/midi.c b/sound/usb/midi.c
index 5c4a3d6c42341..934540042bc2e 100644
--- a/sound/usb/midi.c
+++ b/sound/usb/midi.c
@@ -1803,6 +1803,28 @@ static int snd_usbmidi_create_endpoints(struct
snd_usb_midi *umidi,
return 0;
}
+static struct usb_ms_endpoint_descriptor *find_usb_ms_endpoint_descriptor(
+ struct usb_host_endpoint *hostep)
+{
+ unsigned char *extra = hostep->extra;
+ int extralen = hostep->extralen;
+
+ while (extralen > 3) {
+ struct usb_ms_endpoint_descriptor *ms_ep =
+ (struct usb_ms_endpoint_descriptor *)extra;
+
+ if (ms_ep->bLength > 3 &&
+ ms_ep->bDescriptorType == USB_DT_CS_ENDPOINT &&
+ ms_ep->bDescriptorSubtype == UAC_MS_GENERAL)
+ return ms_ep;
+ if (!extra[0])
+ break;
+ extralen -= extra[0];
+ extra += extra[0];
+ }
+ return NULL;
+}
+
/*
* Returns MIDIStreaming device capabilities.
*/
@@ -1840,11 +1862,8 @@ static int snd_usbmidi_get_ms_info(struct snd_usb_midi
*umidi,
ep = get_ep_desc(hostep);
if (!usb_endpoint_xfer_bulk(ep) && !usb_endpoint_xfer_int(ep))
continue;
- ms_ep = (struct usb_ms_endpoint_descriptor *)hostep->extra;
- if (hostep->extralen < 4 ||
- ms_ep->bLength < 4 ||
- ms_ep->bDescriptorType != USB_DT_CS_ENDPOINT ||
- ms_ep->bDescriptorSubtype != UAC_MS_GENERAL)
+ ms_ep = find_usb_ms_endpoint_descriptor(hostep);
+ if (!ms_ep)
continue;
if (usb_endpoint_dir_out(ep)) {
if (endpoints[epidx].out_ep) {
--
2.25.1
[PATCH AUTOSEL 4.4 49/64] Bluetooth: Handle Inquiry Cancel error after Inquiry Complete
From: Sonny Sasaka
[ Upstream commit adf1d6926444029396861413aba8a0f2a805742a ]
After sending Inquiry Cancel command to the controller, it is possible
that Inquiry Complete event comes before Inquiry Cancel command complete
event. In this case the Inquiry Cancel command will have status of
Command Disallowed since there is no Inquiry session to be cancelled.
This case should not be treated as error, otherwise we can reach an
inconsistent state.
Example of a btmon trace when this happened:
< HCI Command: Inquiry Cancel (0x01|0x0002) plen 0
> HCI Event: Inquiry Complete (0x01) plen 1
Status: Success (0x00)
> HCI Event: Command Complete (0x0e) plen 4
Inquiry Cancel (0x01|0x0002) ncmd 1
Status: Command Disallowed (0x0c)
Signed-off-by: Sonny Sasaka
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
---
net/bluetooth/hci_event.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 04c77747a768d..03319ab8a7c6e 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -41,12 +41,27 @@
/* Handle HCI Event packets */
-static void hci_cc_inquiry_cancel(struct hci_dev *hdev, struct sk_buff *skb)
+static void hci_cc_inquiry_cancel(struct hci_dev *hdev, struct sk_buff *skb,
+ u8 *new_status)
{
__u8 status = *((__u8 *) skb->data);
BT_DBG("%s status 0x%2.2x", hdev->name, status);
+ /* It is possible that we receive Inquiry Complete event right
+* before we receive Inquiry Cancel Command Complete event, in
+* which case the latter event should have status of Command
+* Disallowed (0x0c). This should not be treated as error, since
+* we actually achieve what Inquiry Cancel wants to achieve,
+* which is to end the last Inquiry session.
+*/
+ if (status == 0x0c && !test_bit(HCI_INQUIRY, >flags)) {
+ bt_dev_warn(hdev, "Ignoring error of Inquiry Cancel command");
+ status = 0x00;
+ }
+
+ *new_status = status;
+
if (status)
return;
@@ -2758,7 +2773,7 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev,
struct sk_buff *skb,
switch (*opcode) {
case HCI_OP_INQUIRY_CANCEL:
- hci_cc_inquiry_cancel(hdev, skb);
+ hci_cc_inquiry_cancel(hdev, skb, status);
break;
case HCI_OP_PERIODIC_INQ:
--
2.25.1
[PATCH AUTOSEL 4.4 50/64] USB: EHCI: ehci-mv: fix error handling in mv_ehci_probe()
From: Tang Bin
[ Upstream commit c856b4b0fdb5044bca4c0acf9a66f3b5cc01a37a ]
If the function platform_get_irq() failed, the negative value
returned will not be detected here. So fix error handling in
mv_ehci_probe(). And when get irq failed, the function
platform_get_irq() logs an error message, so remove redundant
message here.
Signed-off-by: Zhang Shengju
Signed-off-by: Tang Bin
Link:
https://lore.kernel.org/r/20200508114305.15740-1-tang...@cmss.chinamobile.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/usb/host/ehci-mv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 849806a75f1ce..273736e1d33fa 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -197,9 +197,8 @@ static int mv_ehci_probe(struct platform_device *pdev)
hcd->regs = ehci_mv->op_regs;
hcd->irq = platform_get_irq(pdev, 0);
- if (!hcd->irq) {
- dev_err(>dev, "Cannot get irq.");
- retval = -ENODEV;
+ if (hcd->irq < 0) {
+ retval = hcd->irq;
goto err_disable_clk;
}
--
2.25.1
[PATCH AUTOSEL 4.4 61/64] mtd: parser: cmdline: Support MTD names containing one or more colons
From: Boris Brezillon
[ Upstream commit eb13fa0227417e84aecc3bd9c029d376e33474d3 ]
Looks like some drivers define MTD names with a colon in it, thus
making mtdpart= parsing impossible. Let's fix the parser to gracefully
handle that case: the last ':' in a partition definition sequence is
considered instead of the first one.
Signed-off-by: Boris Brezillon
Signed-off-by: Ron Minnich
Tested-by: Ron Minnich
Signed-off-by: Richard Weinberger
Signed-off-by: Sasha Levin
---
drivers/mtd/cmdlinepart.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c
index 08f62987cc37c..ffbc9b304beb2 100644
--- a/drivers/mtd/cmdlinepart.c
+++ b/drivers/mtd/cmdlinepart.c
@@ -228,12 +228,29 @@ static int mtdpart_setup_real(char *s)
struct cmdline_mtd_partition *this_mtd;
struct mtd_partition *parts;
int mtd_id_len, num_parts;
- char *p, *mtd_id;
+ char *p, *mtd_id, *semicol;
+
+ /*
+* Replace the first ';' by a NULL char so strrchr can work
+* properly.
+*/
+ semicol = strchr(s, ';');
+ if (semicol)
+ *semicol = '\0';
mtd_id = s;
- /* fetch */
- p = strchr(s, ':');
+ /*
+* fetch . We use strrchr to ignore all ':' that could
+* be present in the MTD name, only the last one is interpreted
+* as an / separator.
+*/
+ p = strrchr(s, ':');
+
+ /* Restore the ';' now. */
+ if (semicol)
+ *semicol = ';';
+
if (!p) {
pr_err("no mtd-id\n");
return -EINVAL;
--
2.25.1
[PATCH AUTOSEL 4.4 54/64] USB: EHCI: ehci-mv: fix less than zero comparison of an unsigned int
From: Colin Ian King
[ Upstream commit a7f40c233a6b0540d28743267560df9cfb571ca9 ]
The comparison of hcd->irq to less than zero for an error check will
never be true because hcd->irq is an unsigned int. Fix this by
assigning the int retval to the return of platform_get_irq and checking
this for the -ve error condition and assigning hcd->irq to retval.
Addresses-Coverity: ("Unsigned compared against 0")
Fixes: c856b4b0fdb5 ("USB: EHCI: ehci-mv: fix error handling in
mv_ehci_probe()")
Signed-off-by: Colin Ian King
Link: https://lore.kernel.org/r/20200515165453.104028-1-colin.k...@canonical.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/usb/host/ehci-mv.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 273736e1d33fa..b29610899c9f6 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -196,11 +196,10 @@ static int mv_ehci_probe(struct platform_device *pdev)
hcd->rsrc_len = resource_size(r);
hcd->regs = ehci_mv->op_regs;
- hcd->irq = platform_get_irq(pdev, 0);
- if (hcd->irq < 0) {
- retval = hcd->irq;
+ retval = platform_get_irq(pdev, 0);
+ if (retval < 0)
goto err_disable_clk;
- }
+ hcd->irq = retval;
ehci = hcd_to_ehci(hcd);
ehci->caps = (struct ehci_caps *) ehci_mv->cap_regs;
--
2.25.1
Re: [vhost next 0/2] mlx5 vdpa fix netdev status
On 2020/9/17 下午8:13, Eli Cohen wrote: Hi Michael, the following two patches aim to fix a failure to set the vdpa driver status bit VIRTIO_NET_S_LINK_UP thus causing failure to bring the link up. I break it to two patches: 1. Introduce proper mlx5 API to set 16 bit status fields per virtio requirements. 2. Fix the failure to set the bit Eli Cohen (2): vdpa/mlx5: Make use of a specific 16 bit endianness API vdpa/mlx5: Fix failure to bring link up drivers/vdpa/mlx5/net/mlx5_vnet.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) Acked-by: Jason Wang
[PATCH AUTOSEL 4.4 36/64] serial: 8250_omap: Fix sleeping function called from invalid context during probe
From: Peter Ujfalusi
[ Upstream commit 4ce35a3617c0ac758c61122b2218b6c8c9ac9398 ]
When booting j721e the following bug is printed:
[1.154821] BUG: sleeping function called from invalid context at
kernel/sched/completion.c:99
[1.154827] in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 12,
name: kworker/0:1
[1.154832] 3 locks held by kworker/0:1/12:
[1.154836] #0: 000840030728 ((wq_completion)events){+.+.}, at:
process_one_work+0x1d4/0x6e8
[1.154852] #1: 80001214fdd8 (deferred_probe_work){+.+.}, at:
process_one_work+0x1d4/0x6e8
[1.154860] #2: 00084060b170 (>mutex){}, at:
__device_attach+0x38/0x138
[1.154872] irq event stamp: 63096
[1.154881] hardirqs last enabled at (63095): []
_raw_spin_unlock_irqrestore+0x70/0x78
[1.154887] hardirqs last disabled at (63096): []
_raw_spin_lock_irqsave+0x28/0x80
[1.154893] softirqs last enabled at (62254): []
_stext+0x488/0x564
[1.154899] softirqs last disabled at (62247): []
irq_exit+0x114/0x140
[1.154906] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted
5.6.0-rc6-next-20200318-00094-g45e4089b0bd3 #221
[1.154911] Hardware name: Texas Instruments K3 J721E SoC (DT)
[1.154917] Workqueue: events deferred_probe_work_func
[1.154923] Call trace:
[1.154928] dump_backtrace+0x0/0x190
[1.154933] show_stack+0x14/0x20
[1.154940] dump_stack+0xe0/0x148
[1.154946] ___might_sleep+0x150/0x1f0
[1.154952] __might_sleep+0x4c/0x80
[1.154957] wait_for_completion_timeout+0x40/0x140
[1.154964] ti_sci_set_device_state+0xa0/0x158
[1.154969] ti_sci_cmd_get_device_exclusive+0x14/0x20
[1.154977] ti_sci_dev_start+0x34/0x50
[1.154984] genpd_runtime_resume+0x78/0x1f8
[1.154991] __rpm_callback+0x3c/0x140
[1.154996] rpm_callback+0x20/0x80
[1.155001] rpm_resume+0x568/0x758
[1.155007] __pm_runtime_resume+0x44/0xb0
[1.155013] omap8250_probe+0x2b4/0x508
[1.155019] platform_drv_probe+0x50/0xa0
[1.155023] really_probe+0xd4/0x318
[1.155028] driver_probe_device+0x54/0xe8
[1.155033] __device_attach_driver+0x80/0xb8
[1.155039] bus_for_each_drv+0x74/0xc0
[1.155044] __device_attach+0xdc/0x138
[1.155049] device_initial_probe+0x10/0x18
[1.155053] bus_probe_device+0x98/0xa0
[1.155058] deferred_probe_work_func+0x74/0xb0
[1.155063] process_one_work+0x280/0x6e8
[1.155068] worker_thread+0x48/0x430
[1.155073] kthread+0x108/0x138
[1.155079] ret_from_fork+0x10/0x18
To fix the bug we need to first call pm_runtime_enable() prior to any
pm_runtime calls.
Reported-by: Tomi Valkeinen
Signed-off-by: Peter Ujfalusi
Link: https://lore.kernel.org/r/20200320125200.6772-1-peter.ujfal...@ti.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/tty/serial/8250/8250_omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index c4383573cf668..0377b35d62b80 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1188,11 +1188,11 @@ static int omap8250_probe(struct platform_device *pdev)
spin_lock_init(>rx_dma_lock);
device_init_wakeup(>dev, true);
+ pm_runtime_enable(>dev);
pm_runtime_use_autosuspend(>dev);
pm_runtime_set_autosuspend_delay(>dev, -1);
pm_runtime_irq_safe(>dev);
- pm_runtime_enable(>dev);
pm_runtime_get_sync(>dev);
--
2.25.1
[PATCH AUTOSEL 4.4 56/64] printk: handle blank console arguments passed in.
From: Shreyas Joshi [ Upstream commit 48021f98130880dd74286459a1ef48b5e9bc374f ] If uboot passes a blank string to console_setup then it results in a trashed memory. Ultimately, the kernel crashes during freeing up the memory. This fix checks if there is a blank parameter being passed to console_setup from uboot. In case it detects that the console parameter is blank then it doesn't setup the serial device and it gracefully exits. Link: https://lore.kernel.org/r/20200522065306.83-1-shreyas.jo...@biamp.com Signed-off-by: Shreyas Joshi Acked-by: Sergey Senozhatsky [pmla...@suse.com: Better format the commit message and code, remove unnecessary brackets.] Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin --- kernel/printk/printk.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index e53a976ca28ea..b55dfb3e801f9 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2032,6 +2032,9 @@ static int __init console_setup(char *str) char *s, *options, *brl_options = NULL; int idx; + if (str[0] == 0) + return 1; + if (_braille_console_setup(, _options)) return 1; -- 2.25.1
[PATCH AUTOSEL 4.4 52/64] ALSA: hda: Fix potential race in unsol event handler
From: Takashi Iwai
[ Upstream commit c637fa151259c0f74665fde7cba5b7eac1417ae5 ]
The unsol event handling code has a loop retrieving the read/write
indices and the arrays without locking while the append to the array
may happen concurrently. This may lead to some inconsistency.
Although there hasn't been any proof of this bad results, it's still
safer to protect the racy accesses.
This patch adds the spinlock protection around the unsol handling loop
for addressing it. Here we take bus->reg_lock as the writer side
snd_hdac_bus_queue_event() is also protected by that lock.
Link: https://lore.kernel.org/r/20200516062556.30951-1-ti...@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/hda/hdac_bus.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/hda/hdac_bus.c b/sound/hda/hdac_bus.c
index 0e81ea89a5965..e3f68a76d90eb 100644
--- a/sound/hda/hdac_bus.c
+++ b/sound/hda/hdac_bus.c
@@ -155,6 +155,7 @@ static void process_unsol_events(struct work_struct *work)
struct hdac_driver *drv;
unsigned int rp, caddr, res;
+ spin_lock_irq(>reg_lock);
while (bus->unsol_rp != bus->unsol_wp) {
rp = (bus->unsol_rp + 1) % HDA_UNSOL_QUEUE_SIZE;
bus->unsol_rp = rp;
@@ -166,10 +167,13 @@ static void process_unsol_events(struct work_struct *work)
codec = bus->caddr_tbl[caddr & 0x0f];
if (!codec || !codec->dev.driver)
continue;
+ spin_unlock_irq(>reg_lock);
drv = drv_to_hdac_driver(codec->dev.driver);
if (drv->unsol_event)
drv->unsol_event(codec, res);
+ spin_lock_irq(>reg_lock);
}
+ spin_unlock_irq(>reg_lock);
}
/**
--
2.25.1
[PATCH AUTOSEL 4.4 57/64] vfio/pci: fix memory leaks of eventfd ctx
From: Qian Cai [ Upstream commit 1518ac272e789cae8c555d69951b032a275b7602 ] Finished a qemu-kvm (-device vfio-pci,host=0001:01:00.0) triggers a few memory leaks after a while because vfio_pci_set_ctx_trigger_single() calls eventfd_ctx_fdget() without the matching eventfd_ctx_put() later. Fix it by calling eventfd_ctx_put() for those memory in vfio_pci_release() before vfio_device_release(). unreferenced object 0xebff008981cc2b00 (size 128): comm "qemu-kvm", pid 4043, jiffies 4294994816 (age 9796.310s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff backtrace: [<917e8f8d>] slab_post_alloc_hook+0x74/0x9c [] kmem_cache_alloc_trace+0x2b4/0x3d4 [<5fcec025>] do_eventfd+0x54/0x1ac [<82791a69>] __arm64_sys_eventfd2+0x34/0x44 [ ] do_el0_svc+0x128/0x1dc [ ] el0_sync_handler+0xd0/0x268 [ ] el0_sync+0x164/0x180 unreferenced object 0x29ff008981cc4180 (size 128): comm "qemu-kvm", pid 4043, jiffies 4294994818 (age 9796.290s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff backtrace: [<917e8f8d>] slab_post_alloc_hook+0x74/0x9c [ ] kmem_cache_alloc_trace+0x2b4/0x3d4 [<5fcec025>] do_eventfd+0x54/0x1ac [<82791a69>] __arm64_sys_eventfd2+0x34/0x44 [ ] do_el0_svc+0x128/0x1dc [ ] el0_sync_handler+0xd0/0x268 [ ] el0_sync+0x164/0x180 Signed-off-by: Qian Cai Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin --- drivers/vfio/pci/vfio_pci.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c index 7a82735d53087..ab765770e8dd6 100644 --- a/drivers/vfio/pci/vfio_pci.c +++ b/drivers/vfio/pci/vfio_pci.c @@ -255,6 +255,10 @@ static void vfio_pci_release(void *device_data) if (!(--vdev->refcnt)) { vfio_spapr_pci_eeh_release(vdev->pdev); vfio_pci_disable(vdev); + if (vdev->err_trigger) + eventfd_ctx_put(vdev->err_trigger); + if (vdev->req_trigger) + eventfd_ctx_put(vdev->req_trigger); } mutex_unlock(_lock); -- 2.25.1
[PATCH AUTOSEL 4.4 51/64] tty: serial: samsung: Correct clock selection logic
From: Jonathan Bakker
[ Upstream commit 7d31676a8d91dd18e08853efd1cb26961a38c6a6 ]
Some variants of the samsung tty driver can pick which clock
to use for their baud rate generation. In the DT conversion,
a default clock was selected to be used if a specific one wasn't
assigned and then a comparison of which clock rate worked better
was done. Unfortunately, the comparison was implemented in such
a way that only the default clock was ever actually compared.
Fix this by iterating through all possible clocks, except when a
specific clock has already been picked via clk_sel (which is
only possible via board files).
Signed-off-by: Jonathan Bakker
Reviewed-by: Krzysztof Kozlowski
Link:
https://lore.kernel.org/r/bn6pr04mb06604e63833ea41837ebf77ba3...@bn6pr04mb0660.namprd04.prod.outlook.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/tty/serial/samsung.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 70a51d0bc6044..42aa37515e9bd 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1151,14 +1151,14 @@ static unsigned int s3c24xx_serial_getclk(struct
s3c24xx_uart_port *ourport,
struct s3c24xx_uart_info *info = ourport->info;
struct clk *clk;
unsigned long rate;
- unsigned int cnt, baud, quot, clk_sel, best_quot = 0;
+ unsigned int cnt, baud, quot, best_quot = 0;
char clkname[MAX_CLK_NAME_LENGTH];
int calc_deviation, deviation = (1 << 30) - 1;
- clk_sel = (ourport->cfg->clk_sel) ? ourport->cfg->clk_sel :
- ourport->info->def_clk_sel;
for (cnt = 0; cnt < info->num_clks; cnt++) {
- if (!(clk_sel & (1 << cnt)))
+ /* Keep selected clock if provided */
+ if (ourport->cfg->clk_sel &&
+ !(ourport->cfg->clk_sel & (1 << cnt)))
continue;
sprintf(clkname, "clk_uart_baud%d", cnt);
--
2.25.1
[PATCH AUTOSEL 4.4 59/64] mtd: rawnand: omap_elm: Fix runtime PM imbalance on error
From: Dinghao Liu
[ Upstream commit 37f7212148cf1d796135cdf8d0c7fee13067674b ]
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Signed-off-by: Miquel Raynal
Link:
https://lore.kernel.org/linux-mtd/20200522104008.28340-1-dinghao@zju.edu.cn
Signed-off-by: Sasha Levin
---
drivers/mtd/nand/omap_elm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/nand/omap_elm.c b/drivers/mtd/nand/omap_elm.c
index 235ec7992b4cf..e46b11847082a 100644
--- a/drivers/mtd/nand/omap_elm.c
+++ b/drivers/mtd/nand/omap_elm.c
@@ -421,6 +421,7 @@ static int elm_probe(struct platform_device *pdev)
pm_runtime_enable(>dev);
if (pm_runtime_get_sync(>dev) < 0) {
ret = -EINVAL;
+ pm_runtime_put_sync(>dev);
pm_runtime_disable(>dev);
dev_err(>dev, "can't enable clock\n");
return ret;
--
2.25.1
[PATCH AUTOSEL 4.4 53/64] fuse: don't check refcount after stealing page
From: Miklos Szeredi
[ Upstream commit 32f98877c57bee6bc27f443a96f49678a2cd6a50 ]
page_count() is unstable. Unless there has been an RCU grace period
between when the page was removed from the page cache and now, a
speculative reference may exist from the page cache.
Reported-by: Matthew Wilcox
Signed-off-by: Miklos Szeredi
Signed-off-by: Sasha Levin
---
fs/fuse/dev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 8142f6bf3d310..fc265f4b839ae 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -850,7 +850,6 @@ static int fuse_check_page(struct page *page)
{
if (page_mapcount(page) ||
page->mapping != NULL ||
- page_count(page) != 1 ||
(page->flags & PAGE_FLAGS_CHECK_AT_PREP &
~(1 << PG_locked |
1 << PG_referenced |
--
2.25.1
[PATCH AUTOSEL 4.4 55/64] e1000: Do not perform reset in reset_task if we are already down
From: Alexander Duyck
[ Upstream commit 49ee3c2ab5234757bfb56a0b3a3cb422f427e3a3 ]
We are seeing a deadlock in e1000 down when NAPI is being disabled. Looking
over the kernel function trace of the system it appears that the interface
is being closed and then a reset is hitting which deadlocks the interface
as the NAPI interface is already disabled.
To prevent this from happening I am disabling the reset task when
__E1000_DOWN is already set. In addition code has been added so that we set
the __E1000_DOWN while holding the __E1000_RESET flag in e1000_close in
order to guarantee that the reset task will not run after we have started
the close call.
Signed-off-by: Alexander Duyck
Tested-by: Maxim Zhukov
Signed-off-by: Jeff Kirsher
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
b/drivers/net/ethernet/intel/e1000/e1000_main.c
index f958188207fd6..e57aca6239f8e 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -568,8 +568,13 @@ void e1000_reinit_locked(struct e1000_adapter *adapter)
WARN_ON(in_interrupt());
while (test_and_set_bit(__E1000_RESETTING, >flags))
msleep(1);
- e1000_down(adapter);
- e1000_up(adapter);
+
+ /* only run the task if not already down */
+ if (!test_bit(__E1000_DOWN, >flags)) {
+ e1000_down(adapter);
+ e1000_up(adapter);
+ }
+
clear_bit(__E1000_RESETTING, >flags);
}
@@ -1456,10 +1461,15 @@ static int e1000_close(struct net_device *netdev)
struct e1000_hw *hw = >hw;
int count = E1000_CHECK_RESET_COUNT;
- while (test_bit(__E1000_RESETTING, >flags) && count--)
+ while (test_and_set_bit(__E1000_RESETTING, >flags) && count--)
usleep_range(1, 2);
- WARN_ON(test_bit(__E1000_RESETTING, >flags));
+ WARN_ON(count < 0);
+
+ /* signal that we're down so that the reset task will no longer run */
+ set_bit(__E1000_DOWN, >flags);
+ clear_bit(__E1000_RESETTING, >flags);
+
e1000_down(adapter);
e1000_power_down_phy(adapter);
e1000_free_irq(adapter);
--
2.25.1
[PATCH AUTOSEL 4.4 58/64] perf kcore_copy: Fix module map when there are no modules loaded
From: Adrian Hunter
[ Upstream commit 61f82e3fb697a8e85f22fdec786528af73dc36d1 ]
In the absence of any modules, no "modules" map is created, but there
are other executable pages to map, due to eBPF JIT, kprobe or ftrace.
Map them by recognizing that the first "module" symbol is not
necessarily from a module, and adjust the map accordingly.
Signed-off-by: Adrian Hunter
Cc: Alexander Shishkin
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Jiri Olsa
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Peter Zijlstra
Cc: Steven Rostedt (VMware)
Cc: x...@kernel.org
Link: http://lore.kernel.org/lkml/20200512121922.8997-10-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/util/symbol-elf.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 2070c02de3af5..ea55cb6b614f4 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1390,6 +1390,7 @@ struct kcore_copy_info {
u64 first_symbol;
u64 last_symbol;
u64 first_module;
+ u64 first_module_symbol;
u64 last_module_symbol;
struct phdr_data kernel_map;
struct phdr_data modules_map;
@@ -1404,6 +1405,8 @@ static int kcore_copy__process_kallsyms(void *arg, const
char *name, char type,
return 0;
if (strchr(name, '[')) {
+ if (!kci->first_module_symbol || start <
kci->first_module_symbol)
+ kci->first_module_symbol = start;
if (start > kci->last_module_symbol)
kci->last_module_symbol = start;
return 0;
@@ -1528,6 +1531,10 @@ static int kcore_copy__calc_maps(struct kcore_copy_info
*kci, const char *dir,
kci->etext += page_size;
}
+ if (kci->first_module_symbol &&
+ (!kci->first_module || kci->first_module_symbol <
kci->first_module))
+ kci->first_module = kci->first_module_symbol;
+
kci->first_module = round_down(kci->first_module, page_size);
if (kci->last_module_symbol) {
--
2.25.1
[PATCH AUTOSEL 4.4 64/64] vfio/pci: fix racy on error and request eventfd ctx
From: Zeng Tao
[ Upstream commit b872d0640840018669032b20b6375a478ed1f923 ]
The vfio_pci_release call will free and clear the error and request
eventfd ctx while these ctx could be in use at the same time in the
function like vfio_pci_request, and it's expected to protect them under
the vdev->igate mutex, which is missing in vfio_pci_release.
This issue is introduced since commit 1518ac272e78 ("vfio/pci: fix memory
leaks of eventfd ctx"),and since commit 5c5866c593bb ("vfio/pci: Clear
error and request eventfd ctx after releasing"), it's very easily to
trigger the kernel panic like this:
[ 9513.904346] Unable to handle kernel NULL pointer dereference at virtual
address 0008
[ 9513.913091] Mem abort info:
[ 9513.915871] ESR = 0x9606
[ 9513.918912] EC = 0x25: DABT (current EL), IL = 32 bits
[ 9513.924198] SET = 0, FnV = 0
[ 9513.927238] EA = 0, S1PTW = 0
[ 9513.930364] Data abort info:
[ 9513.933231] ISV = 0, ISS = 0x0006
[ 9513.937048] CM = 0, WnR = 0
[ 9513.940003] user pgtable: 4k pages, 48-bit VAs, pgdp=007ec7d12000
[ 9513.946414] [0008] pgd=007ec7d13003, p4d=007ec7d13003,
pud=007ec728c003, pmd=
[ 9513.956975] Internal error: Oops: 9606 [#1] PREEMPT SMP
[ 9513.962521] Modules linked in: vfio_pci vfio_virqfd vfio_iommu_type1 vfio
hclge hns3 hnae3 [last unloaded: vfio_pci]
[ 9513.972998] CPU: 4 PID: 1327 Comm: bash Tainted: GW
5.8.0-rc4+ #3
[ 9513.980443] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS
V3.B270.01 05/08/2020
[ 9513.989274] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--)
[ 9513.994827] pc : _raw_spin_lock_irqsave+0x48/0x88
[ 9513.999515] lr : eventfd_signal+0x6c/0x1b0
[ 9514.003591] sp : 800038a0b960
[ 9514.006889] x29: 800038a0b960 x28: 007ef7f4da10
[ 9514.012175] x27: 207eefbbfc80 x26: bb7903457000
[ 9514.017462] x25: bb7912191000 x24: 007ef7f4d400
[ 9514.022747] x23: 20be6e0e4c00 x22: 0008
[ 9514.028033] x21: x20:
[ 9514.033321] x19: 0008 x18:
[ 9514.038606] x17: x16: bb7910029328
[ 9514.043893] x15: x14: 0001
[ 9514.049179] x13: x12: 0002
[ 9514.054466] x11: x10: 0a00
[ 9514.059752] x9 : 800038a0b840 x8 : 007ef7f4de60
[ 9514.065038] x7 : 007fffc96690 x6 : fe01faffb748
[ 9514.070324] x5 : x4 :
[ 9514.075609] x3 : x2 : 0001
[ 9514.080895] x1 : 007ef7f4d400 x0 :
[ 9514.086181] Call trace:
[ 9514.088618] _raw_spin_lock_irqsave+0x48/0x88
[ 9514.092954] eventfd_signal+0x6c/0x1b0
[ 9514.096691] vfio_pci_request+0x84/0xd0 [vfio_pci]
[ 9514.101464] vfio_del_group_dev+0x150/0x290 [vfio]
[ 9514.106234] vfio_pci_remove+0x30/0x128 [vfio_pci]
[ 9514.111007] pci_device_remove+0x48/0x108
[ 9514.115001] device_release_driver_internal+0x100/0x1b8
[ 9514.120200] device_release_driver+0x28/0x38
[ 9514.124452] pci_stop_bus_device+0x68/0xa8
[ 9514.128528] pci_stop_and_remove_bus_device+0x20/0x38
[ 9514.133557] pci_iov_remove_virtfn+0xb4/0x128
[ 9514.137893] sriov_disable+0x3c/0x108
[ 9514.141538] pci_disable_sriov+0x28/0x38
[ 9514.145445] hns3_pci_sriov_configure+0x48/0xb8 [hns3]
[ 9514.150558] sriov_numvfs_store+0x110/0x198
[ 9514.154724] dev_attr_store+0x44/0x60
[ 9514.158373] sysfs_kf_write+0x5c/0x78
[ 9514.162018] kernfs_fop_write+0x104/0x210
[ 9514.166010] __vfs_write+0x48/0x90
[ 9514.169395] vfs_write+0xbc/0x1c0
[ 9514.172694] ksys_write+0x74/0x100
[ 9514.176079] __arm64_sys_write+0x24/0x30
[ 9514.179987] el0_svc_common.constprop.4+0x110/0x200
[ 9514.184842] do_el0_svc+0x34/0x98
[ 9514.188144] el0_svc+0x14/0x40
[ 9514.191185] el0_sync_handler+0xb0/0x2d0
[ 9514.195088] el0_sync+0x140/0x180
[ 9514.198389] Code: b9001020 d280 52800022 f9800271 (885ffe61)
[ 9514.204455] ---[ end trace 648de00c8406465f ]---
[ 9514.212308] note: bash[1327] exited with preempt_count 1
Cc: Qian Cai
Cc: Alex Williamson
Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx")
Signed-off-by: Zeng Tao
Signed-off-by: Alex Williamson
Signed-off-by: Sasha Levin
---
drivers/vfio/pci/vfio_pci.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 662ea7ec82926..8276ef7f3e834 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -255,14 +255,19 @@ static void vfio_pci_release(void *device_data)
if (!(--vdev->refcnt)) {
vfio_spapr_pci_eeh_release(vdev->pdev);
vfio_pci_disable(vdev);
+ mutex_lock(>igate);
if (vdev->err_trigger) {
eventfd_ctx_put(vdev->err_trigger);
vdev->err_trigger = NULL;
}
+ mutex_unlock(>igate);
+
+
[PATCH AUTOSEL 4.4 63/64] vfio/pci: Clear error and request eventfd ctx after releasing
From: Alex Williamson
[ Upstream commit 5c5866c593bbd444d0339ede6a8fb5f14ff66d72 ]
The next use of the device will generate an underflow from the
stale reference.
Cc: Qian Cai
Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx")
Reported-by: Daniel Wagner
Reviewed-by: Cornelia Huck
Tested-by: Daniel Wagner
Signed-off-by: Alex Williamson
Signed-off-by: Sasha Levin
---
drivers/vfio/pci/vfio_pci.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index ab765770e8dd6..662ea7ec82926 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -255,10 +255,14 @@ static void vfio_pci_release(void *device_data)
if (!(--vdev->refcnt)) {
vfio_spapr_pci_eeh_release(vdev->pdev);
vfio_pci_disable(vdev);
- if (vdev->err_trigger)
+ if (vdev->err_trigger) {
eventfd_ctx_put(vdev->err_trigger);
- if (vdev->req_trigger)
+ vdev->err_trigger = NULL;
+ }
+ if (vdev->req_trigger) {
eventfd_ctx_put(vdev->req_trigger);
+ vdev->req_trigger = NULL;
+ }
}
mutex_unlock(_lock);
--
2.25.1
[PATCH AUTOSEL 4.4 60/64] ceph: fix potential race in ceph_check_caps
From: Jeff Layton
[ Upstream commit dc3da0461cc4b76f2d0c5b12247fcb3b520edbbf ]
Nothing ensures that session will still be valid by the time we
dereference the pointer. Take and put a reference.
In principle, we should always be able to get a reference here, but
throw a warning if that's ever not the case.
Signed-off-by: Jeff Layton
Signed-off-by: Ilya Dryomov
Signed-off-by: Sasha Levin
---
fs/ceph/caps.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index 3d0497421e62b..49e693232916f 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -1777,12 +1777,24 @@ ack:
if (mutex_trylock(>s_mutex) == 0) {
dout("inverting session/ino locks on %p\n",
session);
+ session = ceph_get_mds_session(session);
spin_unlock(>i_ceph_lock);
if (took_snap_rwsem) {
up_read(>snap_rwsem);
took_snap_rwsem = 0;
}
- mutex_lock(>s_mutex);
+ if (session) {
+ mutex_lock(>s_mutex);
+ ceph_put_mds_session(session);
+ } else {
+ /*
+* Because we take the reference while
+* holding the i_ceph_lock, it should
+* never be NULL. Throw a warning if it
+* ever is.
+*/
+ WARN_ON_ONCE(true);
+ }
goto retry;
}
}
--
2.25.1
[PATCH AUTOSEL 4.4 37/64] SUNRPC: Fix a potential buffer overflow in 'svc_print_xprts()'
From: Christophe JAILLET
[ Upstream commit b25b60d7bfb02a74bc3c2d998e09aab159df8059 ]
'maxlen' is the total size of the destination buffer. There is only one
caller and this value is 256.
When we compute the size already used and what we would like to add in
the buffer, the trailling NULL character is not taken into account.
However, this trailling character will be added by the 'strcat' once we
have checked that we have enough place.
So, there is a off-by-one issue and 1 byte of the stack could be
erroneously overwridden.
Take into account the trailling NULL, when checking if there is enough
place in the destination buffer.
While at it, also replace a 'sprintf' by a safer 'snprintf', check for
output truncation and avoid a superfluous 'strlen'.
Fixes: dc9a16e49dbba ("svc: Add /proc/sys/sunrpc/transport files")
Signed-off-by: Christophe JAILLET
[ cel: very minor fix to documenting comment
Signed-off-by: Chuck Lever
Signed-off-by: Sasha Levin
---
net/sunrpc/svc_xprt.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index 2b8e80c721db1..a7cd031656801 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -97,8 +97,17 @@ void svc_unreg_xprt_class(struct svc_xprt_class *xcl)
}
EXPORT_SYMBOL_GPL(svc_unreg_xprt_class);
-/*
- * Format the transport list for printing
+/**
+ * svc_print_xprts - Format the transport list for printing
+ * @buf: target buffer for formatted address
+ * @maxlen: length of target buffer
+ *
+ * Fills in @buf with a string containing a list of transport names, each name
+ * terminated with '\n'. If the buffer is too small, some entries may be
+ * missing, but it is guaranteed that all lines in the output buffer are
+ * complete.
+ *
+ * Returns positive length of the filled-in string.
*/
int svc_print_xprts(char *buf, int maxlen)
{
@@ -111,9 +120,9 @@ int svc_print_xprts(char *buf, int maxlen)
list_for_each_entry(xcl, _xprt_class_list, xcl_list) {
int slen;
- sprintf(tmpstr, "%s %d\n", xcl->xcl_name, xcl->xcl_max_payload);
- slen = strlen(tmpstr);
- if (len + slen > maxlen)
+ slen = snprintf(tmpstr, sizeof(tmpstr), "%s %d\n",
+ xcl->xcl_name, xcl->xcl_max_payload);
+ if (slen >= sizeof(tmpstr) || len + slen >= maxlen)
break;
len += slen;
strcat(buf, tmpstr);
--
2.25.1
[PATCH AUTOSEL 4.4 62/64] x86/speculation/mds: Mark mds_user_clear_cpu_buffers() __always_inline
From: Thomas Gleixner
[ Upstream commit a7ef9ba986b5fae9d80f8a7b31db0423687efe4e ]
Prevent the compiler from uninlining and creating traceable/probable
functions as this is invoked _after_ context tracking switched to
CONTEXT_USER and rcu idle.
Signed-off-by: Thomas Gleixner
Reviewed-by: Alexandre Chartre
Acked-by: Peter Zijlstra
Link: https://lkml.kernel.org/r/20200505134340.902709...@linutronix.de
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/nospec-branch.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/nospec-branch.h
b/arch/x86/include/asm/nospec-branch.h
index 664e8505ccd63..2f84887e8934c 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -275,7 +275,7 @@ DECLARE_STATIC_KEY_FALSE(mds_idle_clear);
* combination with microcode which triggers a CPU buffer flush when the
* instruction is executed.
*/
-static inline void mds_clear_cpu_buffers(void)
+static __always_inline void mds_clear_cpu_buffers(void)
{
static const u16 ds = __KERNEL_DS;
@@ -296,7 +296,7 @@ static inline void mds_clear_cpu_buffers(void)
*
* Clear CPU buffers if the corresponding static key is enabled
*/
-static inline void mds_user_clear_cpu_buffers(void)
+static __always_inline void mds_user_clear_cpu_buffers(void)
{
if (static_branch_likely(_user_clear))
mds_clear_cpu_buffers();
--
2.25.1
[PATCH AUTOSEL 4.4 25/64] selinux: sel_avc_get_stat_idx should increase position index
From: Vasily Averin [ Upstream commit 8d269a8e2a8f0bca89022f4ec98de460acb90365 ] If seq_file .next function does not change position index, read after some lseek can generate unexpected output. $ dd if=/sys/fs/selinux/avc/cache_stats # usual output lookups hits misses allocations reclaims frees 817223 810034 7189 7189 6992 7037 1934894 1926896 7998 7998 7632 7683 1322812 1317176 5636 5636 5456 5507 1560571 1551548 9023 9023 9056 9115 0+1 records in 0+1 records out 189 bytes copied, 5,1564e-05 s, 3,7 MB/s $# read after lseek to midle of last line $ dd if=/sys/fs/selinux/avc/cache_stats bs=180 skip=1 dd: /sys/fs/selinux/avc/cache_stats: cannot skip to specified offset 056 9115 end of last line 1560571 1551548 9023 9023 9056 9115 <<< whole last line once again 0+1 records in 0+1 records out 45 bytes copied, 8,7221e-05 s, 516 kB/s $# read after lseek beyond end of of file $ dd if=/sys/fs/selinux/avc/cache_stats bs=1000 skip=1 dd: /sys/fs/selinux/avc/cache_stats: cannot skip to specified offset 1560571 1551548 9023 9023 9056 9115 generates whole last line 0+1 records in 0+1 records out 36 bytes copied, 9,0934e-05 s, 396 kB/s https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Sasha Levin --- security/selinux/selinuxfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c index c02da25d7b631..7778e28cce9d7 100644 --- a/security/selinux/selinuxfs.c +++ b/security/selinux/selinuxfs.c @@ -1370,6 +1370,7 @@ static struct avc_cache_stats *sel_avc_get_stat_idx(loff_t *idx) *idx = cpu + 1; return _cpu(avc_cache_stats, cpu); } + (*idx)++; return NULL; } -- 2.25.1
[PATCH AUTOSEL 4.4 23/64] skbuff: fix a data race in skb_queue_len()
From: Qian Cai
[ Upstream commit 86b18aaa2b5b5bb48e609cd591b3d2d0fdbe0442 ]
sk_buff.qlen can be accessed concurrently as noticed by KCSAN,
BUG: KCSAN: data-race in __skb_try_recv_from_queue / unix_dgram_sendmsg
read to 0x8a1b1d8a81c0 of 4 bytes by task 5371 on cpu 96:
unix_dgram_sendmsg+0x9a9/0xb70 include/linux/skbuff.h:1821
net/unix/af_unix.c:1761
sys_sendmsg+0x33e/0x370
___sys_sendmsg+0xa6/0xf0
__sys_sendmsg+0x69/0xf0
__x64_sys_sendmsg+0x51/0x70
do_syscall_64+0x91/0xb47
entry_SYSCALL_64_after_hwframe+0x49/0xbe
write to 0x8a1b1d8a81c0 of 4 bytes by task 1 on cpu 99:
__skb_try_recv_from_queue+0x327/0x410 include/linux/skbuff.h:2029
__skb_try_recv_datagram+0xbe/0x220
unix_dgram_recvmsg+0xee/0x850
sys_recvmsg+0x1fb/0x210
___sys_recvmsg+0xa2/0xf0
__sys_recvmsg+0x66/0xf0
__x64_sys_recvmsg+0x51/0x70
do_syscall_64+0x91/0xb47
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Since only the read is operating as lockless, it could introduce a logic
bug in unix_recvq_full() due to the load tearing. Fix it by adding
a lockless variant of skb_queue_len() and unix_recvq_full() where
READ_ONCE() is on the read while WRITE_ONCE() is on the write similar to
the commit d7d16a89350a ("net: add skb_queue_empty_lockless()").
Signed-off-by: Qian Cai
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
include/linux/skbuff.h | 14 +-
net/unix/af_unix.c | 11 +--
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 735ff1525f485..ffd698f70a84e 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1438,6 +1438,18 @@ static inline __u32 skb_queue_len(const struct
sk_buff_head *list_)
return list_->qlen;
}
+/**
+ * skb_queue_len_lockless - get queue length
+ * @list_: list to measure
+ *
+ * Return the length of an _buff queue.
+ * This variant can be used in lockless contexts.
+ */
+static inline __u32 skb_queue_len_lockless(const struct sk_buff_head *list_)
+{
+ return READ_ONCE(list_->qlen);
+}
+
/**
* __skb_queue_head_init - initialize non-spinlock portions of sk_buff_head
* @list: queue to initialize
@@ -1641,7 +1653,7 @@ static inline void __skb_unlink(struct sk_buff *skb,
struct sk_buff_head *list)
{
struct sk_buff *next, *prev;
- list->qlen--;
+ WRITE_ONCE(list->qlen, list->qlen - 1);
next = skb->next;
prev = skb->prev;
skb->next = skb->prev = NULL;
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index b5e2ef242efe7..ac78c5ac82846 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -191,11 +191,17 @@ static inline int unix_may_send(struct sock *sk, struct
sock *osk)
return unix_peer(osk) == NULL || unix_our_peer(sk, osk);
}
-static inline int unix_recvq_full(struct sock const *sk)
+static inline int unix_recvq_full(const struct sock *sk)
{
return skb_queue_len(>sk_receive_queue) > sk->sk_max_ack_backlog;
}
+static inline int unix_recvq_full_lockless(const struct sock *sk)
+{
+ return skb_queue_len_lockless(>sk_receive_queue) >
+ READ_ONCE(sk->sk_max_ack_backlog);
+}
+
struct sock *unix_peer_get(struct sock *s)
{
struct sock *peer;
@@ -1792,7 +1798,8 @@ restart_locked:
* - unix_peer(sk) == sk by time of get but disconnected before lock
*/
if (other != sk &&
- unlikely(unix_peer(other) != sk && unix_recvq_full(other))) {
+ unlikely(unix_peer(other) != sk &&
+ unix_recvq_full_lockless(other))) {
if (timeo) {
timeo = unix_wait_for_peer(other, timeo);
--
2.25.1
[PATCH AUTOSEL 4.4 19/64] ar5523: Add USB ID of SMCWUSBT-G2 wireless adapter
From: Mert Dirik
[ Upstream commit 5b362498a79631f283578b64bf6f4d15ed4cc19a ]
Add the required USB ID for running SMCWUSBT-G2 wireless adapter (SMC
"EZ Connect g").
This device uses ar5523 chipset and requires firmware to be loaded. Even
though pid of the device is 4507, this patch adds it as 4506 so that
AR5523_DEVICE_UG macro can set the AR5523_FLAG_PRE_FIRMWARE flag for pid
4507.
Signed-off-by: Mert Dirik
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
---
drivers/net/wireless/ath/ar5523/ar5523.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c
b/drivers/net/wireless/ath/ar5523/ar5523.c
index 5bf22057459e6..bc6330b437958 100644
--- a/drivers/net/wireless/ath/ar5523/ar5523.c
+++ b/drivers/net/wireless/ath/ar5523/ar5523.c
@@ -1774,6 +1774,8 @@ static struct usb_device_id ar5523_id_table[] = {
AR5523_DEVICE_UX(0x0846, 0x4300), /* Netgear / WG111U */
AR5523_DEVICE_UG(0x0846, 0x4250), /* Netgear / WG111T */
AR5523_DEVICE_UG(0x0846, 0x5f00), /* Netgear / WPN111 */
+ AR5523_DEVICE_UG(0x083a, 0x4506), /* SMC / EZ Connect
+ SMCWUSBT-G2 */
AR5523_DEVICE_UG(0x157e, 0x3006), /* Umedia / AR5523_1 */
AR5523_DEVICE_UX(0x157e, 0x3205), /* Umedia / AR5523_2 */
AR5523_DEVICE_UG(0x157e, 0x3006), /* Umedia / TEW444UBEU */
--
2.25.1
[PATCH AUTOSEL 4.4 24/64] audit: CONFIG_CHANGE don't log internal bookkeeping as an event
From: Steve Grubb [ Upstream commit 70b3eeed49e8190d97139806f6fbaf8964306cdb ] Common Criteria calls out for any action that modifies the audit trail to be recorded. That usually is interpreted to mean insertion or removal of rules. It is not required to log modification of the inode information since the watch is still in effect. Additionally, if the rule is a never rule and the underlying file is one they do not want events for, they get an event for this bookkeeping update against their wishes. Since no device/inode info is logged at insertion and no device/inode information is logged on update, there is nothing meaningful being communicated to the admin by the CONFIG_CHANGE updated_rules event. One can assume that the rule was not "modified" because it is still watching the intended target. If the device or inode cannot be resolved, then audit_panic is called which is sufficient. The correct resolution is to drop logging config_update events since the watch is still in effect but just on another unknown inode. Signed-off-by: Steve Grubb Signed-off-by: Paul Moore Signed-off-by: Sasha Levin --- kernel/audit_watch.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c index f45a9a5d3e47a..af453f3c2b3dd 100644 --- a/kernel/audit_watch.c +++ b/kernel/audit_watch.c @@ -316,8 +316,6 @@ static void audit_update_watch(struct audit_parent *parent, if (oentry->rule.exe) audit_remove_mark(oentry->rule.exe); - audit_watch_log_rule_change(r, owatch, "updated_rules"); - call_rcu(>rcu, audit_free_rule_rcu); } -- 2.25.1
[PATCH AUTOSEL 4.4 38/64] ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len
From: Liu Song
[ Upstream commit acc5af3efa303d5f36cc8c0f61716161f6ca1384 ]
In “ubifs_check_node”, when the value of "node_len" is abnormal,
the code will goto label of "out_len" for execution. Then, in the
following "ubifs_dump_node", if inode type is "UBIFS_DATA_NODE",
in "print_hex_dump", an out-of-bounds access may occur due to the
wrong "ch->len".
Therefore, when the value of "node_len" is abnormal, data length
should to be adjusted to a reasonable safe range. At this time,
structured data is not credible, so dump the corrupted data directly
for analysis.
Signed-off-by: Liu Song
Signed-off-by: Richard Weinberger
Signed-off-by: Sasha Levin
---
fs/ubifs/io.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c
index 97be412153328..9213a9e046ae0 100644
--- a/fs/ubifs/io.c
+++ b/fs/ubifs/io.c
@@ -237,7 +237,7 @@ int ubifs_is_mapped(const struct ubifs_info *c, int lnum)
int ubifs_check_node(const struct ubifs_info *c, const void *buf, int lnum,
int offs, int quiet, int must_chk_crc)
{
- int err = -EINVAL, type, node_len;
+ int err = -EINVAL, type, node_len, dump_node = 1;
uint32_t crc, node_crc, magic;
const struct ubifs_ch *ch = buf;
@@ -290,10 +290,22 @@ int ubifs_check_node(const struct ubifs_info *c, const
void *buf, int lnum,
out_len:
if (!quiet)
ubifs_err(c, "bad node length %d", node_len);
+ if (type == UBIFS_DATA_NODE && node_len > UBIFS_DATA_NODE_SZ)
+ dump_node = 0;
out:
if (!quiet) {
ubifs_err(c, "bad node at LEB %d:%d", lnum, offs);
- ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\tprevent out-of-bounds memory access\n");
+ pr_err("\ttruncated data node length %d\n",
safe_len);
+ pr_err("\tcorrupted data node:\n");
+ print_hex_dump(KERN_ERR, "\t", DUMP_PREFIX_OFFSET, 32,
1,
+ buf, safe_len, 0);
+ }
dump_stack();
}
return err;
--
2.25.1
[PATCH AUTOSEL 4.4 14/64] rt_cpu_seq_next should increase position index
From: Vasily Averin [ Upstream commit a3ea86739f1bc7e121d921842f0f4a8ab1af94d9 ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- net/ipv4/route.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 542f6e0f438f1..ea1c319100a5d 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -271,6 +271,7 @@ static void *rt_cpu_seq_next(struct seq_file *seq, void *v, loff_t *pos) *pos = cpu+1; return _cpu(rt_cache_stat, cpu); } + (*pos)++; return NULL; } -- 2.25.1
Re: [PATCH RFC 2/4] mm/page_alloc: place pages to tail in __putback_isolated_page()
On Wed, Sep 16, 2020 at 08:34:09PM +0200, David Hildenbrand wrote: >__putback_isolated_page() already documents that pages will be placed to >the tail of the freelist - this is, however, not the case for >"order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be >the case for all existing users. > >This change affects two users: >- free page reporting >- page isolation, when undoing the isolation. > >This behavior is desireable for pages that haven't really been touched >lately, so exactly the two users that don't actually read/write page >content, but rather move untouched pages. > >The new behavior is especially desirable for memory onlining, where we >allow allocation of newly onlined pages via undo_isolate_page_range() >in online_pages(). Right now, we always place them to the head of the >free list, resulting in undesireable behavior: Assume we add >individual memory chunks via add_memory() and online them right away to >the NORMAL zone. We create a dependency chain of unmovable allocations >e.g., via the memmap. The memmap of the next chunk will be placed onto >previous chunks - if the last block cannot get offlined+removed, all >dependent ones cannot get offlined+removed. While this can already be >observed with individual DIMMs, it's more of an issue for virtio-mem >(and I suspect also ppc DLPAR). > >Note: If we observe a degradation due to the changed page isolation >behavior (which I doubt), we can always make this configurable by the >instance triggering undo of isolation (e.g., alloc_contig_range(), >memory onlining, memory offlining). > >Cc: Andrew Morton >Cc: Alexander Duyck >Cc: Mel Gorman >Cc: Michal Hocko >Cc: Dave Hansen >Cc: Vlastimil Babka >Cc: Wei Yang >Cc: Oscar Salvador >Cc: Mike Rapoport >Cc: Scott Cheloha >Cc: Michael Ellerman >Signed-off-by: David Hildenbrand >--- > mm/page_alloc.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > >diff --git a/mm/page_alloc.c b/mm/page_alloc.c >index 91cefb8157dd..bba9a0f60c70 100644 >--- a/mm/page_alloc.c >+++ b/mm/page_alloc.c >@@ -89,6 +89,12 @@ typedef int __bitwise fop_t; > */ > #define FOP_SKIP_REPORT_NOTIFY((__force fop_t)BIT(0)) > >+/* >+ * Place the freed page to the tail of the freelist after buddy merging. Will >+ * get ignored with page shuffling enabled. >+ */ >+#define FOP_TO_TAIL ((__force fop_t)BIT(1)) >+ > /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */ > static DEFINE_MUTEX(pcp_batch_high_lock); > #define MIN_PERCPU_PAGELIST_FRACTION (8) >@@ -1040,6 +1046,8 @@ static inline void __free_one_page(struct page *page, >unsigned long pfn, > > if (is_shuffle_order(order)) > to_tail = shuffle_pick_tail(); >+ else if (fop_flags & FOP_TO_TAIL) >+ to_tail = true; Take another look into this part. Maybe we can move this check at top? For online_page case, currently we have following call flow: online_page online_pages_range shuffle_zone This means we would always shuffle the newly added pages. Maybe we don't need to do the shuffle when adding them to the free_list? > else > to_tail = buddy_merge_likely(pfn, buddy_pfn, page, order); > >@@ -3289,7 +3297,7 @@ void __putback_isolated_page(struct page *page, unsigned >int order, int mt) > > /* Return isolated page to tail of freelist. */ > __free_one_page(page, page_to_pfn(page), zone, order, mt, >- FOP_SKIP_REPORT_NOTIFY); >+ FOP_SKIP_REPORT_NOTIFY | FOP_TO_TAIL); > } > > /* >-- >2.26.2 -- Wei Yang Help you, Help me
[PATCH AUTOSEL 4.9 90/90] vfio/pci: fix racy on error and request eventfd ctx
From: Zeng Tao
[ Upstream commit b872d0640840018669032b20b6375a478ed1f923 ]
The vfio_pci_release call will free and clear the error and request
eventfd ctx while these ctx could be in use at the same time in the
function like vfio_pci_request, and it's expected to protect them under
the vdev->igate mutex, which is missing in vfio_pci_release.
This issue is introduced since commit 1518ac272e78 ("vfio/pci: fix memory
leaks of eventfd ctx"),and since commit 5c5866c593bb ("vfio/pci: Clear
error and request eventfd ctx after releasing"), it's very easily to
trigger the kernel panic like this:
[ 9513.904346] Unable to handle kernel NULL pointer dereference at virtual
address 0008
[ 9513.913091] Mem abort info:
[ 9513.915871] ESR = 0x9606
[ 9513.918912] EC = 0x25: DABT (current EL), IL = 32 bits
[ 9513.924198] SET = 0, FnV = 0
[ 9513.927238] EA = 0, S1PTW = 0
[ 9513.930364] Data abort info:
[ 9513.933231] ISV = 0, ISS = 0x0006
[ 9513.937048] CM = 0, WnR = 0
[ 9513.940003] user pgtable: 4k pages, 48-bit VAs, pgdp=007ec7d12000
[ 9513.946414] [0008] pgd=007ec7d13003, p4d=007ec7d13003,
pud=007ec728c003, pmd=
[ 9513.956975] Internal error: Oops: 9606 [#1] PREEMPT SMP
[ 9513.962521] Modules linked in: vfio_pci vfio_virqfd vfio_iommu_type1 vfio
hclge hns3 hnae3 [last unloaded: vfio_pci]
[ 9513.972998] CPU: 4 PID: 1327 Comm: bash Tainted: GW
5.8.0-rc4+ #3
[ 9513.980443] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS
V3.B270.01 05/08/2020
[ 9513.989274] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--)
[ 9513.994827] pc : _raw_spin_lock_irqsave+0x48/0x88
[ 9513.999515] lr : eventfd_signal+0x6c/0x1b0
[ 9514.003591] sp : 800038a0b960
[ 9514.006889] x29: 800038a0b960 x28: 007ef7f4da10
[ 9514.012175] x27: 207eefbbfc80 x26: bb7903457000
[ 9514.017462] x25: bb7912191000 x24: 007ef7f4d400
[ 9514.022747] x23: 20be6e0e4c00 x22: 0008
[ 9514.028033] x21: x20:
[ 9514.033321] x19: 0008 x18:
[ 9514.038606] x17: x16: bb7910029328
[ 9514.043893] x15: x14: 0001
[ 9514.049179] x13: x12: 0002
[ 9514.054466] x11: x10: 0a00
[ 9514.059752] x9 : 800038a0b840 x8 : 007ef7f4de60
[ 9514.065038] x7 : 007fffc96690 x6 : fe01faffb748
[ 9514.070324] x5 : x4 :
[ 9514.075609] x3 : x2 : 0001
[ 9514.080895] x1 : 007ef7f4d400 x0 :
[ 9514.086181] Call trace:
[ 9514.088618] _raw_spin_lock_irqsave+0x48/0x88
[ 9514.092954] eventfd_signal+0x6c/0x1b0
[ 9514.096691] vfio_pci_request+0x84/0xd0 [vfio_pci]
[ 9514.101464] vfio_del_group_dev+0x150/0x290 [vfio]
[ 9514.106234] vfio_pci_remove+0x30/0x128 [vfio_pci]
[ 9514.111007] pci_device_remove+0x48/0x108
[ 9514.115001] device_release_driver_internal+0x100/0x1b8
[ 9514.120200] device_release_driver+0x28/0x38
[ 9514.124452] pci_stop_bus_device+0x68/0xa8
[ 9514.128528] pci_stop_and_remove_bus_device+0x20/0x38
[ 9514.133557] pci_iov_remove_virtfn+0xb4/0x128
[ 9514.137893] sriov_disable+0x3c/0x108
[ 9514.141538] pci_disable_sriov+0x28/0x38
[ 9514.145445] hns3_pci_sriov_configure+0x48/0xb8 [hns3]
[ 9514.150558] sriov_numvfs_store+0x110/0x198
[ 9514.154724] dev_attr_store+0x44/0x60
[ 9514.158373] sysfs_kf_write+0x5c/0x78
[ 9514.162018] kernfs_fop_write+0x104/0x210
[ 9514.166010] __vfs_write+0x48/0x90
[ 9514.169395] vfs_write+0xbc/0x1c0
[ 9514.172694] ksys_write+0x74/0x100
[ 9514.176079] __arm64_sys_write+0x24/0x30
[ 9514.179987] el0_svc_common.constprop.4+0x110/0x200
[ 9514.184842] do_el0_svc+0x34/0x98
[ 9514.188144] el0_svc+0x14/0x40
[ 9514.191185] el0_sync_handler+0xb0/0x2d0
[ 9514.195088] el0_sync+0x140/0x180
[ 9514.198389] Code: b9001020 d280 52800022 f9800271 (885ffe61)
[ 9514.204455] ---[ end trace 648de00c8406465f ]---
[ 9514.212308] note: bash[1327] exited with preempt_count 1
Cc: Qian Cai
Cc: Alex Williamson
Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx")
Signed-off-by: Zeng Tao
Signed-off-by: Alex Williamson
Signed-off-by: Sasha Levin
---
drivers/vfio/pci/vfio_pci.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index c08cff0ca08df..237d5aceb302d 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -392,14 +392,19 @@ static void vfio_pci_release(void *device_data)
if (!(--vdev->refcnt)) {
vfio_spapr_pci_eeh_release(vdev->pdev);
vfio_pci_disable(vdev);
+ mutex_lock(>igate);
if (vdev->err_trigger) {
eventfd_ctx_put(vdev->err_trigger);
vdev->err_trigger = NULL;
}
+ mutex_unlock(>igate);
+
+
[PATCH AUTOSEL 4.9 73/90] tty: serial: samsung: Correct clock selection logic
From: Jonathan Bakker
[ Upstream commit 7d31676a8d91dd18e08853efd1cb26961a38c6a6 ]
Some variants of the samsung tty driver can pick which clock
to use for their baud rate generation. In the DT conversion,
a default clock was selected to be used if a specific one wasn't
assigned and then a comparison of which clock rate worked better
was done. Unfortunately, the comparison was implemented in such
a way that only the default clock was ever actually compared.
Fix this by iterating through all possible clocks, except when a
specific clock has already been picked via clk_sel (which is
only possible via board files).
Signed-off-by: Jonathan Bakker
Reviewed-by: Krzysztof Kozlowski
Link:
https://lore.kernel.org/r/bn6pr04mb06604e63833ea41837ebf77ba3...@bn6pr04mb0660.namprd04.prod.outlook.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/tty/serial/samsung.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 4dfdb59061bea..8c89697c53573 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1157,14 +1157,14 @@ static unsigned int s3c24xx_serial_getclk(struct
s3c24xx_uart_port *ourport,
struct s3c24xx_uart_info *info = ourport->info;
struct clk *clk;
unsigned long rate;
- unsigned int cnt, baud, quot, clk_sel, best_quot = 0;
+ unsigned int cnt, baud, quot, best_quot = 0;
char clkname[MAX_CLK_NAME_LENGTH];
int calc_deviation, deviation = (1 << 30) - 1;
- clk_sel = (ourport->cfg->clk_sel) ? ourport->cfg->clk_sel :
- ourport->info->def_clk_sel;
for (cnt = 0; cnt < info->num_clks; cnt++) {
- if (!(clk_sel & (1 << cnt)))
+ /* Keep selected clock if provided */
+ if (ourport->cfg->clk_sel &&
+ !(ourport->cfg->clk_sel & (1 << cnt)))
continue;
sprintf(clkname, "clk_uart_baud%d", cnt);
--
2.25.1
Re: [PATCH RESEND v3 0/5] media: uvcvideo: Fix race conditions
Hi Laurent, On 9/17/20 5:47 AM, Laurent Pinchart wrote: > Hi Guenter, > > On Wed, Sep 16, 2020 at 07:25:42PM -0700, Guenter Roeck wrote: >> Something seems to have gone wrong with v3 of this patch series. >> I am sure I sent it out, but I don't find it anywhere. >> Resending. Sorry for any duplicates. > > I haven't checked the mailing list, but I've found it in my inbox :-) > I'm not forgetting about you, just been fairly busy recently. I still > plan to try and provide an alternative implementation in the V4L2 core > (in a form that I think should even be moved to the cdev core) that > would fix this for all drivers. > Thanks for letting me know. As it turns out, this problem is responsible for about 2% of all Chromebook crashes, so I'll probably not wait for the series to be accepted upstream but apply it as-is to the various ChromeOS kernel branches. > By the way, as you managed to get hold of non-UVC webcams, one thing you > could try in your tests to make the drivers misbehave is to block on a > DQBUF call, and unplug the device at that time. When blocking, DQBUF > releases the driver lock (through the vb2ops .wait_prepare() and > .wait_finis() operations for drivers based on vb2), so this may allow > unregistration to proceed without waiting for userspace calls to > complete. > Good idea. I'll give it a try. Thanks, Guenter >> The uvcvideo code has no lock protection against USB disconnects >> while video operations are ongoing. This has resulted in random >> error reports, typically pointing to a crash in usb_ifnum_to_if(), >> called from usb_hcd_alloc_bandwidth(). A typical traceback is as >> follows. >> >> usb 1-4: USB disconnect, device number 3 >> BUG: unable to handle kernel NULL pointer dereference at >> PGD 0 P4D 0 >> Oops: [#1] PREEMPT SMP PTI >> CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted >> 4.19.113-08536-g5d29ca36db06 #1 >> Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019 >> RIP: 0010:usb_ifnum_to_if+0x29/0x40 >> Code: <...> >> RSP: 0018:a46f42a47a80 EFLAGS: 00010246 >> RAX: RBX: RCX: 904a396c9000 >> RDX: 904a39641320 RSI: 0001 RDI: >> RBP: a46f42a47a80 R08: 0002 R09: >> R10: 9975 R11: 0009 R12: >> R13: 904a396b3800 R14: 904a39e88000 R15: >> FS: 7f396448e700() GS:904a3ba0() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: CR3: 00016cb46000 CR4: 001006f0 >> Call Trace: >> usb_hcd_alloc_bandwidth+0x1ee/0x30f >> usb_set_interface+0x1a3/0x2b7 >> uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo] >> uvc_video_start_streaming+0x91/0xdd [uvcvideo] >> uvc_start_streaming+0x28/0x5d [uvcvideo] >> vb2_start_streaming+0x61/0x143 [videobuf2_common] >> vb2_core_streamon+0xf7/0x10f [videobuf2_common] >> uvc_queue_streamon+0x2e/0x41 [uvcvideo] >> uvc_ioctl_streamon+0x42/0x5c [uvcvideo] >> __video_do_ioctl+0x33d/0x42a >> video_usercopy+0x34e/0x5ff >> ? video_ioctl2+0x16/0x16 >> v4l2_ioctl+0x46/0x53 >> do_vfs_ioctl+0x50a/0x76f >> ksys_ioctl+0x58/0x83 >> __x64_sys_ioctl+0x1a/0x1e >> do_syscall_64+0x54/0xde >> >> While there are not many references to this problem on mailing lists, it is >> reported on a regular basis on various Chromebooks (roughly 300 reports >> per month). The problem is relatively easy to reproduce by adding msleep() >> calls into the code. >> >> I tried to reproduce the problem with non-uvcvideo webcams, but was >> unsuccessful. I was unable to get Philips (pwc) webcams to work. gspca >> based webcams don't experience the problem, or at least I was unable to >> reproduce it (The gspa driver does not trigger sending USB messages in the >> open function, and otherwise uses the locking mechanism provided by the >> v4l2/vb2 core). >> >> I don't presume to claim that I found every issue, but this patch series >> should fix at least the major problems. >> >> The patch series was tested exensively on a Chromebook running chromeos-4.19 >> and on a Linux system running a v5.8.y based kernel. >> >> v3: >> - In patch 5/5, add missing calls to usb_autopm_put_interface() and kfree() >> to failure code path >> >> v2: >> - Added details about problem frequency and testing with non-uvc webcams >> to summary >> - In patch 4/5, return EPOLLERR instead of -ENODEV on poll errors >> - Fix description in patch 5/5 >> >> >> Guenter Roeck (5): >> media: uvcvideo: Cancel async worker earlier >> media: uvcvideo: Lock video streams and queues while unregistering >> media: uvcvideo: Release stream queue when unregistering video device >> media: uvcvideo: Protect uvc queue file operations against disconnect >> media: uvcvideo: Abort uvc_v4l2_open if video device is unregistered >> >>
[PATCH AUTOSEL 4.9 83/90] mtd: rawnand: omap_elm: Fix runtime PM imbalance on error
From: Dinghao Liu
[ Upstream commit 37f7212148cf1d796135cdf8d0c7fee13067674b ]
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Signed-off-by: Miquel Raynal
Link:
https://lore.kernel.org/linux-mtd/20200522104008.28340-1-dinghao@zju.edu.cn
Signed-off-by: Sasha Levin
---
drivers/mtd/nand/omap_elm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/nand/omap_elm.c b/drivers/mtd/nand/omap_elm.c
index a3f32f939cc17..6736777a41567 100644
--- a/drivers/mtd/nand/omap_elm.c
+++ b/drivers/mtd/nand/omap_elm.c
@@ -421,6 +421,7 @@ static int elm_probe(struct platform_device *pdev)
pm_runtime_enable(>dev);
if (pm_runtime_get_sync(>dev) < 0) {
ret = -EINVAL;
+ pm_runtime_put_sync(>dev);
pm_runtime_disable(>dev);
dev_err(>dev, "can't enable clock\n");
return ret;
--
2.25.1
[PATCH AUTOSEL 4.9 70/90] phy: samsung: s5pv210-usb2: Add delay after reset
From: Jonathan Bakker
[ Upstream commit 05942b8c36c7eb5d3fc5e375d4b0d0c49562e85d ]
The USB phy takes some time to reset, so make sure we give it to it. The
delay length was taken from the 4x12 phy driver.
This manifested in issues with the DWC2 driver since commit fe369e1826b3
("usb: dwc2: Make dwc2_readl/writel functions endianness-agnostic.")
where the endianness check would read the DWC ID as 0 due to the phy still
resetting, resulting in the wrong endian mode being chosen.
Signed-off-by: Jonathan Bakker
Link:
https://lore.kernel.org/r/bn6pr04mb06605d52502816e500683553a3...@bn6pr04mb0660.namprd04.prod.outlook.com
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Sasha Levin
---
drivers/phy/phy-s5pv210-usb2.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/phy/phy-s5pv210-usb2.c b/drivers/phy/phy-s5pv210-usb2.c
index 004d320767e4d..bb36cfd4e3e90 100644
--- a/drivers/phy/phy-s5pv210-usb2.c
+++ b/drivers/phy/phy-s5pv210-usb2.c
@@ -142,6 +142,10 @@ static void s5pv210_phy_pwr(struct
samsung_usb2_phy_instance *inst, bool on)
udelay(10);
rst &= ~rstbits;
writel(rst, drv->reg_phy + S5PV210_UPHYRST);
+ /* The following delay is necessary for the reset sequence to be
+* completed
+*/
+ udelay(80);
} else {
pwr = readl(drv->reg_phy + S5PV210_UPHYPWR);
pwr |= phypwr;
--
2.25.1
[PATCH AUTOSEL 4.4 07/64] mtd: cfi_cmdset_0002: don't free cfi->cfiq in error path of cfi_amdstd_setup()
From: Hou Tao [ Upstream commit 03976af89e3bd9489d542582a325892e6a8cacc0 ] Else there may be a double-free problem, because cfi->cfiq will be freed by mtd_do_chip_probe() if both the two invocations of check_cmd_set() return failure. Signed-off-by: Hou Tao Reviewed-by: Richard Weinberger Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin --- drivers/mtd/chips/cfi_cmdset_0002.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c index 972935f1b2f7e..3a3da0eeef1fb 100644 --- a/drivers/mtd/chips/cfi_cmdset_0002.c +++ b/drivers/mtd/chips/cfi_cmdset_0002.c @@ -724,7 +724,6 @@ static struct mtd_info *cfi_amdstd_setup(struct mtd_info *mtd) kfree(mtd->eraseregions); kfree(mtd); kfree(cfi->cmdset_priv); - kfree(cfi->cfiq); return NULL; } -- 2.25.1
[PATCH AUTOSEL 4.4 20/64] Bluetooth: Fix refcount use-after-free issue
From: Manish Mandlik
[ Upstream commit 6c08fc896b60893c5d673764b0668015d76df462 ]
There is no lock preventing both l2cap_sock_release() and
chan->ops->close() from running at the same time.
If we consider Thread A running l2cap_chan_timeout() and Thread B running
l2cap_sock_release(), expected behavior is:
A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb()
A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill()
B::l2cap_sock_release()->sock_orphan()
B::l2cap_sock_release()->l2cap_sock_kill()
where,
sock_orphan() clears "sk->sk_socket" and l2cap_sock_teardown_cb() marks
socket as SOCK_ZAPPED.
In l2cap_sock_kill(), there is an "if-statement" that checks if both
sock_orphan() and sock_teardown() has been run i.e. sk->sk_socket is NULL
and socket is marked as SOCK_ZAPPED. Socket is killed if the condition is
satisfied.
In the race condition, following occurs:
A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb()
B::l2cap_sock_release()->sock_orphan()
B::l2cap_sock_release()->l2cap_sock_kill()
A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill()
In this scenario, "if-statement" is true in both B::l2cap_sock_kill() and
A::l2cap_sock_kill() and we hit "refcount: underflow; use-after-free" bug.
Similar condition occurs at other places where teardown/sock_kill is
happening:
l2cap_disconnect_rsp()->l2cap_chan_del()->l2cap_sock_teardown_cb()
l2cap_disconnect_rsp()->l2cap_sock_close_cb()->l2cap_sock_kill()
l2cap_conn_del()->l2cap_chan_del()->l2cap_sock_teardown_cb()
l2cap_conn_del()->l2cap_sock_close_cb()->l2cap_sock_kill()
l2cap_disconnect_req()->l2cap_chan_del()->l2cap_sock_teardown_cb()
l2cap_disconnect_req()->l2cap_sock_close_cb()->l2cap_sock_kill()
l2cap_sock_cleanup_listen()->l2cap_chan_close()->l2cap_sock_teardown_cb()
l2cap_sock_cleanup_listen()->l2cap_sock_kill()
Protect teardown/sock_kill and orphan/sock_kill by adding hold_lock on
l2cap channel to ensure that the socket is killed only after marked as
zapped and orphan.
Signed-off-by: Manish Mandlik
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
---
net/bluetooth/l2cap_core.c | 26 +++---
net/bluetooth/l2cap_sock.c | 16 +---
2 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 0e31bbe1256cd..f6112f495a36c 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -403,6 +403,9 @@ static void l2cap_chan_timeout(struct work_struct *work)
BT_DBG("chan %p state %s", chan, state_to_string(chan->state));
mutex_lock(>chan_lock);
+ /* __set_chan_timer() calls l2cap_chan_hold(chan) while scheduling
+* this work. No need to call l2cap_chan_hold(chan) here again.
+*/
l2cap_chan_lock(chan);
if (chan->state == BT_CONNECTED || chan->state == BT_CONFIG)
@@ -415,12 +418,12 @@ static void l2cap_chan_timeout(struct work_struct *work)
l2cap_chan_close(chan, reason);
- l2cap_chan_unlock(chan);
-
chan->ops->close(chan);
- mutex_unlock(>chan_lock);
+ l2cap_chan_unlock(chan);
l2cap_chan_put(chan);
+
+ mutex_unlock(>chan_lock);
}
struct l2cap_chan *l2cap_chan_create(void)
@@ -1714,9 +1717,9 @@ static void l2cap_conn_del(struct hci_conn *hcon, int err)
l2cap_chan_del(chan, err);
- l2cap_chan_unlock(chan);
-
chan->ops->close(chan);
+
+ l2cap_chan_unlock(chan);
l2cap_chan_put(chan);
}
@@ -4316,6 +4319,7 @@ static inline int l2cap_disconnect_req(struct l2cap_conn
*conn,
return 0;
}
+ l2cap_chan_hold(chan);
l2cap_chan_lock(chan);
rsp.dcid = cpu_to_le16(chan->scid);
@@ -4324,12 +4328,11 @@ static inline int l2cap_disconnect_req(struct
l2cap_conn *conn,
chan->ops->set_shutdown(chan);
- l2cap_chan_hold(chan);
l2cap_chan_del(chan, ECONNRESET);
- l2cap_chan_unlock(chan);
-
chan->ops->close(chan);
+
+ l2cap_chan_unlock(chan);
l2cap_chan_put(chan);
mutex_unlock(>chan_lock);
@@ -4361,20 +4364,21 @@ static inline int l2cap_disconnect_rsp(struct
l2cap_conn *conn,
return 0;
}
+ l2cap_chan_hold(chan);
l2cap_chan_lock(chan);
if (chan->state != BT_DISCONN) {
l2cap_chan_unlock(chan);
+ l2cap_chan_put(chan);
mutex_unlock(>chan_lock);
return 0;
}
- l2cap_chan_hold(chan);
l2cap_chan_del(chan, 0);
- l2cap_chan_unlock(chan);
-
chan->ops->close(chan);
+
+ l2cap_chan_unlock(chan);
l2cap_chan_put(chan);
mutex_unlock(>chan_lock);
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index d9bbbded49ef8..cb024c25530a3 100644
--- a/net/bluetooth/l2cap_sock.c
+++
