[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200929101016.3743530-3-vladimir.oltean@nxp.com>
Date: Tue, 29 Sep 2020 13:09:57 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: davem@...emloft.net
Cc: alexandre.belloni@...tlin.com, andrew@...n.ch,
f.fainelli@...il.com, vivien.didelot@...il.com,
horatiu.vultur@...rochip.com, joergen.andreasen@...rochip.com,
allan.nielsen@...rochip.com, alexandru.marginean@....com,
claudiu.manoil@....com, xiaoliang.yang_1@....com,
hongbo.wang@....com, netdev@...r.kernel.org, kuba@...nel.org,
jiri@...nulli.us, idosch@...sch.org, UNGLinuxDriver@...rochip.com
Subject: [RFC PATCH v2 net-next 02/21] net: mscc: ocelot: return error if VCAP filter is not found
From: Xiaoliang Yang <xiaoliang.yang_1@....com>
Although it doesn't look like it is possible to hit these conditions
from user space, there are 2 separate, but related, issues.
First, the ocelot_vcap_block_get_filter_index function, née
ocelot_ace_rule_get_index_id prior to the aae4e500e106 ("net: mscc:
ocelot: generalize the "ACE/ACL" names") rename, does not do what the
author probably intended. If the desired filter entry is not present in
the ACL block, this function returns an index equal to the total number
of filters, instead of -1, which is maybe what was intended, judging
from the curious initialization with -1, and the "++index" idioms.
Either way, none of the callers seems to expect this behavior.
Second issue, the callers don't actually check the return value at all.
So in case the filter is not found in the rule list, propagate the
return code.
So update the callers and also take the opportunity to get rid of the
odd coding idioms that appear to work but don't.
Signed-off-by: Xiaoliang Yang <xiaoliang.yang_1@....com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
---
Changes in v2:
Took this patch which was previously targeted to "net" and re-targeted
it to "net-next", because it doesn't appear that this bug can be
triggered, and in plus, when in "net", it conflicts with the work done
here.
drivers/net/ethernet/mscc/ocelot_vcap.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_vcap.c b/drivers/net/ethernet/mscc/ocelot_vcap.c
index 3ef620faf995..51d442ca5cb3 100644
--- a/drivers/net/ethernet/mscc/ocelot_vcap.c
+++ b/drivers/net/ethernet/mscc/ocelot_vcap.c
@@ -726,14 +726,15 @@ static int ocelot_vcap_block_get_filter_index(struct ocelot_vcap_block *block,
struct ocelot_vcap_filter *filter)
{
struct ocelot_vcap_filter *tmp;
- int index = -1;
+ int index = 0;
list_for_each_entry(tmp, &block->rules, list) {
- ++index;
if (filter->id == tmp->id)
- break;
+ return index;
+ index++;
}
- return index;
+
+ return -ENOENT;
}
static struct ocelot_vcap_filter*
@@ -877,6 +878,8 @@ int ocelot_vcap_filter_add(struct ocelot *ocelot,
/* Get the index of the inserted filter */
index = ocelot_vcap_block_get_filter_index(block, filter);
+ if (index < 0)
+ return index;
/* Move down the rules to make place for the new filter */
for (i = block->count - 1; i > index; i--) {
@@ -924,6 +927,8 @@ int ocelot_vcap_filter_del(struct ocelot *ocelot,
/* Gets index of the filter */
index = ocelot_vcap_block_get_filter_index(block, filter);
+ if (index < 0)
+ return index;
/* Delete filter */
ocelot_vcap_block_remove_filter(ocelot, block, filter);
@@ -950,6 +955,9 @@ int ocelot_vcap_filter_stats_update(struct ocelot *ocelot,
int index;
index = ocelot_vcap_block_get_filter_index(block, filter);
+ if (index < 0)
+ return index;
+
is2_entry_get(ocelot, filter, index);
/* After we get the result we need to clear the counters */
--
2.25.1
Powered by blists - more mailing lists