From: Simon Horman <horms@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: nex.sw.ncis.osdt.itp.upstreaming@intel.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Eric Dumazet <edumazet@google.com>,
Michal Kubiak <michal.kubiak@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Jakub Kicinski <kuba@kernel.org>,
intel-wired-lan@lists.osuosl.org, Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net 3/3] idpf: fix UAFs when destroying the queues
Date: Fri, 26 Jul 2024 17:22:14 +0100 [thread overview]
Message-ID: <20240726162214.GQ97837@kernel.org> (raw)
In-Reply-To: <20240724134024.2182959-4-aleksander.lobakin@intel.com>
On Wed, Jul 24, 2024 at 03:40:24PM +0200, Alexander Lobakin wrote:
> The second tagged commit started sometimes (very rarely, but possible)
> throwing WARNs from
> net/core/page_pool.c:page_pool_disable_direct_recycling().
> Turned out idpf frees interrupt vectors with embedded NAPIs *before*
> freeing the queues making page_pools' NAPI pointers lead to freed
> memory before these pools are destroyed by libeth.
> It's not clear whether there are other accesses to the freed vectors
> when destroying the queues, but anyway, we usually free queue/interrupt
> vectors only when the queues are destroyed and the NAPIs are guaranteed
> to not be referenced anywhere.
>
> Invert the allocation and freeing logic making queue/interrupt vectors
> be allocated first and freed last. Vectors don't require queues to be
> present, so this is safe. Additionally, this change allows to remove
> that useless queue->q_vector pointer cleanup, as vectors are still
> valid when freeing the queues (+ both are freed within one function,
> so it's not clear why nullify the pointers at all).
>
> Fixes: 1c325aac10a8 ("idpf: configure resources for TX queues")
> Fixes: 90912f9f4f2d ("idpf: convert header split mode to libeth + napi_build_skb()")
> Reported-by: Michal Kubiak <michal.kubiak@intel.com>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: intel-wired-lan@lists.osuosl.org,
Tony Nguyen <anthony.l.nguyen@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
nex.sw.ncis.osdt.itp.upstreaming@intel.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Michal Kubiak <michal.kubiak@intel.com>
Subject: Re: [PATCH iwl-net 3/3] idpf: fix UAFs when destroying the queues
Date: Fri, 26 Jul 2024 17:22:14 +0100 [thread overview]
Message-ID: <20240726162214.GQ97837@kernel.org> (raw)
In-Reply-To: <20240724134024.2182959-4-aleksander.lobakin@intel.com>
On Wed, Jul 24, 2024 at 03:40:24PM +0200, Alexander Lobakin wrote:
> The second tagged commit started sometimes (very rarely, but possible)
> throwing WARNs from
> net/core/page_pool.c:page_pool_disable_direct_recycling().
> Turned out idpf frees interrupt vectors with embedded NAPIs *before*
> freeing the queues making page_pools' NAPI pointers lead to freed
> memory before these pools are destroyed by libeth.
> It's not clear whether there are other accesses to the freed vectors
> when destroying the queues, but anyway, we usually free queue/interrupt
> vectors only when the queues are destroyed and the NAPIs are guaranteed
> to not be referenced anywhere.
>
> Invert the allocation and freeing logic making queue/interrupt vectors
> be allocated first and freed last. Vectors don't require queues to be
> present, so this is safe. Additionally, this change allows to remove
> that useless queue->q_vector pointer cleanup, as vectors are still
> valid when freeing the queues (+ both are freed within one function,
> so it's not clear why nullify the pointers at all).
>
> Fixes: 1c325aac10a8 ("idpf: configure resources for TX queues")
> Fixes: 90912f9f4f2d ("idpf: convert header split mode to libeth + napi_build_skb()")
> Reported-by: Michal Kubiak <michal.kubiak@intel.com>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2024-07-26 16:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-24 13:40 [Intel-wired-lan] [PATCH iwl-net 0/3] idpf: fix 3 bugs revealed by the Chapter I Alexander Lobakin
2024-07-24 13:40 ` Alexander Lobakin
2024-07-24 13:40 ` [Intel-wired-lan] [PATCH iwl-net 1/3] idpf: fix memory leaks and crashes while performing a soft reset Alexander Lobakin
2024-07-24 13:40 ` Alexander Lobakin
2024-07-26 16:09 ` [Intel-wired-lan] " Simon Horman
2024-07-26 16:09 ` Simon Horman
2024-07-29 8:54 ` [Intel-wired-lan] " Alexander Lobakin
2024-07-29 8:54 ` Alexander Lobakin
2024-07-30 11:03 ` [Intel-wired-lan] " Simon Horman
2024-07-30 11:03 ` Simon Horman
2024-07-30 16:37 ` [Intel-wired-lan] " Simon Horman
2024-07-30 16:37 ` Simon Horman
2024-08-02 0:21 ` [Intel-wired-lan] " Singh, Krishneil K
2024-08-02 0:21 ` Singh, Krishneil K
2024-07-24 13:40 ` [Intel-wired-lan] [PATCH iwl-net 2/3] idpf: fix memleak in vport interrupt configuration Alexander Lobakin
2024-07-24 13:40 ` Alexander Lobakin
2024-07-26 16:16 ` [Intel-wired-lan] " Simon Horman
2024-07-26 16:16 ` Simon Horman
2024-08-02 0:22 ` [Intel-wired-lan] " Singh, Krishneil K
2024-08-02 0:22 ` Singh, Krishneil K
2024-07-24 13:40 ` [Intel-wired-lan] [PATCH iwl-net 3/3] idpf: fix UAFs when destroying the queues Alexander Lobakin
2024-07-24 13:40 ` Alexander Lobakin
2024-07-26 16:22 ` Simon Horman [this message]
2024-07-26 16:22 ` Simon Horman
2024-08-02 0:23 ` [Intel-wired-lan] " Singh, Krishneil K
2024-08-02 0:23 ` Singh, Krishneil K
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=20240726162214.GQ97837@kernel.org \
--to=horms@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.kubiak@intel.com \
--cc=netdev@vger.kernel.org \
--cc=nex.sw.ncis.osdt.itp.upstreaming@intel.com \
--cc=pabeni@redhat.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.