20 months agorpmsg: char: Update local endpt address for virtio-rpmsg backend rpmsg-linux-5.4.y
Suman Anna [Tue, 15 Sep 2020 00:13:52 +0000 (19:13 -0500)]
rpmsg: char: Update local endpt address for virtio-rpmsg backend

The rpmsg char driver creates a local end-point when the actual endpt
device is opened. The virtio-rpmsg backend can dynamically allocate the
local end-point address if the endpt creation is done using the address
RPMSG_ADDR_ANY. This is not reflected in the sysfs src file, so update
the stored address with the allocated address in such a case. This
allows the userspace to be able to retrieve the local end-point address
through sysfs.

Signed-off-by: Suman Anna <s-anna@ti.com>
20 months agorpmsg: char: Add device id_table for auto-probe
Suman Anna [Thu, 10 Sep 2020 18:39:41 +0000 (13:39 -0500)]
rpmsg: char: Add device id_table for auto-probe

The rpmsg char driver is not auto-probed for any rpmsg device
without relying on the device's driver_override feature. Add a
device id_table to the rpmsg-char driver to facilitate this
auto-probe. Any rpmsg device with the name "rpmsg_chrdev" will
be auto-probed to begin with.

The driver_override will continue to work just fine as well.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
2 years agorpmsg: fix lockdep warnings in virtio rpmsg bus driver
Angela Stegmaier [Sat, 22 Feb 2020 07:26:37 +0000 (01:26 -0600)]
rpmsg: fix lockdep warnings in virtio rpmsg bus driver

The virtio rpmsg bus framework uses endpoints as the basis for
sending and receiving messages to/from a remote processor. Each
rpmsg bus device will have a primary endpoint if the corresponding
rpmsg bus driver supports a callback, and secondary child endpoints
associated with the same rpmsg bus device. The life-cycle of these
endpoints are tied to the corresponding rpmsg device. A virtio rpmsg
bus device can also have its own endpoint for supporting name service
announcements from a corresponding remote processor to create and
delete rpmsg devices dynamically.

Each endpoint has a callback lock associated with it to provide
protection/mutual exclusion between threads that process incoming
rpmsg messages and threads that want to delete the endpoint. The
virtio rpmsg name service endpoint callback will run while holding
it's ept->cb_lock to create/delete rpmsg devices for RPMSG_NS_CREATE
and RPMSG_NS_DELETE messages respectively. The latter message
processing will destroy the requested channel, and will ultimately
result in all the secondary rpmsg device endpoints also to be
destroyed. The ept->cb_lock for the channel's endpoint is also
locked during its destruction while setting the callback to NULL.
This results in a seemingly nested locking of the ept->cb_lock even
though the locking is on different mutexes. This will result in a
false warning from the lockdep validator when it is enabled because
the lockdep deals with classes and both are the same class, although
they are different instances.

Similar circular dependency scenarios also exist with remoteproc
error recovery and existing rpmsg drivers - rpmsg_rpc and rpmsg_proto.

These issues are fixed by replacing the existing mutex_lock() calls
with the mutex_lock_nested() API variation and using different
subclasses for the NameService end-point and for the rpmsg channel
device end-points.

Following are example warning signatures that get fixed by this patch:

1. Recursive locking dependency during RPMSG_NS_DESTROY message processing
 WARNING: possible recursive locking detected
 kworker/0:0/1069 is trying to acquire lock:
 e37914c0 (&ept->cb_lock){+.+.}, at: __rpmsg_destroy_ept+0x40/0x6c [virtio_rpmsg_bus]

 but task is already holding lock:
 e3d14bc0 (&ept->cb_lock){+.+.}, at: rpmsg_recv_done+0x6c/0x34c [virtio_rpmsg_bus]

 other info that might help us debug this:
  Possible unsafe locking scenario:


  *** DEADLOCK ***

  May be due to missing lock nesting notatio

 4 locks held by kworker/0:0/1069:
  #0: e700b6a0 ((wq_completion)events){+.+.}, at: process_one_work+0x1f4/0x824
  #1: e2175f24 ((work_completion)(&mq->work)){+.+.}, at: process_one_work+0x1f4/0x824
  #2: e3d14bc0 (&ept->cb_lock){+.+.}, at: rpmsg_recv_done+0x6c/0x34c [virtio_rpmsg_bus]
  #3: e335e0bc (&dev->mutex){....}, at: device_release_driver_internal+0x18/0x1bc

2. Circular locking dependency during error recovery of rpmsg-rpc driver
 WARNING: possible circular locking dependency detected
 kworker/0:4/1068 is trying to acquire lock:
 e3e2b2c0 (&ept->cb_lock){+.+.}, at: __rpmsg_destroy_ept+0x40/0x6c [virtio_rpmsg_bus]

 but task is already holding lock:
 e4282380 (&rppcdev->lock){+.+.}, at: rppc_remove+0x88/0x238 [rpmsg_rpc]

 which lock already depends on the new lock.

 other info that might help us debug this:

 Chain exists of:
  &ept->cb_lock --> rppc_devices_lock --> &rppcdev->lock

  Possible unsafe locking scenario:
        CPU0                    CPU1
        ----                    ----

  *** DEADLOCK ***

 7 locks held by kworker/0:4/1068:
  #0: e700b6a0 ((wq_completion)events){+.+.}, at: process_one_work+0x1f4/0x824
  #1: e2289f24 ((work_completion)(&rproc->crash_handler)){+.+.}, at: process_one_work+0x1f4/0x824
  #2: e47ebb1c (&rproc->lock){+.+.}, at: rproc_trigger_recovery+0x44/0x460
  #3: e3e064e4 (&dev->mutex){....}, at: device_release_driver_internal+0x18/0x1bc
  #4: e37bd4bc (&dev->mutex){....}, at: device_release_driver_internal+0x18/0x1bc
  #5: bf019034 (rppc_devices_lock){+.+.}, at: rppc_remove+0x3c/0x238 [rpmsg_rpc]
  #6: e4282380 (&rppcdev->lock){+.+.}, at: rppc_remove+0x88/0x238 [rpmsg_rpc]

3. Circular locking dependency during error recovery of rpmsg-proto driver
 WARNING: possible circular locking dependency detected
 kworker/0:1/21 is trying to acquire lock:
 e47869c0 (&ept->cb_lock){+.+.}, at: __rpmsg_destroy_ept+0x40/0x6c [virtio_rpmsg_bus]

 but task is already holding lock:
 bf027034 (rpmsg_channels_lock){+.+.}, at: rpmsg_proto_remove+0x28/0x16c [rpmsg_proto]

 which lock already depends on the new lock.

 other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----

  *** DEADLOCK ***

 6 locks held by kworker/0:1/21:
  #0: e700b6a0 ((wq_completion)events){+.+.}, at: process_one_work+0x1f4/0x824
  #1: e6057f24 ((work_completion)(&rproc->crash_handler)){+.+.}, at: process_one_work+0x1f4/0x824
  #2: e3884b1c (&rproc->lock){+.+.}, at: rproc_trigger_recovery+0x44/0x460
  #3: e20a88e4 (&dev->mutex){....}, at: device_release_driver_internal+0x18/0x1bc
  #4: e39ae0bc (&dev->mutex){....}, at: device_release_driver_internal+0x18/0x1bc
  #5: bf027034 (rpmsg_channels_lock){+.+.}, at: rpmsg_proto_remove+0x28/0x16c [rpmsg_proto]

Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
[s-anna@ti.com: flip the subclass values, update crash log examples for 5.4]
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agonet/rpmsg: unblock reader threads operating on errored sockets
Suman Anna [Mon, 4 Mar 2019 21:00:35 +0000 (15:00 -0600)]
net/rpmsg: unblock reader threads operating on errored sockets

The rpmsg_proto driver is used to provide a socket interface
to userspace under the AF_RPMSG address family, and is used
by the TI IPC MessageQ stack. The typical usage for receiving
messages include a thread blocked on a select() call with
appropriate socket fds, followed by a recvfrom() on the fd
returned/marked ready by select().

The rpmsg_sock_poll() function implements the logic needed
by the select() call, and marks a socket ready only when there
is data to be read currently. Any reader thread waiting on the
select() call to return is currently not unblocked when a remote
processor goes through an error recovery, and can remain blocked
forever as its remote processor peer thread may never send it
another message. Enhance the rpmsg_proto driver so that a waiting
thread can be unblocked by waking it up during the process of
marking the open sockets with the error status RPMSG_ERROR. This
is achieved by using the socket's .sk_error_report() ops, and is
preferred over the .sk_state_change() ops to wakeup only a single
exclusive thread.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agonet/rpmsg: return ENOLINK upon Rx on errored sockets
Suman Anna [Tue, 28 Feb 2017 22:25:52 +0000 (16:25 -0600)]
net/rpmsg: return ENOLINK upon Rx on errored sockets

The rpmsg_proto driver is used to provide a socket interface to
userspace under the AF_RPMSG address family, and is used by the TI
IPC MessageQ stack. The rpmsg proto driver creates a rpmsg endpoint
per remote processor (a Rx socket) for each MessageQ object through
the socket's bind() call. These rpmsg endpoints are associated with
a published parent rpmsg device from that remote processor. These
endpoints are cleaned up normally either when the userspace program
/ application closes them or through the automatic cleanup of the
file descriptors when a process is terminated/closed. These endpoints
can also be cleaned up by the rpmsg_proto driver as part of the error
recovery of a remote processor, during the removal of their parent
rpmsg device, with the corresponding Rx sockets simply marked with
the error status RPMSG_ERROR.

This error status is not currently being returned to the userspace
in the socket's recvfrom() interface. Fix this by specifically
checking for this error status, and returning an error value of
ENOLINK back to userspace. The ENOLINK error code is used to allow
the userspace to differentiate this terminal error from other errors
on the Rx sockets and take appropriate action. This error code on
Rx sockets serves the same as the error code ESHUTDOWN used for Tx
sockets, and is chosen specifically to have a meaningful strerror
message appropriate to Rx sockets.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agonet/rpmsg: return ESHUTDOWN upon Tx on errored sockets
Suman Anna [Fri, 24 Oct 2014 21:39:49 +0000 (16:39 -0500)]
net/rpmsg: return ESHUTDOWN upon Tx on errored sockets

The rpmsg proto driver uses a single rpmsg channel device
published from a remote processor to transmit all socket-based
messages intended for that remote processor. This channel will
be auto-removed and recreated if the remote processor goes
through an error recovery process. Any connected sockets are
marked with an error status, and further transmissions on these
connected sockets should gracefully return an error. This error
condition is specifically checked for and a new error ESHUTDOWN
is returned back to userspace to differentiate it from
transmissions on an unconnected socket.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agonet/rpmsg: add support to handle a remote processor error recovery
Suman Anna [Sat, 4 Mar 2017 00:40:31 +0000 (18:40 -0600)]
net/rpmsg: add support to handle a remote processor error recovery

