openbcm

Git mirror of https://github.com/Broadcom-Network-Switching-Software/OpenBCM
git clone git://git.finwo.net/mirror/broadcom/openbcm
Log | Files | Refs | README

commit a772ad60a8460ee8c24f6689bed8237c26fc6ff1
parent 30dd545330b0b6af5a5dc3d1d559dab657428eb7
Author: Broadcom SDK Release <sdk.releases@broadcom.com>
Date:   Thu, 25 Apr 2019 20:32:20 -0700

SDK-177985: Case study: A potential Service-Impacting Defect (SID) was identi...

Devices: 56980_A0,56980_B0
Module: ALPM

Symptom:
ALPM: Mysterious appearance of Global High route in pre-pivot table
without user actually programming the route

Case study: A potential Service-Impacting Defect (SID) was identified in
Tomahawk3 (no other devices are impacted) running L3 ALPM code SDK
version 6.5.14 through 6.5.16. Under some circumstances, SDK may end up
inserting an extraneous, seemingly random and almost always incorrectly
formatted route into TCAM Level1 in addition to the route that Network
OS was trying to install by calling bcm_route_add() API. The erroneous
route may result in mis-forwarding and/or drops of IP traffic.    Root
cause: The issue is caused by the lack of clearing of
"lpm_cfg->tcam_write" data buffer in
$SDK/src/bcm/esw/alpm2/alpm.c::alpm_cb_insert() upon completion of a
Level2 bucket split if such split requires a delayed TCAM write. The
circumstances under which that could occur are rare but realistic. As a
result, a subsequent call to bcm_route_add() may end up using the stale
buffer. Since the data was previously pointing to a local variable on
the stack of a function that already returned, the next operation would
try to interpret the bogus pointer, which could result in writing an
unpredictably formatted entry into TCAM Level1 under some limited but
specific circumstances. Furthermore, if the bit corresponding to the
“valid” bit happened to be set, this could result in the extraneous,
bogus entry being interpreted as a real route by HW.     Impact: Without
the fix, customers could see extraneous, seemingly random route entries
installed in ALPM TCAM Level1 besides the ones that Network OS intended
to install. The issue impacts Tomahawk3 devices only. No other devices
are impacted.     Action taken: Added 4 lines to code to clear the
buffer and augmented an internal test.     Follow-up actions required:
All customers using ALPM on Tomahawk3 must apply the 4-line code patch
that can be obtained from Broadcom FAE team and/or need to plan to
upgrade to SDK-6.5.17 that will contain the fix to avoid the potential
mis-forwarding.

Diffstat:
Msdk-6.5.16/src/bcm/esw/alpm2/alpm.c | 9+++++----
1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/sdk-6.5.16/src/bcm/esw/alpm2/alpm.c b/sdk-6.5.16/src/bcm/esw/alpm2/alpm.c @@ -4269,7 +4269,7 @@ retry: lpm_cfg->pvt_node = pvt_node; } else { lpm_cfg->l1_pvt_node = upr_pvt_node; - ALPM_IER_PRT_EXCEPT(alpm_cb_path_construct(u, acb, lpm_cfg), BCM_E_FULL); + ALPM_IEG_PRT_EXCEPT(alpm_cb_path_construct(u, acb, lpm_cfg), BCM_E_FULL); pvt_node = lpm_cfg->pvt_node; if (pvt_node == NULL) { goto retry; @@ -4384,7 +4384,7 @@ retry_spl: ptcam_write = lpm_cfg->tcam_write; if (ptcam_write != NULL) { if (ptcam_write->rv == BCM_E_NONE) { - return rv; /* already done in alpm_bkt_add_to_npvt */ + goto _exit; /* already done in alpm_bkt_add_to_npvt */ } else if (ptcam_write->rv == BCM_E_FULL) { rv = BCM_E_FULL; retry_count ++; @@ -4432,7 +4432,8 @@ retry_spl: } VRF_ROUTE_ADD(acb, vrf_id, ipt); - +_exit: + lpm_cfg->tcam_write = NULL; return rv; bad: @@ -4442,7 +4443,7 @@ bad: if (bkt_node != NULL) { alpm_util_free(bkt_node); } - + lpm_cfg->tcam_write = NULL; return rv; }