[net-next,1/3] net: introduce napi_is_scheduled helper

  We currently have napi_if_scheduled_mark_missed that can be used to
check if napi is scheduled but that does more thing than simply checking
it and return a bool. Some driver already implement custom function to
check if napi is scheduled.

Drop these custom function and introduce napi_is_scheduled that simply
check if napi is scheduled atomically.

Update any driver and code that implement a similar check and instead
use this new helper.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 drivers/net/ethernet/chelsio/cxgb3/sge.c  | 8 --------
 drivers/net/wireless/realtek/rtw89/core.c | 2 +-
 include/linux/netdevice.h                 | 5 +++++
 net/core/dev.c                            | 2 +-
 4 files changed, 7 insertions(+), 10 deletions(-)
  

> -----Original Message-----
> From: Christian Marangi <ansuelsmth@gmail.com>
> Sent: Friday, September 22, 2023 4:13 AM
> To: Vincent Whitchurch <vincent.whitchurch@axis.com>; Raju Rangoju
> <rajur@chelsio.com>; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Alexandre Torgue <alexandre.torgue@foss.st.com>;
> Jose Abreu <joabreu@synopsys.com>; Maxime Coquelin
> <mcoquelin.stm32@gmail.com>; Ping-Ke Shih <pkshih@realtek.com>; Kalle
> Valo <kvalo@kernel.org>; Simon Horman <horms@kernel.org>; Daniel
> Borkmann <daniel@iogearbox.net>; Jiri Pirko <jiri@resnulli.us>; Hangbin Liu
> <liuhangbin@gmail.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com; linux-
> arm-kernel@lists.infradead.org; linux-wireless@vger.kernel.org
> Cc: Christian Marangi <ansuelsmth@gmail.com>
> Subject: [net-next PATCH 1/3] net: introduce napi_is_scheduled helper
> 
> We currently have napi_if_scheduled_mark_missed that can be used to
> check if napi is scheduled but that does more thing than simply checking
> it and return a bool. Some driver already implement custom function to
> check if napi is scheduled.
> 
> Drop these custom function and introduce napi_is_scheduled that simply
> check if napi is scheduled atomically.
> 
> Update any driver and code that implement a similar check and instead
> use this new helper.
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>

Looks good to me.
Reviewed-by: Amritha Nambiar <amritha.nambiar@intel.com>

