All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: David Wilder <wilder@us.ibm.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jv@jvosburgh.net" <jv@jvosburgh.net>,
	"pradeeps@linux.vnet.ibm.com" <pradeeps@linux.vnet.ibm.com>,
	Pradeep Satyanarayana <pradeep@us.ibm.com>,
	"i.maximets@ovn.org" <i.maximets@ovn.org>,
	Adrian Moreno Zapata <amorenoz@redhat.com>,
	Hangbin Liu <haliu@redhat.com>
Subject: Re: [PATCH net-next v5 6/7] bonding: Update for extended arp_ip_target format.
Date: Wed, 16 Jul 2025 10:00:14 +0100	[thread overview]
Message-ID: <20250716090014.GK721198@horms.kernel.org> (raw)
In-Reply-To: <MW3PR15MB391324648F78241D4AC721A6FA57A@MW3PR15MB3913.namprd15.prod.outlook.com>

On Tue, Jul 15, 2025 at 06:22:37PM +0000, David Wilder wrote:
> 
> 
> 
> ________________________________________
> From: Simon Horman <horms@kernel.org>
> Sent: Tuesday, July 15, 2025 6:58 AM
> To: David Wilder
> Cc: netdev@vger.kernel.org; jv@jvosburgh.net; pradeeps@linux.vnet.ibm.com; Pradeep Satyanarayana; i.maximets@ovn.org; Adrian Moreno Zapata; Hangbin Liu
> Subject: [EXTERNAL] Re: [PATCH net-next v5 6/7] bonding: Update for extended arp_ip_target format.
> 
> >On Mon, Jul 14, 2025 at 03:54:51PM -0700, David Wilder wrote:
> >> Updated bond_fill_info() to support extended arp_ip_target format.
> >>
> >> Forward and backward compatibility between the kernel and iprout2 is
> >> preserved.
> >>
> >> Signed-off-by: David Wilder <wilder@us.ibm.com>
> >> ---
> >>  drivers/net/bonding/bond_netlink.c | 28 ++++++++++++++++++++++++++--
> >>  include/net/bonding.h              |  1 +
> >>  2 files changed, 27 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c
> >> index 5486ef40907e..6e8aebe5629f 100644
> >> --- a/drivers/net/bonding/bond_netlink.c
> >> +++ b/drivers/net/bonding/bond_netlink.c
> >> @@ -701,8 +701,32 @@ static int bond_fill_info(struct sk_buff *skb,
> >>
> >>       targets_added = 0;
> >>       for (i = 0; i < BOND_MAX_ARP_TARGETS; i++) {
> >> -             if (bond->params.arp_targets[i].target_ip) {
> >> -                     if (nla_put_be32(skb, i, bond->params.arp_targets[i].target_ip))
> >> +             struct bond_arp_target *target = &bond->params.arp_targets[i];
> >> +             struct Data {
> >> +                     __u32 addr;
> >> +                     struct bond_vlan_tag vlans[BOND_MAX_VLAN_TAGS + 1];
> >> +             } data;
> >> +             int size = 0;
> >> +
> >> +             if (target->target_ip) {
> >> +                     data.addr = target->target_ip;
> >
> >Hi David,
> >
> >There appears to be an endian mismatch here. Sparse says:
> >
>   >.../bond_netlink.c:712:35: warning: incorrect type in assignment (different base types)
>   >.../bond_netlink.c:712:35:    expected unsigned int [usertype] addr
>   >.../bond_netlink.c:712:35:    got restricted __be32 [usertype] target_ip
> >
> >> +                     size = sizeof(target->target_ip);
> >> +             }
> >
> >It seems that data.addr may be used uninitialised below
> >if the if condition above is not met.
> 
> >Flagged by Smatch.
> 
> Hi Simon
> 
> Thanks for catching this,  I will make the following change in the next version.
> 
> @@ -703,15 +703,14 @@ static int bond_fill_info(struct sk_buff *skb,
>         for (i = 0; i < BOND_MAX_ARP_TARGETS; i++) {
>                 struct bond_arp_target *target = &bond->params.arp_targets[i];
>                 struct Data {
> -                       __u32 addr;
> +                       __be32 addr;
>                         struct bond_vlan_tag vlans[BOND_MAX_VLAN_TAGS + 1];
>                 } data;
>                 int size = 0;
> 
> -               if (target->target_ip) {
> -                       data.addr = target->target_ip;
> -                       size = sizeof(target->target_ip);
> -               }
> +               BUG_ON(!target->target_ip);

Hi David,

I think this addresses the issues I raised, thanks!

But please don't use BUG_ON() like this, it will crash the kernel,
which seems disproportionate to the problem at hand.

I'm not particularly familiar with this code. But it seems
that it is filling in netlink attributes. And does not make
any resource allocations. So perhaps this is sufficient?

		if (!target->target_ip)
			return -EINVAL;

> +               data.addr = target->target_ip;
> +               size = sizeof(target->target_ip);
> 
>                 for (int level = 0; target->flags & BOND_TARGET_USERTAGS && target->tags; level++) {
>                         if (level > BOND_MAX_VLAN_TAGS)
> 
> David Wilder

  reply	other threads:[~2025-07-16  9:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-14 22:54 [PATCH net-next v5 0/7] bonding: Extend arp_ip_target format to allow for a list of vlan tags David Wilder
2025-07-14 22:54 ` [PATCH net-next v5 1/7] bonding: Adding struct bond_arp_target David Wilder
2025-09-09 13:21   ` Paolo Abeni
2025-09-10 16:30     ` David Wilder
2025-07-14 22:54 ` [PATCH net-next v5 2/7] bonding: Adding extra_len field to struct bond_opt_value David Wilder
2025-09-09 13:23   ` Paolo Abeni
2025-09-10 16:23     ` David Wilder
2025-07-14 22:54 ` [PATCH net-next v5 3/7] bonding: arp_ip_target helpers David Wilder
2025-09-09 13:25   ` Paolo Abeni
2025-07-14 22:54 ` [PATCH net-next v5 4/7] bonding: Processing extended arp_ip_target from user space David Wilder
2025-07-14 22:54 ` [PATCH net-next v5 5/7] bonding: Update to bond_arp_send_all() to use supplied vlan tags David Wilder
2025-07-14 22:54 ` [PATCH net-next v5 6/7] bonding: Update for extended arp_ip_target format David Wilder
2025-07-15 13:58   ` Simon Horman
2025-07-15 18:22     ` David Wilder
2025-07-16  9:00       ` Simon Horman [this message]
2025-07-16  9:17   ` kernel test robot
2025-07-14 22:54 ` [PATCH net-next v5 7/7] bonding: Selftest and documentation for the arp_ip_target parameter David Wilder
2025-07-15 13:59   ` Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250716090014.GK721198@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=amorenoz@redhat.com \
    --cc=haliu@redhat.com \
    --cc=i.maximets@ovn.org \
    --cc=jv@jvosburgh.net \
    --cc=netdev@vger.kernel.org \
    --cc=pradeep@us.ibm.com \
    --cc=pradeeps@linux.vnet.ibm.com \
    --cc=wilder@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.