diff mbox series

[net-next] net: sched: cls_api: improve the error message for ID allocation failure

Message ID 20240912215306.2060709-1-kuba@kernel.org (mailing list archive)
State Changes Requested
Delegated to: Netdev Maintainers
Headers show
Series [net-next] net: sched: cls_api: improve the error message for ID allocation failure | expand

Checks

Context Check Description
netdev/series_format success Single patches do not need cover letters
netdev/tree_selection success Clearly marked for net-next
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 16 this patch: 16
netdev/build_tools success No tools touched, skip
netdev/cc_maintainers success CCed 7 of 7 maintainers
netdev/build_clang success Errors and warnings before: 16 this patch: 16
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 23 this patch: 23
netdev/checkpatch warning WARNING: line length of 113 exceeds 80 columns WARNING: line length of 119 exceeds 80 columns WARNING: line length of 92 exceeds 80 columns
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
netdev/contest fail net-next-2024-09-13--12-00 (tests: 764)

Commit Message

Jakub Kicinski Sept. 12, 2024, 9:53 p.m. UTC 
We run into an exhaustion problem with the kernel-allocated filter IDs.
Our allocation problem can be fixed on the user space side,
but the error message in this case was quite misleading:

  "Filter with specified priority/protocol not found" (EINVAL)

Specifically when we can't allocate a _new_ ID because filter with
lowest ID already _exists_, saying "filter not found", is confusing.

Kernel allocates IDs in range of 0xc0000 -> 0x8000, giving out ID one
lower than lowest existing in that range. The error message makes sense
when tcf_chain_tp_find() gets called for GET and DEL but for NEW we
need to provide more specific error messages for all three cases:

 - user wants the ID to be auto-allocated but filter with ID 0x8000
   already exists

 - filter already exists and can be replaced, but user asked
   for a protocol change

 - filter doesn't exist

Caller of tcf_chain_tp_insert_unique() doesn't set extack today,
so don't bother plumbing it in.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: jhs@mojatatu.com
CC: xiyou.wangcong@gmail.com
CC: jiri@resnulli.us
---
 net/sched/cls_api.c | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

Comments

Simon Horman Sept. 13, 2024, 11:03 a.m. UTC | #1 
On Thu, Sep 12, 2024 at 02:53:06PM -0700, Jakub Kicinski wrote:
> We run into an exhaustion problem with the kernel-allocated filter IDs.
> Our allocation problem can be fixed on the user space side,
> but the error message in this case was quite misleading:
> 
>   "Filter with specified priority/protocol not found" (EINVAL)
> 
> Specifically when we can't allocate a _new_ ID because filter with
> lowest ID already _exists_, saying "filter not found", is confusing.
> 
> Kernel allocates IDs in range of 0xc0000 -> 0x8000, giving out ID one
> lower than lowest existing in that range. The error message makes sense
> when tcf_chain_tp_find() gets called for GET and DEL but for NEW we
> need to provide more specific error messages for all three cases:
> 
>  - user wants the ID to be auto-allocated but filter with ID 0x8000
>    already exists
> 
>  - filter already exists and can be replaced, but user asked
>    for a protocol change
> 
>  - filter doesn't exist
> 
> Caller of tcf_chain_tp_insert_unique() doesn't set extack today,
> so don't bother plumbing it in.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Reviewed-by: Simon Horman <horms@kernel.org>
Jakub Kicinski Sept. 13, 2024, 2:42 p.m. UTC | #2 
On Thu, 12 Sep 2024 14:53:06 -0700 Jakub Kicinski wrote:
>  	} else {
>  		chain_info->next = NULL;
> +		NL_SET_ERR_MSG(extack, "Filter with specified priority/protocol not found");
>  	}

I messed up here, the cases which handle NULL as success now print a
warning.
diff mbox series

Patch

diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 17d97bbe890f..a2e5c7975dda 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -1932,7 +1932,8 @@  static void tcf_chain_tp_remove(struct tcf_chain *chain,
 static struct tcf_proto *tcf_chain_tp_find(struct tcf_chain *chain,
 					   struct tcf_chain_info *chain_info,
 					   u32 protocol, u32 prio,
-					   bool prio_allocate);
+					   bool prio_allocate,
+					   struct netlink_ext_ack *extack);
 
 /* Try to insert new proto.
  * If proto with specified priority already exists, free new proto
@@ -1957,7 +1958,7 @@  static struct tcf_proto *tcf_chain_tp_insert_unique(struct tcf_chain *chain,
 	}
 
 	tp = tcf_chain_tp_find(chain, &chain_info,
-			       protocol, prio, false);
+			       protocol, prio, false, NULL);
 	if (!tp)
 		err = tcf_chain_tp_insert(chain, &chain_info, tp_new);
 	mutex_unlock(&chain->filter_chain_lock);
@@ -2017,7 +2018,8 @@  static void tcf_chain_tp_delete_empty(struct tcf_chain *chain,
 static struct tcf_proto *tcf_chain_tp_find(struct tcf_chain *chain,
 					   struct tcf_chain_info *chain_info,
 					   u32 protocol, u32 prio,
-					   bool prio_allocate)
+					   bool prio_allocate,
+					   struct netlink_ext_ack *extack)
 {
 	struct tcf_proto **pprev;
 	struct tcf_proto *tp;
@@ -2028,9 +2030,14 @@  static struct tcf_proto *tcf_chain_tp_find(struct tcf_chain *chain,
 	     pprev = &tp->next) {
 		if (tp->prio >= prio) {
 			if (tp->prio == prio) {
-				if (prio_allocate ||
-				    (tp->protocol != protocol && protocol))
+				if (prio_allocate) {
+					NL_SET_ERR_MSG(extack, "Lowest ID from auto-alloc range already in use");
+					return ERR_PTR(-ENOSPC);
+				}
+				if (tp->protocol != protocol && protocol) {
+					NL_SET_ERR_MSG(extack, "Protocol mismatch for filter with specified priority");
 					return ERR_PTR(-EINVAL);
+				}
 			} else {
 				tp = NULL;
 			}
@@ -2043,6 +2050,7 @@  static struct tcf_proto *tcf_chain_tp_find(struct tcf_chain *chain,
 		tcf_proto_get(tp);
 	} else {
 		chain_info->next = NULL;
+		NL_SET_ERR_MSG(extack, "Filter with specified priority/protocol not found");
 	}
 	return tp;
 }
@@ -2311,9 +2319,8 @@  static int tc_new_tfilter(struct sk_buff *skb, struct nlmsghdr *n,
 
 	mutex_lock(&chain->filter_chain_lock);
 	tp = tcf_chain_tp_find(chain, &chain_info, protocol,
-			       prio, prio_allocate);
+			       prio, prio_allocate, extack);
 	if (IS_ERR(tp)) {
-		NL_SET_ERR_MSG(extack, "Filter with specified priority/protocol not found");
 		err = PTR_ERR(tp);
 		goto errout_locked;
 	}
@@ -2538,9 +2545,8 @@  static int tc_del_tfilter(struct sk_buff *skb, struct nlmsghdr *n,
 
 	mutex_lock(&chain->filter_chain_lock);
 	tp = tcf_chain_tp_find(chain, &chain_info, protocol,
-			       prio, false);
+			       prio, false, extack);
 	if (!tp || IS_ERR(tp)) {
-		NL_SET_ERR_MSG(extack, "Filter with specified priority/protocol not found");
 		err = tp ? PTR_ERR(tp) : -ENOENT;
 		goto errout_locked;
 	} else if (tca[TCA_KIND] && nla_strcmp(tca[TCA_KIND], tp->ops->kind)) {
@@ -2678,10 +2684,9 @@  static int tc_get_tfilter(struct sk_buff *skb, struct nlmsghdr *n,
 
 	mutex_lock(&chain->filter_chain_lock);
 	tp = tcf_chain_tp_find(chain, &chain_info, protocol,
-			       prio, false);
+			       prio, false, extack);
 	mutex_unlock(&chain->filter_chain_lock);
 	if (!tp || IS_ERR(tp)) {
-		NL_SET_ERR_MSG(extack, "Filter with specified priority/protocol not found");
 		err = tp ? PTR_ERR(tp) : -ENOENT;
 		goto errout;
 	} else if (tca[TCA_KIND] && nla_strcmp(tca[TCA_KIND], tp->ops->kind)) {