diff mbox series

[v2,1/2] net: page_pool: check page pool ethtool stats

Message ID abr3xq5eankrmzvyhjd5za6itfm5s7wpqwfy7lp3iuwsv33oi3@dx5eg6wmb2so (mailing list archive)
State Changes Requested
Delegated to: Netdev Maintainers
Headers show
Series net: page_pool: check page pool ethtool stats | expand

Checks

Context Check Description
netdev/series_format warning Target tree name not specified in the subject
netdev/tree_selection success Guessed tree name to be net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 1342 this patch: 1342
netdev/cc_maintainers warning 4 maintainers not CCed: edumazet@google.com pabeni@redhat.com kuba@kernel.org davem@davemloft.net
netdev/build_clang success Errors and warnings before: 1364 this patch: 1364
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 1365 this patch: 1365
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 9 lines checked
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Sven Auhagen Oct. 1, 2023, 11:41 a.m. UTC
If the page_pool variable is null while passing it to
the page_pool_get_stats function we receive a kernel error.

Check if the page_pool variable is at least valid.

Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de>
Reported-by: Paulo Da Silva <Paulo.DaSilva@kyberna.com>

Comments

Jakub Kicinski Oct. 2, 2023, 7:46 p.m. UTC | #1
On Sun, 1 Oct 2023 13:41:15 +0200 Sven Auhagen wrote:
> If the page_pool variable is null while passing it to
> the page_pool_get_stats function we receive a kernel error.
> 
> Check if the page_pool variable is at least valid.

IMHO this seems insufficient, the driver still has to check if PP 
was instantiated when the strings are queried. My weak preference
would be to stick to v1 and have the driver check all the conditions.
But if nobody else feels this way, it's fine :)
Sven Auhagen Oct. 3, 2023, 4:12 a.m. UTC | #2
On Mon, Oct 02, 2023 at 12:46:50PM -0700, Jakub Kicinski wrote:
> On Sun, 1 Oct 2023 13:41:15 +0200 Sven Auhagen wrote:
> > If the page_pool variable is null while passing it to
> > the page_pool_get_stats function we receive a kernel error.
> > 
> > Check if the page_pool variable is at least valid.
> 
> IMHO this seems insufficient, the driver still has to check if PP 
> was instantiated when the strings are queried. My weak preference
> would be to stick to v1 and have the driver check all the conditions.
> But if nobody else feels this way, it's fine :)

:) let me know which variant is preferred so I can send a new
v3.
Ilias Apalodimas Oct. 25, 2023, 5:59 a.m. UTC | #3
Hi Jakub,

On Mon, Oct 02, 2023 at 12:46:50PM -0700, Jakub Kicinski wrote:
> On Sun, 1 Oct 2023 13:41:15 +0200 Sven Auhagen wrote:
> > If the page_pool variable is null while passing it to
> > the page_pool_get_stats function we receive a kernel error.
> >
> > Check if the page_pool variable is at least valid.
>
> IMHO this seems insufficient, the driver still has to check if PP
> was instantiated when the strings are queried. My weak preference
> would be to stick to v1 and have the driver check all the conditions.
> But if nobody else feels this way, it's fine :)

I don't disagree, but OTOH it would be sane for the API not to crash if
something invalid is passed.  Maybe the best approach would be to keep the
driver checks, which are saner, but add the page pool code as well with a
printable error indicating a driver bug?

Thanks
/Ilias
Leon Romanovsky Oct. 25, 2023, 7:53 a.m. UTC | #4
On Wed, Oct 25, 2023 at 08:59:44AM +0300, Ilias Apalodimas wrote:
> Hi Jakub,
> 
> On Mon, Oct 02, 2023 at 12:46:50PM -0700, Jakub Kicinski wrote:
> > On Sun, 1 Oct 2023 13:41:15 +0200 Sven Auhagen wrote:
> > > If the page_pool variable is null while passing it to
> > > the page_pool_get_stats function we receive a kernel error.
> > >
> > > Check if the page_pool variable is at least valid.
> >
> > IMHO this seems insufficient, the driver still has to check if PP
> > was instantiated when the strings are queried. My weak preference
> > would be to stick to v1 and have the driver check all the conditions.
> > But if nobody else feels this way, it's fine :)
> 
> I don't disagree, but OTOH it would be sane for the API not to crash if
> something invalid is passed. 

