bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next] sfc: trace_xdp_exception on XDP failure
@ 2019-11-11 10:51 Arthur Fabre
  2019-11-11 17:27 ` Edward Cree
  2019-11-12 19:37 ` kbuild test robot
  0 siblings, 2 replies; 6+ messages in thread
From: Arthur Fabre @ 2019-11-11 10:51 UTC (permalink / raw)
  To: Solarflare linux maintainers, Edward Cree, Charles McLachlan,
	Martin Habets, David Miller, Alexei Starovoitov, Daniel Borkmann,
	Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend, netdev,
	bpf
  Cc: kernel-team, Arthur Fabre

The sfc driver can drop packets processed with XDP, notably when running
out of buffer space on XDP_TX, or returning an unknown XDP action.
This increments the rx_xdp_bad_drops ethtool counter.

Call trace_xdp_exception everywhere rx_xdp_bad_drops is incremented to
easily monitor this from userspace.

This mirrors the behavior of other drivers.

Signed-off-by: Arthur Fabre <afabre@cloudflare.com>
---
 drivers/net/ethernet/sfc/rx.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index a7d9841105d8..5bfe1f6112a1 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -678,6 +678,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
 				  "XDP is not possible with multiple receive fragments (%d)\n",
 				  channel->rx_pkt_n_frags);
 		channel->n_rx_xdp_bad_drops++;
+		trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
 		return false;
 	}
 
@@ -724,6 +725,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
 				netif_err(efx, rx_err, efx->net_dev,
 					  "XDP TX failed (%d)\n", err);
 			channel->n_rx_xdp_bad_drops++;
+			trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
 		} else {
 			channel->n_rx_xdp_tx++;
 		}
@@ -737,6 +739,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
 				netif_err(efx, rx_err, efx->net_dev,
 					  "XDP redirect failed (%d)\n", err);
 			channel->n_rx_xdp_bad_drops++;
+			trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
 		} else {
 			channel->n_rx_xdp_redirect++;
 		}
@@ -746,6 +749,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
 		bpf_warn_invalid_xdp_action(xdp_act);
 		efx_free_rx_buffers(rx_queue, rx_buf, 1);
 		channel->n_rx_xdp_bad_drops++;
+		trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
 		break;
 
 	case XDP_ABORTED:
-- 
2.24.0.rc2


^ permalink raw reply related	[flat|nested] 6+ messages in thread
* Re: [PATCH net-next] sfc: trace_xdp_exception on XDP failure
  2019-11-11 10:51 [PATCH net-next] sfc: trace_xdp_exception on XDP failure Arthur Fabre
@ 2019-11-11 17:27 ` Edward Cree
  2019-11-11 17:38   ` Arthur Fabre
  2019-11-12 19:37 ` kbuild test robot
  1 sibling, 1 reply; 6+ messages in thread
From: Edward Cree @ 2019-11-11 17:27 UTC (permalink / raw)
  To: Arthur Fabre, Solarflare linux maintainers, Charles McLachlan,
	Martin Habets, David Miller, Alexei Starovoitov, Daniel Borkmann,
	Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend, netdev,
	bpf
  Cc: kernel-team

On 11/11/2019 10:51, Arthur Fabre wrote:
> The sfc driver can drop packets processed with XDP, notably when running
> out of buffer space on XDP_TX, or returning an unknown XDP action.
> This increments the rx_xdp_bad_drops ethtool counter.
>
> Call trace_xdp_exception everywhere rx_xdp_bad_drops is incremented to
> easily monitor this from userspace.
>
> This mirrors the behavior of other drivers.
>
> Signed-off-by: Arthur Fabre <afabre@cloudflare.com>
> ---
>  drivers/net/ethernet/sfc/rx.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
> index a7d9841105d8..5bfe1f6112a1 100644
> --- a/drivers/net/ethernet/sfc/rx.c
> +++ b/drivers/net/ethernet/sfc/rx.c
> @@ -678,6 +678,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
>  				  "XDP is not possible with multiple receive fragments (%d)\n",
>  				  channel->rx_pkt_n_frags);
>  		channel->n_rx_xdp_bad_drops++;
> +		trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
>  		return false;
>  	}
AIUI trace_xdp_exception() is improper here as we have not run
 the XDP program (and xdp_act is thus uninitialised).

The other three, below, appear to be correct.
-Ed

>  
> @@ -724,6 +725,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
>  				netif_err(efx, rx_err, efx->net_dev,
>  					  "XDP TX failed (%d)\n", err);
>  			channel->n_rx_xdp_bad_drops++;
> +			trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
>  		} else {
>  			channel->n_rx_xdp_tx++;
>  		}
> @@ -737,6 +739,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
>  				netif_err(efx, rx_err, efx->net_dev,
>  					  "XDP redirect failed (%d)\n", err);
>  			channel->n_rx_xdp_bad_drops++;
> +			trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
>  		} else {
>  			channel->n_rx_xdp_redirect++;
>  		}
> @@ -746,6 +749,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
>  		bpf_warn_invalid_xdp_action(xdp_act);
>  		efx_free_rx_buffers(rx_queue, rx_buf, 1);
>  		channel->n_rx_xdp_bad_drops++;
> +		trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
>  		break;
>  
>  	case XDP_ABORTED:


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH net-next] sfc: trace_xdp_exception on XDP failure
  2019-11-11 17:27 ` Edward Cree
