Message ID | 20230331235528.1106675-2-anjali.k.kulkarni@oracle.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp926721vqo; Fri, 31 Mar 2023 17:22:52 -0700 (PDT) X-Google-Smtp-Source: AKy350asyyy2I5obR1x3GZ6NEhAsFvfW/qS1RE+JB4W1HFzQJ4GzJzoFG71bPN0/eo31r/ih2HYZ X-Received: by 2002:a17:906:d207:b0:92b:b4d9:3f07 with SMTP id w7-20020a170906d20700b0092bb4d93f07mr26828903ejz.14.1680308572062; Fri, 31 Mar 2023 17:22:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680308572; cv=none; d=google.com; s=arc-20160816; b=KUeXFjYTZ3xlnBd4+Wess0SU1bYhhHjfLxcgdlEdLnLmHKgCSUk9eL9KVT/OOO1gGD 5v9jUA0Jtw6szZ2V1l0j6M31HqFCgHJ9OBMwLS8PKR3ZCUts1DttQqX54SYzDRLA/uMj rxVYp0cA1Yzgz0RHj/iPDz0fIjyjIzjMoBIYB1Iq2FN5nqmaiUS+HxHwSaL9sVIRTAem cf3V4yHxDon0GyfcPSoQbg/eb0T4hOcIf1jRV1OKft8MRXAQ+wT4I3wtOmG0JcfO0zBR QSvNHKPXlVZWW0DrSI0WShdhxeZTsOO48io7weZMkUcpAamTUsi2Gg4tngd5FK/kjqht lU3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=JLjZZTYyJYJMe3QiAlLr02+MhgbjP8RiniXG97TsRPo=; b=yRDcpGA0rxKy5LL5CAwLDjiu/cMUq0dDl0oaw2ghdBvkcV0+bbtFHXQ3cOBljW/54y IydhF3XHp9Fa7tkSRJXQV13Qp1GlCaVqmP8qqx8aZ1gPCKIKbKUd90K+FLHi6U9xJAyp hgHigtye5lPV0S/JDiijj9ki3wPcgRteR2+ggCv1hAq2nWsxncippEoseBE3lDacxjCs jc58cweDFKIpfEkxIZR5womOXrDvtMoxsBxVKNmOcQkMYywAGjdXSC/nPsSh3hIhQxq2 M2fZ2RZ2vXotpnk0uTZpcjk8M9RFc/HBFfE5PwnjDnC6wPr6ZhbiOuFPsprF/UrNl+e8 YWqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2022-7-12 header.b="dOg9I/vH"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d3-20020a170906304300b009334dc89725si2772301ejd.145.2023.03.31.17.22.27; Fri, 31 Mar 2023 17:22:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2022-7-12 header.b="dOg9I/vH"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233345AbjCaXz5 (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Fri, 31 Mar 2023 19:55:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233179AbjCaXzw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 31 Mar 2023 19:55:52 -0400 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9B8B71C1F9; Fri, 31 Mar 2023 16:55:51 -0700 (PDT) Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 32VKr7Ib014473; Fri, 31 Mar 2023 23:55:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding; s=corp-2022-7-12; bh=JLjZZTYyJYJMe3QiAlLr02+MhgbjP8RiniXG97TsRPo=; b=dOg9I/vHygleuC9XF2Ko/PVAHm3hsqvks0pUmM+K0yWk35jzdlyJIrEHx7Ucl/6rpui0 Ny3ZE18Bobin6MJwEy5xgGbyt9sWdgbNOVEuYfAJe4wg5NWDYW/ZDRCQkM38L8gXDzb/ Rmi7FzCOYlIFuYO+bWATwN3d1Wf/+VcfxeC2KpH0QRm58s8GZgEBwrciicwyanWWGO58 nL1dpzbBn9kQtnr5J2r5XE2nWk+UXPYjJxJYpFZOO3V/fUGW7t4FoAUtjNonJmRBaaIN NrArgXbBT7AMXZMQ7SYI2EHqX7u72ROn/7f9uxkMSxg3gk4l0XFncS4OmIbzwLq5mrex /w== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3pmqbyy9cs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 31 Mar 2023 23:55:34 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 32VMNgYL023539; Fri, 31 Mar 2023 23:55:33 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3phqdkm2qm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 31 Mar 2023 23:55:33 +0000 Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 32VNtUIb019347; Fri, 31 Mar 2023 23:55:32 GMT Received: from ca-dev112.us.oracle.com (ca-dev112.us.oracle.com [10.129.136.47]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id 3phqdkm2p9-2; Fri, 31 Mar 2023 23:55:32 +0000 From: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> To: davem@davemloft.net Cc: edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, zbr@ioremap.net, brauner@kernel.org, johannes@sipsolutions.net, ecree.xilinx@gmail.com, leon@kernel.org, keescook@chromium.org, socketcan@hartkopp.net, petrm@nvidia.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, anjali.k.kulkarni@oracle.com Subject: [PATCH v4 1/6] netlink: Reverse the patch which removed filtering Date: Fri, 31 Mar 2023 16:55:23 -0700 Message-Id: <20230331235528.1106675-2-anjali.k.kulkarni@oracle.com> X-Mailer: git-send-email 2.40.0 In-Reply-To: <20230331235528.1106675-1-anjali.k.kulkarni@oracle.com> References: <20230331235528.1106675-1-anjali.k.kulkarni@oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-03-31_07,2023-03-31_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 spamscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2303310196 X-Proofpoint-GUID: vFnbKuzHejwMqL3iUDgiwMtJIAGOo52J X-Proofpoint-ORIG-GUID: vFnbKuzHejwMqL3iUDgiwMtJIAGOo52J X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761931241017926742?= X-GMAIL-MSGID: =?utf-8?q?1761931241017926742?= |
Series |
Process connector bug fixes & enhancements
|
|
Commit Message
Anjali Kulkarni
March 31, 2023, 11:55 p.m. UTC
To use filtering at the connector & cn_proc layers, we need to enable
filtering in the netlink layer. This reverses the patch which removed
netlink filtering.
Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com>
---
include/linux/netlink.h | 5 +++++
net/netlink/af_netlink.c | 25 +++++++++++++++++++++++--
2 files changed, 28 insertions(+), 2 deletions(-)
Comments
On Fri, 31 Mar 2023 16:55:23 -0700 Anjali Kulkarni wrote: > To use filtering at the connector & cn_proc layers, we need to enable > filtering in the netlink layer. This reverses the patch which removed > netlink filtering. > > Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Acked-by: Jakub Kicinski <kuba@kernel.org>
On Fri, 31 Mar 2023 16:55:23 -0700 Anjali Kulkarni wrote: > +int netlink_broadcast_filtered(struct sock *ssk, struct sk_buff *skb, > + __u32 portid, __u32 group, gfp_t allocation, > + int (*filter)(struct sock *dsk, > + struct sk_buff *skb, void *data), > + void *filter_data); > -int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 portid, > - u32 group, gfp_t allocation) > +int netlink_broadcast_filtered(struct sock *ssk, struct sk_buff *skb, > + u32 portid, > + u32 group, gfp_t allocation, > + int (*filter)(struct sock *dsk, > + struct sk_buff *skb, void *data), > + void *filter_data) nit: slight divergence between __u32 and u32 types, something to clean up if you post v5
> On Mar 31, 2023, at 9:09 PM, Jakub Kicinski <kuba@kernel.org> wrote: > > On Fri, 31 Mar 2023 16:55:23 -0700 Anjali Kulkarni wrote: >> +int netlink_broadcast_filtered(struct sock *ssk, struct sk_buff *skb, >> + __u32 portid, __u32 group, gfp_t allocation, >> + int (*filter)(struct sock *dsk, >> + struct sk_buff *skb, void *data), >> + void *filter_data); > >> -int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 portid, >> - u32 group, gfp_t allocation) >> +int netlink_broadcast_filtered(struct sock *ssk, struct sk_buff *skb, >> + u32 portid, >> + u32 group, gfp_t allocation, >> + int (*filter)(struct sock *dsk, >> + struct sk_buff *skb, void *data), >> + void *filter_data) > > nit: slight divergence between __u32 and u32 types, something to clean > up if you post v5 Thanks so much! Will do. Any comments on the connector patches? Anjali
On Sat, 1 Apr 2023 18:24:11 +0000 Anjali Kulkarni wrote: > > nit: slight divergence between __u32 and u32 types, something to clean > > up if you post v5 > > Thanks so much! Will do. Any comments on the connector patches? patch 3 looks fine as far as I can read thru the ugly in place casts patch 5 looks a bit connector specific, no idea :S patch 6 does seem to lift the NET_ADMIN for group 0 and from &init_user_ns, CAP_NET_ADMIN to net->user_ns, CAP_NET_ADMIN whether that's right or not I have no idea :( Also, BTW, on the coding level: +static int cn_bind(struct net *net, int group) +{ + unsigned long groups = 0; + groups = (unsigned long) group; + + if (test_bit(CN_IDX_PROC - 1, &groups)) Why not just +static int cn_bind(struct net *net, int group) +{ + if (group == CN_IDX_PROC) ? Who are you hoping will merge this?
> On Apr 1, 2023, at 12:12 PM, Jakub Kicinski <kuba@kernel.org> wrote: > > On Sat, 1 Apr 2023 18:24:11 +0000 Anjali Kulkarni wrote: >>> nit: slight divergence between __u32 and u32 types, something to clean >>> up if you post v5 >> >> Thanks so much! Will do. Any comments on the connector patches? > > patch 3 looks fine as far as I can read thru the ugly in place casts Thanks for reviewing! > patch 5 looks a bit connector specific, no idea :S > patch 6 does seem to lift the NET_ADMIN for group 0 > and from &init_user_ns, CAP_NET_ADMIN to net->user_ns, CAP_NET_ADMIN > whether that's right or not I have no idea :( I can move this back to &init_user_ns, and will look at group 0 too. > > Also, BTW, on the coding level: > > +static int cn_bind(struct net *net, int group) > +{ > + unsigned long groups = 0; > + groups = (unsigned long) group; > + > + if (test_bit(CN_IDX_PROC - 1, &groups)) > > Why not just > > +static int cn_bind(struct net *net, int group) > +{ > + if (group == CN_IDX_PROC) > > ? Will change this. > > Who are you hoping will merge this? I am not sure. Whom should I contact to move this forward?
> > Who are you hoping will merge this? Could I request you to look into merging the patches which seem ok to you, since you are listed as the maintainer for these? I can make any more changes for the connector patches if you see the need.. Anjali
On Sat, 1 Apr 2023 19:58:31 +0000 Anjali Kulkarni wrote: > > patch 5 looks a bit connector specific, no idea :S > > patch 6 does seem to lift the NET_ADMIN for group 0 > > and from &init_user_ns, CAP_NET_ADMIN to net->user_ns, CAP_NET_ADMIN > > whether that's right or not I have no idea :( > I can move this back to &init_user_ns, and will look at group 0 too. Just to be clear - I wasn't saying that it's incorrect, I simply don't know :)
On Sun, 2 Apr 2023 02:32:19 +0000 Anjali Kulkarni wrote: > > Who are you hoping will merge this? > Could I request you to look into merging the patches which seem ok to > you, since you are listed as the maintainer for these? I can make any > more changes for the connector patches if you see the need.. The first two, you mean? We can merge them, but we need to know that the rest is also going somewhere. Kernel has a rule against merging APIs without any in-tree users, so we need a commitment that the user will also reach linux-next before the merge window :( Christian was commenting on previous releases maybe he can take or just review the last 4 patches?
> On Apr 3, 2023, at 1:50 PM, Jakub Kicinski <kuba@kernel.org> wrote: > > On Sun, 2 Apr 2023 02:32:19 +0000 Anjali Kulkarni wrote: >>> Who are you hoping will merge this? >> Could I request you to look into merging the patches which seem ok to >> you, since you are listed as the maintainer for these? I can make any >> more changes for the connector patches if you see the need.. > > The first two, you mean? We can merge them, but we need to know that Yes, even perhaps the first 3:-), since the third one has bug fixes which looked ok to you? > the rest is also going somewhere. Kernel has a rule against merging > APIs without any in-tree users, so we need a commitment that the > user will also reach linux-next before the merge window :( Yes, sounds right. > > Christian was commenting on previous releases maybe he can take or just > review the last 4 patches? Sounds fine too. I hope Christian can review these. Anjali
> On Apr 3, 2023, at 1:50 PM, Jakub Kicinski <kuba@kernel.org> wrote: > > On Sun, 2 Apr 2023 02:32:19 +0000 Anjali Kulkarni wrote: >>> Who are you hoping will merge this? >> Could I request you to look into merging the patches which seem ok to >> you, since you are listed as the maintainer for these? I can make any >> more changes for the connector patches if you see the need.. > > The first two, you mean? We can merge them, but we need to know that > the rest is also going somewhere. Kernel has a rule against merging > APIs without any in-tree users, so we need a commitment that the > user will also reach linux-next before the merge window :( > Jakub, could you please look into reviewing patches 3,4 & 5 as well? Patch 4 is just test code. Patch 3 is fixing bug fixes in current code so should be good to have - also it is not too connector specific. I can explain patch 5 in more detail if needed. > Christian was commenting on previous releases maybe he can take or just > review the last 4 patches? Christian, could you please look into reviewing patch 6? This just deals with who can get the exit notifications. Thanks Anjali
On Wed, 26 Apr 2023 23:58:55 +0000 Anjali Kulkarni wrote: > Jakub, could you please look into reviewing patches 3,4 & 5 as well? > Patch 4 is just test code. Patch 3 is fixing bug fixes in current > code so should be good to have - also it is not too connector > specific. I can explain patch 5 in more detail if needed. I don't have sufficient knowledge to review that code, sorry :(
> On Apr 27, 2023, at 10:03 AM, Jakub Kicinski <kuba@kernel.org> wrote: > > On Wed, 26 Apr 2023 23:58:55 +0000 Anjali Kulkarni wrote: >> Jakub, could you please look into reviewing patches 3,4 & 5 as well? >> Patch 4 is just test code. Patch 3 is fixing bug fixes in current >> code so should be good to have - also it is not too connector >> specific. I can explain patch 5 in more detail if needed. > > I don't have sufficient knowledge to review that code, sorry :( Is there anyone who can please help review this code? Christian, could you please help take a look? Thanks Anjali
> On May 11, 2023, at 9:04 AM, Anjali Kulkarni <Anjali.K.Kulkarni@oracle.com> wrote: > > > >> On Apr 27, 2023, at 10:03 AM, Jakub Kicinski <kuba@kernel.org> wrote: >> >> On Wed, 26 Apr 2023 23:58:55 +0000 Anjali Kulkarni wrote: >>> Jakub, could you please look into reviewing patches 3,4 & 5 as well? >>> Patch 4 is just test code. Patch 3 is fixing bug fixes in current >>> code so should be good to have - also it is not too connector >>> specific. I can explain patch 5 in more detail if needed. >> >> I don't have sufficient knowledge to review that code, sorry :( > > Is there anyone who can please help review this code? > Christian, could you please help take a look? > Thanks > Anjali > Gentle ping again - Christian could you please help review? Anjali
On Thu, 1 Jun 2023 16:15:31 +0000 Anjali Kulkarni wrote: > >> I don't have sufficient knowledge to review that code, sorry :( > > > > Is there anyone who can please help review this code? > > Christian, could you please help take a look? > > Gentle ping again - Christian could you please help review? The code may have security implications, I really don't feel like I can be the sole reviewer. There's a bunch of experts working at Oracle, maybe you could get one of them to put their name on it? I can apply the patches, I just want to be sure I'm not the _only_ reviewer.
> On Jun 1, 2023, at 9:24 AM, Jakub Kicinski <kuba@kernel.org> wrote: > > On Thu, 1 Jun 2023 16:15:31 +0000 Anjali Kulkarni wrote: >>>> I don't have sufficient knowledge to review that code, sorry :( >>> >>> Is there anyone who can please help review this code? >>> Christian, could you please help take a look? >> >> Gentle ping again - Christian could you please help review? > > The code may have security implications, I really don't feel like I can > be the sole reviewer. There's a bunch of experts working at Oracle, > maybe you could get one of them to put their name on it? I can apply > the patches, I just want to be sure I'm not the _only_ reviewer. Thanks so much for your response. There is someone at Oracle who looked at this some time ago and is familiar enough with this to review the code - but he is not a kernel committer - he sends occasional patches upstream which get committed - would it be ok if he reviewed it along with you and then you could commit it? If you know of someone from Oracle who could also potentially review it, please let me know.
On Thu, 1 Jun 2023 16:34:08 +0000 Anjali Kulkarni wrote: > > The code may have security implications, I really don't feel like I can > > be the sole reviewer. There's a bunch of experts working at Oracle, > > maybe you could get one of them to put their name on it? I can apply > > the patches, I just want to be sure I'm not the _only_ reviewer. > > Thanks so much for your response. There is someone at Oracle who > looked at this some time ago and is familiar enough with this to > review the code - but he is not a kernel committer - he sends > occasional patches upstream which get committed - would it be ok if > he reviewed it along with you and then you could commit it? If you > know of someone from Oracle who could also potentially review it, > please let me know. I meant someone seasoned. IMHO one of the benefits of employing upstream experts for corporation like Oracle should be that you can lean on them for reviews: $ git log --format='%ae' --author='Oracle' --since='2 years ago' | sort | uniq -c | sort -rn 811 willy@infradead.org 312 rmk+kernel@armlinux.org.uk 91 Liam.Howlett@Oracle.com 60 vishal.moola@gmail.com $ git log --format='%ae' --author='@oracle.com' --since='2 years ago' | sort | uniq -c | sort -rn | head -10 451 chuck.lever@oracle.com 154 michael.christie@oracle.com 118 nick.alcock@oracle.com 71 martin.petersen@oracle.com 59 mike.kravetz@oracle.com 58 sidhartha.kumar@oracle.com 55 liam.howlett@oracle.com 53 anand.jain@oracle.com 32 dai.ngo@oracle.com 32 allison.henderson@oracle.com
> On Jun 1, 2023, at 9:43 AM, Jakub Kicinski <kuba@kernel.org> wrote: > > On Thu, 1 Jun 2023 16:34:08 +0000 Anjali Kulkarni wrote: >>> The code may have security implications, I really don't feel like I can >>> be the sole reviewer. There's a bunch of experts working at Oracle, >>> maybe you could get one of them to put their name on it? I can apply >>> the patches, I just want to be sure I'm not the _only_ reviewer. >> >> Thanks so much for your response. There is someone at Oracle who >> looked at this some time ago and is familiar enough with this to >> review the code - but he is not a kernel committer - he sends >> occasional patches upstream which get committed - would it be ok if >> he reviewed it along with you and then you could commit it? If you >> know of someone from Oracle who could also potentially review it, >> please let me know. > > I meant someone seasoned. IMHO one of the benefits of employing > upstream experts for corporation like Oracle should be that you > can lean on them for reviews: > > $ git log --format='%ae' --author='Oracle' --since='2 years ago' | sort | uniq -c | sort -rn > 811 willy@infradead.org > 312 rmk+kernel@armlinux.org.uk > 91 Liam.Howlett@Oracle.com > 60 vishal.moola@gmail.com > > $ git log --format='%ae' --author='@oracle.com' --since='2 years ago' | sort | uniq -c | sort -rn | head -10 > 451 chuck.lever@oracle.com > 154 michael.christie@oracle.com > 118 nick.alcock@oracle.com > 71 martin.petersen@oracle.com > 59 mike.kravetz@oracle.com > 58 sidhartha.kumar@oracle.com > 55 liam.howlett@oracle.com > 53 anand.jain@oracle.com > 32 dai.ngo@oracle.com > 32 allison.henderson@oracle.com Thanks, let me check. Anjali
diff --git a/include/linux/netlink.h b/include/linux/netlink.h index c43ac7690eca..866bbc5a4c8d 100644 --- a/include/linux/netlink.h +++ b/include/linux/netlink.h @@ -206,6 +206,11 @@ bool netlink_strict_get_check(struct sk_buff *skb); int netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32 portid, int nonblock); int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, __u32 portid, __u32 group, gfp_t allocation); +int netlink_broadcast_filtered(struct sock *ssk, struct sk_buff *skb, + __u32 portid, __u32 group, gfp_t allocation, + int (*filter)(struct sock *dsk, + struct sk_buff *skb, void *data), + void *filter_data); int netlink_set_err(struct sock *ssk, __u32 portid, __u32 group, int code); int netlink_register_notifier(struct notifier_block *nb); int netlink_unregister_notifier(struct notifier_block *nb); diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c index c64277659753..003c7e6ec9be 100644 --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -1432,6 +1432,8 @@ struct netlink_broadcast_data { int delivered; gfp_t allocation; struct sk_buff *skb, *skb2; + int (*tx_filter)(struct sock *dsk, struct sk_buff *skb, void *data); + void *tx_data; }; static void do_one_broadcast(struct sock *sk, @@ -1485,6 +1487,11 @@ static void do_one_broadcast(struct sock *sk, p->delivery_failure = 1; goto out; } + if (p->tx_filter && p->tx_filter(sk, p->skb2, p->tx_data)) { + kfree_skb(p->skb2); + p->skb2 = NULL; + goto out; + } if (sk_filter(sk, p->skb2)) { kfree_skb(p->skb2); p->skb2 = NULL; @@ -1507,8 +1514,12 @@ static void do_one_broadcast(struct sock *sk, sock_put(sk); } -int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 portid, - u32 group, gfp_t allocation) +int netlink_broadcast_filtered(struct sock *ssk, struct sk_buff *skb, + u32 portid, + u32 group, gfp_t allocation, + int (*filter)(struct sock *dsk, + struct sk_buff *skb, void *data), + void *filter_data) { struct net *net = sock_net(ssk); struct netlink_broadcast_data info; @@ -1527,6 +1538,8 @@ int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 portid, info.allocation = allocation; info.skb = skb; info.skb2 = NULL; + info.tx_filter = filter; + info.tx_data = filter_data; /* While we sleep in clone, do not allow to change socket list */ @@ -1552,6 +1565,14 @@ int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 portid, } return -ESRCH; } +EXPORT_SYMBOL(netlink_broadcast_filtered); + +int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 portid, + u32 group, gfp_t allocation) +{ + return netlink_broadcast_filtered(ssk, skb, portid, group, allocation, + NULL, NULL); +} EXPORT_SYMBOL(netlink_broadcast); struct netlink_set_err_data {