All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Cc: anthony.l.nguyen@intel.com,
	Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
	intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-net v1] i40e: Fix macvlan leak by synchronizing access to mac_filter_hash
Date: Tue, 24 Sep 2024 07:56:48 +0100	[thread overview]
Message-ID: <20240924065648.GA4029621@kernel.org> (raw)
In-Reply-To: <20240923091219.3040651-1-aleksandr.loktionov@intel.com>

On Mon, Sep 23, 2024 at 11:12:19AM +0200, Aleksandr Loktionov wrote:
> This patch addresses a macvlan leak issue in the i40e driver caused by
> concurrent access to vsi->mac_filter_hash. The leak occurs when multiple
> threads attempt to modify the mac_filter_hash simultaneously, leading to
> inconsistent state and potential memory leaks.
> 
> To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing
> vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock),
> ensuring atomic operations and preventing concurrent access.
> 
> Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in
> i40e_add_mac_filter() to help catch similar issues in the future.
> 
> Reproduction steps:
> 1. Spawn VFs and configure port vlan on them.
> 2. Trigger concurrent macvlan operations (e.g., adding and deleting
> 	portvlan and/or mac filters).
> 3. Observe the potential memory leak and inconsistent state in the
> 	mac_filter_hash.
> 
> This synchronization ensures the integrity of the mac_filter_hash and prevents
> the described leak.
> 
> Fixes: fed0d9f13266 ("i40e: Fix VF's MAC Address change on VM")
> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Thanks Aleksandr,

I see that:

1) All calls to i40e_add_mac_filter() and all other calls
   to i40e_del_mac_filter() are already protected by
   vsi->mac_filter_hash_lock.

2) i40e_del_mac_filter() already asserts that
   vsi->mac_filter_hash_lock is held.

So this looks good to me.

Reviewed-by: Simon Horman <horms@kernel.org>

...

WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
	netdev@vger.kernel.org,
	Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
Subject: Re: [PATCH iwl-net v1] i40e: Fix macvlan leak by synchronizing access to mac_filter_hash
Date: Tue, 24 Sep 2024 07:56:48 +0100	[thread overview]
Message-ID: <20240924065648.GA4029621@kernel.org> (raw)
In-Reply-To: <20240923091219.3040651-1-aleksandr.loktionov@intel.com>

On Mon, Sep 23, 2024 at 11:12:19AM +0200, Aleksandr Loktionov wrote:
> This patch addresses a macvlan leak issue in the i40e driver caused by
> concurrent access to vsi->mac_filter_hash. The leak occurs when multiple
> threads attempt to modify the mac_filter_hash simultaneously, leading to
> inconsistent state and potential memory leaks.
> 
> To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing
> vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock),
> ensuring atomic operations and preventing concurrent access.
> 
> Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in
> i40e_add_mac_filter() to help catch similar issues in the future.
> 
> Reproduction steps:
> 1. Spawn VFs and configure port vlan on them.
> 2. Trigger concurrent macvlan operations (e.g., adding and deleting
> 	portvlan and/or mac filters).
> 3. Observe the potential memory leak and inconsistent state in the
> 	mac_filter_hash.
> 
> This synchronization ensures the integrity of the mac_filter_hash and prevents
> the described leak.
> 
> Fixes: fed0d9f13266 ("i40e: Fix VF's MAC Address change on VM")
> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Thanks Aleksandr,

I see that:

1) All calls to i40e_add_mac_filter() and all other calls
   to i40e_del_mac_filter() are already protected by
   vsi->mac_filter_hash_lock.

2) i40e_del_mac_filter() already asserts that
   vsi->mac_filter_hash_lock is held.

So this looks good to me.

Reviewed-by: Simon Horman <horms@kernel.org>

...

  reply	other threads:[~2024-09-24  6:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-23  9:12 [Intel-wired-lan] [PATCH iwl-net v1] i40e: Fix macvlan leak by synchronizing access to mac_filter_hash Aleksandr Loktionov
2024-09-23  9:12 ` Aleksandr Loktionov
2024-09-24  6:56 ` Simon Horman [this message]
2024-09-24  6:56   ` Simon Horman
2024-10-03 12:03   ` [Intel-wired-lan] " Romanowski, Rafal
2024-10-03 12:03     ` Romanowski, Rafal

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=20240924065648.GA4029621@kernel.org \
    --to=horms@kernel.org \
    --cc=aleksandr.loktionov@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=arkadiusz.kubalewski@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=netdev@vger.kernel.org \
    /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.