> ---
>  drivers/net/ethernet/chelsio/cxgb3/sge.c  | 8 --------
>  drivers/net/wireless/realtek/rtw89/core.c | 2 +-
>  include/linux/netdevice.h                 | 5 +++++
>  net/core/dev.c                            | 2 +-
>  4 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> index 2e9a74fe0970..71fa2dc19034 100644
> --- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> @@ -2501,14 +2501,6 @@ static int napi_rx_handler(struct napi_struct *napi,
> int budget)
>  	return work_done;
>  }
> 
> -/*
> - * Returns true if the device is already scheduled for polling.
> - */
> -static inline int napi_is_scheduled(struct napi_struct *napi)
> -{
> -	return test_bit(NAPI_STATE_SCHED, &napi->state);
> -}
> -
>  /**
>   *	process_pure_responses - process pure responses from a response
> queue
>   *	@adap: the adapter
> diff --git a/drivers/net/wireless/realtek/rtw89/core.c
> b/drivers/net/wireless/realtek/rtw89/core.c
> index 133bf289bacb..bbf4ea3639d4 100644
> --- a/drivers/net/wireless/realtek/rtw89/core.c
> +++ b/drivers/net/wireless/realtek/rtw89/core.c
> @@ -1744,7 +1744,7 @@ static void rtw89_core_rx_to_mac80211(struct
> rtw89_dev *rtwdev,
>  	struct napi_struct *napi = &rtwdev->napi;
> 
>  	/* In low power mode, napi isn't scheduled. Receive it to netif. */
> -	if (unlikely(!test_bit(NAPI_STATE_SCHED, &napi->state)))
> +	if (unlikely(!napi_is_scheduled(napi)))
>  		napi = NULL;
> 
>  	rtw89_core_hw_to_sband_rate(rx_status);
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index db3d8429d50d..8eac00cd3b92 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -482,6 +482,11 @@ static inline bool napi_prefer_busy_poll(struct
> napi_struct *n)
>  	return test_bit(NAPI_STATE_PREFER_BUSY_POLL, &n->state);
>  }
> 
> +static inline bool napi_is_scheduled(struct napi_struct *n)
> +{
> +	return test_bit(NAPI_STATE_SCHED, &n->state);
> +}
> +
>  bool napi_schedule_prep(struct napi_struct *n);
> 
>  /**
> diff --git a/net/core/dev.c b/net/core/dev.c
> index cc03a5758d2d..32ba8002f65a 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6523,7 +6523,7 @@ static int __napi_poll(struct napi_struct *n, bool
> *repoll)
>  	 * accidentally calling ->poll() when NAPI is not scheduled.
>  	 */
>  	work = 0;
> -	if (test_bit(NAPI_STATE_SCHED, &n->state)) {
> +	if (napi_is_scheduled(n)) {
>  		work = n->poll(n, weight);
>  		trace_napi_poll(n, work, weight);
>  	}
> --
> 2.40.1
>
  

On Fri, Sep 22, 2023 at 1:13 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
>
> We currently have napi_if_scheduled_mark_missed that can be used to
> check if napi is scheduled but that does more thing than simply checking
> it and return a bool. Some driver already implement custom function to
> check if napi is scheduled.
>
> Drop these custom function and introduce napi_is_scheduled that simply
> check if napi is scheduled atomically.
>
> Update any driver and code that implement a similar check and instead
> use this new helper.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
>  drivers/net/ethernet/chelsio/cxgb3/sge.c  | 8 --------
>  drivers/net/wireless/realtek/rtw89/core.c | 2 +-
>  include/linux/netdevice.h                 | 5 +++++
>  net/core/dev.c                            | 2 +-
>  4 files changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> index 2e9a74fe0970..71fa2dc19034 100644
> --- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> @@ -2501,14 +2501,6 @@ static int napi_rx_handler(struct napi_struct *napi, int budget)
>         return work_done;
>  }
>
> -/*
> - * Returns true if the device is already scheduled for polling.
> - */
> -static inline int napi_is_scheduled(struct napi_struct *napi)
> -{
> -       return test_bit(NAPI_STATE_SCHED, &napi->state);
> -}
> -
>  /**
>   *     process_pure_responses - process pure responses from a response queue
>   *     @adap: the adapter
> diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c
> index 133bf289bacb..bbf4ea3639d4 100644
> --- a/drivers/net/wireless/realtek/rtw89/core.c
> +++ b/drivers/net/wireless/realtek/rtw89/core.c
> @@ -1744,7 +1744,7 @@ static void rtw89_core_rx_to_mac80211(struct rtw89_dev *rtwdev,
>         struct napi_struct *napi = &rtwdev->napi;
>
>         /* In low power mode, napi isn't scheduled. Receive it to netif. */
> -       if (unlikely(!test_bit(NAPI_STATE_SCHED, &napi->state)))
> +       if (unlikely(!napi_is_scheduled(napi)))
>                 napi = NULL;
>
>         rtw89_core_hw_to_sband_rate(rx_status);
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index db3d8429d50d..8eac00cd3b92 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -482,6 +482,11 @@ static inline bool napi_prefer_busy_poll(struct napi_struct *n)
>         return test_bit(NAPI_STATE_PREFER_BUSY_POLL, &n->state);
>  }
>


In which context is it safe to call this helper ?

I fear that making this available will add more bugs.

For instance rspq_check_napi() seems buggy to me.

> +static inline bool napi_is_scheduled(struct napi_struct *n)

const ...

