From: Haofeng Li <lihaofeng@kylinos.cn>

Return the real error code 'err' instead of hardcoded -1 in the error
path of ynl_exec_dump(). This provides better error information to
callers for debugging and error handling.

Signed-off-by: Haofeng Li <lihaofeng@kylinos.cn>
---
 tools/net/ynl/lib/ynl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/net/ynl/lib/ynl.c b/tools/net/ynl/lib/ynl.c
index 2a169c3c0797..1a79adcc3ac0 100644
--- a/tools/net/ynl/lib/ynl.c
+++ b/tools/net/ynl/lib/ynl.c
@@ -1064,5 +1064,5 @@ int ynl_exec_dump(struct ynl_sock *ys, struct nlmsghdr *req_nlh,
 
 err_close_list:
 	yds->first = ynl_dump_end(yds);
-	return -1;
+	return err;
 }
-- 
2.25.1

On Fri, 26 Sep 2025 17:58:20 +0800 Haofeng Li wrote:
> Return the real error code 'err' instead of hardcoded -1 in the error
> path of ynl_exec_dump(). This provides better error information to
> callers for debugging and error handling.

Do you have a realistic example that can happen today? This is not
kernel code the error is always -1, and the details are in errno.

> This is not kernel code the error is always -1, and the details are in errno.

Thank you for the feedback and for pointing that out.

You are absolutely right. I now understand that in the context of this 
userspace code, the error handling convention relies on errno for 
details when the return value is -1. My patch was attempting to align 
the return value with a specific internal error code, which, as you clarified,
 is not the established practice here and doesn't provide the intended 
benefit in this case.

I appreciate you taking the time to explain this.