linux-toradex.git/drivers, branch v4.9.107

serial: pl011: add console matching function

2018-06-06T14:44:39+00:00

commit 10879ae5f12e9cab3c4e8e9504c1aaa8a033bde7 upstream.

This patch adds function pl011_console_match() that implements
method match of struct console.  It allows to match consoles against
data specified in a string, for example taken from command line or
compiled by ACPI SPCR table handler.

This patch was merged to tty-next but then reverted because of
conflict with

commit 46e36683f433 ("serial: earlycon: Extend earlycon command line option to support 64-bit addresses")

Now it is fixed.

Signed-off-by: Aleksey Makarov 
Reviewed-by: Peter Hurley 
Acked-by: Russell King 
Tested-by: Christopher Covington 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Disable LVDS on Radiant P845

2018-06-06T14:44:38+00:00

commit b3fb22733ae61050f8d10a1d6a8af176c5c5db1a upstream.

Radiant P845 does not have LVDS, only VGA.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105468
Signed-off-by: Ondrej Zary 
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20180309222204.4771-1-linux@rainbow-software.org
(cherry picked from commit 7f7105f99b75aca4f8c2a748ed6b82c7f8be3293)
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Greg Kroah-Hartman

drm/psr: Fix missed entry in PSR setup time table.

2018-06-06T14:44:38+00:00

commit bdcc02cf1bb508fc700df7662f55058f651f2621 upstream.

Entry corresponding to 220 us setup time was missing. I am not aware of
any specific bug this fixes, but this could potentially result in enabling
PSR on a panel with a higher setup time requirement than supported by the
hardware.

I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a.

Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()")
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Jose Roberto de Souza 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: José Roberto de Souza 
Reviewed-by: Tarun Vyas 
Signed-off-by: Dhinakaran Pandiyan 
Signed-off-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-3-dhinakaran.pandiyan@intel.com
Signed-off-by: Greg Kroah-Hartman

IB/core: Fix error code for invalid GID entry

2018-06-06T14:44:38+00:00

commit a840c93ca7582bb6c88df2345a33f979b7a67874 upstream.

When a GID entry is invalid EAGAIN is returned. This is an incorrect error
code, there is nothing that will make this GID entry valid again in
bounded time.

Some user space tools fail incorrectly if EAGAIN is returned here, and
this represents a small ABI change from earlier kernels.

The first patch in the Fixes list makes entries that were valid before
to become invalid, allowing this code to trigger, while the second patch
in the Fixes list introduced the wrong EAGAIN.

Therefore revert the return result to EINVAL which matches the historical
expectations of the ibv_query_gid_type() API of the libibverbs user space
library.

Cc: 
Fixes: 598ff6bae689 ("IB/core: Refactor GID modify code for RoCE")
Fixes: 03db3a2d81e6 ("IB/core: Add RoCE GID table management")
Reviewed-by: Daniel Jurgens 
Signed-off-by: Parav Pandit 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

hwtracing: stm: fix build error on some arches

2018-06-06T14:44:38+00:00

commit 806e30873f0e74d9d41b0ef761bd4d3e55c7d510 upstream.

Commit b5e2ced9bf81 ("stm class: Use vmalloc for the master map") caused
a build error on some arches as vmalloc.h was not explicitly included.

Fix that by adding it to the list of includes.

Fixes: b5e2ced9bf81 ("stm class: Use vmalloc for the master map")
Reported-by: kbuild test robot 
Cc: Alexander Shishkin 
Signed-off-by: Greg Kroah-Hartman

stm class: Use vmalloc for the master map

2018-06-06T14:44:38+00:00

commit b5e2ced9bf81393034072dd4d372f6b430bc1f0a upstream.

Fengguang is running into a warning from the buddy allocator:

> swapper/0: page allocation failure: order:9, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.17.0-rc1 #262
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
> Call Trace:
...
>  __kmalloc+0x14b/0x180: ____cache_alloc at mm/slab.c:3127
>  stm_register_device+0xf3/0x5c0: stm_register_device at drivers/hwtracing/stm/core.c:695
...

Which is basically a result of the stm class trying to allocate ~512kB
for the dummy_stm with its default parameters. There's no reason, however,
for it not to be vmalloc()ed instead, which is what this patch does.

Reported-by: Fengguang Wu 
Signed-off-by: Alexander Shishkin 
CC: stable@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman

scsi: scsi_transport_srp: Fix shost to rport translation

2018-06-06T14:44:38+00:00

commit c9ddf73476ff4fffb7a87bd5107a0705bf2cf64b upstream.

Since an SRP remote port is attached as a child to shost->shost_gendev
and as the only child, the translation from the shost pointer into an
rport pointer must happen by looking up the shost child that is an
rport. This patch fixes the following KASAN complaint:

BUG: KASAN: slab-out-of-bounds in srp_timed_out+0x57/0x110 [scsi_transport_srp]
Read of size 4 at addr ffff880035d3fcc0 by task kworker/1:0H/19