> +{
> +       return test_bit(NAPI_STATE_SCHED, &n->state);
> +}
> +
>  bool napi_schedule_prep(struct napi_struct *n);
>
>  /**
> diff --git a/net/core/dev.c b/net/core/dev.c
> index cc03a5758d2d..32ba8002f65a 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6523,7 +6523,7 @@ static int __napi_poll(struct napi_struct *n, bool *repoll)
>          * accidentally calling ->poll() when NAPI is not scheduled.
>          */
>         work = 0;
> -       if (test_bit(NAPI_STATE_SCHED, &n->state)) {
> +       if (napi_is_scheduled(n)) {
>                 work = n->poll(n, weight);
>                 trace_napi_poll(n, work, weight);
>         }
> --
> 2.40.1
>
  

On Sat, Sep 30, 2023 at 01:59:53PM +0200, Eric Dumazet wrote:
> On Fri, Sep 22, 2023 at 1:13 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> >
> > We currently have napi_if_scheduled_mark_missed that can be used to
> > check if napi is scheduled but that does more thing than simply checking
> > it and return a bool. Some driver already implement custom function to
> > check if napi is scheduled.
> >
> > Drop these custom function and introduce napi_is_scheduled that simply
> > check if napi is scheduled atomically.
> >
> > Update any driver and code that implement a similar check and instead
> > use this new helper.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
> >  drivers/net/ethernet/chelsio/cxgb3/sge.c  | 8 --------
> >  drivers/net/wireless/realtek/rtw89/core.c | 2 +-
> >  include/linux/netdevice.h                 | 5 +++++
> >  net/core/dev.c                            | 2 +-
> >  4 files changed, 7 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > index 2e9a74fe0970..71fa2dc19034 100644
> > --- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > +++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > @@ -2501,14 +2501,6 @@ static int napi_rx_handler(struct napi_struct *napi, int budget)
> >         return work_done;
> >  }
> >
> > -/*
> > - * Returns true if the device is already scheduled for polling.
> > - */
> > -static inline int napi_is_scheduled(struct napi_struct *napi)
> > -{
> > -       return test_bit(NAPI_STATE_SCHED, &napi->state);
> > -}
> > -
> >  /**
> >   *     process_pure_responses - process pure responses from a response queue
> >   *     @adap: the adapter
> > diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c
> > index 133bf289bacb..bbf4ea3639d4 100644
> > --- a/drivers/net/wireless/realtek/rtw89/core.c
> > +++ b/drivers/net/wireless/realtek/rtw89/core.c
> > @@ -1744,7 +1744,7 @@ static void rtw89_core_rx_to_mac80211(struct rtw89_dev *rtwdev,
> >         struct napi_struct *napi = &rtwdev->napi;
> >
> >         /* In low power mode, napi isn't scheduled. Receive it to netif. */
> > -       if (unlikely(!test_bit(NAPI_STATE_SCHED, &napi->state)))
> > +       if (unlikely(!napi_is_scheduled(napi)))
> >                 napi = NULL;
> >
> >         rtw89_core_hw_to_sband_rate(rx_status);
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index db3d8429d50d..8eac00cd3b92 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -482,6 +482,11 @@ static inline bool napi_prefer_busy_poll(struct napi_struct *n)
> >         return test_bit(NAPI_STATE_PREFER_BUSY_POLL, &n->state);
> >  }
> >
> 
> 
> In which context is it safe to call this helper ?
>

test_bit is atomic so it should be always safe. Also the idea of this
check (and from what I can see this apply also to the other 2 user) is
somehow best effort, we check if in the current istant there is a napi
scheduled and we act.

> I fear that making this available will add more bugs.
> 
> For instance rspq_check_napi() seems buggy to me.
> 

Mhhh why? Am I opening a can of worms?

> > +static inline bool napi_is_scheduled(struct napi_struct *n)
> 
> const ...
> 

Will change in v2. Thanks!