@ 2019-11-11 17:38   ` Arthur Fabre
  2019-11-11 18:01     ` Edward Cree
  0 siblings, 1 reply; 6+ messages in thread
From: Arthur Fabre @ 2019-11-11 17:38 UTC (permalink / raw)
  To: Edward Cree
  Cc: Solarflare linux maintainers, Charles McLachlan, Martin Habets,
	David Miller, Alexei Starovoitov, Daniel Borkmann,
	Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend, netdev,
	bpf, kernel-team

On Mon, Nov 11, 2019 at 5:27 PM Edward Cree <ecree@solarflare.com> wrote:
>
> On 11/11/2019 10:51, Arthur Fabre wrote:
> > diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
> > index a7d9841105d8..5bfe1f6112a1 100644
> > --- a/drivers/net/ethernet/sfc/rx.c
> > +++ b/drivers/net/ethernet/sfc/rx.c
> > @@ -678,6 +678,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
> >                                 "XDP is not possible with multiple receive fragments (%d)\n",
> >                                 channel->rx_pkt_n_frags);
> >               channel->n_rx_xdp_bad_drops++;
> > +             trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
> >               return false;
> >       }
> AIUI trace_xdp_exception() is improper here as we have not run
>  the XDP program (and xdp_act is thus uninitialised).
>
> The other three, below, appear to be correct.
> -Ed
>

Good point. Do you know under what conditions we'd end up with
"fragmented" packets? As far as I can tell this isn't IP
fragmentation?

