Re: [devel-ipsec] Re: [PATCH ipsec-next v2 4/4] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration

[Dan Carpenter <dan.carpenter@linaro.org>]

On Mon, Jan 19, 2026 at 09:21:51AM +0100, Antony Antony wrote:
> Hi Dan,
> 
> On Mon, Jan 19, 2026 at 08:27:25AM +0300, Dan Carpenter via Devel wrote:
> > Hi Antony,
> > 
> > kernel test robot noticed the following build warnings:
> > 
> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > 
> > url:    https://github.com/intel-lab-lkp/linux/commits/Antony-Antony/xfrm-remove-redundant-assignments/20260118-041031
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git master
> > patch link:    https://lore.kernel.org/r/951cb30ac3866c6075bc7359d0997dbffc3ce6da.1768679141.git.antony.antony%40secunet.com
> > patch subject: [PATCH ipsec-next v2 4/4] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration
> > config: hexagon-randconfig-r072-20260118 (https://download.01.org/0day-ci/archive/20260119/202601190605.ZVkgcUYl-lkp@intel.com/config)
> > compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710)
> > smatch version: v0.5.0-8985-g2614ff1a
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> > | Closes: https://lore.kernel.org/r/202601190605.ZVkgcUYl-lkp@intel.com/
> > 
> > New smatch warnings:
> > net/xfrm/xfrm_user.c:3299 xfrm_do_migrate_state() warn: missing error code? 'err'
> 
> Looking at this more closely, xfrm_user_state_lookup() always sets *errp 
> when it returns NULL.
> 
> > Old smatch warnings:
> > net/xfrm/xfrm_user.c:1024 xfrm_add_sa() warn: missing error code? 'err'
> > net/xfrm/xfrm_user.c:2248 xfrm_add_policy() warn: missing error code? 'err'
> > net/xfrm/xfrm_user.c:3018 xfrm_add_acquire() warn: missing error code 'err'
> 
> Also, as the "Old smatch warnings" show, this same pattern exists elsewhere
> in the file, most of the calls to xfrm_user_state_lookup().
> 
> I'm inclined to leave it as is rather than change a pattern that's 
> consistent throughout the file. Does smatch follow the code doing
> cross-function analysis? In this case, look into xfrm_user_state_lookup()
> and further down to see that *errp is set when NULL is returned?
> 

Ah, right.  Sorry about that.  Yes, of course, it shouldn't be
changed.

The zero day bot can't do cross function analysis because it doesn't
scale for the number of trees the bot tests...

regards,
dan carpenter