> > +{
> > +       return test_bit(NAPI_STATE_SCHED, &n->state);
> > +}
> > +
> >  bool napi_schedule_prep(struct napi_struct *n);
> >
> >  /**
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index cc03a5758d2d..32ba8002f65a 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -6523,7 +6523,7 @@ static int __napi_poll(struct napi_struct *n, bool *repoll)
> >          * accidentally calling ->poll() when NAPI is not scheduled.
> >          */
> >         work = 0;
> > -       if (test_bit(NAPI_STATE_SCHED, &n->state)) {
> > +       if (napi_is_scheduled(n)) {
> >                 work = n->poll(n, weight);
> >                 trace_napi_poll(n, work, weight);
> >         }
> > --
> > 2.40.1
> >
  

On Sat, Sep 30, 2023 at 2:11 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
>
> On Sat, Sep 30, 2023 at 01:59:53PM +0200, Eric Dumazet wrote:
> > On Fri, Sep 22, 2023 at 1:13 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > >
> > > We currently have napi_if_scheduled_mark_missed that can be used to
> > > check if napi is scheduled but that does more thing than simply checking
> > > it and return a bool. Some driver already implement custom function to
> > > check if napi is scheduled.
> > >
> > > Drop these custom function and introduce napi_is_scheduled that simply
> > > check if napi is scheduled atomically.
> > >
> > > Update any driver and code that implement a similar check and instead
> > > use this new helper.
> > >
> > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > > ---
> > >  drivers/net/ethernet/chelsio/cxgb3/sge.c  | 8 --------
> > >  drivers/net/wireless/realtek/rtw89/core.c | 2 +-
> > >  include/linux/netdevice.h                 | 5 +++++
> > >  net/core/dev.c                            | 2 +-
> > >  4 files changed, 7 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > > index 2e9a74fe0970..71fa2dc19034 100644
> > > --- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > > +++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > > @@ -2501,14 +2501,6 @@ static int napi_rx_handler(struct napi_struct *napi, int budget)
> > >         return work_done;
> > >  }
> > >
> > > -/*
> > > - * Returns true if the device is already scheduled for polling.
> > > - */
> > > -static inline int napi_is_scheduled(struct napi_struct *napi)
> > > -{
> > > -       return test_bit(NAPI_STATE_SCHED, &napi->state);
> > > -}
> > > -
> > >  /**
> > >   *     process_pure_responses - process pure responses from a response queue
> > >   *     @adap: the adapter
> > > diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c
> > > index 133bf289bacb..bbf4ea3639d4 100644
> > > --- a/drivers/net/wireless/realtek/rtw89/core.c
> > > +++ b/drivers/net/wireless/realtek/rtw89/core.c
> > > @@ -1744,7 +1744,7 @@ static void rtw89_core_rx_to_mac80211(struct rtw89_dev *rtwdev,
> > >         struct napi_struct *napi = &rtwdev->napi;
> > >
> > >         /* In low power mode, napi isn't scheduled. Receive it to netif. */
> > > -       if (unlikely(!test_bit(NAPI_STATE_SCHED, &napi->state)))
> > > +       if (unlikely(!napi_is_scheduled(napi)))
> > >                 napi = NULL;
> > >
> > >         rtw89_core_hw_to_sband_rate(rx_status);
> > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > > index db3d8429d50d..8eac00cd3b92 100644
> > > --- a/include/linux/netdevice.h
> > > +++ b/include/linux/netdevice.h
> > > @@ -482,6 +482,11 @@ static inline bool napi_prefer_busy_poll(struct napi_struct *n)
> > >         return test_bit(NAPI_STATE_PREFER_BUSY_POLL, &n->state);
> > >  }
> > >
> >
> >
> > In which context is it safe to call this helper ?
> >
>
> test_bit is atomic so it should be always safe. Also the idea of this
> check (and from what I can see this apply also to the other 2 user) is
> somehow best effort, we check if in the current istant there is a napi
> scheduled and we act.

I think testing a bit here is not enough to take any kind of useful decision,
unless used in a particular context.

>
> > I fear that making this available will add more bugs.
> >
> > For instance rspq_check_napi() seems buggy to me.
> >
>
> Mhhh why? Am I opening a can of worms?

Yes I think :/

Because only the thread that has grabbed the bit can make any sense of it.

Another thread reading it would not really know if the value is not going to
change immediately. So what would be the point ?

It seems rspq_check_napi() real intent was maybe the following,
but really this is hard to know if the current race in this code is okay or not.

diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c
b/drivers/net/ethernet/chelsio/cxgb3/sge.c
index 2e9a74fe0970df333226b80af8716f30865c01b7..e153c9590b36b38e430bc93660146b428e9b3347
100644
--- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
@@ -2676,8 +2676,10 @@ static int rspq_check_napi(struct sge_qset *qs)

        if (!napi_is_scheduled(&qs->napi) &&
            is_new_response(&q->desc[q->cidx], q)) {
-               napi_schedule(&qs->napi);
-               return 1;
+               if (napi_schedule_prep(&qs->napi)) {
+                       __napi_schedule(&qs->napi);
+                       return 1;
+               }
        }
        return 0;
 }
  

