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