CPU: 1 PID: 19 Comm: kworker/1:0H Not tainted 4.16.0-rc3-dbg+ #1
Workqueue: kblockd blk_mq_timeout_work
Call Trace:
dump_stack+0x85/0xc7
print_address_description+0x65/0x270
kasan_report+0x231/0x350
srp_timed_out+0x57/0x110 [scsi_transport_srp]
scsi_times_out+0xc7/0x3f0 [scsi_mod]
blk_mq_terminate_expired+0xc2/0x140
bt_iter+0xbc/0xd0
blk_mq_queue_tag_busy_iter+0x1c7/0x350
blk_mq_timeout_work+0x325/0x3f0
process_one_work+0x441/0xa50
worker_thread+0x76/0x6c0
kthread+0x1b2/0x1d0
ret_from_fork+0x24/0x30

Fixes: e68ca75200fe ("scsi_transport_srp: Reduce failover time")
Signed-off-by: Bart Van Assche 
Cc: Hannes Reinecke 
Cc: Johannes Thumshirn 
Cc: Jason Gunthorpe 
Cc: Doug Ledford 
Cc: Laurence Oberman 
Cc: stable@vger.kernel.org
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

iio:kfifo_buf: check for uint overflow

2018-06-06T14:44:37+00:00

commit 3d13de4b027d5f6276c0f9d3a264f518747d83f2 upstream.

Currently, the following causes a kernel OOPS in memcpy:

echo 1073741825 > buffer/length
echo 1 > buffer/enable

Note that using 1073741824 instead of 1073741825 causes "write error:
Cannot allocate memory" but no OOPS.

This is because 1073741824 == 2^30 and 1073741825 == 2^30+1. Since kfifo
rounds up to the nearest power of 2, it will actually call kmalloc with
roundup_pow_of_two(length) * bytes_per_datum.

Using length == 1073741825 and bytes_per_datum == 2, we get:

kmalloc(roundup_pow_of_two(1073741825) * 2
or kmalloc(2147483648 * 2)
or kmalloc(4294967296)
or kmalloc(UINT_MAX + 1)

so this overflows to 0, causing kmalloc to return ZERO_SIZE_PTR and
subsequent memcpy to fail once the device is enabled.

Fix this by checking for overflow prior to allocating a kfifo. With this
check added, the above code returns -EINVAL when enabling the buffer,
rather than causing an OOPS.

Signed-off-by: Martin Kelly 
cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

net/mlx4_en: fix potential use-after-free with dma_unmap_page

2018-06-06T14:44:37+00:00

[ Not relevant upstream, therefore no upstream commit. ]

To fix, unmap the page as soon as possible.

When swiotlb is in use, calling dma_unmap_page means that
the original page mapped with dma_map_page must still be valid,
as swiotlb will copy data from its internal cache back to the
originally requested DMA location.

When GRO is enabled, before this patch all references to the
original frag may be put and the page freed before dma_unmap_page
in mlx4_en_free_frag is called.

It is possible there is a path where the use-after-free occurs
even with GRO disabled, but this has not been observed so far.

The bug can be trivially detected by doing the following:

* Compile the kernel with DEBUG_PAGEALLOC
* Run the kernel as a Xen Dom0
* Leave GRO enabled on the interface
* Run a 10 second or more test with iperf over the interface.

This bug was likely introduced in
commit 4cce66cdd14a ("mlx4_en: map entire pages to increase throughput"),
first part of u3.6.

It was incidentally fixed in
commit 34db548bfb95 ("mlx4: add page recycling in receive path"),
first part of v4.12.

This version applies to the v4.9 series.

Signed-off-by: Sarah Newman 
Tested-by: Sarah Newman 
Cc: Tariq Toukan 
Cc: Yishai Hadas 
Signed-off-by: Greg Kroah-Hartman

arm64: Add hypervisor safe helper for checking constant capabilities

2018-06-06T14:44:35+00:00

commit a4023f682739439b434165b54af7cb3676a4766e upstream.

The hypervisor may not have full access to the kernel data structures
and hence cannot safely use cpus_have_cap() helper for checking the
system capability. Add a safe helper for hypervisors to check a constant
system capability, which *doesn't* fall back to checking the bitmap
maintained by the kernel. With this, make the cpus_have_cap() only
check the bitmask and force constant cap checks to use the new API
for quicker checks.

Cc: Robert Ritcher 
Cc: Tirumalesh Chalamarla 
Signed-off-by: Suzuki K Poulose 
Reviewed-by: Will Deacon 
Reviewed-by: Marc Zyngier 
Signed-off-by: Catalin Marinas 
[4.9: restore cpus_have_const_cap() to previously-backported code]
Signed-off-by: Mark Rutland  [v4.9 backport]
Signed-off-by: Greg Kroah-Hartman