* [PATCH v2 1/2] net: page_pool: check page pool ethtool stats @ 2023-10-01 11:41 Sven Auhagen 2023-10-02 19:46 ` Jakub Kicinski 0 siblings, 1 reply; 8+ messages in thread From: Sven Auhagen @ 2023-10-01 11:41 UTC (permalink / raw) To: netdev Cc: thomas.petazzoni, hawk, lorenzo, Paulo.DaSilva, ilias.apalodimas, mcroce 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> 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; -- 2.42.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v2 1/2] net: page_pool: check page pool ethtool stats 2023-10-01 11:41 [PATCH v2 1/2] net: page_pool: check page pool ethtool stats Sven Auhagen @ 2023-10-02 19:46 ` Jakub Kicinski 2023-10-03 4:12 ` Sven Auhagen 2023-10-25 5:59 ` Ilias Apalodimas 0 siblings, 2 replies; 8+ messages in thread From: Jakub Kicinski @ 2023-10-02 19:46 UTC (permalink / raw) To: Sven Auhagen Cc: netdev, thomas.petazzoni, hawk, lorenzo, Paulo.DaSilva, ilias.apalodimas, mcroce 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 :) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 1/2] net: page_pool: check page pool ethtool stats 2023-10-02 19:46 ` Jakub Kicinski @ 2023-10-03 4:12 ` Sven Auhagen 2023-10-25 5:59 ` Ilias Apalodimas 1 sibling, 0 replies; 8+ messages in thread From: Sven Auhagen @ 2023-10-03 4:12 UTC (permalink / raw) To: Jakub Kicinski Cc: netdev, thomas.petazzoni, hawk, lorenzo, Paulo.DaSilva, ilias.apalodimas, mcroce 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 1/2] net: page_pool: check page pool ethtool stats 2023-10-02 19:46 ` Jakub Kicinski 2023-10-03 4:12 ` Sven Auhagen @ 2023-10-25 5:59 ` Ilias Apalodimas 2023-10-25 7:53 ` Leon Romanovsky 1 sibling, 1 reply; 8+ messages in thread From: Ilias Apalodimas @ 2023-10-25 5:59 UTC (permalink / raw) To: Jakub Kicinski Cc: Sven Auhagen, netdev, thomas.petazzoni, hawk, lorenzo, Paulo.DaSilva, mcroce 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 1/2] net: page_pool: check page pool ethtool stats 2023-10-25 5:59 ` Ilias Apalodimas @ 2023-10-25 7:53 ` Leon Romanovsky 2023-10-30 9:39 ` Sven Auhagen 0 siblings, 1 reply; 8+ messages in thread From: Leon Romanovsky @ 2023-10-25 7:53 UTC (permalink / raw) To: Ilias Apalodimas Cc: Jakub Kicinski, Sven Auhagen, netdev, thomas.petazzoni, hawk, lorenzo, Paulo.DaSilva, mcroce 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 1/2] net: page_pool: check page pool ethtool stats 2023-10-25 7:53 ` Leon Romanovsky @ 2023-10-30 9:39 ` Sven Auhagen 2023-10-30 14:23 ` Leon Romanovsky 0 siblings, 1 reply; 8+ messages in thread From: Sven Auhagen @ 2023-10-30 9:39 UTC (permalink / raw) To: Leon Romanovsky Cc: Ilias Apalodimas, Jakub Kicinski, netdev, thomas.petazzoni, hawk, lorenzo, Paulo.DaSilva, mcroce 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 > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 1/2] net: page_pool: check page pool ethtool stats 2023-10-30 9:39 ` Sven Auhagen @ 2023-10-30 14:23 ` Leon Romanovsky 2023-10-30 14:42 ` Sven Auhagen 0 siblings, 1 reply; 8+ messages in thread From: Leon Romanovsky @ 2023-10-30 14:23 UTC (permalink / raw) To: Sven Auhagen Cc: Ilias Apalodimas, Jakub Kicinski, netdev, thomas.petazzoni, hawk, lorenzo, Paulo.DaSilva, mcroce 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 > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 1/2] net: page_pool: check page pool ethtool stats 2023-10-30 14:23 ` Leon Romanovsky @ 2023-10-30 14:42 ` Sven Auhagen 0 siblings, 0 replies; 8+ messages in thread From: Sven Auhagen @ 2023-10-30 14:42 UTC (permalink / raw) To: Leon Romanovsky Cc: Ilias Apalodimas, Jakub Kicinski, netdev, thomas.petazzoni, hawk, lorenzo, Paulo.DaSilva, mcroce 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 > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-10-30 14:43 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-10-01 11:41 [PATCH v2 1/2] net: page_pool: check page pool ethtool stats Sven Auhagen 2023-10-02 19:46 ` Jakub Kicinski 2023-10-03 4:12 ` Sven Auhagen 2023-10-25 5:59 ` Ilias Apalodimas 2023-10-25 7:53 ` Leon Romanovsky 2023-10-30 9:39 ` Sven Auhagen 2023-10-30 14:23 ` Leon Romanovsky 2023-10-30 14:42 ` Sven Auhagen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).