In-kernel API assumes that in-kernel callers know how to use it.

> Maybe the best approach would be to keep the
> driver checks, which are saner, but add the page pool code as well with a
> printable error indicating a driver bug?

It is no different from adding extra checks to prevent drivers from random calls
with random parameters to well defined API.

Thanks

> 
> Thanks
> /Ilias
>
Sven Auhagen Oct. 30, 2023, 9:39 a.m. UTC | #5
On Wed, Oct 25, 2023 at 10:53:41AM +0300, Leon Romanovsky wrote:
> On Wed, Oct 25, 2023 at 08:59:44AM +0300, Ilias Apalodimas wrote:
> > Hi Jakub,
> > 
> > On Mon, Oct 02, 2023 at 12:46:50PM -0700, Jakub Kicinski wrote:
> > > On Sun, 1 Oct 2023 13:41:15 +0200 Sven Auhagen wrote:
> > > > If the page_pool variable is null while passing it to
> > > > the page_pool_get_stats function we receive a kernel error.
> > > >
> > > > Check if the page_pool variable is at least valid.
> > >
> > > IMHO this seems insufficient, the driver still has to check if PP
> > > was instantiated when the strings are queried. My weak preference
> > > would be to stick to v1 and have the driver check all the conditions.
> > > But if nobody else feels this way, it's fine :)
> > 
> > I don't disagree, but OTOH it would be sane for the API not to crash if
> > something invalid is passed. 
> 
> In-kernel API assumes that in-kernel callers know how to use it.
> 
> > Maybe the best approach would be to keep the
> > driver checks, which are saner, but add the page pool code as well with a
> > printable error indicating a driver bug?
> 
> It is no different from adding extra checks to prevent drivers from random calls
> with random parameters to well defined API.
> 
> Thanks

I can see the point for both arguments so I think we should definitely
keep the driver check.

Is there a consensus on what to do on the page pool side?
Do you want me to keep the additional page pool check to prevent
a kernel crash?
I mean the mvneta change was also implemented with this problem
and it leads to serious side effects without an additional check.
Especially if the page pool ethtool stats is implemented in more
drivers in the future and the implementations are not 100% correct,
it will crash the kernel.

Best
Sven

> 
> > 
> > Thanks
> > /Ilias
> >
Leon Romanovsky Oct. 30, 2023, 2:23 p.m. UTC | #6
On Mon, Oct 30, 2023 at 10:39:18AM +0100, Sven Auhagen wrote:
> On Wed, Oct 25, 2023 at 10:53:41AM +0300, Leon Romanovsky wrote:
> > On Wed, Oct 25, 2023 at 08:59:44AM +0300, Ilias Apalodimas wrote:
> > > Hi Jakub,
> > > 
> > > On Mon, Oct 02, 2023 at 12:46:50PM -0700, Jakub Kicinski wrote:
> > > > On Sun, 1 Oct 2023 13:41:15 +0200 Sven Auhagen wrote:
> > > > > If the page_pool variable is null while passing it to
> > > > > the page_pool_get_stats function we receive a kernel error.
> > > > >
> > > > > Check if the page_pool variable is at least valid.
> > > >
> > > > IMHO this seems insufficient, the driver still has to check if PP
> > > > was instantiated when the strings are queried. My weak preference
> > > > would be to stick to v1 and have the driver check all the conditions.
> > > > But if nobody else feels this way, it's fine :)
> > > 
> > > I don't disagree, but OTOH it would be sane for the API not to crash if
> > > something invalid is passed. 
> > 
> > In-kernel API assumes that in-kernel callers know how to use it.
> > 
> > > Maybe the best approach would be to keep the
> > > driver checks, which are saner, but add the page pool code as well with a
> > > printable error indicating a driver bug?
> > 
> > It is no different from adding extra checks to prevent drivers from random calls
> > with random parameters to well defined API.
> > 
> > Thanks
> 
> I can see the point for both arguments so I think we should definitely
> keep the driver check.
> 
> Is there a consensus on what to do on the page pool side?
> Do you want me to keep the additional page pool check to prevent
> a kernel crash?