The rpmsg_proto driver is used to provide a socket interface to
userspace under the AF_RPMSG address family, and is used by the
TI IPC MessageQ stack. The rpmsg proto driver uses a single rpmsg
channel device published from a remote processor to transmit and
receive all socket-based messages to/from that remote processor.
There can be any number of Tx and Rx sockets associated with each
remote processor's rpmsg device. This rpmsg channel device will be
auto-removed and recreated if the associated remote processor goes
through an error recovery process. Any existing open sockets (both
Tx and Rx) are oblivious if the underlying rpmsg channel has been
removed, and any further operations on such sockets can create
various kernel crashes due to invalid pointer dereferences.

This patch adds the error recovery support to the rpmsg-proto driver.
This is achieved by using the private field of the published rpmsg
channel device's endpoint (ept->priv) to maintain a list of all the
connected and bound sockets, and setting a new error status
(RPMSG_ERROR) on all these open sockets when the associated parent
rpmsg device is removed. This new error status allows the driver
to check for a valid state of a socket before performing any actions
on it thereby preventing any kernel crashes. The status is also used
to allow the userspace to perform appropriate cleanup and/or recovery

The logic is asymmetric because of the slight difference between the
Rx and Tx sockets. All the Tx sockets use the one-time published
rpmsg_channel devices for transmissions and just need to be marked
with the error status, while each of the Rx sockets have their own
derivative rpmsg endpoints, and so need to be removed alongside the
removal of the associated rpmsg channel device in addition. The
sockets themselves are freed up anytime either by the userspace
closing them or through an automatic close when the process is

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agorpmsg: rpc: fix potential memory leak of unprocessed skbs
Suman Anna [Tue, 7 Jan 2020 23:17:37 +0000 (17:17 -0600)]
rpmsg: rpc: fix potential memory leak of unprocessed skbs

A user thread sends a request for a remote function execution
on the remote processor through a write() fop. All the responses
from the remote service are queued using allocated skbs in the
driver's rpmsg callback. The allocated skbs are processed and
freed in a read() fop. An error recovery causes a blocked user
thread to bail out immediately and any in-flight queued skbs
are left unprocessed. These in-flight skbs are never freed and
can result in a memory leak.

Fix the memory leak by checking for the presence of any of these
unprocessed skbs in the read queue, and freeing them during the
file descriptor's release() function. This also ensures no memory
is leaked for user applications with bugs and not using matching
write() and read() fops.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agorpmsg: rpc: fix ept memory leak during recovery
Suman Anna [Fri, 31 Oct 2014 23:17:56 +0000 (18:17 -0500)]
rpmsg: rpc: fix ept memory leak during recovery

The rpmsg-rpc driver exposes a character device for each remote
service (a rpmsg-rpc device) providing a bunch of remote execution
functions. An endpoint is created in the open() fops, and forms the
source end-point of a dedicated communication channel to allow an
application to send and receive remote function execution commands/
responses on this service. This endpoint address is a child of the
parent virtio device to which the rpmsg-rpc device belongs to. The
virtio devices are deleted and recreated during a remoteproc crash
and recovery process. The associated child endpoints are not deleted
at present during recovery, and the corresponding release() cannot
delete the end-points if it happens after a recovery as the parent
rpmsg-rpc device has already been removed, thereby resulting in a
memory leak during recovery amidst an active usage.

Fix this by deleting all the epts associated with the parent virtio
device of the corresponding rpmsg-rpc device. This is done during the
rpmsg-rpc driver's .remove() which is invoked during the deletion of
the virtio device.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agorpmsg: rpc: use the local device pointer in all file operations
Suman Anna [Fri, 7 Nov 2014 20:14:09 +0000 (14:14 -0600)]
rpmsg: rpc: use the local device pointer in all file operations

The remote processor recovery process includes the deletion and
recreation of an rpmsg-rpc device. The representative rppc_device
structure is retained and reused if there are any open applications
using the exposed character device. The underlying device pointer
for a rppc_device is though deleted and recreated and can become
NULL at any point if an error recovery happens. So, switch to using
the local reference device pointer in all the fop functions for
the exposed character device.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agorpmsg: rpc: maintain a reference device pointer per open fd
Suman Anna [Fri, 7 Nov 2014 17:17:13 +0000 (11:17 -0600)]
rpmsg: rpc: maintain a reference device pointer per open fd

The remote processor recovery process includes the deletion and
recreation of an rpmsg-rpc device. The representative rppc_device
structure is retained and reused if there are any open applications
using the exposed character device. The underlying device pointer
for a rppc_device is though deleted and recreated and is asynchronous
to any of the operations on the exposed character device. A reference
to this device pointer is to be maintained therefore for each open
application so that it can be used during regular fops and until the
file descriptor is closed instead of referencing the rppc_device's
dev pointer, which can become NULL at any point due to a recovery
process. The actual memory of the rppc_device's dev pointer deleted
in the driver's .remove() is freed when all the open applications
have closed either gracefully or forcefully. Any new applications
after a recovery will leverage a newly created device pointer.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agorpmsg: rpc: fix sysfs entry creation failures during recovery
Suman Anna [Sat, 1 Nov 2014 00:28:53 +0000 (19:28 -0500)]
rpmsg: rpc: fix sysfs entry creation failures during recovery

The rpmsg-rpc driver exposes a character device for each remote
service (a rpmsg-rpc device) providing a bunch of remote execution
functions. The remote service can be running on any of the available
remote processors, and the supported functions are published as
different sysfs entries on that particular device. These rpmsg-rpc
devices are deleted and recreated as part of the reboot of the remote
processor during an error recovery. The sysfs entries are also deleted
and recreated. The current logic retains the associated rppc_device
structure and the underlying device pointer if there are any
applications actively using the character device at the time of the
rpmsg-rpc device removal, and reuses it upon the reprobe of the same
rpmsg-rpc device. The creation of the sysfs entries fails with -ENOENT
due to an invalid reference to a non-existing parent object, and this
is exposed first in 3.14 kernel due to the repartitioning of the core
sysfs code into a new common kernfs code.

Fix this by deleting the underlying device pointer in the driver's
.remove, and recreating it with the appropriate new rpmsg server
device as its parent in the driver's .probe function. A name
description field is also added to the representative rppc_device
structure for looking up the service on reprobe as the device name
cannot be used due to the deletion of the device pointer.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agorpmsg: pru: add a PRU RPMsg driver
Jason Reeder [Thu, 6 Feb 2020 04:31:11 +0000 (22:31 -0600)]
rpmsg: pru: add a PRU RPMsg driver

An RPMsg driver that exposes interfaces to user space, to
allow applications to communicate with the PRU processors
on available TI SoCs has been added. This is restricted to
SoCs that have the PRUSS remoteproc support.

Signed-off-by: Jason Reeder <jreeder@ti.com>
[s-anna@ti.com: various cleanups, rpmsg rebase fixes for 5.4]
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoHACK: rpmsg: virtio_rpmsg_bus: fix up vring buffer logic for TI Keystone SoCs
Suman Anna [Sun, 24 Feb 2019 05:09:56 +0000 (23:09 -0600)]
HACK: rpmsg: virtio_rpmsg_bus: fix up vring buffer logic for TI Keystone SoCs