On Sat, Sep 30, 2023 at 03:42:20PM +0200, Eric Dumazet wrote:
> On Sat, Sep 30, 2023 at 2:11 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> >
> > On Sat, Sep 30, 2023 at 01:59:53PM +0200, Eric Dumazet wrote:
> > > On Fri, Sep 22, 2023 at 1:13 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > >
> > > > We currently have napi_if_scheduled_mark_missed that can be used to
> > > > check if napi is scheduled but that does more thing than simply checking
> > > > it and return a bool. Some driver already implement custom function to
> > > > check if napi is scheduled.
> > > >
> > > > Drop these custom function and introduce napi_is_scheduled that simply
> > > > check if napi is scheduled atomically.
> > > >
> > > > Update any driver and code that implement a similar check and instead
> > > > use this new helper.
> > > >
> > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > > > ---
> > > >  drivers/net/ethernet/chelsio/cxgb3/sge.c  | 8 --------
> > > >  drivers/net/wireless/realtek/rtw89/core.c | 2 +-
> > > >  include/linux/netdevice.h                 | 5 +++++
> > > >  net/core/dev.c                            | 2 +-
> > > >  4 files changed, 7 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > > > index 2e9a74fe0970..71fa2dc19034 100644
> > > > --- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > > > +++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > > > @@ -2501,14 +2501,6 @@ static int napi_rx_handler(struct napi_struct *napi, int budget)
> > > >         return work_done;
> > > >  }
> > > >
> > > > -/*
> > > > - * Returns true if the device is already scheduled for polling.
> > > > - */
> > > > -static inline int napi_is_scheduled(struct napi_struct *napi)
> > > > -{
> > > > -       return test_bit(NAPI_STATE_SCHED, &napi->state);
> > > > -}
> > > > -
> > > >  /**
> > > >   *     process_pure_responses - process pure responses from a response queue
> > > >   *     @adap: the adapter
> > > > diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c
> > > > index 133bf289bacb..bbf4ea3639d4 100644
> > > > --- a/drivers/net/wireless/realtek/rtw89/core.c
> > > > +++ b/drivers/net/wireless/realtek/rtw89/core.c
> > > > @@ -1744,7 +1744,7 @@ static void rtw89_core_rx_to_mac80211(struct rtw89_dev *rtwdev,
> > > >         struct napi_struct *napi = &rtwdev->napi;
> > > >
> > > >         /* In low power mode, napi isn't scheduled. Receive it to netif. */
> > > > -       if (unlikely(!test_bit(NAPI_STATE_SCHED, &napi->state)))
> > > > +       if (unlikely(!napi_is_scheduled(napi)))
> > > >                 napi = NULL;
> > > >
> > > >         rtw89_core_hw_to_sband_rate(rx_status);
> > > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > > > index db3d8429d50d..8eac00cd3b92 100644
> > > > --- a/include/linux/netdevice.h
> > > > +++ b/include/linux/netdevice.h
> > > > @@ -482,6 +482,11 @@ static inline bool napi_prefer_busy_poll(struct napi_struct *n)
> > > >         return test_bit(NAPI_STATE_PREFER_BUSY_POLL, &n->state);
> > > >  }
> > > >
> > >
> > >
> > > In which context is it safe to call this helper ?
> > >
> >
> > test_bit is atomic so it should be always safe. Also the idea of this
> > check (and from what I can see this apply also to the other 2 user) is
> > somehow best effort, we check if in the current istant there is a napi
> > scheduled and we act.
> 
> I think testing a bit here is not enough to take any kind of useful decision,
> unless used in a particular context.
>

Ehhh the idea here was to reduce code duplication since the very same
test will be done in stmmac. So I guess this code cleanup is a NACK and
I have to duplicate the test in the stmmac driver.

> >
> > > I fear that making this available will add more bugs.
> > >
> > > For instance rspq_check_napi() seems buggy to me.
> > >
> >
> > Mhhh why? Am I opening a can of worms?
> 
> Yes I think :/
> 
> Because only the thread that has grabbed the bit can make any sense of it.
> 
> Another thread reading it would not really know if the value is not going to
> change immediately. So what would be the point ?
> 
> It seems rspq_check_napi() real intent was maybe the following,
> but really this is hard to know if the current race in this code is okay or not.
> 
> diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> index 2e9a74fe0970df333226b80af8716f30865c01b7..e153c9590b36b38e430bc93660146b428e9b3347
> 100644
> --- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> @@ -2676,8 +2676,10 @@ static int rspq_check_napi(struct sge_qset *qs)
> 
>         if (!napi_is_scheduled(&qs->napi) &&
>             is_new_response(&q->desc[q->cidx], q)) {
> -               napi_schedule(&qs->napi);
> -               return 1;
> +               if (napi_schedule_prep(&qs->napi)) {
> +                       __napi_schedule(&qs->napi);
> +                       return 1;
> +               }
>         }
>         return 0;
>  }
  