I don't want to see bloat of checks in kernel API. They hide issues and
not prevent them.

> I mean the mvneta change was also implemented with this problem
> and it leads to serious side effects without an additional check.
> Especially if the page pool ethtool stats is implemented in more
> drivers in the future and the implementations are not 100% correct,
> it will crash the kernel.

Like many other driver mistakes.

Thanks

> 
> Best
> Sven
> 
> > 
> > > 
> > > Thanks
> > > /Ilias
> > >
Sven Auhagen Oct. 30, 2023, 2:42 p.m. UTC | #7
On Mon, Oct 30, 2023 at 04:23:55PM +0200, Leon Romanovsky wrote:
> On Mon, Oct 30, 2023 at 10:39:18AM +0100, Sven Auhagen wrote:
> > On Wed, Oct 25, 2023 at 10:53:41AM +0300, Leon Romanovsky wrote:
> > > On Wed, Oct 25, 2023 at 08:59:44AM +0300, Ilias Apalodimas wrote:
> > > > Hi Jakub,
> > > > 
> > > > On Mon, Oct 02, 2023 at 12:46:50PM -0700, Jakub Kicinski wrote:
> > > > > On Sun, 1 Oct 2023 13:41:15 +0200 Sven Auhagen wrote:
> > > > > > If the page_pool variable is null while passing it to
> > > > > > the page_pool_get_stats function we receive a kernel error.
> > > > > >
> > > > > > Check if the page_pool variable is at least valid.
> > > > >
> > > > > IMHO this seems insufficient, the driver still has to check if PP
> > > > > was instantiated when the strings are queried. My weak preference
> > > > > would be to stick to v1 and have the driver check all the conditions.
> > > > > But if nobody else feels this way, it's fine :)
> > > > 
> > > > I don't disagree, but OTOH it would be sane for the API not to crash if
> > > > something invalid is passed. 
> > > 
> > > In-kernel API assumes that in-kernel callers know how to use it.
> > > 
> > > > Maybe the best approach would be to keep the
> > > > driver checks, which are saner, but add the page pool code as well with a
> > > > printable error indicating a driver bug?
> > > 
> > > It is no different from adding extra checks to prevent drivers from random calls
> > > with random parameters to well defined API.
> > > 
> > > Thanks
> > 
> > I can see the point for both arguments so I think we should definitely
> > keep the driver check.
> > 
> > Is there a consensus on what to do on the page pool side?
> > Do you want me to keep the additional page pool check to prevent
> > a kernel crash?
> 
> I don't want to see bloat of checks in kernel API. They hide issues and
> not prevent them.
> 
> > I mean the mvneta change was also implemented with this problem
> > and it leads to serious side effects without an additional check.
> > Especially if the page pool ethtool stats is implemented in more
> > drivers in the future and the implementations are not 100% correct,
> > it will crash the kernel.
> 
> Like many other driver mistakes.
> 
> Thanks

Understood, thanks.
I will resubmit with the initial patch that has only
the driver fix in it.

Best
Sven

> 
> > 
> > Best
> > Sven
> > 
> > > 
> > > > 
> > > > Thanks
> > > > /Ilias
> > > >
diff mbox series

Patch

diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index 2396c99bedea..4c5dca6b4a16 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -65,6 +65,9 @@  bool page_pool_get_stats(struct page_pool *pool,
 	if (!stats)
 		return false;
 
+	if (!pool)
+		return false;
+
 	/* The caller is responsible to initialize stats. */
 	stats->alloc_stats.fast += pool->alloc_stats.fast;
 	stats->alloc_stats.slow += pool->alloc_stats.slow;