The virtio rpmsg logic is always based on publishing the physical vring
buffers in the vring control structures to expose them to the remote
processor side. Commit 9dd87c2af651 ("rpmsg: virtio_rpmsg_bus: fix
sg_set_buf() when addr is not a valid kernel address") has fixed up
this logic to scale for the case with the virtio rpmsg buffers were
allocated from either a HighMem region or a dedicated carveout (mapped
into kernel in vmalloc space). The fix initialized the sg_table with
appropriate page address which is translated back to a dma_addr_t
using sg_phys() call in virtqueue_add() (in vring_map_one_sg())
function. This fix was sufficient for SoCs where both the host and
the remote processors used 32-bit addressing scheme.

This logic failed for TI Keystone platforms though, which have a 36-bit
physical address and only a regular 32-bit dma address (the first 2 GB
of RAM at 0x800000000 is aliased at 0x80000000) due to the truncation of
the physical address. Furthermore, the remote processors on these SoCs
leverage the 32-bit aliased address for referencing the IPC shared memory
buffers. Fix this issue and make the virtio rpmsg stack functional on
these platforms by initializing the sg entry with the page address
corresponding to the dma address of the vring buffer instead of it's
physical address. This solution allows the core virtio_ring code to
remain unchanged, and results in publishing the desired aliased
addresses in the vring control structures.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agouapi: fix linux/rpmsg_rpc.h userspace compilation errors
Suman Anna [Tue, 4 Feb 2020 00:19:16 +0000 (18:19 -0600)]
uapi: fix linux/rpmsg_rpc.h userspace compilation errors

The uapi rpmsg_rpc.h header file generates a whole bunch
of userspace compilation errors with allmodconfig and when
using ARM GCC 9.2-2019.12 compiler:

./usr/include/linux/rpmsg_rpc.h:19:2: error: unknown type name ‘uint32_t’
./usr/include/linux/rpmsg_rpc.h:20:2: error: unknown type name ‘int32_t’
./usr/include/linux/rpmsg_rpc.h:72:2: error: unknown type name ‘uint32_t’
./usr/include/linux/rpmsg_rpc.h:73:2: error: unknown type name ‘ptrdiff_t’
./usr/include/linux/rpmsg_rpc.h:74:2: error: unknown type name ‘size_t’
./usr/include/linux/rpmsg_rpc.h:75:2: error: unknown type name ‘int32_t’
./usr/include/linux/rpmsg_rpc.h:92:2: error: unknown type name ‘uint32_t’
./usr/include/linux/rpmsg_rpc.h:93:2: error: unknown type name ‘size_t’
./usr/include/linux/rpmsg_rpc.h:94:2: error: unknown type name ‘size_t’
./usr/include/linux/rpmsg_rpc.h:95:2: error: unknown type name ‘size_t’
./usr/include/linux/rpmsg_rpc.h:96:2: error: unknown type name ‘int32_t’
./usr/include/linux/rpmsg_rpc.h:114:2: error: unknown type name ‘uint32_t’
./usr/include/linux/rpmsg_rpc.h:115:2: error: unknown type name ‘uint32_t’
./usr/include/linux/rpmsg_rpc.h:117:2: error: unknown type name ‘uint32_t’
./usr/include/linux/rpmsg_rpc.h:127:2: error: unknown type name ‘uint32_t’
./usr/include/linux/rpmsg_rpc.h:128:2: error: unknown type name ‘uint32_t’
./usr/include/linux/rpmsg_rpc.h:174:2: error: unknown type name ‘uint16_t’
./usr/include/linux/rpmsg_rpc.h:175:2: error: unknown type name ‘uint16_t’
./usr/include/linux/rpmsg_rpc.h:176:2: error: unknown type name ‘uint32_t’
./usr/include/linux/rpmsg_rpc.h:177:2: error: unknown type name ‘uint32_t’
./usr/include/linux/rpmsg_rpc.h:178:2: error: unknown type name ‘int32_t’
./usr/include/linux/rpmsg_rpc.h:179:2: error: unknown type name ‘uint32_t’
./usr/include/linux/rpmsg_rpc.h:180:2: error: unknown type name ‘uint8_t’

Fix these by switching the integer types uint8_t, uint16_t, uint32_t and
int32_t to the types from linux/types.h __u8, __u16, __u32 and __s32
respectively, and including the proper userspace headers.

Fixes: b7540e45bf1c ("rpmsg: rpc: introduce a new rpmsg_rpc driver")
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agorpmsg: rpc: introduce a new rpmsg_rpc driver
Suman Anna [Wed, 29 Jan 2020 00:56:29 +0000 (18:56 -0600)]
rpmsg: rpc: introduce a new rpmsg_rpc driver

The new rpmsg client driver, rpmsg_rpc, is introduced to provide a
framework for userspace applications to execute functions on different
remote processors.

The functions themselves are published by the remote processors by
different libraries. Each set of functions are published and supported
by a corresponding rpmsg server channel, and is exposed to the user-space
as its own device. User-space applications can open this character device,
and execute any of the published functions associated with the device.

The rpmsg-rpc driver allows any function upto 10 arguments with in-built
pointer translation. The kernel-userspace interaction allows any buffer
pointers to be replaced in the marshalled packet, provided the buffers
are obtained from allocators backed by dma_buf framework.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Erik Rainey <erik.rainey@ti.com>
2 years agonet/rpmsg: add support for new rpmsg sockets
Suman Anna [Tue, 7 Jan 2020 17:36:21 +0000 (11:36 -0600)]
net/rpmsg: add support for new rpmsg sockets

Add the support for a new socket address and protocol family -
remote-processor messaging sockets. This rpmsg protocol driver
provides the necessary support to expose a rpmsg communication
channel through the socket API to userspace under the AF_RPMSG
address family. The usage relies on leveraging the socket API's
connect() for Tx sockets and bind() for Rx sockets to exchange
messages to/from a remote processor. All message communication
is performed using the userspace created sockets, and even though
the probed rpmsg proto devices do create an embedded rpmsg endpoint
for receiving messages, they are not really designed to process
any such unexpected Rx messages.

This driver forms the kernel transport portion of the the TI
IPC MessageQ stack. The MessageQ stack usage of the AF_RPMSG
socket interface is not really designed to handle multiple
rpmsg-proto devices published from the same remote processor,
so a restriction is imposed to allow only a single rpmsg device
even though there are no such restrictions imposed by the
rpmsg bus infrastructure. This can be scaled to make it more
generic if needed but probably will require some userspace
interface adjustments.

This patch is based on some quite an old rpmsg socket support
patch from Ohad and some work by Rob Tivy. This has been updated
rather heavily to work with all the rpmsg framework changes in
4.9+ kernels.

Signed-off-by: Ohad Ben Cohen <ohad@wizery.com>
[s-anna@ti.com: adapted, improved and modified for latest kernel]
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agorpmsg: core: add API to get MTU
Arnaud Pouliquen [Wed, 13 Nov 2019 17:22:49 +0000 (18:22 +0100)]
rpmsg: core: add API to get MTU

Return the rpmsg buffer MTU for sending message, so rpmsg users
can split a long message in several sub rpmsg buffers.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
[s-anna@ti.com: cherry-pick https://patchwork.kernel.org/patch/11242365/]
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc: fall back to using parent memory pool if no dedicated available
Tero Kristo [Fri, 5 Jul 2019 04:08:13 +0000 (07:08 +0300)]
remoteproc: fall back to using parent memory pool if no dedicated available

In some cases, like with OMAP remoteproc, we are not creating dedicated
memory pool for the virtio device. Instead, we use the same memory pool
for all shared memories. The current virtio memory pool handling forces
a split between these two, as a separate device is created for it,
causing memory to be allocated from bad location if the dedicated pool
is not available. Fix this by falling back to using the parent device
memory pool if dedicated is not available.

Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Tero Kristo <t-kristo@ti.com>
2 years agorpmsg: add a description field
Ohad Ben-Cohen [Wed, 14 Aug 2019 23:56:34 +0000 (18:56 -0500)]
rpmsg: add a description field

Add a new description field to the rpmsg bus infrastructure
that can be passed onto the rpmsg client drivers for additional
information. The current rpmsg bus client drivers need to have
a fixed id_table for proper matching, this new field can allow
flexibility for the client drivers (eg: like creating unique

The description field is published through an enhanced name
service announcement message structure. The name service
message processing logic is updated to maintain backward
compatibility with the previous message structure.

Based on an initial patch from Ohad Ben-Cohen.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: forward port, add sysfs documentation, fixup qcom drivers]
[s-anna@ti.com: cherry-pick https://patchwork.kernel.org/patch/11096599/ ]
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: reworked to support both rpmsg with/without the desc field]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
2 years agoremoteproc: add an api to do pa to da conversion
Subramaniam Chanderashekarapuram [Mon, 18 Aug 2014 22:13:17 +0000 (17:13 -0500)]
remoteproc: add an api to do pa to da conversion

Added an api to provide memory translation from a
physical address to a device virtual address.
Since, carveouts and mappings are stored separately,
we need to traverse both lists.

Also stored the physical addresses for RSC_DEVMEM entries
to enable pa to da conversion for dev mem address spaces too.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc: add api for retrieving a rproc unique id
Suman Anna [Mon, 15 Jan 2018 18:01:54 +0000 (12:01 -0600)]
remoteproc: add api for retrieving a rproc unique id

A new api, rproc_get_id(), is added to allow remoteproc/rpmsg clients
to be able to retrieve a fixed unique id associated with a rproc
device. Each of the rprocs is given an ida index as well, but this
is dynamic depending on the order rproc_alloc is called (probe order),
and also depends on what remote processor devices are instantiated.
This unique id needs to be supported for both DT and non-DT devices.
The platform device id or the remoteproc alias id are therefore
chosen for non-DT and DT devices respectively, with the assumption
that the remoteproc devices are created with known platform device
ids or alias ids in DT.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc: Fix and restore the parenting hierarchy for vdev
Suman Anna [Tue, 17 Dec 2019 01:15:27 +0000 (19:15 -0600)]
remoteproc: Fix and restore the parenting hierarchy for vdev

The commit 086d08725d34 ("remoteproc: create vdev subdevice with specific
dma memory pool") has introduced a new vdev subdevice for each vdev
declared in the firmware resource table and made it as the parent for the
created virtio rpmsg devices instead of the previous remoteproc device.
This changed the overall parenting hierarchy for the rpmsg devices, which
were children of virtio devices, and does not allow the corresponding
rpmsg drivers to retrieve the parent rproc device through the
rproc_get_by_child() API.

Fix this by restoring the remoteproc device as the parent. The new vdev
subdevice can continue to inherit the DMA attributes from the remoteproc's
parent device (actual platform device).

Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agorpmsg: Fix Kconfig indentation
Krzysztof Kozlowski [Wed, 20 Nov 2019 13:39:44 +0000 (21:39 +0800)]
rpmsg: Fix Kconfig indentation

[ Upstream commit 8cf9b615653e40debdcf3b6f1d69e6b580d71173 ]

Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^        /\t/' -i */Kconfig

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191120133945.13938-1-krzk@kernel.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '8cf9b615653e' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agorpmsg: char: Simplify 'rpmsg_eptdev_release()'
Christophe JAILLET [Tue, 29 Oct 2019 06:09:14 +0000 (07:09 +0100)]
rpmsg: char: Simplify 'rpmsg_eptdev_release()'

[ Upstream commit bb06a5ce88fd3489d2415470b20ab949550a62ec ]

Use 'skb_queue_purge()' instead of re-implementing it.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'bb06a5ce88fd' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agorpmsg: char: release allocated memory
Navid Emamdoost [Tue, 17 Sep 2019 03:31:23 +0000 (22:31 -0500)]
rpmsg: char: release allocated memory

[ Upstream commit bbe692e349e2a1edf3fe0a29a0e05899c9c94d51 ]

In rpmsg_eptdev_write_iter, if copy_from_iter_full fails the allocated
buffer needs to be released.

Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'bbe692e349e2' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc: Fix wrong rvring index computation
Clement Leger [Fri, 4 Oct 2019 07:37:36 +0000 (09:37 +0200)]
remoteproc: Fix wrong rvring index computation

[ Upstream commit 00a0eec59ddbb1ce966b19097d8a8d2f777e726a ]

Index of rvring is computed using pointer arithmetic. However, since
rvring->rvdev->vring is the base of the vring array, computation
of rvring idx should be reversed. It previously lead to writing at negative
indices in the resource table.

Signed-off-by: Clement Leger <cleger@kalray.eu>
Link: https://lore.kernel.org/r/20191004073736.8327-1-cleger@kalray.eu
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '00a0eec59ddb' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc: fix argument 2 of rproc_mem_entry_init
Ben Dooks (Codethink) [Thu, 17 Oct 2019 11:59:52 +0000 (12:59 +0100)]
remoteproc: fix argument 2 of rproc_mem_entry_init

[ Upstream commit 99cf0361e7af29511309804bbedd240bf939cebd ]

The rproc_mem_entry_init() call takes a pointer to a vm
as the second argument. The code is currently using a
plain 0 as "NULL". Change to using NULL to fix the
following sparse warnings:

drivers/remoteproc/remoteproc_core.c:339:49: warning: Using plain integer as NULL pointer
drivers/remoteproc/remoteproc_core.c:916:46: warning: Using plain integer as NULL pointer

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '99cf0361e7af' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc: debug: Remove unneeded NULL check
Ding Xiang [Tue, 24 Sep 2019 02:58:54 +0000 (10:58 +0800)]
remoteproc: debug: Remove unneeded NULL check

[ Upstream commit 0ad82e3a2234dfa38ec835d1772e8c9af176d458 ]

debugfs_remove_recursive will do NULL check, so remove
the redundant null check

Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '0ad82e3a2234' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc: remove useless typedef
Clement Leger [Fri, 4 Oct 2019 17:44:24 +0000 (19:44 +0200)]
remoteproc: remove useless typedef

[ Upstream commit 006d72da28db06a0762b1f536458ac1a9a4ba8d1 ]

rproc_handle_resources_t is not used anymore, remove it.

Signed-off-by: Clement Leger <cleger@kalray.eu>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '006d72da28db' from v5.5]
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoLinux 5.4
Linus Torvalds [Mon, 25 Nov 2019 00:32:01 +0000 (16:32 -0800)]
Linux 5.4

2 years agoMerge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Linus Torvalds [Sun, 24 Nov 2019 20:36:39 +0000 (12:36 -0800)]
Merge branch 'fixes' of git://git./linux/kernel/git/viro/vfs

Pull cramfs fix from Al Viro:
 "Regression fix, fallen through the cracks"

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  cramfs: fix usage on non-MTD device

2 years agocramfs: fix usage on non-MTD device
Maxime Bizon [Sat, 19 Oct 2019 19:24:11 +0000 (15:24 -0400)]
cramfs: fix usage on non-MTD device

we fail to mount on MTD, we don't try on block device.

Note: this relies upon cramfs_mtd_fill_super() leaving no side
effects on fc state in case of failure; in general, failing
get_tree_...() does *not* mean "fine to try again"; e.g. parsed
options might've been consumed by fill_super callback and freed
on failure.

Fixes: 74f78fc5ef43 ("vfs: Convert cramfs to use the new mount API")

Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2 years agoMerge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Linus Torvalds [Sat, 23 Nov 2019 21:02:18 +0000 (13:02 -0800)]
Merge tag 'for_linus' of git://git./linux/kernel/git/mst/vhost

Pull last minute virtio bugfixes from Michael Tsirkin:
 "Minor bugfixes all over the place"

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  virtio_balloon: fix shrinker count
  virtio_balloon: fix shrinker scan number of pages
  virtio_console: allocate inbufs in add_port() only if it is needed
  virtio_ring: fix return code on DMA mapping fails

2 years agoMerge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Linus Torvalds [Sat, 23 Nov 2019 00:57:26 +0000 (16:57 -0800)]
Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input

Pull input fix from Dmitry Torokhov:
 "Just a single revert as RMI mode should not have been enabled for this
  model [yet?]"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Revert "Input: synaptics - enable RMI mode for X1 Extreme 2nd Generation"

2 years agoRevert "Input: synaptics - enable RMI mode for X1 Extreme 2nd Generation"
Lyude Paul [Fri, 22 Nov 2019 22:52:54 +0000 (14:52 -0800)]
Revert "Input: synaptics - enable RMI mode for X1 Extreme 2nd Generation"

This reverts commit 68b9c5066e39af41d3448abfc887c77ce22dd64d.

Ugh, I really dropped the ball on this one :\. So as it turns out RMI4
works perfectly fine on the X1 Extreme Gen 2 except for one thing I
didn't notice because I usually use the trackpoint: clicking with the
touchpad. Somehow this is broken, in fact we don't even seem to indicate
BTN_LEFT as a valid event type for the RMI4 touchpad. And, I don't even
see any RMI4 events coming from the touchpad when I press down on it.
This only seems to work for PS/2 mode.

Since that means we have a regression, and PS/2 mode seems to work fine
for the time being - revert this for now. We'll have to do a more
thorough investigation on this.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://lore.kernel.org/r/20191119234534.10725-1-lyude@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2 years agoMerge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Linus Torvalds [Fri, 22 Nov 2019 22:28:14 +0000 (14:28 -0800)]
Merge git://git./linux/kernel/git/netdev/net

Pull networking fixes from David Miller:

 1) Validate tunnel options length in act_tunnel_key, from Xin Long.

 2) Fix DMA sync bug in gve driver, from Adi Suresh.

 3) TSO kills performance on some r8169 chips due to HW issues, disable
    by default in that case, from Corinna Vinschen.

 4) Fix clock disable mismatch in fec driver, from Chubong Yuan.

 5) Fix interrupt status bits define in hns3 driver, from Huazhong Tan.

 6) Fix workqueue deadlocks in qeth driver, from Julian Wiedmann.

 7) Don't napi_disable() twice in r8152 driver, from Hayes Wang.

 8) Fix SKB extension memory leak, from Florian Westphal.

* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (54 commits)
  r8152: avoid to call napi_disable twice
  MAINTAINERS: Add myself as maintainer of virtio-vsock
  udp: drop skb extensions before marking skb stateless
  net: rtnetlink: prevent underflows in do_setvfinfo()
  can: m_can_platform: remove unnecessary m_can_class_resume() call
  can: m_can_platform: set net_device structure as driver data
  hv_netvsc: Fix send_table offset in case of a host bug
  hv_netvsc: Fix offset usage in netvsc_send_table()
  net-ipv6: IPV6_TRANSPARENT - check NET_RAW prior to NET_ADMIN
  sfc: Only cancel the PPS workqueue if it exists
  nfc: port100: handle command failure cleanly
  net-sysfs: fix netdev_queue_add_kobject() breakage
  r8152: Re-order napi_disable in rtl8152_close
  net: qca_spi: Move reset_count to struct qcaspi
  net: qca_spi: fix receive buffer size check
  net/ibmvnic: Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode
  Revert "net/ibmvnic: Fix EOI when running in XIVE mode"
  net/mlxfw: Verify FSM error code translation doesn't exceed array size
  net/mlx5: Update the list of the PCI supported devices
  net/mlx5: Fix auto group size calculation

2 years agoafs: Fix large file support
Marc Dionne [Thu, 21 Nov 2019 15:37:26 +0000 (15:37 +0000)]
afs: Fix large file support

By default s_maxbytes is set to MAX_NON_LFS, which limits the usable
file size to 2GB, enforced by the vfs.

Commit b9b1f8d5930a ("AFS: write support fixes") added support for the
64-bit fetch and store server operations, but did not change this value.
As a result, attempts to write past the 2G mark result in EFBIG errors:

 $ dd if=/dev/zero of=foo bs=1M count=1 seek=2048
 dd: error writing 'foo': File too large

Set s_maxbytes to MAX_LFS_FILESIZE.

Fixes: b9b1f8d5930a ("AFS: write support fixes")
Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2 years agoafs: Fix possible assert with callbacks from yfs servers
Marc Dionne [Thu, 21 Nov 2019 15:26:15 +0000 (15:26 +0000)]
afs: Fix possible assert with callbacks from yfs servers

Servers sending callback breaks to the YFS_CM_SERVICE service may
send up to YFSCBMAX (1024) fids in a single RPC.  Anything over
AFSCBMAX (50) will cause the assert in afs_break_callbacks to trigger.

Remove the assert, as the count has already been checked against
the appropriate max values in afs_deliver_cb_callback and

Fixes: 35dbfba3111a ("afs: Implement the YFS cache manager service")
Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2 years agor8152: avoid to call napi_disable twice
Hayes Wang [Fri, 22 Nov 2019 08:21:09 +0000 (16:21 +0800)]
r8152: avoid to call napi_disable twice

Call napi_disable() twice would cause dead lock. There are three situations
may result in the issue.

1. rtl8152_pre_reset() and set_carrier() are run at the same time.
2. Call rtl8152_set_tunable() after rtl8152_close().
3. Call rtl8152_set_ringparam() after rtl8152_close().

For #1, use the same solution as commit 84811412464d ("r8152: Re-order
napi_disable in rtl8152_close"). For #2 and #3, add checking the flag
of IFF_UP and using napi_disable/napi_enable during mutex.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoMerge branch 'akpm' (patches from Andrew)
Linus Torvalds [Fri, 22 Nov 2019 17:49:08 +0000 (09:49 -0800)]
Merge branch 'akpm' (patches from Andrew)

Merge misc fixes from Andrew Morton:
 "Three fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  mm/ksm.c: don't WARN if page is still mapped in remove_stable_node()
  mm/memory_hotplug: don't access uninitialized memmaps in shrink_zone_span()
  Revert "fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()"

2 years agoMerge tag 'linux-can-fixes-for-5.4-20191122' of git://git.kernel.org/pub/scm/linux...
David S. Miller [Fri, 22 Nov 2019 17:42:11 +0000 (09:42 -0800)]
Merge tag 'linux-can-fixes-for-5.4-20191122' of git://git./linux/kernel/git/mkl/linux-can

Marc Kleine-Budde says:

pull-request: can 2019-11-22

this is a pull request of 2 patches for net/master, if possible for the
current release cycle. Otherwise these patches should hit v5.4 via the
stable tree.

Both patches of this pull request target the m_can driver. Pankaj Sharma
fixes the fallout in the m_can_platform part, which appeared with the
introduction of the m_can platform framework.

Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoMAINTAINERS: Add myself as maintainer of virtio-vsock
Stefano Garzarella [Fri, 22 Nov 2019 10:20:10 +0000 (11:20 +0100)]
MAINTAINERS: Add myself as maintainer of virtio-vsock

Since I'm actively working on vsock and virtio/vhost transports,
Stefan suggested to help him to maintain it.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoudp: drop skb extensions before marking skb stateless
Florian Westphal [Thu, 21 Nov 2019 05:56:23 +0000 (06:56 +0100)]
udp: drop skb extensions before marking skb stateless

Once udp stack has set the UDP_SKB_IS_STATELESS flag, later skb free
assumes all skb head state has been dropped already.

This will leak the extension memory in case the skb has extensions other
than the ipsec secpath, e.g. bridge nf data.

To fix this, set the UDP_SKB_IS_STATELESS flag only if we don't have
extensions or if the extension space can be free'd.

Fixes: 895b5c9f206eb7d25dc1360a ("netfilter: drop bridge nf reset from nf_reset")
Cc: Paolo Abeni <pabeni@redhat.com>
Reported-by: Byron Stanoszek <gandalf@winds.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agonet: rtnetlink: prevent underflows in do_setvfinfo()
Dan Carpenter [Wed, 20 Nov 2019 12:34:38 +0000 (15:34 +0300)]
net: rtnetlink: prevent underflows in do_setvfinfo()

