Thread (8 messages) 8 messages, 5 authors, 2024-11-15

Re: [PATCH][next] xfrm: Add error handling when nla_put_u32() returns an error

From: Simon Horman <horms@kernel.org>
Date: 2024-11-13 17:59:13
Also in: kernel-janitors, lkml

On Wed, Nov 13, 2024 at 04:10:15PM +0300, Dan Carpenter wrote:
On Wed, Nov 13, 2024 at 10:59:39AM +0000, Simon Horman wrote:
quoted
On Tue, Nov 12, 2024 at 04:36:06PM -0700, Everest K.C. wrote:
quoted
Error handling is missing when call to nla_put_u32() fails.
Handle the error when the call to nla_put_u32() returns an error.

The error was reported by Coverity Scan.
Report:
CID 1601525: (#1 of 1): Unused value (UNUSED_VALUE)
returned_value: Assigning value from nla_put_u32(skb, XFRMA_SA_PCPU, x->pcpu_num)
to err here, but that stored value is overwritten before it can be used

Fixes: 1ddf9916ac09 ("xfrm: Add support for per cpu xfrm state handling.")
Signed-off-by: Everest K.C. <redacted>
Reviewed-by: Simon Horman <horms@kernel.org>

For future reference, I think the appropriate target for this tree
is ipsec-next rather than next.

	Subject: [PATCH ipsec-next] xfrm: ...
All these trees are a pain in the butt to track.  It's fine for people who only
work in one tree but for people doing static checker stuff, then we have to
deal with all 388 trees in linux-next.

I've changed my scripts to add [next] to my patches if Linus hasn't merged the
commit from the Fixes tag.  I still add net and net-next by hand but I'm going
to just automate that as well because doing it by hand has been failure prone.

But then if we try to add all the ipsec or whatever trees, it just becomes
unworkable.  I started to write a script which would look do the --is-ancestor
check based on the Fixes tag, but it take forever to update the git trees.  I
wasn't able to figure out a way to make this work.

Also once Linus merges the commit, there is no way to tell which tree the commit
goes to so it only applies to linux-next.  For networking, I already have the
script that greps the patch for -w net and grep -vw wireless.  But I don't want
to maintain a list greps for everyone's tree.

A lot of this scripting could be built into the CI system.  The CI system is
already doing some scripting based on the subject but we could do it based on
the Fixes tag instead.  If there isn't a Fixes tag, then it should go to
net-next.
Hi Dan,

I take your point that this is not very friendly to people sending
the occasional patch (towards Networking). And certainly there
is room to improve the CI.

FWIIW, my goto when preparing patches is something like the following.
Because at least for Networking, we do try to make MAINTAINERS reflect
reality:

./scripts/get_maintainer.pl --scm net/xfrm/xfrm_user.c
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help