On Mon, Oct 2, 2023 at 2:29 PM Christian Marangi <ansuelsmth@gmail.com> wrote:

> Ehhh the idea here was to reduce code duplication since the very same
> test will be done in stmmac. So I guess this code cleanup is a NACK and
> I have to duplicate the test in the stmmac driver.

I simply wanted to add a comment in front of this function/helper,
advising not using it unless absolutely needed.

Thus my question "In which context is it safe to call this helper ?"

As long as it was private with a driver, I did not mind.

But if made public in include/linux/netdevice.h, I would rather not
have to explain
to future users why it can be problematic.
  

On Mon, Oct 02, 2023 at 02:35:22PM +0200, Eric Dumazet wrote:
> On Mon, Oct 2, 2023 at 2:29 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> 
> > Ehhh the idea here was to reduce code duplication since the very same
> > test will be done in stmmac. So I guess this code cleanup is a NACK and
> > I have to duplicate the test in the stmmac driver.
> 
> I simply wanted to add a comment in front of this function/helper,
> advising not using it unless absolutely needed.
> 
> Thus my question "In which context is it safe to call this helper ?"
> 
> As long as it was private with a driver, I did not mind.
> 
> But if made public in include/linux/netdevice.h, I would rather not
> have to explain
> to future users why it can be problematic.

Oh ok!

We have plenty of case similar to this. (example some clock API very
internal that should not be used normally or regmap related)

I will include some comments warning that this should not be used in
normal circumstances and other warnings. If you have suggestion on what
to add feel free to write them.

Any clue on how to proceed with the sge driver?
  

On Mon, Oct 2, 2023 at 2:43 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
>
> On Mon, Oct 02, 2023 at 02:35:22PM +0200, Eric Dumazet wrote:
> > On Mon, Oct 2, 2023 at 2:29 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> >
> > > Ehhh the idea here was to reduce code duplication since the very same
> > > test will be done in stmmac. So I guess this code cleanup is a NACK and
> > > I have to duplicate the test in the stmmac driver.
> >
> > I simply wanted to add a comment in front of this function/helper,
> > advising not using it unless absolutely needed.
> >
> > Thus my question "In which context is it safe to call this helper ?"
> >
> > As long as it was private with a driver, I did not mind.
> >
> > But if made public in include/linux/netdevice.h, I would rather not
> > have to explain
> > to future users why it can be problematic.
>
> Oh ok!
>
> We have plenty of case similar to this. (example some clock API very
> internal that should not be used normally or regmap related)
>
> I will include some comments warning that this should not be used in
> normal circumstances and other warnings. If you have suggestion on what
> to add feel free to write them.
>
> Any clue on how to proceed with the sge driver?
>

I would remove use of this helper for something with no race ?

Feel free to submit this :

(Alternative would be to change napi_schedule() to return a boolean)

diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c
b/drivers/net/ethernet/chelsio/cxgb3/sge.c
index 2e9a74fe0970df333226b80af8716f30865c01b7..09d0e6aa4db982e3488e0c28bed33e83453801d0
100644
--- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
@@ -2501,14 +2501,6 @@ static int napi_rx_handler(struct napi_struct
*napi, int budget)
        return work_done;
 }

-/*
- * Returns true if the device is already scheduled for polling.
- */
-static inline int napi_is_scheduled(struct napi_struct *napi)
-{
-       return test_bit(NAPI_STATE_SCHED, &napi->state);
-}
-
 /**
  *     process_pure_responses - process pure responses from a response queue
  *     @adap: the adapter
@@ -2674,9 +2666,9 @@ static int rspq_check_napi(struct sge_qset *qs)
 {
        struct sge_rspq *q = &qs->rspq;

-       if (!napi_is_scheduled(&qs->napi) &&
-           is_new_response(&q->desc[q->cidx], q)) {
-               napi_schedule(&qs->napi);
+       if (is_new_response(&q->desc[q->cidx], q) &&
+           napi_schedule_prep(&qs->napi)) {
+               __napi_schedule(&qs->napi);
                return 1;
        }
        return 0;
  

On Mon, Oct 02, 2023 at 02:49:11PM +0200, Eric Dumazet wrote:
> On Mon, Oct 2, 2023 at 2:43 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> >
> > On Mon, Oct 02, 2023 at 02:35:22PM +0200, Eric Dumazet wrote:
> > > On Mon, Oct 2, 2023 at 2:29 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > >
> > > > Ehhh the idea here was to reduce code duplication since the very same
> > > > test will be done in stmmac. So I guess this code cleanup is a NACK and
> > > > I have to duplicate the test in the stmmac driver.
> > >
> > > I simply wanted to add a comment in front of this function/helper,
> > > advising not using it unless absolutely needed.
> > >
> > > Thus my question "In which context is it safe to call this helper ?"
> > >
> > > As long as it was private with a driver, I did not mind.
> > >
> > > But if made public in include/linux/netdevice.h, I would rather not
> > > have to explain
> > > to future users why it can be problematic.
> >
> > Oh ok!
> >
> > We have plenty of case similar to this. (example some clock API very
> > internal that should not be used normally or regmap related)
> >
> > I will include some comments warning that this should not be used in
> > normal circumstances and other warnings. If you have suggestion on what
> > to add feel free to write them.
> >
> > Any clue on how to proceed with the sge driver?
> >
> 
> I would remove use of this helper for something with no race ?
> 
> Feel free to submit this :
> 
> (Alternative would be to change napi_schedule() to return a boolean)
>

Think mod napi_schedule() to return a bool would result in massive
warning (actually error with werror) with return value not handled.

I will submit with your Suggested-by. Ok for you?

> diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> index 2e9a74fe0970df333226b80af8716f30865c01b7..09d0e6aa4db982e3488e0c28bed33e83453801d0
> 100644
> --- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> @@ -2501,14 +2501,6 @@ static int napi_rx_handler(struct napi_struct
> *napi, int budget)
>         return work_done;
>  }
> 
> -/*
> - * Returns true if the device is already scheduled for polling.
> - */
> -static inline int napi_is_scheduled(struct napi_struct *napi)
> -{
> -       return test_bit(NAPI_STATE_SCHED, &napi->state);
> -}
> -
>  /**
>   *     process_pure_responses - process pure responses from a response queue
>   *     @adap: the adapter
> @@ -2674,9 +2666,9 @@ static int rspq_check_napi(struct sge_qset *qs)
>  {
>         struct sge_rspq *q = &qs->rspq;
> 
> -       if (!napi_is_scheduled(&qs->napi) &&
> -           is_new_response(&q->desc[q->cidx], q)) {
> -               napi_schedule(&qs->napi);
> +       if (is_new_response(&q->desc[q->cidx], q) &&
> +           napi_schedule_prep(&qs->napi)) {
> +               __napi_schedule(&qs->napi);
>                 return 1;
>         }
>         return 0;
  

On Mon, Oct 2, 2023 at 2:55 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
>
> On Mon, Oct 02, 2023 at 02:49:11PM +0200, Eric Dumazet wrote:
> > On Mon, Oct 2, 2023 at 2:43 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > >
> > > On Mon, Oct 02, 2023 at 02:35:22PM +0200, Eric Dumazet wrote:
> > > > On Mon, Oct 2, 2023 at 2:29 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > >
> > > > > Ehhh the idea here was to reduce code duplication since the very same
> > > > > test will be done in stmmac. So I guess this code cleanup is a NACK and
> > > > > I have to duplicate the test in the stmmac driver.
> > > >
> > > > I simply wanted to add a comment in front of this function/helper,
> > > > advising not using it unless absolutely needed.
> > > >
> > > > Thus my question "In which context is it safe to call this helper ?"
> > > >
> > > > As long as it was private with a driver, I did not mind.
> > > >
> > > > But if made public in include/linux/netdevice.h, I would rather not
> > > > have to explain
> > > > to future users why it can be problematic.
> > >
> > > Oh ok!
> > >
> > > We have plenty of case similar to this. (example some clock API very
> > > internal that should not be used normally or regmap related)
> > >
> > > I will include some comments warning that this should not be used in
> > > normal circumstances and other warnings. If you have suggestion on what
> > > to add feel free to write them.
> > >
> > > Any clue on how to proceed with the sge driver?
> > >
> >
> > I would remove use of this helper for something with no race ?
> >
> > Feel free to submit this :
> >
> > (Alternative would be to change napi_schedule() to return a boolean)
> >
>
> Think mod napi_schedule() to return a bool would result in massive
> warning (actually error with werror) with return value not handled.
>

It should not, unless we added a __must_check

> I will submit with your Suggested-by. Ok for you?

Absolutely, thanks.

>
> > diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > index 2e9a74fe0970df333226b80af8716f30865c01b7..09d0e6aa4db982e3488e0c28bed33e83453801d0
> > 100644
> > --- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > +++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > @@ -2501,14 +2501,6 @@ static int napi_rx_handler(struct napi_struct
> > *napi, int budget)
> >         return work_done;
> >  }
> >
> > -/*
> > - * Returns true if the device is already scheduled for polling.
> > - */
> > -static inline int napi_is_scheduled(struct napi_struct *napi)
> > -{
> > -       return test_bit(NAPI_STATE_SCHED, &napi->state);
> > -}
> > -
> >  /**
> >   *     process_pure_responses - process pure responses from a response queue
> >   *     @adap: the adapter
> > @@ -2674,9 +2666,9 @@ static int rspq_check_napi(struct sge_qset *qs)
> >  {
> >         struct sge_rspq *q = &qs->rspq;
> >
> > -       if (!napi_is_scheduled(&qs->napi) &&
> > -           is_new_response(&q->desc[q->cidx], q)) {
> > -               napi_schedule(&qs->napi);
> > +       if (is_new_response(&q->desc[q->cidx], q) &&
> > +           napi_schedule_prep(&qs->napi)) {
> > +               __napi_schedule(&qs->napi);
> >                 return 1;
> >         }
> >         return 0;
>
> --
>         Ansuel
  

On Mon, Oct 2, 2023 at 2:56 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Mon, Oct 2, 2023 at 2:55 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> >
> > On Mon, Oct 02, 2023 at 02:49:11PM +0200, Eric Dumazet wrote:
> > > On Mon, Oct 2, 2023 at 2:43 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > >
> > > > On Mon, Oct 02, 2023 at 02:35:22PM +0200, Eric Dumazet wrote:
> > > > > On Mon, Oct 2, 2023 at 2:29 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > > >
> > > > > > Ehhh the idea here was to reduce code duplication since the very same
> > > > > > test will be done in stmmac. So I guess this code cleanup is a NACK and
> > > > > > I have to duplicate the test in the stmmac driver.
> > > > >
> > > > > I simply wanted to add a comment in front of this function/helper,
> > > > > advising not using it unless absolutely needed.
> > > > >
> > > > > Thus my question "In which context is it safe to call this helper ?"
> > > > >
> > > > > As long as it was private with a driver, I did not mind.
> > > > >
> > > > > But if made public in include/linux/netdevice.h, I would rather not
> > > > > have to explain
> > > > > to future users why it can be problematic.
> > > >
> > > > Oh ok!
> > > >
> > > > We have plenty of case similar to this. (example some clock API very
> > > > internal that should not be used normally or regmap related)
> > > >
> > > > I will include some comments warning that this should not be used in
> > > > normal circumstances and other warnings. If you have suggestion on what
> > > > to add feel free to write them.
> > > >
> > > > Any clue on how to proceed with the sge driver?
> > > >
> > >
> > > I would remove use of this helper for something with no race ?
> > >
> > > Feel free to submit this :
> > >
> > > (Alternative would be to change napi_schedule() to return a boolean)
> > >
> >
> > Think mod napi_schedule() to return a bool would result in massive
> > warning (actually error with werror) with return value not handled.
> >
>
> It should not, unless we added a __must_check

This was what I was thinking :

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index e070a4540fbaf4a9cf310d5f53c4401840c72776..6aa2bc315411d1a0f7db314f1fbfb11aae7c31fe
100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -491,10 +491,13 @@ bool napi_schedule_prep(struct napi_struct *n);
  * Schedule NAPI poll routine to be called if it is not already
  * running.
  */
-static inline void napi_schedule(struct napi_struct *n)
+static inline bool napi_schedule(struct napi_struct *n)
 {
-       if (napi_schedule_prep(n))
+       if (napi_schedule_prep(n)) {
                __napi_schedule(n);
+               return true;
+       }
+       return false;
 }

 /**