| author | Suman Anna <s-anna@ti.com> | |
| Sat, 4 Mar 2017 00:40:31 +0000 (18:40 -0600) | ||
| committer | Suman Anna <s-anna@ti.com> | |
| Sat, 22 Feb 2020 06:54:30 +0000 (00:54 -0600) | ||
| commit | 3779cbac0a34f13964b515384599a2e51ff6e30e | |
| tree | 9c77dd6a1d14d6682ba14918249030175eb230ea | tree | snapshot (tar.xz tar.gz zip) |
| parent | 30e402a7b1a6c61b4adf9aba69a56921abade9df | commit | diff |
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
steps.
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
terminated/closed.
Signed-off-by: Suman Anna <s-anna@ti.com>
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
steps.
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
terminated/closed.
Signed-off-by: Suman Anna <s-anna@ti.com>
| net/rpmsg/rpmsg_proto.c | diff | blob | history |