The "ivm->vf" variable is a u32, but the problem is that a number of
drivers cast it to an int and then forget to check for negatives.  An
example of this is in the cxgb4 driver.

  2890  static int cxgb4_mgmt_get_vf_config(struct net_device *dev,
  2891                                      int vf, struct ifla_vf_info *ivi)
  2892  {
  2893          struct port_info *pi = netdev_priv(dev);
  2894          struct adapter *adap = pi->adapter;
  2895          struct vf_info *vfinfo;
  2897          if (vf >= adap->num_vfs)
  2898                  return -EINVAL;
  2899          vfinfo = &adap->vfinfo[vf];

There are 48 functions affected.

drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c:8435 hclge_set_vf_vlan_filter() warn: can 'vfid' underflow 's32min-2147483646'
drivers/net/ethernet/freescale/enetc/enetc_pf.c:377 enetc_pf_set_vf_mac() warn: can 'vf' underflow 's32min-2147483646'
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2899 cxgb4_mgmt_get_vf_config() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2960 cxgb4_mgmt_set_vf_rate() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3019 cxgb4_mgmt_set_vf_rate() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3038 cxgb4_mgmt_set_vf_vlan() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3086 cxgb4_mgmt_set_vf_link_state() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/chelsio/cxgb/cxgb2.c:791 get_eeprom() warn: can 'i' underflow 's32min-(-4),0,4-s32max'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:82 bnxt_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:164 bnxt_set_vf_trust() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:186 bnxt_get_vf_config() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:228 bnxt_set_vf_mac() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:264 bnxt_set_vf_vlan() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:293 bnxt_set_vf_bw() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:333 bnxt_set_vf_link_state() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2595 bnx2x_vf_op_prep() warn: can 'vfidx' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2595 bnx2x_vf_op_prep() warn: can 'vfidx' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2281 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2285 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2286 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2292 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2297 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1832 qlcnic_sriov_set_vf_mac() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1864 qlcnic_sriov_set_vf_tx_rate() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1937 qlcnic_sriov_set_vf_vlan() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:2005 qlcnic_sriov_get_vf_config() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:2036 qlcnic_sriov_set_vf_spoofchk() warn: can 'vf' underflow 's32min-254'
drivers/net/ethernet/emulex/benet/be_main.c:1914 be_get_vf_config() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/emulex/benet/be_main.c:1915 be_get_vf_config() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/emulex/benet/be_main.c:1922 be_set_vf_tvt() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/emulex/benet/be_main.c:1951 be_clear_vf_tvt() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/emulex/benet/be_main.c:2063 be_set_vf_tx_rate() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/emulex/benet/be_main.c:2091 be_set_vf_link_state() warn: can 'vf' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:2609 ice_set_vf_port_vlan() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3050 ice_get_vf_cfg() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3103 ice_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3181 ice_set_vf_mac() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3237 ice_set_vf_trust() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3286 ice_set_vf_link_state() warn: can 'vf_id' underflow 's32min-65534'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:3919 i40e_validate_vf() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:3957 i40e_ndo_set_vf_mac() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4104 i40e_ndo_set_vf_port_vlan() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4263 i40e_ndo_set_vf_bw() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4309 i40e_ndo_get_vf_config() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4371 i40e_ndo_set_vf_link_state() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4441 i40e_ndo_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4441 i40e_ndo_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-2147483646'
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4504 i40e_ndo_set_vf_trust() warn: can 'vf_id' underflow 's32min-2147483646'

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoMerge tag 'pm-5.4-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael...
Linus Torvalds [Fri, 22 Nov 2019 17:18:16 +0000 (09:18 -0800)]
Merge tag 'pm-5.4-final' of git://git./linux/kernel/git/rafael/linux-pm

Pull power management regression fix from Rafael Wysocki:
 "Fix problems with switching cpufreq drivers on some x86 systems with
  ACPI (and with changing the operation modes of the intel_pstate driver
  on those systems) introduced by recent changes related to the
  management of frequency limits in cpufreq"

* tag 'pm-5.4-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM: QoS: Invalidate frequency QoS requests after removal

2 years agoMerge tag 'drm-fixes-2019-11-22' of git://anongit.freedesktop.org/drm/drm
Linus Torvalds [Fri, 22 Nov 2019 17:14:30 +0000 (09:14 -0800)]
Merge tag 'drm-fixes-2019-11-22' of git://anongit.freedesktop.org/drm/drm

Pull drm fixes from Dave Airlie:
 "Two sets of fixes in here, one for amdgpu, and one for i915.

  The amdgpu ones are pretty small, i915's CI system seems to have a few
  problems in the last week or so, there is one major regression fix for
  fb_mmap, but there are a bunch of other issues fixed in there as well,
  oops, screen flashes and rcu related.

   - Remove experimental flag for navi14
   - Fix confusing power message failures on older VI parts
   - Hang fix for gfxoff when using the read register interface
   - Two stability regression fixes for Raven

   - Fix kernel oops on dumb_create ioctl on no crtc situation
   - Fix bad ugly colored flash on VLV/CHV related to gamma LUT update
   - Fix unity of the frequencies reported on PMU
   - Fix kernel oops on set_page_dirty using better locks around it
   - Protect the request pointer with RCU to prevent it being freed
     while we might need still
   - Make pool objects read-only
   - Restore physical addresses for fb_map to avoid corrupted page

* tag 'drm-fixes-2019-11-22' of git://anongit.freedesktop.org/drm/drm:
  drm/i915/fbdev: Restore physical addresses for fb_mmap()
  Revert "drm/amd/display: enable S/G for RAVEN chip"
  drm/amdgpu: disable gfxoff on original raven
  drm/amdgpu: disable gfxoff when using register read interface
  drm/amd/powerplay: correct fine grained dpm force level setting
  drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICs
  drm/amdgpu: remove experimental flag for Navi14
  drm/i915: make pool objects read-only
  drm/i915: Protect request peeking with RCU
  drm/i915/userptr: Try to acquire the page lock around set_page_dirty()
  drm/i915/pmu: "Frequency" is reported as accumulated cycles
  drm/i915: Preload LUTs if the hw isn't currently using them
  drm/i915: Don't oops in dumb_create ioctl if we have no crtcs

2 years agomm/ksm.c: don't WARN if page is still mapped in remove_stable_node()
Andrey Ryabinin [Fri, 22 Nov 2019 01:54:01 +0000 (17:54 -0800)]
mm/ksm.c: don't WARN if page is still mapped in remove_stable_node()

It's possible to hit the WARN_ON_ONCE(page_mapped(page)) in
remove_stable_node() when it races with __mmput() and squeezes in
between ksm_exit() and exit_mmap().

  WARNING: CPU: 0 PID: 3295 at mm/ksm.c:888 remove_stable_node+0x10c/0x150

  Call Trace:

Remove the warning as there is nothing scary going on.

Link: http://lkml.kernel.org/r/20191119131850.5675-1-aryabinin@virtuozzo.com
Fixes: cbf86cfe04a6 ("ksm: remove old stable nodes more thoroughly")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2 years agomm/memory_hotplug: don't access uninitialized memmaps in shrink_zone_span()
David Hildenbrand [Fri, 22 Nov 2019 01:53:56 +0000 (17:53 -0800)]
mm/memory_hotplug: don't access uninitialized memmaps in shrink_zone_span()

Let's limit shrinking to !ZONE_DEVICE so we can fix the current code.
We should never try to touch the memmap of offline sections where we
could have uninitialized memmaps and could trigger BUGs when calling
page_to_nid() on poisoned pages.

There is no reliable way to distinguish an uninitialized memmap from an
initialized memmap that belongs to ZONE_DEVICE, as we don't have
anything like SECTION_IS_ONLINE we can use similar to
pfn_to_online_section() for !ZONE_DEVICE memory.

E.g., set_zone_contiguous() similarly relies on pfn_to_online_section()
and will therefore never set a ZONE_DEVICE zone consecutive.  Stopping
to shrink the ZONE_DEVICE therefore results in no observable changes,
besides /proc/zoneinfo indicating different boundaries - something we
can totally live with.

Before commit d0dc12e86b31 ("mm/memory_hotplug: optimize memory
hotplug"), the memmap was initialized with 0 and the node with the right
value.  So the zone might be wrong but not garbage.  After that commit,
both the zone and the node will be garbage when touching uninitialized

Toshiki reported a BUG (race between delayed initialization of
ZONE_DEVICE memmaps without holding the memory hotplug lock and
concurrent zone shrinking).


"Iteration of create and destroy namespace causes the panic as below:

      kernel BUG at mm/page_alloc.c:535!
      CPU: 7 PID: 2766 Comm: ndctl Not tainted 5.4.0-rc4 #6
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
      RIP: 0010:set_pfnblock_flags_mask+0x95/0xf0
      Call Trace:
       pmem_attach_disk+0x16b/0x600 [nd_pmem]

  While creating a namespace and initializing memmap, if you destroy the
  namespace and shrink the zone, it will initialize the memmap outside
  the zone and trigger VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page),
  pfn), page) in set_pfnblock_flags_mask()."

This BUG is also mitigated by this commit, where we for now stop to
shrink the ZONE_DEVICE zone until we can do it in a safe and clean way.