On Mon, Nov 11, 2019 at 5:27 PM Edward Cree <ecree@solarflare.com> wrote:
>
> On 11/11/2019 10:51, Arthur Fabre wrote:
> > The sfc driver can drop packets processed with XDP, notably when running
> > out of buffer space on XDP_TX, or returning an unknown XDP action.
> > This increments the rx_xdp_bad_drops ethtool counter.
> >
> > Call trace_xdp_exception everywhere rx_xdp_bad_drops is incremented to
> > easily monitor this from userspace.
> >
> > This mirrors the behavior of other drivers.
> >
> > Signed-off-by: Arthur Fabre <afabre@cloudflare.com>
> > ---
> >  drivers/net/ethernet/sfc/rx.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
> > index a7d9841105d8..5bfe1f6112a1 100644
> > --- a/drivers/net/ethernet/sfc/rx.c
> > +++ b/drivers/net/ethernet/sfc/rx.c
> > @@ -678,6 +678,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
> >                                 "XDP is not possible with multiple receive fragments (%d)\n",
> >                                 channel->rx_pkt_n_frags);
> >               channel->n_rx_xdp_bad_drops++;
> > +             trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
> >               return false;
> >       }
> AIUI trace_xdp_exception() is improper here as we have not run
>  the XDP program (and xdp_act is thus uninitialised).
>
> The other three, below, appear to be correct.
> -Ed
>
> >
> > @@ -724,6 +725,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
> >                               netif_err(efx, rx_err, efx->net_dev,
> >                                         "XDP TX failed (%d)\n", err);
> >                       channel->n_rx_xdp_bad_drops++;
> > +                     trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
> >               } else {
> >                       channel->n_rx_xdp_tx++;
> >               }
> > @@ -737,6 +739,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
> >                               netif_err(efx, rx_err, efx->net_dev,
> >                                         "XDP redirect failed (%d)\n", err);
> >                       channel->n_rx_xdp_bad_drops++;
> > +                     trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
> >               } else {
> >                       channel->n_rx_xdp_redirect++;
> >               }
> > @@ -746,6 +749,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
> >               bpf_warn_invalid_xdp_action(xdp_act);
> >               efx_free_rx_buffers(rx_queue, rx_buf, 1);
> >               channel->n_rx_xdp_bad_drops++;
> > +             trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
> >               break;
> >
> >       case XDP_ABORTED:
>

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH net-next] sfc: trace_xdp_exception on XDP failure
  2019-11-11 17:38   ` Arthur Fabre
@ 2019-11-11 18:01     ` Edward Cree
  2019-11-12 14:52       ` Arthur Fabre
  0 siblings, 1 reply; 6+ messages in thread
From: Edward Cree @ 2019-11-11 18:01 UTC (permalink / raw)
  To: Arthur Fabre
  Cc: Solarflare linux maintainers, Charles McLachlan, Martin Habets,
	David Miller, Alexei Starovoitov, Daniel Borkmann,
	Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend, netdev,
	bpf, kernel-team

On 11/11/2019 17:38, Arthur Fabre wrote:
> On Mon, Nov 11, 2019 at 5:27 PM Edward Cree <ecree@solarflare.com> wrote:
>>
>> On 11/11/2019 10:51, Arthur Fabre wrote:
>>> diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
>>> index a7d9841105d8..5bfe1f6112a1 100644
>>> --- a/drivers/net/ethernet/sfc/rx.c
>>> +++ b/drivers/net/ethernet/sfc/rx.c
>>> @@ -678,6 +678,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
>>>                                 "XDP is not possible with multiple receive fragments (%d)\n",
>>>                                 channel->rx_pkt_n_frags);
>>>               channel->n_rx_xdp_bad_drops++;
>>> +             trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
>>>               return false;
>>>       }
>> AIUI trace_xdp_exception() is improper here as we have not run
>>  the XDP program (and xdp_act is thus uninitialised).
>>
>> The other three, below, appear to be correct.
>> -Ed
>>
> 
> Good point. Do you know under what conditions we'd end up with
> "fragmented" packets? As far as I can tell this isn't IP
> fragmentation?

Fragments in this case means that the packet data are spread across
 multiple RX buffers (~= memory pages).  This should only happen if
 the RX packet is too big to fit in a single buffer, and when
 enabling XDP we ensure that the MTU is small enough to prevent
 that.  So in theory this can't happen if the NIC is functioning
 correctly.

-Ed

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH net-next] sfc: trace_xdp_exception on XDP failure
  2019-11-11 18:01     ` Edward Cree
@ 2019-11-12 14:52       ` Arthur Fabre
  0 siblings, 0 replies; 6+ messages in thread
From: Arthur Fabre @ 2019-11-12 14:52 UTC (permalink / raw)
  To: Edward Cree
  Cc: Solarflare linux maintainers, Charles McLachlan, Martin Habets,
	David Miller, Alexei Starovoitov, Daniel Borkmann,
	Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend, netdev,
	bpf, kernel-team

On Mon, Nov 11, 2019 at 6:01 PM Edward Cree <ecree@solarflare.com> wrote:
>
> On 11/11/2019 17:38, Arthur Fabre wrote:
> > On Mon, Nov 11, 2019 at 5:27 PM Edward Cree <ecree@solarflare.com> wrote:
> >>
> >> On 11/11/2019 10:51, Arthur Fabre wrote:
> >>> diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
> >>> index a7d9841105d8..5bfe1f6112a1 100644
> >>> --- a/drivers/net/ethernet/sfc/rx.c
> >>> +++ b/drivers/net/ethernet/sfc/rx.c
> >>> @@ -678,6 +678,7 @@ static bool efx_do_xdp(struct efx_nic *efx, struct efx_channel *channel,
> >>>                                 "XDP is not possible with multiple receive fragments (%d)\n",
> >>>                                 channel->rx_pkt_n_frags);
> >>>               channel->n_rx_xdp_bad_drops++;
> >>> +             trace_xdp_exception(efx->net_dev, xdp_prog, xdp_act);
> >>>               return false;
> >>>       }
> >> AIUI trace_xdp_exception() is improper here as we have not run
> >>  the XDP program (and xdp_act is thus uninitialised).
> >>
> >> The other three, below, appear to be correct.
> >> -Ed
> >>
> >
> > Good point. Do you know under what conditions we'd end up with
> > "fragmented" packets? As far as I can tell this isn't IP
> > fragmentation?
>
> Fragments in this case means that the packet data are spread across
>  multiple RX buffers (~= memory pages).  This should only happen if
>  the RX packet is too big to fit in a single buffer, and when
>  enabling XDP we ensure that the MTU is small enough to prevent
>  that.  So in theory this can't happen if the NIC is functioning
>  correctly.
>
> -Ed

Makes sense, thank you for the explanation.

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH net-next] sfc: trace_xdp_exception on XDP failure
  2019-11-11 10:51 [PATCH net-next] sfc: trace_xdp_exception on XDP failure Arthur Fabre
  2019-11-11 17:27 ` Edward Cree
@ 2019-11-12 19:37 ` kbuild test robot
  1 sibling, 0 replies; 6+ messages in thread
From: kbuild test robot @ 2019-11-12 19:37 UTC (permalink / raw)
  To: Arthur Fabre
  Cc: kbuild-all, Solarflare linux maintainers, Edward Cree,
	Charles McLachlan, Martin Habets, David Miller,
	Alexei Starovoitov, Daniel Borkmann, Jakub Kicinski,
	Jesper Dangaard Brouer, John Fastabend, netdev, bpf, kernel-team,
	Arthur Fabre

[-- Attachment #1: Type: text/plain, Size: 7490 bytes --]

Hi Arthur,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]
[also build test WARNING on next-20191112]
[cannot apply to v5.4-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Arthur-Fabre/sfc-trace_xdp_exception-on-XDP-failure/20191113-021808
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git ca22d6977b9b4ab0fd2e7909b57e32ba5b95046f
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=mips 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   In file included from include/trace/events/xdp.h:10:0,
                    from include/linux/bpf_trace.h:5,
                    from drivers/net/ethernet/sfc/rx.c:21:
   drivers/net/ethernet/sfc/rx.c: In function '__efx_rx_packet':
>> include/linux/tracepoint.h:193:6: warning: 'xdp_act' may be used uninitialized in this function [-Wmaybe-uninitialized]
        ((void(*)(proto))(it_func))(args); \
         ^
   drivers/net/ethernet/sfc/rx.c:658:6: note: 'xdp_act' was declared here
     u32 xdp_act;
         ^~~~~~~
--
   In file included from include/trace/events/xdp.h:10:0,
                    from include/linux/bpf_trace.h:5,
                    from drivers/net//ethernet/sfc/rx.c:21:
   drivers/net//ethernet/sfc/rx.c: In function '__efx_rx_packet':
>> include/linux/tracepoint.h:193:6: warning: 'xdp_act' may be used uninitialized in this function [-Wmaybe-uninitialized]
        ((void(*)(proto))(it_func))(args); \
         ^
   drivers/net//ethernet/sfc/rx.c:658:6: note: 'xdp_act' was declared here
     u32 xdp_act;
         ^~~~~~~

vim +/xdp_act +193 include/linux/tracepoint.h

97e1c18e8d17bd Mathieu Desnoyers       2008-07-18  151  
97e1c18e8d17bd Mathieu Desnoyers       2008-07-18  152  /*
97e1c18e8d17bd Mathieu Desnoyers       2008-07-18  153   * it_func[0] is never NULL because there is at least one element in the array
97e1c18e8d17bd Mathieu Desnoyers       2008-07-18  154   * when the array itself is non NULL.
38516ab59fbc5b Steven Rostedt          2010-04-20  155   *
38516ab59fbc5b Steven Rostedt          2010-04-20  156   * Note, the proto and args passed in includes "__data" as the first parameter.
38516ab59fbc5b Steven Rostedt          2010-04-20  157   * The reason for this is to handle the "void" prototype. If a tracepoint
38516ab59fbc5b Steven Rostedt          2010-04-20  158   * has a "void" prototype, then it is invalid to declare a function
38516ab59fbc5b Steven Rostedt          2010-04-20  159   * as "(void *, void)". The DECLARE_TRACE_NOARGS() will pass in just
38516ab59fbc5b Steven Rostedt          2010-04-20  160   * "void *data", where as the DECLARE_TRACE() will pass in "void *data, proto".
97e1c18e8d17bd Mathieu Desnoyers       2008-07-18  161   */
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  162) #define __DO_TRACE(tp, proto, args, cond, rcuidle)			\
97e1c18e8d17bd Mathieu Desnoyers       2008-07-18  163  	do {								\
38516ab59fbc5b Steven Rostedt          2010-04-20  164  		struct tracepoint_func *it_func_ptr;			\
38516ab59fbc5b Steven Rostedt          2010-04-20  165  		void *it_func;						\
38516ab59fbc5b Steven Rostedt          2010-04-20  166  		void *__data;						\
0c7a52e4d4b5c4 Zenghui Yu              2018-11-28  167  		int __maybe_unused __idx = 0;				\
97e1c18e8d17bd Mathieu Desnoyers       2008-07-18  168  									\
287050d3902644 Steven Rostedt          2010-12-02  169  		if (!(cond))						\
287050d3902644 Steven Rostedt          2010-12-02  170  			return;						\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  171) 									\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  172) 		/* srcu can't be used from NMI */			\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  173) 		WARN_ON_ONCE(rcuidle && in_nmi());			\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  174) 									\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  175) 		/* keep srcu and sched-rcu usage consistent */		\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  176) 		preempt_disable_notrace();				\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  177) 									\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  178) 		/*							\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  179) 		 * For rcuidle callers, use srcu since sched-rcu	\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  180) 		 * doesn't work from the idle path.			\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  181) 		 */							\
865e63b04e9b2a Steven Rostedt (VMware  2018-09-04  182) 		if (rcuidle) {						\
0c7a52e4d4b5c4 Zenghui Yu              2018-11-28  183  			__idx = srcu_read_lock_notrace(&tracepoint_srcu);\
865e63b04e9b2a Steven Rostedt (VMware  2018-09-04  184) 			rcu_irq_enter_irqson();				\
865e63b04e9b2a Steven Rostedt (VMware  2018-09-04  185) 		}							\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  186) 									\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  187) 		it_func_ptr = rcu_dereference_raw((tp)->funcs);		\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  188) 									\
38516ab59fbc5b Steven Rostedt          2010-04-20  189  		if (it_func_ptr) {					\
97e1c18e8d17bd Mathieu Desnoyers       2008-07-18  190  			do {						\
38516ab59fbc5b Steven Rostedt          2010-04-20  191  				it_func = (it_func_ptr)->func;		\
38516ab59fbc5b Steven Rostedt          2010-04-20  192  				__data = (it_func_ptr)->data;		\
38516ab59fbc5b Steven Rostedt          2010-04-20 @193  				((void(*)(proto))(it_func))(args);	\
38516ab59fbc5b Steven Rostedt          2010-04-20  194  			} while ((++it_func_ptr)->func);		\
97e1c18e8d17bd Mathieu Desnoyers       2008-07-18  195  		}							\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  196) 									\
865e63b04e9b2a Steven Rostedt (VMware  2018-09-04  197) 		if (rcuidle) {						\
865e63b04e9b2a Steven Rostedt (VMware  2018-09-04  198) 			rcu_irq_exit_irqson();				\
0c7a52e4d4b5c4 Zenghui Yu              2018-11-28  199  			srcu_read_unlock_notrace(&tracepoint_srcu, __idx);\
865e63b04e9b2a Steven Rostedt (VMware  2018-09-04  200) 		}							\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  201) 									\
e6753f23d961d6 Joel Fernandes (Google  2018-07-30  202) 		preempt_enable_notrace();				\
97e1c18e8d17bd Mathieu Desnoyers       2008-07-18  203  	} while (0)
97e1c18e8d17bd Mathieu Desnoyers       2008-07-18  204  

:::::: The code at line 193 was first introduced by commit
:::::: 38516ab59fbc5b3bb278cf5e1fe2867c70cff32e tracing: Let tracepoints have data passed to tracepoint callbacks

:::::: TO: Steven Rostedt <srostedt@redhat.com>
:::::: CC: Steven Rostedt <rostedt@goodmis.org>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 62097 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-11-12 19:38 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-11 10:51 [PATCH net-next] sfc: trace_xdp_exception on XDP failure Arthur Fabre
2019-11-11 17:27 ` Edward Cree
2019-11-11 17:38   ` Arthur Fabre
2019-11-11 18:01     ` Edward Cree
2019-11-12 14:52       ` Arthur Fabre
2019-11-12 19:37 ` kbuild test robot

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).