Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp4220632imc; Mon, 25 Feb 2019 00:40:22 -0800 (PST) X-Google-Smtp-Source: AHgI3IZUC2x9qX/Gd2YrtIxZYDDJa55KkLzMw2ips9kUoXvV5gKCAqji9mx0Oca0itTzFHO6DV7B X-Received: by 2002:a17:902:4503:: with SMTP id m3mr19097664pld.35.1551084022177; Mon, 25 Feb 2019 00:40:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551084022; cv=none; d=google.com; s=arc-20160816; b=onio4pDU2Y+SFpIog2igUpSqSAtQbYp0+NBs2plq86iE2/oElonfU11S38imBDoWPD 357dmAJBfHIwod5EDsdUNy+E7m0xnaUF9sjcf2iG1GaWmEyOTo3YE10eEPKwZTPbARC4 xAclClXM5fsYG9OZvi1Fko3lXYz9FRljc3E1aWbGoXiBn1vgMXGkoU0XWh8lHJgUnwhN xoyL3xtl8V+2CCvmmnaa8S/eKcq0kEKz5atKw+5YvDH2NvoKcxgRpKfNyn7t5e9uv8zP ln0fL6XKqeWmd/nXHlNFK/P8E8KkegglMeGVcU1tf0dbhxrO+3imT3mMwdd7s73Ma4Kl TVpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=8V0SrIF+ozk2bF5u2B01pjsUr4SqZvfsSS/ThJsdGqA=; b=KjgEbXjTwHH1edx1ETHklL4lJXeAsOLVlvnMAMZHUAcrQ3tTEcq38qlYcDALq8D7dn pZvzwC22OBAuu3rONsAh6w2Uy+14MrsuGVtIPMTX9beLbZIKdYdwDrBD4dP4lNyM44kz AOR3KH/AGxuMaTs0Rj7t/GCmQToNBVBbn2rNChnSPncyVidxf7Mq3YbTq21r1sMQVBE6 H7emE/Qe7voOiu/wjN45hVrGXdBVKz4uIPmkIs5Zl0ho9dp/Ia+bNr6gJEDBZ3UZCj55 D2EAORiHWBrlAnlX5r1XOx6LZ9P/yZYqKO3K0tbIchoUurh0QjRDvSXtclUbKp8aKCCn mmCA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s66si9294495pgs.115.2019.02.25.00.40.06; Mon, 25 Feb 2019 00:40:22 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726296AbfBYIjp (ORCPT + 99 others); Mon, 25 Feb 2019 03:39:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:7453 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726054AbfBYIjp (ORCPT ); Mon, 25 Feb 2019 03:39:45 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D29DC13AA8; Mon, 25 Feb 2019 08:39:43 +0000 (UTC) Received: from carbon (ovpn-200-42.brq.redhat.com [10.40.200.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1EA7460857; Mon, 25 Feb 2019 08:39:34 +0000 (UTC) Date: Mon, 25 Feb 2019 09:39:33 +0100 From: Jesper Dangaard Brouer To: Daniel Borkmann Cc: Jakub Kicinski , Joe Perches , syzbot , ast@kernel.org, christian@brauner.io, davem@davemloft.net, dsahern@gmail.com, hawk@kernel.org, idosch@mellanox.com, john.fastabend@gmail.com, kafai@fb.com, ktkhai@virtuozzo.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, petrm@mellanox.com, roopa@cumulusnetworks.com, songliubraving@fb.com, syzkaller-bugs@googlegroups.com, xdp-newbies@vger.kernel.org, yhs@fb.com, brouer@redhat.com Subject: Re: INFO: task hung in rtnetlink_rcv_msg Message-ID: <20190225093933.748ceab4@carbon> In-Reply-To: <279c5bae-0b18-b03a-2858-4749e18afa26@iogearbox.net> References: <000000000000c07a5805827e85d5@google.com> <20190222120129.1f2f1c17@cakuba.netronome.com> <20190222134511.13eb7a82@cakuba.netronome.com> <279c5bae-0b18-b03a-2858-4749e18afa26@iogearbox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 25 Feb 2019 08:39:44 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 23 Feb 2019 01:47:00 +0100 Daniel Borkmann 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