* Re: [PATCH] l2tp: Fix modalias of l2tp_ip
From: David Miller @ 2010-12-08 18:25 UTC (permalink / raw)
To: mmarek; +Cc: jchapman, netdev, linux-kernel
In-Reply-To: <1291639152-26608-1-git-send-email-mmarek@suse.cz>
From: Michal Marek <mmarek@suse.cz>
Date: Mon, 6 Dec 2010 13:39:12 +0100
> Using the SOCK_DGRAM enum results in
> "net-pf-2-proto-SOCK_DGRAM-type-115", so use the numeric value like it
> is done in net/dccp.
>
> Signed-off-by: Michal Marek <mmarek@suse.cz>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2] via-rhine: hardware VLAN support
From: David Miller @ 2010-12-08 18:24 UTC (permalink / raw)
To: rl; +Cc: netdev, jesse
In-Reply-To: <20101206105940.GA17817@core.hellgate.ch>
From: Roger Luethi <rl@hellgate.ch>
Date: Mon, 6 Dec 2010 11:59:40 +0100
> This patch adds VLAN hardware support for Rhine chips.
>
> The driver uses up to 3 additional bytes of buffer space when extracting
> 802.1Q headers; PKT_BUF_SZ should still be sufficient.
>
> The initial code was provided by David Lv. I reworked it to use standard
> kernel facilities. Coding style clean up mostly follows via-velocity.
>
> Adapted to new interface for VLAN acceleration (per request of Jesse Gross).
>
> Signed-off-by: David Lv <DavidLv@viatech.com.cn>
> Signed-off-by: Roger Luethi <rl@hellgate.ch>
Applied, thanks a lot Roger.
^ permalink raw reply
* Re: [PATCH v2] net/r8169: Remove the firmware of RTL8111D
From: David Miller @ 2010-12-08 18:20 UTC (permalink / raw)
To: maximlevitsky; +Cc: hayeswang, romieu, netdev, linux-kernel
In-Reply-To: <1291671494.30050.19.camel@maxim-laptop>
From: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Mon, 06 Dec 2010 23:38:14 +0200
> Hayes Wang, maybe you know who is responsible for DVB division in your
> company?
Are you completely kidding me?
Are you for real?
Please do not hijack a discussion about a networking patch to ask
questions like this. Start a new thread on the appropriate mailing
list to ask questions like this.
You aren't commenting on the patch, you aren't giving any kind of
feedback at all on this change, and on top of it YOU QUOTED THE
ENTIRE PATCH.
All of this gets logged into our patch tracking facilities in
patchwork, so now I have to sift through your crap just to review
and work on evaluating this change.
Please never do this ever again.
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: adding prefetchw() call
From: David Miller @ 2010-12-08 18:17 UTC (permalink / raw)
To: junchangwang
Cc: eric.dumazet, robert.olsson, john.r.fastabend, andy.shevchenko,
netdev
In-Reply-To: <20101206063349.GA6147@Desktop-Junchang>
From: Junchang Wang <junchangwang@gmail.com>
Date: Mon, 6 Dec 2010 14:33:52 +0800
>
> We know for sure pktgen is going to write skb->data right after
> *_alloc_skb, causing unnecessary cache misses.
>
> Idea is to add a prefetchw() call to prefetch the first cache line
> indicated by skb->data. On systems with Adjacent Cache Line Prefetch,
> it's probably two cache lines are prefetched.
>
> With this prefetch, pktgen on Intel SR1625 server with two E5530
> quad-core processors and a single ixgbe-based NIC went from 8.63Mpps
> to 9.03Mpps, with 4.6% improvement.
>
>
> Signed-off-by: Junchang Wang <junchangwang@gmail.com>
Your patch was corrupted by your email client, please fix this up
and resubmit.
^ permalink raw reply
* Re: [patch] econet: unlock on -EPERM path
From: David Miller @ 2010-12-08 18:14 UTC (permalink / raw)
To: error27; +Cc: netdev, philb, eric.dumazet, kernel-janitors
In-Reply-To: <20101207110138.GM10623@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Tue, 7 Dec 2010 14:01:38 +0300
> We need to do a mutex_unlock() and a put_dev() before returning.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Nelson Elhage beat you to this one, so I integrates his version.
Thanks.
^ permalink raw reply
* Re: [PATCH] econet: Do the correct cleanup after an unprivileged SIOCSIFADDR.
From: David Miller @ 2010-12-08 18:14 UTC (permalink / raw)
To: nelhage; +Cc: philb, netdev, stable
In-Reply-To: <1291589152-4640-1-git-send-email-nelhage@ksplice.com>
From: Nelson Elhage <nelhage@ksplice.com>
Date: Sun, 5 Dec 2010 17:45:52 -0500
> We need to drop the mutex and do a dev_put, so set an error code and break like
> the other paths, instead of returning directly.
>
> Cc: stable@kernel.org
> Signed-off-by: Nelson Elhage <nelhage@ksplice.com>
Applied, thanks Nelson.
^ permalink raw reply
* Re: [PATCH] net: RCU conversion of dev_getbyhwaddr() and arp_ioctl()
From: Eric Dumazet @ 2010-12-08 18:11 UTC (permalink / raw)
To: David Miller
Cc: maximlevitsky, linux1394-devel, stefanr, netdev, kuznet, jmorris,
kaber
In-Reply-To: <20101208.101035.226775926.davem@davemloft.net>
Le mercredi 08 décembre 2010 à 10:10 -0800, David Miller a écrit :
> I know about the conflict and will resolve it when I do a merge in
> the next hour or so.
>
> Don't worry about this.
Ah thats great, thanks !
^ permalink raw reply
* Re: [PATCH] atm: correct sysfs 'device' link creation and parent relationships
From: David Miller @ 2010-12-08 18:11 UTC (permalink / raw)
To: kay.sievers; +Cc: dcbw, netdev, duncan.sands, linux-usb, chas
In-Reply-To: <AANLkTikhkVPcibAH8cSRvZSLop=Ew19Tn=KtY7prkKUn@mail.gmail.com>
From: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue, 7 Dec 2010 08:35:53 +0100
> On Sun, Dec 5, 2010 at 23:17, Dan Williams <dcbw@redhat.com> wrote:
>> The ATM subsystem was incorrectly creating the 'device' link for ATM
>> nodes in sysfs. This led to incorrect device/parent relationships
>> exposed by sysfs and udev. Instead of rolling the 'device' link by hand
>> in the generic ATM code, pass each ATM driver's bus device down to the
>> sysfs code and let sysfs do this stuff correctly.
>
> Looks good to me.
I've applied this to net-2.6, thanks Dan.
^ permalink raw reply
* Re: [PATCH] net: RCU conversion of dev_getbyhwaddr() and arp_ioctl()
From: David Miller @ 2010-12-08 18:10 UTC (permalink / raw)
To: eric.dumazet
Cc: maximlevitsky, linux1394-devel, stefanr, netdev, kuznet, jmorris,
kaber
In-Reply-To: <1291831654.2883.66.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 08 Dec 2010 19:07:34 +0100
> Le mercredi 08 décembre 2010 à 10:05 -0800, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Sun, 05 Dec 2010 12:23:53 +0100
>>
>> > [PATCH] net: RCU conversion of dev_getbyhwaddr() and arp_ioctl()
>> >
>> > dev_getbyhwaddr() was called under RTNL.
>> >
>> > Rename it to dev_getbyhwaddr_rcu() and change all its caller to now use
>> > RCU locking instead of RTNL.
>> >
>> > Change arp_ioctl() to use RCU instead of RTNL locking.
>> >
>> > Note: this fix a dev refcount bug in llc
>> >
>> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>>
>> Applied, thanks Eric.
>
> Hmm, dont you want I resubmit it after the "llc: fix a device refcount
> imbalance" patch pulled from net-2.6 ?
>
> Sorry for the mess...
I know about the conflict and will resolve it when I do a merge in
the next hour or so.
Don't worry about this.
^ permalink raw reply
* Re: [PATCH] net: RCU conversion of dev_getbyhwaddr() and arp_ioctl()
From: Eric Dumazet @ 2010-12-08 18:07 UTC (permalink / raw)
To: David Miller
Cc: maximlevitsky, linux1394-devel, stefanr, netdev, kuznet, jmorris,
kaber
In-Reply-To: <20101208.100528.193703457.davem@davemloft.net>
Le mercredi 08 décembre 2010 à 10:05 -0800, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sun, 05 Dec 2010 12:23:53 +0100
>
> > [PATCH] net: RCU conversion of dev_getbyhwaddr() and arp_ioctl()
> >
> > dev_getbyhwaddr() was called under RTNL.
> >
> > Rename it to dev_getbyhwaddr_rcu() and change all its caller to now use
> > RCU locking instead of RTNL.
> >
> > Change arp_ioctl() to use RCU instead of RTNL locking.
> >
> > Note: this fix a dev refcount bug in llc
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied, thanks Eric.
Hmm, dont you want I resubmit it after the "llc: fix a device refcount
imbalance" patch pulled from net-2.6 ?
Sorry for the mess...
^ permalink raw reply
* Re: [PATCH] net: RCU conversion of dev_getbyhwaddr() and arp_ioctl()
From: David Miller @ 2010-12-08 18:05 UTC (permalink / raw)
To: eric.dumazet
Cc: maximlevitsky, linux1394-devel, stefanr, netdev, kuznet, jmorris,
kaber
In-Reply-To: <1291548233.2806.212.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 05 Dec 2010 12:23:53 +0100
> [PATCH] net: RCU conversion of dev_getbyhwaddr() and arp_ioctl()
>
> dev_getbyhwaddr() was called under RTNL.
>
> Rename it to dev_getbyhwaddr_rcu() and change all its caller to now use
> RCU locking instead of RTNL.
>
> Change arp_ioctl() to use RCU instead of RTNL locking.
>
> Note: this fix a dev refcount bug in llc
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] enic: Add ndo_set_rx_mode support for enic vnics
From: David Miller @ 2010-12-08 18:02 UTC (permalink / raw)
To: roprabhu; +Cc: netdev
In-Reply-To: <20101205062336.28056.72156.stgit@savbu-pc100.cisco.com>
From: Roopa Prabhu <roprabhu@cisco.com>
Date: Sat, 04 Dec 2010 22:23:36 -0800
> From: Roopa Prabhu <roprabhu@cisco.com>
>
> Add ndo_set_rx_mode support to register unicast and multicast address filters for enic vnics
>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>
> Signed-off-by: Christian Benvenuti <benve@cisco.com>
This patch does not apply to net-next-2.6, please respin this.
Thanks.
^ permalink raw reply
* Re: net-next-2.6 [PATCH 0/2] dccp: Policy-based packet dequeueing interface
From: David Miller @ 2010-12-08 18:01 UTC (permalink / raw)
To: gerrit; +Cc: dccp, netdev
In-Reply-To: <1291621444-5927-1-git-send-email-gerrit@erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Mon, 6 Dec 2010 08:44:02 +0100
> Hi Dave,
>
> please find attached a self-contained 2-patch set by Tomasz which adds an API
> to influence DCCP packet dequeueing. It evolved from discussions in 2008,
> adding and adds basic building blocks for sending congestion controlled
> multimedia packets that have a priority or a deadline attached to them.
>
> Occasionally people still make new suggestions for such an API, apparently
> overlooking the excellent work Tomasz has done and which has been in the
> test tree for two years.
>
> Patch #1: introduces the new policy-based packet dequeueing infrastructure.
> Patch #2: adds parameter (sanity) checking of cmsg qpolicy parameters.
>
> I have also placed this in into a fresh (today's) copy of net-next-2.6, on
>
> git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp']
>
> The set is fully bisectable.
Looks good, pulled, thanks a lot!
^ permalink raw reply
* Re: [PATCH net-2.6] llc: fix a device refcount imbalance
From: David Miller @ 2010-12-08 17:59 UTC (permalink / raw)
To: eric.dumazet
Cc: maximlevitsky, linux1394-devel, stefanr, netdev, kuznet, jmorris,
kaber, opurdila, stable
In-Reply-To: <1291550606.2806.237.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 05 Dec 2010 13:03:26 +0100
> [PATCH net-2.6] llc: fix a device refcount imbalance
>
> commit abf9d537fea225 (llc: add support for SO_BINDTODEVICE) added one
> refcount imbalance in llc_ui_bind(), because dev_getbyhwaddr() doesnt
> take a reference on device, while dev_get_by_index() does.
>
> Fix this using RCU locking. And since an RCU conversion will be done for
> 2.6.38 for dev_getbyhwaddr(), put the rcu_read_lock/unlock exactly at
> their final place.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] net/9p/protocol.c: Remove duplicated macros.
From: David Miller @ 2010-12-08 17:56 UTC (permalink / raw)
To: tfransosi
Cc: linux-kernel, ericvh, sripathik, aneesh.kumar, jvrao, akpm,
netdev
In-Reply-To: <3300e3823b702d35658175ff6379a4f77fa9a5b0.1291512089.git.tfransosi@gmail.com>
From: Thiago Farina <tfransosi@gmail.com>
Date: Sat, 4 Dec 2010 23:22:46 -0200
> Use the macros already provided by kernel.h file.
>
> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
I'll apply this, thanks!
^ permalink raw reply
* Re: ctnetlink loop
From: David Miller @ 2010-12-08 17:50 UTC (permalink / raw)
To: holger; +Cc: netfilter-devel, netdev, pablo
Holger, this replay -EAGAIN loop in nfnetlink processing was added by
Pablo to handle module loading properly, I think. So it might not be
safe to just unilaterally remove it.
See:
commit e6a7d3c04f8fe49099521e6dc9a46b0272381f2f
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Tue Oct 14 11:58:31 2008 -0700
netfilter: ctnetlink: remove bogus module dependency between ctnetlink and nf_nat
This patch removes the module dependency between ctnetlink and
nf_nat by means of an indirect call that is initialized when
nf_nat is loaded. Now, nf_conntrack_netlink only requires
nf_conntrack and nfnetlink.
This patch puts nfnetlink_parse_nat_setup_hook into the
nf_conntrack_core to avoid dependencies between ctnetlink,
nf_conntrack_ipv4 and nf_conntrack_ipv6.
This patch also introduces the function ctnetlink_change_nat
that is only invoked from the creation path. Actually, the
nat handling cannot be invoked from the update path since
this is not allowed. By introducing this function, we remove
the useless nat handling in the update path and we avoid
deadlock-prone code.
This patch also adds the required EAGAIN logic for nfnetlink.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/include/linux/netfilter/nfnetlink.h b/include/linux/netfilter/nfnetlink.h
index 0d8424f..7d8e045 100644
--- a/include/linux/netfilter/nfnetlink.h
+++ b/include/linux/netfilter/nfnetlink.h
@@ -78,6 +78,9 @@ extern int nfnetlink_send(struct sk_buff *skb, u32 pid, unsigned group,
int echo);
extern int nfnetlink_unicast(struct sk_buff *skb, u_int32_t pid, int flags);
+extern void nfnl_lock(void);
+extern void nfnl_unlock(void);
+
#define MODULE_ALIAS_NFNL_SUBSYS(subsys) \
MODULE_ALIAS("nfnetlink-subsys-" __stringify(subsys))
diff --git a/include/net/netfilter/nf_nat_core.h b/include/net/netfilter/nf_nat_core.h
index f29eeb9..5868406 100644
--- a/include/net/netfilter/nf_nat_core.h
+++ b/include/net/netfilter/nf_nat_core.h
@@ -25,4 +25,12 @@ static inline int nf_nat_initialized(struct nf_conn *ct,
else
return test_bit(IPS_DST_NAT_DONE_BIT, &ct->status);
}
+
+struct nlattr;
+
+extern int
+(*nfnetlink_parse_nat_setup_hook)(struct nf_conn *ct,
+ enum nf_nat_manip_type manip,
+ struct nlattr *attr);
+
#endif /* _NF_NAT_CORE_H */
diff --git a/net/ipv4/netfilter/nf_nat_core.c b/net/ipv4/netfilter/nf_nat_core.c
index 2ac9eaf..a65cf69 100644
--- a/net/ipv4/netfilter/nf_nat_core.c
+++ b/net/ipv4/netfilter/nf_nat_core.c
@@ -584,6 +584,98 @@ static struct nf_ct_ext_type nat_extend __read_mostly = {
.flags = NF_CT_EXT_F_PREALLOC,
};
+#if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE)
+
+#include <linux/netfilter/nfnetlink.h>
+#include <linux/netfilter/nfnetlink_conntrack.h>
+
+static const struct nla_policy protonat_nla_policy[CTA_PROTONAT_MAX+1] = {
+ [CTA_PROTONAT_PORT_MIN] = { .type = NLA_U16 },
+ [CTA_PROTONAT_PORT_MAX] = { .type = NLA_U16 },
+};
+
+static int nfnetlink_parse_nat_proto(struct nlattr *attr,
+ const struct nf_conn *ct,
+ struct nf_nat_range *range)
+{
+ struct nlattr *tb[CTA_PROTONAT_MAX+1];
+ const struct nf_nat_protocol *npt;
+ int err;
+
+ err = nla_parse_nested(tb, CTA_PROTONAT_MAX, attr, protonat_nla_policy);
+ if (err < 0)
+ return err;
+
+ npt = nf_nat_proto_find_get(nf_ct_protonum(ct));
+ if (npt->nlattr_to_range)
+ err = npt->nlattr_to_range(tb, range);
+ nf_nat_proto_put(npt);
+ return err;
+}
+
+static const struct nla_policy nat_nla_policy[CTA_NAT_MAX+1] = {
+ [CTA_NAT_MINIP] = { .type = NLA_U32 },
+ [CTA_NAT_MAXIP] = { .type = NLA_U32 },
+};
+
+static int
+nfnetlink_parse_nat(struct nlattr *nat,
+ const struct nf_conn *ct, struct nf_nat_range *range)
+{
+ struct nlattr *tb[CTA_NAT_MAX+1];
+ int err;
+
+ memset(range, 0, sizeof(*range));
+
+ err = nla_parse_nested(tb, CTA_NAT_MAX, nat, nat_nla_policy);
+ if (err < 0)
+ return err;
+
+ if (tb[CTA_NAT_MINIP])
+ range->min_ip = nla_get_be32(tb[CTA_NAT_MINIP]);
+
+ if (!tb[CTA_NAT_MAXIP])
+ range->max_ip = range->min_ip;
+ else
+ range->max_ip = nla_get_be32(tb[CTA_NAT_MAXIP]);
+
+ if (range->min_ip)
+ range->flags |= IP_NAT_RANGE_MAP_IPS;
+
+ if (!tb[CTA_NAT_PROTO])
+ return 0;
+
+ err = nfnetlink_parse_nat_proto(tb[CTA_NAT_PROTO], ct, range);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static int
+nfnetlink_parse_nat_setup(struct nf_conn *ct,
+ enum nf_nat_manip_type manip,
+ struct nlattr *attr)
+{
+ struct nf_nat_range range;
+
+ if (nfnetlink_parse_nat(attr, ct, &range) < 0)
+ return -EINVAL;
+ if (nf_nat_initialized(ct, manip))
+ return -EEXIST;
+
+ return nf_nat_setup_info(ct, &range, manip);
+}
+#else
+static int
+nfnetlink_parse_nat_setup(struct nf_conn *ct,
+ enum nf_nat_manip_type manip,
+ struct nlattr *attr)
+{
+ return -EOPNOTSUPP;
+}
+#endif
+
static int __net_init nf_nat_net_init(struct net *net)
{
net->ipv4.nat_bysource = nf_ct_alloc_hashtable(&nf_nat_htable_size,
@@ -654,6 +746,9 @@ static int __init nf_nat_init(void)
BUG_ON(nf_nat_seq_adjust_hook != NULL);
rcu_assign_pointer(nf_nat_seq_adjust_hook, nf_nat_seq_adjust);
+ BUG_ON(nfnetlink_parse_nat_setup_hook != NULL);
+ rcu_assign_pointer(nfnetlink_parse_nat_setup_hook,
+ nfnetlink_parse_nat_setup);
return 0;
cleanup_extend:
@@ -667,10 +762,12 @@ static void __exit nf_nat_cleanup(void)
nf_ct_l3proto_put(l3proto);
nf_ct_extend_unregister(&nat_extend);
rcu_assign_pointer(nf_nat_seq_adjust_hook, NULL);
+ rcu_assign_pointer(nfnetlink_parse_nat_setup_hook, NULL);
synchronize_net();
}
MODULE_LICENSE("GPL");
+MODULE_ALIAS("nf-nat-ipv4");
module_init(nf_nat_init);
module_exit(nf_nat_cleanup);
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 27de3c7..622d7c6 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -38,9 +38,16 @@
#include <net/netfilter/nf_conntrack_core.h>
#include <net/netfilter/nf_conntrack_extend.h>
#include <net/netfilter/nf_conntrack_acct.h>
+#include <net/netfilter/nf_nat.h>
#define NF_CONNTRACK_VERSION "0.5.0"
+unsigned int
+(*nfnetlink_parse_nat_setup_hook)(struct nf_conn *ct,
+ enum nf_nat_manip_type manip,
+ struct nlattr *attr) __read_mostly;
+EXPORT_SYMBOL_GPL(nfnetlink_parse_nat_setup_hook);
+
DEFINE_SPINLOCK(nf_conntrack_lock);
EXPORT_SYMBOL_GPL(nf_conntrack_lock);
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index cadfd15..08e82d6 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -689,71 +689,6 @@ ctnetlink_parse_tuple(struct nlattr *cda[], struct nf_conntrack_tuple *tuple,
return 0;
}
-#ifdef CONFIG_NF_NAT_NEEDED
-static const struct nla_policy protonat_nla_policy[CTA_PROTONAT_MAX+1] = {
- [CTA_PROTONAT_PORT_MIN] = { .type = NLA_U16 },
- [CTA_PROTONAT_PORT_MAX] = { .type = NLA_U16 },
-};
-
-static int nfnetlink_parse_nat_proto(struct nlattr *attr,
- const struct nf_conn *ct,
- struct nf_nat_range *range)
-{
- struct nlattr *tb[CTA_PROTONAT_MAX+1];
- const struct nf_nat_protocol *npt;
- int err;
-
- err = nla_parse_nested(tb, CTA_PROTONAT_MAX, attr, protonat_nla_policy);
- if (err < 0)
- return err;
-
- npt = nf_nat_proto_find_get(nf_ct_protonum(ct));
- if (npt->nlattr_to_range)
- err = npt->nlattr_to_range(tb, range);
- nf_nat_proto_put(npt);
- return err;
-}
-
-static const struct nla_policy nat_nla_policy[CTA_NAT_MAX+1] = {
- [CTA_NAT_MINIP] = { .type = NLA_U32 },
- [CTA_NAT_MAXIP] = { .type = NLA_U32 },
-};
-
-static inline int
-nfnetlink_parse_nat(struct nlattr *nat,
- const struct nf_conn *ct, struct nf_nat_range *range)
-{
- struct nlattr *tb[CTA_NAT_MAX+1];
- int err;
-
- memset(range, 0, sizeof(*range));
-
- err = nla_parse_nested(tb, CTA_NAT_MAX, nat, nat_nla_policy);
- if (err < 0)
- return err;
-
- if (tb[CTA_NAT_MINIP])
- range->min_ip = nla_get_be32(tb[CTA_NAT_MINIP]);
-
- if (!tb[CTA_NAT_MAXIP])
- range->max_ip = range->min_ip;
- else
- range->max_ip = nla_get_be32(tb[CTA_NAT_MAXIP]);
-
- if (range->min_ip)
- range->flags |= IP_NAT_RANGE_MAP_IPS;
-
- if (!tb[CTA_NAT_PROTO])
- return 0;
-
- err = nfnetlink_parse_nat_proto(tb[CTA_NAT_PROTO], ct, range);
- if (err < 0)
- return err;
-
- return 0;
-}
-#endif
-
static inline int
ctnetlink_parse_help(struct nlattr *attr, char **helper_name)
{
@@ -879,6 +814,34 @@ out:
}
static int
+ctnetlink_parse_nat_setup(struct nf_conn *ct,
+ enum nf_nat_manip_type manip,
+ struct nlattr *attr)
+{
+ typeof(nfnetlink_parse_nat_setup_hook) parse_nat_setup;
+
+ parse_nat_setup = rcu_dereference(nfnetlink_parse_nat_setup_hook);
+ if (!parse_nat_setup) {
+#ifdef CONFIG_KMOD
+ rcu_read_unlock();
+ nfnl_unlock();
+ if (request_module("nf-nat-ipv4") < 0) {
+ nfnl_lock();
+ rcu_read_lock();
+ return -EOPNOTSUPP;
+ }
+ nfnl_lock();
+ rcu_read_lock();
+ if (nfnetlink_parse_nat_setup_hook)
+ return -EAGAIN;
+#endif
+ return -EOPNOTSUPP;
+ }
+
+ return parse_nat_setup(ct, manip, attr);
+}
+
+static int
ctnetlink_change_status(struct nf_conn *ct, struct nlattr *cda[])
{
unsigned long d;
@@ -897,31 +860,6 @@ ctnetlink_change_status(struct nf_conn *ct, struct nlattr *cda[])
/* ASSURED bit can only be set */
return -EBUSY;
- if (cda[CTA_NAT_SRC] || cda[CTA_NAT_DST]) {
-#ifndef CONFIG_NF_NAT_NEEDED
- return -EOPNOTSUPP;
-#else
- struct nf_nat_range range;
-
- if (cda[CTA_NAT_DST]) {
- if (nfnetlink_parse_nat(cda[CTA_NAT_DST], ct,
- &range) < 0)
- return -EINVAL;
- if (nf_nat_initialized(ct, IP_NAT_MANIP_DST))
- return -EEXIST;
- nf_nat_setup_info(ct, &range, IP_NAT_MANIP_DST);
- }
- if (cda[CTA_NAT_SRC]) {
- if (nfnetlink_parse_nat(cda[CTA_NAT_SRC], ct,
- &range) < 0)
- return -EINVAL;
- if (nf_nat_initialized(ct, IP_NAT_MANIP_SRC))
- return -EEXIST;
- nf_nat_setup_info(ct, &range, IP_NAT_MANIP_SRC);
- }
-#endif
- }
-
/* Be careful here, modifying NAT bits can screw up things,
* so don't let users modify them directly if they don't pass
* nf_nat_range. */
@@ -929,6 +867,31 @@ ctnetlink_change_status(struct nf_conn *ct, struct nlattr *cda[])
return 0;
}
+static int
+ctnetlink_change_nat(struct nf_conn *ct, struct nlattr *cda[])
+{
+#ifdef CONFIG_NF_NAT_NEEDED
+ int ret;
+
+ if (cda[CTA_NAT_DST]) {
+ ret = ctnetlink_parse_nat_setup(ct,
+ IP_NAT_MANIP_DST,
+ cda[CTA_NAT_DST]);
+ if (ret < 0)
+ return ret;
+ }
+ if (cda[CTA_NAT_SRC]) {
+ ret = ctnetlink_parse_nat_setup(ct,
+ IP_NAT_MANIP_SRC,
+ cda[CTA_NAT_SRC]);
+ if (ret < 0)
+ return ret;
+ }
+ return 0;
+#else
+ return -EOPNOTSUPP;
+#endif
+}
static inline int
ctnetlink_change_helper(struct nf_conn *ct, struct nlattr *cda[])
@@ -1157,6 +1120,14 @@ ctnetlink_create_conntrack(struct nlattr *cda[],
}
}
+ if (cda[CTA_NAT_SRC] || cda[CTA_NAT_DST]) {
+ err = ctnetlink_change_nat(ct, cda);
+ if (err < 0) {
+ rcu_read_unlock();
+ goto err;
+ }
+ }
+
if (cda[CTA_PROTOINFO]) {
err = ctnetlink_change_protoinfo(ct, cda);
if (err < 0) {
diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
index b75c9c4..4739f9f 100644
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -44,15 +44,17 @@ static struct sock *nfnl = NULL;
static const struct nfnetlink_subsystem *subsys_table[NFNL_SUBSYS_COUNT];
static DEFINE_MUTEX(nfnl_mutex);
-static inline void nfnl_lock(void)
+void nfnl_lock(void)
{
mutex_lock(&nfnl_mutex);
}
+EXPORT_SYMBOL_GPL(nfnl_lock);
-static inline void nfnl_unlock(void)
+void nfnl_unlock(void)
{
mutex_unlock(&nfnl_mutex);
}
+EXPORT_SYMBOL_GPL(nfnl_unlock);
int nfnetlink_subsys_register(const struct nfnetlink_subsystem *n)
{
@@ -132,6 +134,7 @@ static int nfnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
return 0;
type = nlh->nlmsg_type;
+replay:
ss = nfnetlink_get_subsys(type);
if (!ss) {
#ifdef CONFIG_KMOD
@@ -165,7 +168,10 @@ static int nfnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
} else
return -EINVAL;
- return nc->call(nfnl, skb, nlh, cda);
+ err = nc->call(nfnl, skb, nlh, cda);
+ if (err == -EAGAIN)
+ goto replay;
+ return err;
}
}
^ permalink raw reply related
* Re: [PATCH net-2.6] ifb: goto resched directly if error happens and dp->tq isn't empty
From: David Miller @ 2010-12-08 17:45 UTC (permalink / raw)
To: hadi; +Cc: xiaosuo, jarkao2, netdev
In-Reply-To: <1291559144.2159.682.camel@mojatatu>
From: jamal <hadi@cyberus.ca>
Date: Sun, 05 Dec 2010 09:25:44 -0500
> On Sun, 2010-12-05 at 08:09 +0800, Changli Gao wrote:
>> If we break the loop when there are still skbs in tq and no skb in
>> rq, the skbs will be left in txq until new skbs are enqueued into rq.
>> In rare cases, no new skb is queued, then these skbs will stay in rq
>> forever.
>>
>> After this patch, if tq isn't empty when we break the loop, we goto
>> resched directly.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
>
> Dave, this goes to stable as well.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] TCP: Bug fix in initialization of receive window.
From: David Miller @ 2010-12-08 17:41 UTC (permalink / raw)
To: nanditad; +Cc: chavey, ycheng, netdev
In-Reply-To: <1291419224-20853-1-git-send-email-nanditad@google.com>
From: Nandita Dukkipati <nanditad@google.com>
Date: Fri, 3 Dec 2010 15:33:44 -0800
> The bug has to do with boundary checks on the initial receive window.
> If the initial receive window falls between init_cwnd and the
> receive window specified by the user, the initial window is incorrectly
> brought down to init_cwnd. The correct behavior is to allow it to
> remain unchanged.
>
> Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6] cxgb4: fix MAC address hash filter
From: David Miller @ 2010-12-08 17:36 UTC (permalink / raw)
To: dm; +Cc: netdev
In-Reply-To: <1291408744-2392-1-git-send-email-dm@chelsio.com>
From: Dimitris Michailidis <dm@chelsio.com>
Date: Fri, 3 Dec 2010 12:39:04 -0800
> Fix the calculation of the inexact hash-based MAC address filter.
> It's 64 bits but current code is missing a ULL. Results in filtering out
> some legitimate packets.
>
> Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Vladislav Zolotarov @ 2010-12-08 17:31 UTC (permalink / raw)
To: David Miller
Cc: bhutchings@solarflare.com, dm@chelsio.com,
peter.p.waskiewicz.jr@intel.com, netdev@vger.kernel.org
In-Reply-To: <20101208.083921.71108761.davem@davemloft.net>
> > I also agree with Dimitris: what we have here is an offload of some
> > Netfilter functionality to HW. Regardless the HW implementation (TCAM or
> > not) if it's allowed to configure more than one rule for the same
> > protocol the ordering of filtering rules is important: for instance if u
> > change the order of applying the rules in the example below the result
> > of the filtering for the traffic with both VLAN 4 and destination port
> > 3000 will be different.
>
> It's not the same, this whole ordering thing you expect in netfilter
> land is simply not present in these hardware implementations.
>
> The hardware does a parallel TCAM match lookup, and whatever matches
> is used.
So, u say that in scope of a single protocol all rules create a set
which ordering is a vendor specific and the same configuration of
n-tuple rules may generate different results for the same traffic on
NICs from different vendors? Don't u think it's confusing from the user
point of view? ;)
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: David Miller @ 2010-12-08 17:31 UTC (permalink / raw)
To: bhutchings; +Cc: vladz, dm, peter.p.waskiewicz.jr, netdev
In-Reply-To: <1291829364.2560.24.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 08 Dec 2010 17:29:24 +0000
> I think the interfaces are actually somewhat more flexible than any of
> the current implementations.
Yeah you're probably right.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 17:29 UTC (permalink / raw)
To: David Miller; +Cc: vladz, dm, peter.p.waskiewicz.jr, netdev
In-Reply-To: <20101208.083921.71108761.davem@davemloft.net>
On Wed, 2010-12-08 at 08:39 -0800, David Miller wrote:
> From: "Vladislav Zolotarov" <vladz@broadcom.com>
> Date: Wed, 8 Dec 2010 18:24:03 +0200
>
> > I also agree with Dimitris: what we have here is an offload of some
> > Netfilter functionality to HW. Regardless the HW implementation (TCAM or
> > not) if it's allowed to configure more than one rule for the same
> > protocol the ordering of filtering rules is important: for instance if u
> > change the order of applying the rules in the example below the result
> > of the filtering for the traffic with both VLAN 4 and destination port
> > 3000 will be different.
>
> It's not the same, this whole ordering thing you expect in netfilter
> land is simply not present in these hardware implementations.
>
> The hardware does a parallel TCAM match lookup, and whatever matches
> is used.
I think the match with the lowest index wins, which is why it's possible
to specify the rule's index (location) with ETHTOOL_SRXCLSRLINS and why
Peter defined new commands without that for use with the ixgbe driver.
> Some hardware does link-level protocol lookups first, then L3/L4 later
> in the RX path right before computing the hash and selecting an RX
> queue.
>
> There really is no ordering available, so let's not pretend it can be
> used "just like" netfilter rules.
>
> As per the difference between the various ethtool facilities, this
> just represents the fact that whats available to offload differs
> per device. The best we can do is encapsulate commonality as best
> as we can, but each interface essentially represents what one
> major chipset provides.
I think the interfaces are actually somewhat more flexible than any of
the current implementations.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 17:22 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291825443.31064.193.camel@lb-tlvb-vladz>
On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
> > > It's a bit worse than that. Currently one can only append filters, not
> > > insert at a given position, as ethtool_rx_ntuple doesn't have an index
> > > field. For devices that use TCAMs, where position matters, it's quite an
> > > obstacle. It also means one cannot modify an existing filter by specifying
> > > a new filter for the same index.
> >
> > It looks like drivers for devices that use TCAMs should implement the
> > RXNFC interface instead.
> >
>
> Ben, from ethtool manpage it sounds like RXNFC option defines the way
> the RSS hash should be calculated, while SRXNTUPLE is meant to control
> the destination Rx queue for a stream specified by a filter/filters.
By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
> The
> semantics for a specification of the steam is also quite different. For
> instance, how do u define a rule to drop all packets with source IP
> address 192.168.10.200 by means of RXNFC?
Something like this, I think:
struct ethtool_rxnfc insert_rule = {
.cmd = ETHTOOL_SRXCLSRLINS,
.flow_type = IP_USER_SPEC,
.fs = {
.flow_type = IP_USER_SPEC,
.h_u.usr_ip4_spec = {
.ip4src = inet_aton("192.168.10.200"),
.ip_ver = ETH_RX_NFC_IP4
},
.m_u.usr_ip4_spec = {
.ip4dst = 0xffffffff,
.l4_4_bytes = 0xffffffff,
.tos = 0xff,
.proto = 0xff
},
.ring_cookie = RX_CLS_FLOW_DISC,
.location = 0,
}
};
[...]
> I also agree with Dimitris: what we have here is an offload of some
> Netfilter functionality to HW. Regardless the HW implementation (TCAM or
> not) if it's allowed to configure more than one rule for the same
> protocol the ordering of filtering rules is important: for instance if u
> change the order of applying the rules in the example below the result
> of the filtering for the traffic with both VLAN 4 and destination port
> 3000 will be different.
Our hardware (and, I suspect, the ixgbe hardware) has hash tables for
specific types of matching. There is some control of precedence between
different types of match, but that's all.
> ethtool -U ethX flow-type tcp4 vlan 4 action 0
> ethtool -U ethX flow-type tcp4 dst-port 3000 action 3
>
> By the way it's also unclear from the ethtool man page if it's allowed
> to configure more than one rule for the same protocol. If it's not then
> the above example is void... ;)
It's allowed, but precedence is unspecified.
> However, if we want to define a proper
> filtering interface I think we shouldn't restrict the driver
> implementation from defining a set of rules for the same protocol,
> allowing not to though.
>
> So, I think that attaching an index to each rule could be a good idea -
> this would allow us both inserting rules at the desired positions in the
> filtering rule table and editing the existing rules.
This really sounds like the RXNFC interface.
> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
> last in general may override the decision made based on the hash result.
> So, it sounds like applying rules of SRXNTUPLE should come before
> applying the RSS logic and only if there was no match RSS should be
> applied to that frame. Do I get it right?
That's right.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: rndis gadget: Inconsistent locking
From: Michał Nazarewicz @ 2010-12-08 17:15 UTC (permalink / raw)
To: linux-usb, netdev, Neil Jones
In-Reply-To: <AANLkTi==UqNNzokLcLWDpjM0cqM6aXjppsi4p6ogMAqX@mail.gmail.com>
On Wed, 08 Dec 2010 16:11:30 +0100, Neil Jones <neiljay@gmail.com> wrote:
> Im getting another lockdep warning when using the RNDIS gadget:
>
> WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
> Modules linked in: g_ether
>
> Call trace:
> [<40003bf8>] _show_stack+0x68/0x7c
> [<40003c20>] _dump_stack+0x14/0x28
> [<40013c3c>] _warn_slowpath_common+0x5c/0x7c
> [<40013c74>] _warn_slowpath_null+0x18/0x2c
> [<4001b17c>] ___local_bh_disable+0xc0/0xd0
> [<4001b1a0>] _local_bh_disable+0x14/0x28
> [<402e57f8>] __raw_spin_lock_bh+0x18/0x54
> [<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
> [<402580c4>] _dev_get_stats+0xb8/0xc0
> [<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
> [<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
> [<401d66fc>] _dwc_otg_request_done+0xd8/0x220
> [<401d928c>] _ep0_complete_request+0x3f4/0x578
> [<401d95bc>] _handle_ep0+0x1ac/0x146c
> [<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
> [<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
> [<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
> [<40054cf4>] _handle_IRQ_event+0x4c/0x184
> [<40057b4c>] _handle_level_irq+0xac/0x15c
> [<4000b204>] _metag_soc_irq_demux+0xac/0xb4
> [<40002dd4>] _do_IRQ+0x4c/0x78
> [<40004000>] _trigger_handler+0x38/0xac
> [<40000b18>] ___TBIBoingVec+0xc/0x10
> [<40003588>] _cpu_idle+0x54/0x78
>
> no locks held by swapper/0.
> ---[ end trace 77ac3cfee0ae5b25 ]---
Known problem.
> It looks like we are calling spin_lock_bh in the completion function
> which is running in hard_irq, I think the driver should defer handling
> this msg (and maybe all requests) to a workqueue?
Does this help: <https://patchwork.kernel.org/patch/195562/>?
--
Best regards, _ _
| Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o
| Computer Science, Michał "mina86" Nazarewicz (o o)
+----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo--
^ permalink raw reply
* Re: [PATCH 0/2] New jhash function
From: David Miller @ 2010-12-08 17:09 UTC (permalink / raw)
To: kadlec; +Cc: linux-kernel, netdev, netfilter-devel, torvalds, rusty
In-Reply-To: <1291379941-31565-1-git-send-email-kadlec@blackhole.kfki.hu>
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date: Fri, 3 Dec 2010 13:38:59 +0100
> The current jhash.h implements the lookup2() hash function by Bob Jenkins.
> However, lookup2() is outdated as Bob wrote a new hash function called
> lookup3(). There is a longer comparison of those two and other hash
> functions at http://burtleburtle.net/bob/hash/doobs.html.
>
> Please consider applying the following patches.
Patch #1 is already in the net-next-2.6 tree, and as long as there are
no major objections to the general crowd (including Rusty et al.) I am
happy to put patch #2 into my tree as well.
Rusty, does the current version of patch #2 look good to you?
Thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox