Re: INFO: task hung in rtnetlink_rcv_msg

From: Jesper Dangaard Brouer
Date: Mon Feb 25 2019 - 03:39:47 EST


On Sat, 23 Feb 2019 01:47:00 +0100
Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote:

> On 02/22/2019 10:45 PM, Jakub Kicinski wrote:
> > On Fri, 22 Feb 2019 12:14:57 -0800, Joe Perches wrote:
> >> On Fri, 2019-02-22 at 12:01 -0800, Jakub Kicinski wrote:
> >>> Hi!
> >>>
> >>> Seems like something funny is going on with get_maintainer.pl since XDP
> >>> entry got added. We seem to have been CCed on:
> >>
> >> I suggest removing the MAINTAINERS line with
> >>
> >> K: xdp
> >>
> >> as xdp is a pretty generic file/patch content
> >> regex match for the K: type
> >>
> >> $ git grep --name-only xdp | wc -l
> >> 236

I'm unsure how K: works, but you grep definitely selects some wrong files.

I tried with "xdp_":
git grep --name-only xdp_

That does catch all the driver that have XDP support, which is the
point of the exercise (to catch drivers).

It does contain a couple of false-positives:
drivers/net/ethernet/neterion/vxge/vxge-traffic.c
drivers/thunderbolt/tb_msgs.h
drivers/thunderbolt/xdomain.c
sound/soc/codecs/rt5670.c

Via the pattern '[^a-z]xdp_' I'm only left with the thunderbolt
false-positive, as it have a data struct's called tb_xdp_*.




> >> Rather more files than desired.
> >>
> >> The N: match is dubious too.
> >>
> >> It's generally better to have specific lists of
> >> maintained file patterns rather than using the
> >> K: and N: pattern matches.
> >>
> >> ---
> >> MAINTAINERS | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index d7ad97b235ec..aa703e2cb882 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -16970,7 +16970,6 @@ F: include/net/xdp.h
> >> F: kernel/bpf/devmap.c
> >> F: kernel/bpf/cpumap.c
> >> F: include/trace/events/xdp.h
> >> -K: xdp
> >> N: xdp
> >>
> >> XDP SOCKETS (AF_XDP)
> >
> > Thanks for the explanation, at least now I know why it happens! :)
> > I'll leave it to Daniel to decide if we really need it removed,
> > so far the false positives weren't overwhelming, just surprising.
>
> No strong opinion. I've seen this K+N pattern in a number of places
> in the maintainers file. I'm fine either way if it gets too noisy. :)



--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer