commit c4282ca76c5b81ed73ef4c5eb5c07ee397e51642 upstream.
commit 88e8ac7000dc ("tipc: reduce transmission rate of reset messages
when link is down") revealed a flaw in the node FSM, as defined in
the log of commit 66996b6c47 ("tipc: extend node FSM").
We see the following scenario:
1: Node B receives a RESET message from node A before its link endpoint
is fully up, i.e., the node FSM is in state SELF_UP_PEER_COMING. This
event will not change the node FSM state, but the (distinct) link FSM
will move to state RESETTING.
2: As an effect of the previous event, the local endpoint on B will
declare node A lost, and post the event SELF_DOWN to the its node
FSM. This moves the FSM state to SELF_DOWN_PEER_LEAVING, meaning
that no messages will be accepted from A until it receives another
RESET message that confirms that A's endpoint has been reset. This
is wasteful, since we know this as a fact already from the first
received RESET, but worse is that the link instance's FSM has not
wasted this information, but instead moved on to state ESTABLISHING,
meaning that it repeatedly sends out ACTIVATE messages to the reset
peer A.
3: Node A will receive one of the ACTIVATE messages, move its link FSM
to state ESTABLISHED, and start repeatedly sending out STATE messages
to node B.
4: Node B will consistently drop these messages, since it can only accept
accept a RESET according to its node FSM.
5: After four lost STATE messages node A will reset its link and start
repeatedly sending out RESET messages to B.
6: Because of the reduced send rate for RESET messages, it is very
likely that A will receive an ACTIVATE (which is sent out at a much
higher frequency) before it gets the chance to send a RESET, and A
may hence quickly move back to state ESTABLISHED and continue sending
out STATE messages, which will again be dropped by B.
7: GOTO 5.
8: After having repeated the cycle 5-7 a number of times, node A will
by chance get in between with sending a RESET, and the situation is
resolved.
Unfortunately, we have seen that it may take a substantial amount of
time before this vicious loop is broken, sometimes in the order of
minutes.
We correct this by making a small correction to the node FSM: When a
node in state SELF_UP_PEER_COMING receives a SELF_DOWN event, it now
moves directly back to state SELF_DOWN_PEER_DOWN, instead of as now
SELF_DOWN_PEER_LEAVING. This is logically consistent, since we don't
need to wait for RESET confirmation from of an endpoint that we alread
know has been reset. It also means that node B in the scenario above
will not be dropping incoming STATE messages, and the link can come up
immediately.
Finally, a symmetry comparison reveals that the FSM has a similar
error when receiving the event PEER_DOWN in state PEER_UP_SELF_COMING.
Instead of moving to PERR_DOWN_SELF_LEAVING, it should move directly
to SELF_DOWN_PEER_DOWN. Although we have never seen any negative effect
of this logical error, we choose fix this one, too.
The node FSM looks as follows after those changes:
+----------------------------------------+
| PEER_DOWN_EVT|
| |
+------------------------+----------------+ |
|SELF_DOWN_EVT | | |
| | | |
| +-----------+ +-----------+ |
| |NODE_ | |NODE_ | |
| +----------|FAILINGOVER|<---------|SYNCHING |-----------+ |
| |SELF_ +-----------+ FAILOVER_+-----------+ PEER_ | |
| |DOWN_EVT | A BEGIN_EVT A | DOWN_EVT| |
| | | | | | | |
| | | | | | | |
| | |FAILOVER_ |FAILOVER_ |SYNCH_ |SYNCH_ | |
| | |END_EVT |BEGIN_EVT |BEGIN_EVT|END_EVT | |
| | | | | | | |
| | | | | | | |
| | | +--------------+ | | |
| | +-------->| SELF_UP_ |<-------+ | |
| | +-----------------| PEER_UP |----------------+ | |
| | |SELF_DOWN_EVT +--------------+ PEER_DOWN_EVT| | |
| | | A A | | |
| | | | | | | |
| | | PEER_UP_EVT| |SELF_UP_EVT | | |
| | | | | | | |
V V V | | V V V
+------------+ +-----------+ +-----------+ +------------+
|SELF_DOWN_ | |SELF_UP_ | |PEER_UP_ | |PEER_DOWN |
|PEER_LEAVING| |PEER_COMING| |SELF_COMING| |SELF_LEAVING|
+------------+ +-----------+ +-----------+ +------------+
| | A A | |
| | | | | |
| SELF_ | |SELF_ |PEER_ |PEER_ |
| DOWN_EVT| |UP_EVT |UP_EVT |DOWN_EVT |
| | | | | |
| | | | | |
| | +--------------+ | |
|PEER_DOWN_EVT +--->| SELF_DOWN_ |<---+ SELF_DOWN_EVT|
+------------------->| PEER_DOWN |<--------------------+
+--------------+
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c8bcfb1255fe9d929c227d67bdcd84430fd200b upstream.
In the refactoring commit d570d86497 ("tipc: enqueue arrived buffers
in socket in separate function") we did by accident replace the test
if (sk->sk_backlog.len == 0)
atomic_set(&tsk->dupl_rcvcnt, 0);
with
if (sk->sk_backlog.len)
atomic_set(&tsk->dupl_rcvcnt, 0);
This effectively disables the compensation we have for the double
receive buffer accounting that occurs temporarily when buffers are
moved from the backlog to the socket receive queue. Until now, this
has gone unnoticed because of the large receive buffer limits we are
applying, but becomes indispensable when we reduce this buffer limit
later in this series.
We now fix this by inverting the mentioned condition.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 541726abe7daca64390c2ec34e6a203145f1686d upstream.
Nametable updates received from the network that cannot be applied
immediately are placed on a defer queue. This queue is global to the
TIPC module, which might cause problems when using TIPC in containers.
To prevent nametable updates from escaping into the wrong namespace,
we make the queue pernet instead.
Signed-off-by: Erik Hugne <erik.hugne@gmail.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9bd160bfa27fa41927dbbce7ee0ea779700e09ef upstream.
Expand headroom further in order to be able to fit the larger IPv6
header. Prior to this patch this caused a skb under panic for certain
tipc packets when using IPv6 UDP bearer(s).
Signed-off-by: Richard Alpe <richard.alpe@ericsson.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When user application provides invalid (out of range) stripe size and
stripe indices, while submitting requests for the stripe based image
processing by the CPP kernel driver, the driver could perform out of
bounds access of the internal buffers.
This fix ensures that stripe size and indices of frame/command buffer
are properly validated during the configuration and before processing
such requests through the CPP hardware block.
CRs-fixed: 2002207
Change-Id: Ib79e36fb507d8e75d8fc28afb990020a0e1bf845
Signed-off-by: Ravi kumar Koyyana <rkoyyana@codeaurora.org>
When the Camera application exercises 32-bit version of the V4L2 ioctl
operation, it results accessing user space memory illegally. This is
due to the direct access of user space buffer by Camera CPP driver.
Thus, fix this by copying user space buffer contents into kernel space
buffer of the driver for further processing. Only after checking for
proper length of user space buffer, proceed further. This will prevent
the buffer overflow and invalid memory access.
CRs-fixed: 2025367
Change-Id: I85cf4a961884c7bb0d036299b886044aef7baf7c
Signed-off-by: Ravi kumar Koyyana <rkoyyana@codeaurora.org>
Write ioctl is needed for production tools.
Enable by default to have default build supporting
that functionality.
Change-Id: I7c835c5e718ade187070efd0680bb43d27d9807e
Signed-off-by: Hamad Kadmany <hkadmany@codeaurora.org>
For each input and output buffer given to mdss rotator, it is necessary
to check the range of the plane_count value against the MAX_PLANES
definition, in order to avoid any plane array out of bound access.
CRs-Fixed: 2028681
Change-Id: I117bf5daead17e5e97c62c6dc8e21d1fcc9d8e74
Signed-off-by: Benjamin Chan <bkchan@codeaurora.org>
For any given output buffer to the MDSS WFD, it is necessary to check
the range of the plane_count against the MAX_PLANES definition, in order
to avoid any out of bound access.
CRs-Fixed: 2028702
Change-Id: I4f1497a3a2e4ca2d30fc268e68cfdacc0d8539ea
Signed-off-by: Benjamin Chan <bkchan@codeaurora.org>
For non-atomic display commit that use pan_display, it is not possible
to use multi-rect feature from the DMA pipe. This fix is to reject any
multi-rect DMA pipe being used in the commit when all the non
multi-rect DMA pipes are not available.
CRs-Fixed: 2036486
Change-Id: I16722d62650807b5f46ca2bb544653f43a01edf1
Signed-off-by: Benjamin Chan <bkchan@codeaurora.org>
Include the panel dtsi files as part of all the different
msm8998 platform specific device tree files. This will
separate panel properties from SOC specific MDSS binding.
Change-Id: I423a53b4601447d0c7be2bdc041b36495f99da3b
Signed-off-by: Chandan Uddaraju <chandanu@codeaurora.org>
This change moves the registration of indication call back after inquiring
the state of remote PD, this is logical flow since in any case just after
registration we are inquiring the state and doing client notification.
With existing arrangement of code, sometime there is occurring a race
condition between inquiring the remote pd state and indication call back.
Change-Id: I2d4d5e0dc7afde9dfb89747b878c26862532bec4
Signed-off-by: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org>
It is a case of write after free, this is causing page allocation
failure due to corruption. This is due to freeing up of segments
allocated for venus subsystem, when venus fw loading fail midway.
Change-Id: I0019a05b1d1336dcf361264607597430e5f1625a
Signed-off-by: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org>
ath10k core destroy frees the debug references and
this is leading to crash when ATH10K_DBG_SNOC mask is
defined.
Fix this by moving logs to prior ath10k core destroy.
Change-Id: If4fd96fdfd9faaf19480b6d523c501747f56d40e
Signed-off-by: Govind Singh <govinds@codeaurora.org>
Since the qmi service in snoc driver gets registered late,
it misses the first time FW ready is sent. This causes the
wait on FW ready to fail and eventually the driver loading fails.
Proceed with the driver initialization only once the FW ready
indication arrives. Handle error in case the wait for these
events timeout.
Change-Id: Ib20ddb3a2f8b5b48936cc97b38f637f31e4e0100
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
mmc clock scaling can be disabled/enabled through sysfs.
The present logic in this path deregisters/registers with devfreq
every time. Instead of this, we can simply suspend/resume the clock
scaling when requested for disabling/enabling clock scaling.
This patch updates the mentioned logic.
With original logic, observed deadlock between devfreq registration
and cmdqd thread in low memory conditions. The updated logic fixes
this deadlock condition aswell.
Change-Id: Ifee1ffbe24b13b8f5dc1c9f0579ce9ddf4b4faf3
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
We should use kecho here instead of echo, so that make -s will
skip printing anything here. Otherwise, builds with make -s will
be confused and consider this informational message a
warning/error.
Change-Id: I4c854636e5b8b7e8b11eba8e5a52824ebee50ea1
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add state bit to defer recursive shutdown. This state
bit adds support for synchronization between reinit
and shutdown method during SSR within SSR.
Change-Id: Ifb857ecdb6545709706380631c423f0e24269e11
Signed-off-by: Anurag Chouhan <achouhan@codeaurora.org>
Kryo has 3 groups of events PMRESR0, 1, 2. If kryo_read_pmresr()
is asked to read other than these 3 event groups, return ZERO value.
Change-Id: Ifa348baa749182bb0dcb67562195472699301b1a
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Mohammed Khajapasha <mkhaja@codeaurora.org>
This will help reduce excessive logging in case of tasklet
overflow scenarios.
Change-Id: I93f8442c4dcf725cab2d722694d194921b764aff
Signed-off-by: Venu Yeshala <vyeshala@codeaurora.org>
The MHI driver requires the MHI_CB_XFER event handling be atomic.
This change makes the addr map locks into spinlocks so sleep is
avoided while processing the XFER event.
CRs-Fixed: 1089824
Change-Id: I7bd8f606f92095bb47741aa54a846b687fe948b9
Signed-off-by: Chris Lew <clew@codeaurora.org>