Link: http://lkml.kernel.org/r/20191006085646.5768-5-david@redhat.com
Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") [visible after d0dc12e86b319]
Signed-off-by: David Hildenbrand <david@redhat.com>
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Reported-by: Toshiki Fukasawa <t-fukasawa@vx.jp.nec.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Damian Tometzki <damian.tometzki@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Halil Pasic <pasic@linux.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jun Yao <yaojun8558363@gmail.com>
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Pankaj Gupta <pagupta@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pavel Tatashin <pavel.tatashin@microsoft.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Qian Cai <cai@lca.pw>
Cc: Rich Felker <dalias@libc.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>
Cc: Will Deacon <will@kernel.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Yu Zhao <yuzhao@google.com>
Cc: <stable@vger.kernel.org> [4.13+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2 years agoRevert "fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()"
Joseph Qi [Fri, 22 Nov 2019 01:53:52 +0000 (17:53 -0800)]
Revert "fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()"

This reverts commit 56e94ea132bb5c2c1d0b60a6aeb34dcb7d71a53d.

Commit 56e94ea132bb ("fs: ocfs2: fix possible null-pointer dereferences
in ocfs2_xa_prepare_entry()") introduces a regression that fail to
create directory with mount option user_xattr and acl.  Actually the
reported NULL pointer dereference case can be correctly handled by
loc->xl_ops->xlo_add_entry(), so revert it.

Link: http://lkml.kernel.org/r/1573624916-83825-1-git-send-email-joseph.qi@linux.alibaba.com
Fixes: 56e94ea132bb ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()")
Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Reported-by: Thomas Voegtle <tv@lio96.de>
Acked-by: Changwei Ge <gechangwei@live.cn>
Cc: Jia-Ju Bai <baijiaju1990@gmail.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Gang He <ghe@suse.com>
Cc: Jun Piao <piaojun@huawei.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2 years agocan: m_can_platform: remove unnecessary m_can_class_resume() call
Pankaj Sharma [Tue, 19 Nov 2019 10:20:38 +0000 (15:50 +0530)]
can: m_can_platform: remove unnecessary m_can_class_resume() call

The function m_can_runtime_resume() is getting recursively called from
m_can_class_resume(). This results in a lock up.

We need not call m_can_class_resume() during m_can_runtime_resume().

Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework")
Signed-off-by: Pankaj Sharma <pankj.sharma@samsung.com>
Signed-off-by: Sriram Dash <sriram.dash@samsung.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2 years agocan: m_can_platform: set net_device structure as driver data
Pankaj Sharma [Tue, 19 Nov 2019 10:20:37 +0000 (15:50 +0530)]
can: m_can_platform: set net_device structure as driver data

The current code is failing during clock prepare enable because of not
getting proper clock from platform device.

[    0.852089] Call trace:
[    0.854516]  0xffff0000fa22a668
[    0.857638]  clk_prepare+0x20/0x34
[    0.861019]  m_can_runtime_resume+0x2c/0xe4
[    0.865180]  pm_generic_runtime_resume+0x28/0x38
[    0.869770]  __rpm_callback+0x16c/0x1bc
[    0.873583]  rpm_callback+0x24/0x78
[    0.877050]  rpm_resume+0x428/0x560
[    0.880517]  __pm_runtime_resume+0x7c/0xa8
[    0.884593]  m_can_clk_start.isra.9.part.10+0x1c/0xa8
[    0.889618]  m_can_class_register+0x138/0x370
[    0.893950]  m_can_plat_probe+0x120/0x170
[    0.897939]  platform_drv_probe+0x4c/0xa0
[    0.901924]  really_probe+0xd8/0x31c
[    0.905477]  driver_probe_device+0x58/0xe8
[    0.909551]  device_driver_attach+0x68/0x70
[    0.913711]  __driver_attach+0x9c/0xf8
[    0.917437]  bus_for_each_dev+0x50/0xa0
[    0.921251]  driver_attach+0x20/0x28
[    0.924804]  bus_add_driver+0x148/0x1fc
[    0.928617]  driver_register+0x6c/0x124
[    0.932431]  __platform_driver_register+0x48/0x50
[    0.937113]  m_can_plat_driver_init+0x18/0x20
[    0.941446]  do_one_initcall+0x4c/0x19c
[    0.945259]  kernel_init_freeable+0x1d0/0x280
[    0.949591]  kernel_init+0x10/0x100
[    0.953057]  ret_from_fork+0x10/0x18
[    0.956614] Code: 00000000 00000000 00000000 00000000 (fa22a668)
[    0.962681] ---[ end trace 881f71bd609de763 ]---
[    0.967301] Kernel panic - not syncing: Attempted to kill init!

A device driver for CAN controller hardware registers itself with the
Linux network layer as a network device. So, the driver data for m_can
should ideally be of type net_device.

Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework")
Signed-off-by: Pankaj Sharma <pankj.sharma@samsung.com>
Signed-off-by: Sriram Dash <sriram.dash@samsung.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2 years agoMerge branch 'hv_netvsc-Fix-send-indirection-table-offset'
David S. Miller [Fri, 22 Nov 2019 03:32:23 +0000 (19:32 -0800)]
Merge branch 'hv_netvsc-Fix-send-indirection-table-offset'

Haiyang Zhang says:

hv_netvsc: Fix send indirection table offset

Fix send indirection table offset issues related to guest and
host bugs.

Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agohv_netvsc: Fix send_table offset in case of a host bug
Haiyang Zhang [Thu, 21 Nov 2019 21:33:41 +0000 (13:33 -0800)]
hv_netvsc: Fix send_table offset in case of a host bug

If negotiated NVSP version <= NVSP_PROTOCOL_VERSION_6, the offset may
be wrong (too small) due to a host bug. This can cause missing the
end of the send indirection table, and add multiple zero entries from
leading zeros before the data region. This bug adds extra burden on
channel 0.

So fix the offset by computing it from the data structure sizes. This
will ensure netvsc driver runs normally on unfixed hosts, and future
fixed hosts.

Fixes: 5b54dac856cb ("hyperv: Add support for virtual Receive Side Scaling (vRSS)")
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agohv_netvsc: Fix offset usage in netvsc_send_table()
Haiyang Zhang [Thu, 21 Nov 2019 21:33:40 +0000 (13:33 -0800)]
hv_netvsc: Fix offset usage in netvsc_send_table()

To reach the data region, the existing code adds offset in struct
nvsp_5_send_indirect_table on the beginning of this struct. But the
offset should be based on the beginning of its container,
struct nvsp_message. This bug causes the first table entry missing,
and adds an extra zero from the zero pad after the data region.
This can put extra burden on the channel 0.

So, correct the offset usage. Also add a boundary check to ensure
not reading beyond data region.

Fixes: 5b54dac856cb ("hyperv: Add support for virtual Receive Side Scaling (vRSS)")
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agonet-ipv6: IPV6_TRANSPARENT - check NET_RAW prior to NET_ADMIN
Maciej Żenczykowski [Thu, 21 Nov 2019 21:19:08 +0000 (13:19 -0800)]
net-ipv6: IPV6_TRANSPARENT - check NET_RAW prior to NET_ADMIN

NET_RAW is less dangerous, so more likely to be available to a process,
so check it first to prevent some spurious logging.

This matches IP_TRANSPARENT which checks NET_RAW first.

Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoMerge tag 'drm-intel-fixes-2019-11-21' of git://anongit.freedesktop.org/drm/drm-intel...
Dave Airlie [Fri, 22 Nov 2019 00:23:22 +0000 (10:23 +1000)]
Merge tag 'drm-intel-fixes-2019-11-21' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

- Fix kernel oops on dumb_create ioctl on no crtc situation
- Fix bad ugly colored flash on VLV/CHV related to gamma LUT update
- Fix unity of the frequencies reported on PMU
- Fix kernel oops on set_page_dirty using better locks around it
- Protect the request pointer with RCU to prevent it being freed while we might need still
- Make pool objects read-only
- Restore physical addresses for fb_map to avoid corrupted page table

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121165339.GA23920@intel.com
2 years agoMerge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Linus Torvalds [Thu, 21 Nov 2019 20:15:24 +0000 (12:15 -0800)]
Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux

Pull arm64 fix from Will Deacon:
 "Ensure PAN is re-enabled following user fault in uaccess routines.

  After I thought we were done for 5.4, we had a report this week of a
  nasty issue that has been shown to leak data between different user
  address spaces thanks to corruption of entries in the TLB. In
  hindsight, we should have spotted this in review when the PAN code was
  merged back in v4.3, but hindsight is 20/20 and I'm trying not to beat
  myself up too much about it despite being fairly miserable.

  Anyway, the fix is "obvious" but the actual failure is more more
  subtle, and is described in the commit message. I've included a fairly
  mechanical follow-up patch here as well, which moves this checking out
  into the C wrappers which is what we do for {get,put}_user() already
  and allows us to remove these bloody assembly macros entirely. The
  patches have passed kernelci [1] [2] [3] and CKI [4] tests over night,
  as well as some targetted testing [5] for this particular issue.

  The first patch is tagged for stable and should be applied to 4.14,
  4.19 and 5.3. I have separate backports for 4.4 and 4.9, which I'll
  send out once this has landed in your tree (although the original
  patch applies cleanly, it won't build for those two trees).

  Thanks to Pavel Tatashin for reporting this and Mark Rutland for
  helping to diagnose the issue and review/test the solution"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: uaccess: Remove uaccess_*_not_uao asm macros
  arm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess fault

2 years agosfc: Only cancel the PPS workqueue if it exists
Martin Habets [Thu, 21 Nov 2019 17:52:15 +0000 (17:52 +0000)]
sfc: Only cancel the PPS workqueue if it exists

The workqueue only exists for the primary PF. For other functions
we hit a WARN_ON in kernel/workqueue.c.

Fixes: 7c236c43b838 ("sfc: Add support for IEEE-1588 PTP")
Signed-off-by: Martin Habets <mhabets@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoMerge tag 'for-linus-20191121' of git://git.kernel.dk/linux-block
Linus Torvalds [Thu, 21 Nov 2019 20:04:50 +0000 (12:04 -0800)]
Merge tag 'for-linus-20191121' of git://git.kernel.dk/linux-block

Pull block fix from Jens Axboe:
 "Just a single fix for an issue in nbd introduced in this cycle"

* tag 'for-linus-20191121' of git://git.kernel.dk/linux-block:
  nbd:fix memory leak in nbd_get_socket()

2 years agoMerge tag 'gpio-v5.4-5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux...
Linus Torvalds [Thu, 21 Nov 2019 20:01:30 +0000 (12:01 -0800)]
Merge tag 'gpio-v5.4-5' of git://git./linux/kernel/git/linusw/linux-gpio

Pull GPIO fixes from Linus Walleij:
 "A last set of small fixes for GPIO, this cycle was quite busy.

   - Fix debounce delays on the MAX77620 GPIO expander

   - Use the correct unit for debounce times on the BD70528 GPIO expander

   - Get proper deps for parallel builds of the GPIO tools

   - Add a specific ACPI quirk for the Terra Pad 1061"

* tag 'gpio-v5.4-5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist
  tools: gpio: Correctly add make dependencies for gpio_utils
  gpio: bd70528: Use correct unit for debounce times
  gpio: max77620: Fixup debounce delays

2 years agoMerge tag 'for-linus-2019-11-21' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Thu, 21 Nov 2019 19:51:49 +0000 (11:51 -0800)]
Merge tag 'for-linus-2019-11-21' of git://git./linux/kernel/git/brauner/linux

Pull pidfd fixlet from Christian Brauner:
 "This contains a simple fix for the pidfd poll method. In the original
  patchset pidfd_poll() was made to return an unsigned int. However, the
  poll method is defined to return a __poll_t. While the unsigned int is
  not a huge deal it's just nicer to return a __poll_t.

  I've decided to send it right before the 5.4 release mainly so that
  stable doesn't need to backport it to both 5.4 and 5.3"

* tag 'for-linus-2019-11-21' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
  fork: fix pidfd_poll()'s return type

2 years agonfc: port100: handle command failure cleanly
Oliver Neukum [Thu, 21 Nov 2019 10:37:10 +0000 (11:37 +0100)]
nfc: port100: handle command failure cleanly

If starting the transfer of a command suceeds but the transfer for the reply
fails, it is not enough to initiate killing the transfer for the
command may still be running. You need to wait for the killing to finish
before you can reuse URB and buffer.

Reported-and-tested-by: syzbot+711468aa5c3a1eabf863@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agodrm/i915/fbdev: Restore physical addresses for fb_mmap()
Chris Wilson [Wed, 13 Nov 2019 18:06:33 +0000 (18:06 +0000)]
drm/i915/fbdev: Restore physical addresses for fb_mmap()

fbdev uses the physical address of our framebuffer for its fb_mmap()
routine. While we need to adapt this address for the new io BAR, we have
to fix v5.4 first! The simplest fix is to restore the smem back to v5.3
and we will then probably have to implement our fbops->fb_mmap() callback
to handle local memory.

Reported-by: Neil MacLeod <freedesktop@nmacleod.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256
Fixes: 5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Neil MacLeod <freedesktop@nmacleod.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113180633.3947-1-chris@chris-wilson.co.uk
(cherry picked from commit abc5520704ab438099fe352636b30b05c1253bea)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 9faf5fa4d3dad3b0c0fa6e67689c144981a11c27)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2 years agonet-sysfs: fix netdev_queue_add_kobject() breakage
Eric Dumazet [Thu, 21 Nov 2019 03:19:07 +0000 (19:19 -0800)]
net-sysfs: fix netdev_queue_add_kobject() breakage

kobject_put() should only be called in error path.

Fixes: b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jouni Hogander <jouni.hogander@unikie.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoMerge tag 'drm-fixes-5.4-2019-11-20' of git://people.freedesktop.org/~agd5f/linux...
Dave Airlie [Thu, 21 Nov 2019 05:07:35 +0000 (15:07 +1000)]
Merge tag 'drm-fixes-5.4-2019-11-20' of git://people.freedesktop.org/~agd5f/linux into drm-fixes


- Remove experimental flag for navi14
- Fix confusing power message failures on older VI parts
- Hang fix for gfxoff when using the read register interface
- Two stability regression fixes for Raven

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191120235130.23755-1-alexander.deucher@amd.com
2 years agoRevert "drm/amd/display: enable S/G for RAVEN chip"
Alex Deucher [Fri, 15 Nov 2019 15:26:52 +0000 (10:26 -0500)]
Revert "drm/amd/display: enable S/G for RAVEN chip"

This reverts commit 1c4259159132ae4ceaf7c6db37a6cf76417f73d9.

S/G display is not stable with the IOMMU enabled on some

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205523
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2 years agodrm/amdgpu: disable gfxoff on original raven
Alex Deucher [Fri, 15 Nov 2019 15:21:23 +0000 (10:21 -0500)]
drm/amdgpu: disable gfxoff on original raven

There are still combinations of sbios and firmware that
are not stable.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=204689
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2 years agodrm/amdgpu: disable gfxoff when using register read interface
Alex Deucher [Thu, 14 Nov 2019 16:39:05 +0000 (11:39 -0500)]
drm/amdgpu: disable gfxoff when using register read interface

When gfxoff is enabled, accessing gfx registers via MMIO
can lead to a hang.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205497
Acked-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2 years agodrm/amd/powerplay: correct fine grained dpm force level setting
Evan Quan [Thu, 14 Nov 2019 08:58:31 +0000 (16:58 +0800)]
drm/amd/powerplay: correct fine grained dpm force level setting

For fine grained dpm, there is only two levels supported. However
to reflect correctly the current clock frequency, there is an
intermediate level faked. Thus on forcing level setting, we
need to treat level 2 correctly as level 1.

Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2 years agodrm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICs
Evan Quan [Thu, 14 Nov 2019 07:30:39 +0000 (15:30 +0800)]
drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICs

Otherwise, the error message prompted will confuse user.

Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2 years agodrm/amdgpu: remove experimental flag for Navi14
Alex Deucher [Fri, 15 Nov 2019 14:38:28 +0000 (09:38 -0500)]
drm/amdgpu: remove experimental flag for Navi14

5.4 and newer works fine with navi14.

Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2 years agoMerge tag 'mlx5-fixes-2019-11-20' of git://git.kernel.org/pub/scm/linux/kernel/git...
David S. Miller [Wed, 20 Nov 2019 20:56:32 +0000 (12:56 -0800)]
Merge tag 'mlx5-fixes-2019-11-20' of git://git./linux/kernel/git/saeed/linux

Saeed Mahameed says:

Mellanox, mlx5 fixes 2019-11-20

This series introduces some fixes to mlx5 driver.

Please pull and let me know if there is any problem.

For -stable v4.9:
 ('net/mlx5e: Fix set vf link state error flow')

For -stable v4.14
 ('net/mlxfw: Verify FSM error code translation doesn't exceed array size')

For -stable v4.19
 ('net/mlx5: Fix auto group size calculation')

For -stable v5.3
 ('net/mlx5e: Fix error flow cleanup in mlx5e_tc_tun_create_header_ipv4/6')
 ('net/mlx5e: Do not use non-EXT link modes in EXT mode')
 ('net/mlx5: Update the list of the PCI supported devices')

Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agor8152: Re-order napi_disable in rtl8152_close
Prashant Malani [Wed, 20 Nov 2019 19:40:21 +0000 (11:40 -0800)]
r8152: Re-order napi_disable in rtl8152_close

Both rtl_work_func_t() and rtl8152_close() call napi_disable().
Since the two calls aren't protected by a lock, if the close
function starts executing before the work function, we can get into a
situation where the napi_disable() function is called twice in
succession (first by rtl8152_close(), then by set_carrier()).

In such a situation, the second call would loop indefinitely, since
rtl8152_close() doesn't call napi_enable() to clear the NAPI_STATE_SCHED

The rtl8152_close() function in turn issues a
cancel_delayed_work_sync(), and so it would wait indefinitely for the
rtl_work_func_t() to complete. Since rtl8152_close() is called by a
process holding rtnl_lock() which is requested by other processes, this
eventually leads to a system deadlock and crash.

Re-order the napi_disable() call to occur after the work function
disabling and urb cancellation calls are issued.

Change-Id: I6ef0b703fc214998a037a68f722f784e1d07815e
Reported-by: http://crbug.com/1017928
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoMerge branch 'qca_spi-fixes'
David S. Miller [Wed, 20 Nov 2019 20:42:23 +0000 (12:42 -0800)]
Merge branch 'qca_spi-fixes'

Stefan Wahren says:

net: qca_spi: Fix receive and reset issues

This small patch series fixes two major issues in the SPI driver for the

It has been tested on a Charge Control C 300 (NXP i.MX6ULL +
2x QCA7000).

Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agonet: qca_spi: Move reset_count to struct qcaspi
Stefan Wahren [Wed, 20 Nov 2019 17:29:13 +0000 (18:29 +0100)]
net: qca_spi: Move reset_count to struct qcaspi

The reset counter is specific for every QCA700x chip. So move this
into the private driver struct. Otherwise we get unpredictable reset
behavior in setups with multiple QCA700x chips.

Fixes: 291ab06ecf67 (net: qualcomm: new Ethernet over SPI driver for QCA7000)
Signed-off-by: Stefan Wahren <stefan.wahren@in-tech.com>
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agonet: qca_spi: fix receive buffer size check
Michael Heimpold [Wed, 20 Nov 2019 17:29:12 +0000 (18:29 +0100)]
net: qca_spi: fix receive buffer size check

When receiving many or larger packets, e.g. when doing a file download,
it was observed that the read buffer size register reports up to 4 bytes
more than the current define allows in the check.
If this is the case, then no data transfer is initiated to receive the
packets (and thus to empty the buffer) which results in a stall of the

These 4 bytes are a hardware generated frame length which is prepended
to the actual frame, thus we have to respect it during our check.

Fixes: 026b907d58c4 ("net: qca_spi: Add available buffer space verification")
Signed-off-by: Michael Heimpold <michael.heimpold@in-tech.com>
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoMerge branch 'ibmvnic-regression'
David S. Miller [Wed, 20 Nov 2019 20:37:15 +0000 (12:37 -0800)]
Merge branch 'ibmvnic-regression'

Juliet Kim says:

Support both XIVE and XICS modes in ibmvnic

This series aims to support both XICS and XIVE with avoiding
a regression in behavior when a system runs in XICS mode.

Patch 1 reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(“net/ibmvnic: Fix EOI when running in XIVE mode.”)

Patch 2 Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode

Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agonet/ibmvnic: Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode
Juliet Kim [Wed, 20 Nov 2019 15:50:04 +0000 (10:50 -0500)]
net/ibmvnic: Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode

Reversion of commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(“net/ibmvnic: Fix EOI when running in XIVE mode.”) leaves us
calling H_EOI even in XIVE mode. That will fail with H_FUNCTION
because H_EOI is not supported in that mode. That failure is
harmless. Ignore it so we can use common code for both XICS and

Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoRevert "net/ibmvnic: Fix EOI when running in XIVE mode"
Juliet Kim [Wed, 20 Nov 2019 15:50:03 +0000 (10:50 -0500)]
Revert "net/ibmvnic: Fix EOI when running in XIVE mode"

This reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(“net/ibmvnic: Fix EOI when running in XIVE mode.”) since that
has the unintended effect of changing the interrupt priority
and emits warning when running in legacy XICS mode.

Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agonet/mlxfw: Verify FSM error code translation doesn't exceed array size
Eran Ben Elisha [Sun, 17 Nov 2019 08:18:59 +0000 (10:18 +0200)]
net/mlxfw: Verify FSM error code translation doesn't exceed array size

Array mlxfw_fsm_state_err_str contains value to string translation, when
values are provided by mlxfw_dev. If value is larger than
MLXFW_FSM_STATE_ERR_MAX, return "unknown error" as expected instead of
reading an address than exceed array size.

Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agonet/mlx5: Update the list of the PCI supported devices
Shani Shapp [Tue, 12 Nov 2019 13:10:00 +0000 (15:10 +0200)]
net/mlx5: Update the list of the PCI supported devices

Add the upcoming ConnectX-6 LX device ID.

Fixes: 85327a9c4150 ("net/mlx5: Update the list of the PCI supported devices")
Signed-off-by: Shani Shapp <shanish@mellanox.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agonet/mlx5: Fix auto group size calculation
Maor Gottlieb [Thu, 5 Sep 2019 06:56:10 +0000 (09:56 +0300)]
net/mlx5: Fix auto group size calculation

Once all the large flow groups (defined by the user when the flow table
is created - max_num_groups) were created, then all the following new
flow groups will have only one flow table entry, even though the flow table
has place to larger groups.
Fix the condition to prefer large flow group.

Fixes: f0d22d187473 ("net/mlx5_core: Introduce flow steering autogrouped flow table")
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agonet/mlx5e: Add missing capability bit check for IP-in-IP
Marina Varshaver [Tue, 19 Nov 2019 16:52:13 +0000 (18:52 +0200)]
net/mlx5e: Add missing capability bit check for IP-in-IP

Device that doesn't support IP-in-IP offloads has to filter csum and gso
offload support, otherwise kernel will conclude that device is capable of
offloading csum and gso for IP-in-IP tunnels and that might result in
IP-in-IP tunnel not functioning.

Fixes: 25948b87dda2 ("net/mlx5e: Support TSO and TX checksum offloads for IP-in-IP")
Signed-off-by: Marina Varshaver <marinav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agonet/mlx5e: Do not use non-EXT link modes in EXT mode
Eran Ben Elisha [Sun, 17 Nov 2019 13:17:05 +0000 (15:17 +0200)]
net/mlx5e: Do not use non-EXT link modes in EXT mode

On some old Firmwares, connector type value was not supported, and value
read from FW was 0. For those, driver used link mode in order to set
connector type in link_ksetting.

After FW exposed the connector type, driver translated the value to ethtool
definitions. However, as 0 is a valid value, before returning PORT_OTHER,
driver run the check of link mode in order to maintain backward

Cited patch added support to EXT mode.  With both features (connector type
and EXT link modes) ,if connector_type read from FW is 0 and EXT mode is
set, driver mistakenly compare EXT link modes to non-EXT link mode.
Fixed that by skipping this comparison if we are in EXT mode, as connector
type value is valid in this scenario.

Fixes: 6a897372417e ("net/mlx5: ethtool, Add ethtool support for 50Gbps per lane link modes")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Reviewed-by: Aya Levin <ayal@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agonet/mlx5e: Fix set vf link state error flow
Roi Dayan [Wed, 13 Nov 2019 12:42:00 +0000 (14:42 +0200)]
net/mlx5e: Fix set vf link state error flow

Before this commit the ndo always returned success.
Fix that.

Fixes: 1ab2068a4c66 ("net/mlx5: Implement vports admin state backup/restore")
Signed-off-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Vlad Buslov <vladbu@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agonet/mlx5: DR, Limit STE hash table enlarge based on bytemask
Alex Vesker [Sun, 10 Nov 2019 13:39:36 +0000 (15:39 +0200)]
net/mlx5: DR, Limit STE hash table enlarge based on bytemask

When an ste hash table has too many collision we enlarge it
to a bigger hash table (rehash). Rehashing collision improvement
depends on the bytemask value. The more 1 bits we have in bytemask
means better spreading in the table.

Without this fix tables can grow in size without providing any
improvement which can lead to memory depletion and failures.

This patch will limit table rehash to reduce memory and improve
the performance.

Fixes: 41d07074154c ("net/mlx5: DR, Expose steering rule functionality")
Signed-off-by: Alex Vesker <valex@mellanox.com>
Reviewed-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agonet/mlx5: DR, Skip rehash for tables with byte mask zero
Alex Vesker [Thu, 31 Oct 2019 13:24:59 +0000 (15:24 +0200)]
net/mlx5: DR, Skip rehash for tables with byte mask zero

The byte mask fields affect on the hash index distribution,
when the byte mask is zero, the hash calculation will always
be equal to the same index.

To avoid unneeded rehash of hash tables mark the table to skip

This is needed by the next patch which will limit table rehash
to reduce memory consumption.

Fixes: 41d07074154c ("net/mlx5: DR, Expose steering rule functionality")
Signed-off-by: Alex Vesker <valex@mellanox.com>
Reviewed-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agonet/mlx5: DR, Fix invalid EQ vector number on CQ creation
Alex Vesker [Mon, 4 Nov 2019 09:59:21 +0000 (11:59 +0200)]
net/mlx5: DR, Fix invalid EQ vector number on CQ creation

When creating a CQ, the CPU id is used for the vector value.
This would fail in-case the CPU id was higher than the maximum
vector value.

Fixes: 297cccebdc5a ("net/mlx5: DR, Expose an internal API to issue RDMA operations")
Signed-off-by: Alex Vesker <valex@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Reviewed-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agonet/mlx5e: Reorder mirrer action parsing to check for encap first
Vlad Buslov [Thu, 7 Nov 2019 11:37:57 +0000 (13:37 +0200)]
net/mlx5e: Reorder mirrer action parsing to check for encap first

Mirred action parsing code in parse_tc_fdb_actions() first checks if
out_dev has same parent id, and only verifies that there is a pending encap
action that was parsed before. Recent change in vxlan module made function
netdev_port_same_parent_id() to return true when called for mlx5 eswitch
representor and vxlan device created explicitly on mlx5 representor
device (vxlan devices created with "external" flag without explicitly
specifying parent interface are not affected). With call to
netdev_port_same_parent_id() returning true, incorrect code path is chosen
and encap rules fail to offload because vxlan dev is not a valid eswitch
forwarding dev. Dmesg log of error:

[ 1784.389797] devices ens1f0_0 vxlan1 not on same switch HW, can't offload forwarding

In order to fix the issue, rearrange conditional in parse_tc_fdb_actions()
to check for pending encap action before checking if out_dev has the same
parent id.

Fixes: 0ce1822c2a08 ("vxlan: add adjacent link to limit depth level")
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agonet/mlx5e: Fix ingress rate configuration for representors
Eli Cohen [Thu, 7 Nov 2019 07:07:34 +0000 (09:07 +0200)]
net/mlx5e: Fix ingress rate configuration for representors

Current code uses the old method of prio encoding in
flow_cls_common_offload. Fix to follow the changes introduced in
commit ef01adae0e43 ("net: sched: use major priority number as hardware priority").

Fixes: fcb64c0f5640 ("net/mlx5: E-Switch, add ingress rate support")
Signed-off-by: Eli Cohen <eli@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agonet/mlx5e: Fix error flow cleanup in mlx5e_tc_tun_create_header_ipv4/6
Eli Cohen [Thu, 31 Oct 2019 07:00:43 +0000 (09:00 +0200)]
net/mlx5e: Fix error flow cleanup in mlx5e_tc_tun_create_header_ipv4/6

Be sure to release the neighbour in case of failures after successful
route lookup.

Fixes: 101f4de9dd52 ("net/mlx5e: Move TC tunnel offloading code to separate source file")
Signed-off-by: Eli Cohen <eli@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2 years agoMerge branch 's390-fixes'
David S. Miller [Wed, 20 Nov 2019 20:29:47 +0000 (12:29 -0800)]
Merge branch 's390-fixes'

Julian Wiedmann says:

s390/qeth: fixes 2019-11-20

please apply two late qeth fixes to your net tree.

The first fixes a deadlock that can occur if a qeth device is set
offline while in the middle of processing deferred HW events.
The second patch converts the return value of an error path to
use -EIO, so that it can be passed back to userspace.

Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agos390/qeth: return proper errno on IO error
Julian Wiedmann [Wed, 20 Nov 2019 13:20:57 +0000 (14:20 +0100)]
s390/qeth: return proper errno on IO error

When propagating IO errors back to userspace, one error path in
qeth_irq() currently returns '1' instead of a proper errno.

Fixes: 54daaca7024d ("s390/qeth: cancel cmd on early error")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agos390/qeth: fix potential deadlock on workqueue flush
Julian Wiedmann [Wed, 20 Nov 2019 13:20:56 +0000 (14:20 +0100)]
s390/qeth: fix potential deadlock on workqueue flush

The L2 bridgeport code uses the coarse 'conf_mutex' for guarding access
to its configuration state.
This can result in a deadlock when qeth_l2_stop_card() - called under the
conf_mutex - blocks on flush_workqueue() to wait for the completion of
pending bridgeport workers. Such workers would also need to aquire
the conf_mutex, stalling indefinitely.

Introduce a lock that specifically guards the bridgeport configuration,
so that the workers no longer need the conf_mutex.
Wrapping qeth_l2_promisc_to_bridge() in this fine-grained lock then also
fixes a theoretical race against a concurrent qeth_bridge_port_role_store()

Fixes: c0a2e4d10d93 ("s390/qeth: conclude all event processing before offlining a card")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoipv6/route: return if there is no fib_nh_gw_family
Hangbin Liu [Wed, 20 Nov 2019 07:39:06 +0000 (15:39 +0800)]
ipv6/route: return if there is no fib_nh_gw_family

Previously we will return directly if (!rt || !rt->fib6_nh.fib_nh_gw_family)
in function rt6_probe(), but after commit cc3a86c802f0
("ipv6: Change rt6_probe to take a fib6_nh"), the logic changed to
return if there is fib_nh_gw_family.

Fixes: cc3a86c802f0 ("ipv6: Change rt6_probe to take a fib6_nh")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agonet-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject
Jouni Hogander [Wed, 20 Nov 2019 07:08:16 +0000 (09:08 +0200)]
net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject

kobject_init_and_add takes reference even when it fails. This has
to be given up by the caller in error handling. Otherwise memory
allocated by kobject_init_and_add is never freed. Originally found
by Syzkaller:

BUG: memory leak
unreferenced object 0xffff8880679f8b08 (size 8):
  comm "netdev_register", pid 269, jiffies 4294693094 (age 12.132s)
  hex dump (first 8 bytes):
    72 78 2d 30 00 36 20 d4                          rx-0.6 .
    [<000000008c93818e>] __kmalloc_track_caller+0x16e/0x290
    [<000000001f2e4e49>] kvasprintf+0xb1/0x140
    [<000000007f313394>] kvasprintf_const+0x56/0x160
    [<00000000aeca11c8>] kobject_set_name_vargs+0x5b/0x140
    [<0000000073a0367c>] kobject_init_and_add+0xd8/0x170
    [<0000000088838e4b>] net_rx_queue_update_kobjects+0x152/0x560
    [<000000006be5f104>] netdev_register_kobject+0x210/0x380
    [<00000000e31dab9d>] register_netdevice+0xa1b/0xf00
    [<00000000f68b2465>] __tun_chr_ioctl+0x20d5/0x3dd0
    [<000000004c50599f>] tun_chr_ioctl+0x2f/0x40
    [<00000000bbd4c317>] do_vfs_ioctl+0x1c7/0x1510
    [<00000000d4c59e8f>] ksys_ioctl+0x99/0xb0
    [<00000000946aea81>] __x64_sys_ioctl+0x78/0xb0
    [<0000000038d946e5>] do_syscall_64+0x16f/0x580
    [<00000000e0aa5d8f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [<00000000285b3d1a>] 0xffffffffffffffff

Cc: David Miller <davem@davemloft.net>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Jouni Hogander <jouni.hogander@unikie.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2 years agoarm64: uaccess: Remove uaccess_*_not_uao asm macros
Pavel Tatashin [Wed, 20 Nov 2019 17:07:40 +0000 (12:07 -0500)]
arm64: uaccess: Remove uaccess_*_not_uao asm macros

It is safer and simpler to drop the uaccess assembly macros in favour of
inline C functions. Although this bloats the Image size slightly, it
aligns our user copy routines with '{get,put}_user()' and generally
makes the code a lot easier to reason about.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
[will: tweaked commit message and changed temporary variable names]
Signed-off-by: Will Deacon <will@kernel.org>
2 years agoarm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess fault
Pavel Tatashin [Tue, 19 Nov 2019 22:10:06 +0000 (17:10 -0500)]
arm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess fault

A number of our uaccess routines ('__arch_clear_user()' and
'__arch_copy_{in,from,to}_user()') fail to re-enable PAN if they
encounter an unhandled fault whilst accessing userspace.

For CPUs implementing both hardware PAN and UAO, this bug has no effect
when both extensions are in use by the kernel.

For CPUs implementing hardware PAN but not UAO, this means that a kernel
using hardware PAN may execute portions of code with PAN inadvertently
disabled, opening us up to potential security vulnerabilities that rely
on userspace access from within the kernel which would usually be
prevented by this mechanism. In other words, parts of the kernel run the
same way as they would on a CPU without PAN implemented/emulated at all.

For CPUs not implementing hardware PAN and instead relying on software
emulation via 'CONFIG_ARM64_SW_TTBR0_PAN=y', the impact is unfortunately
much worse. Calling 'schedule()' with software PAN disabled means that
the next task will execute in the kernel using the page-table and ASID
of the previous process even after 'switch_mm()', since the actual
hardware switch is deferred until return to userspace. At this point, or
if there is a intermediate call to 'uaccess_enable()', the page-table
and ASID of the new process are installed. Sadly, due to the changes
introduced by KPTI, this is not an atomic operation and there is a very
small window (two instructions) where the CPU is configured with the
page-table of the old task and the ASID of the new task; a speculative
access in this state is disastrous because it would corrupt the TLB
entries for the new task with mappings from the previous address space.

As Pavel explains:

  | I was able to reproduce memory corruption problem on Broadcom's SoC
  | ARMv8-A like this:
  | Enable software perf-events with PERF_SAMPLE_CALLCHAIN so userland's
  | stack is accessed and copied.
  | The test program performed the following on every CPU and forking
  | many processes:
  | unsigned long *map = mmap(NULL, PAGE_SIZE, PROT_READ|PROT_WRITE,
  | map[0] = getpid();
  | sched_yield();
  | if (map[0] != getpid()) {
  | fprintf(stderr, "Corruption detected!");
  | }
  | munmap(map, PAGE_SIZE);
  | From time to time I was getting map[0] to contain pid for a
  | different process.

Ensure that PAN is re-enabled when returning after an unhandled user
fault from our uaccess routines.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org>
Fixes: 338d4f49d6f7 ("arm64: kernel: Add support for Privileged Access Never")
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
[will: rewrote commit message]
Signed-off-by: Will Deacon <will@kernel.org>
2 years agofork: fix pidfd_poll()'s return type
Luc Van Oostenryck [Wed, 20 Nov 2019 00:33:20 +0000 (01:33 +0100)]
fork: fix pidfd_poll()'s return type

pidfd_poll() is defined as returning 'unsigned int' but the
.poll method is declared as returning '__poll_t', a bitwise type.

Fix this by using the proper return type and using the EPOLL
constants instead of the POLL ones, as required for __poll_t.

Fixes: b53b0b9d9a61 ("pidfd: add polling support")
Cc: Joel Fernandes (Google) <joel@joelfernandes.org>
Cc: stable@vger.kernel.org # 5.3
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20191120003320.31138-1-luc.vanoostenryck@gmail.com
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>