* Re: [PATCH 00/05] ipv6: RFC4214 Support
From: David Miller @ 2007-11-07 5:37 UTC (permalink / raw)
To: dlstevens; +Cc: Fred.L.Templin, netdev, netdev-owner
In-Reply-To: <OF2BBF1458.DA94A99E-ON8825738C.001CC740-8825738C.001DC134@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Tue, 6 Nov 2007 21:26:15 -0800
> Last I heard, there are Intellectual Property claims with ISATAP,
> which is why the RFC is not standards track and which makes it
> effectively a proprietary protocol.
>
> Unless that's been resolved, I think the claim by the IP owner is
> that it can't be distributed without a license from them. So, maybe
> not worth the effort for an experimental RFC.
If this is the case, I agree, we cannot include ISATAP
support in the kernel.
^ permalink raw reply
* Re: [PATCH 00/05] ipv6: RFC4214 Support
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-11-07 5:55 UTC (permalink / raw)
To: davem, Fred.L.Templin; +Cc: dlstevens, netdev, yoshfuji
In-Reply-To: <20071106.213750.91637349.davem@davemloft.net>
In article <20071106.213750.91637349.davem@davemloft.net> (at Tue, 06 Nov 2007 21:37:50 -0800 (PST)), David Miller <davem@davemloft.net> says:
> From: David Stevens <dlstevens@us.ibm.com>
> Date: Tue, 6 Nov 2007 21:26:15 -0800
>
> > Last I heard, there are Intellectual Property claims with ISATAP,
> > which is why the RFC is not standards track and which makes it
> > effectively a proprietary protocol.
> >
> > Unless that's been resolved, I think the claim by the IP owner is
> > that it can't be distributed without a license from them. So, maybe
> > not worth the effort for an experimental RFC.
>
> If this is the case, I agree, we cannot include ISATAP
> support in the kernel.
I guess license is no longer required for implementers of ISATAP.
Is it right, Fred?
https://datatracker.ietf.org/ipr/550/
--yoshfuji
^ permalink raw reply
* Re: [PATCH 00/05] ipv6: RFC4214 Support
From: David Stevens @ 2007-11-07 6:07 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明
Cc: davem, Fred.L.Templin, netdev, netdev-owner, yoshfuji
In-Reply-To: <20071107.145550.50882731.yoshfuji@linux-ipv6.org>
> I guess license is no longer required for implementers of ISATAP.
> Is it right, Fred?
>
> https://datatracker.ietf.org/ipr/550/
Does this also allow license-free redistribution?
I'm certainly no lawyer, but I don't see the point of
having a patent that doesn't restrict *something*. :-)
+-DLS
^ permalink raw reply
* Re: [PATCH 00/05] ipv6: RFC4214 Support
From: David Miller @ 2007-11-07 6:37 UTC (permalink / raw)
To: dlstevens; +Cc: yoshfuji, Fred.L.Templin, netdev, netdev-owner
In-Reply-To: <OF6A8C8B34.85D1FAD8-ON8825738C.00215308-8825738C.00218D8F@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Tue, 6 Nov 2007 22:07:44 -0800
> > I guess license is no longer required for implementers of ISATAP.
> > Is it right, Fred?
> >
> > https://datatracker.ietf.org/ipr/550/
>
> Does this also allow license-free redistribution?
>
> I'm certainly no lawyer, but I don't see the point of
> having a patent that doesn't restrict *something*. :-)
That is my interpretation as well. It allows
license free implementation, but not distribution
of said implementation.
^ permalink raw reply
* Re: [PATCH 00/05] ipv6: RFC4214 Support
From: Pekka Savola @ 2007-11-07 7:03 UTC (permalink / raw)
To: David Miller; +Cc: dlstevens, yoshfuji, Fred.L.Templin, netdev
In-Reply-To: <20071106.223705.246628214.davem@davemloft.net>
On Tue, 6 Nov 2007, David Miller wrote:
> From: David Stevens <dlstevens@us.ibm.com>
> Date: Tue, 6 Nov 2007 22:07:44 -0800
>
>>> I guess license is no longer required for implementers of ISATAP.
>>> Is it right, Fred?
>>>
>>> https://datatracker.ietf.org/ipr/550/
>>
>> Does this also allow license-free redistribution?
>>
>> I'm certainly no lawyer, but I don't see the point of
>> having a patent that doesn't restrict *something*. :-)
DavidS, the history here is that first the IPR holder did not grant
license-free implementation. After considerable time (and I suspect
energy spent by Fred), the company was convinced that license-free
implementation did not hurt their interests and they were willing to
give it away on this specific instance. I'm not sure if you should
attribute to hidden agendas what you can explain by "doing the right
thing" (granted, very few companies do this which may make it suspect,
but still..).
> That is my interpretation as well. It allows license free
> implementation, but not distribution of said implementation.
This may be a fine point. When submitting the IPR notice, the IPR
holder is asked whether it can be implemented without a license. No
questions about redistribution are asked -- maybe nobody thought that
asking that would be necessary if a positive answer is received on the
first one. I'd guess that the owner that grants license-free
implementation would also be fine with license-free (re-)distribution.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
^ permalink raw reply
* Re: [PATCH] Compact some ifdefs in the fib code
From: David Miller @ 2007-11-07 7:34 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4718BB4A.7020105@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Fri, 19 Oct 2007 18:12:26 +0400
> There are places that check for CONFIG_IP_MULTIPLE_TABLES
> twice in the same file, but the internals of these #ifdefs
> can be merged.
>
> As a side effect - remove one ifdef from inside a function.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks!
^ permalink raw reply
* Re: [2.6 patch] unexport softnet_data
From: David Miller @ 2007-11-07 7:41 UTC (permalink / raw)
To: shannon.nelson
Cc: bunk, shemminger, netdev, christopher.leech, dan.j.williams
In-Reply-To: <BAE9DCEF64577A439B3A37F36F9B691C034CC519@orsmsx418.amr.corp.intel.com>
From: "Nelson, Shannon" <shannon.nelson@intel.com>
Date: Fri, 26 Oct 2007 08:38:55 -0700
> There is no creation of a pinned_list yet in this path, so I don't think
> this would do us much good.
The pinned list is created in the generic net/ipv4/tcp.c code, not in
the address family specific code.
So your comments do not apply as a reason for this patch to not go in.
My patch has been in Linus's tree for weeks, and until you show me a
real reason why the check shouldn't be there in the ipv6 path, it's
staying.
^ permalink raw reply
* Re: [2.6 patch] always export sysctl_{r,w}mem_max
From: David Miller @ 2007-11-07 7:50 UTC (permalink / raw)
To: ebiederm; +Cc: rick.jones2, bunk, netdev, linux-kernel
In-Reply-To: <m1d4v1whh5.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Fri, 26 Oct 2007 18:04:22 -0600
> So if this is really something we want to stop doing we should
> be able to take a few extra moments remove the code from the
> two problem drivers, and remove the exports.
I've killed the references in dlm and rrunner in the net-2.6
tree.
^ permalink raw reply
* Re: [PATCH 00/05] ipv6: RFC4214 Support
From: David Stevens @ 2007-11-07 7:54 UTC (permalink / raw)
To: Pekka Savola; +Cc: David Miller, Fred.L.Templin, netdev, netdev-owner, yoshfuji
In-Reply-To: <Pine.LNX.4.64.0711070856130.27362@netcore.fi>
> give it away on this specific instance. I'm not sure if you should
> attribute to hidden agendas what you can explain by "doing the right
> thing" (granted, very few companies do this which may make it suspect,
> but still..).
Pekka,
I'm not assuming hidden agendas here; I simply don't know what
they mean by "no license for implementers." It doesn't say they
relinquish *all* licensing, which would be clearer if that's what they
mean. If implementers, distributors, and users are included, then
who's left that does need licensing? If that answer really is nobody,
then why bother with "for implementers."?
So, I don't think it's a hidden agenda, I think they said what
they mean. I just don't know what they mean. :-)
+-DLS
^ permalink raw reply
* Re: [2.6 patch] let USB_USBNET always select MII
From: David Miller @ 2007-11-07 8:10 UTC (permalink / raw)
To: bunk; +Cc: toralf.foerster, dbrownell, jgarzik, linux-kernel, netdev
In-Reply-To: <20071101222524.GB7227@stusta.de>
From: Adrian Bunk <bunk@kernel.org>
Date: Thu, 1 Nov 2007 23:25:24 +0100
> All this USB_USBNET_MII trickery is simply not worth it considering how
> few code it saves.
>
> As a side effect, this also fixes the following compile error reported
> by Toralf Förster:
>
> <-- snip -->
>
> ...
> LD .tmp_vmlinux1
> drivers/built-in.o: In function `usbnet_set_settings':
> (.text+0xf1876): undefined reference to `mii_ethtool_sset'
> drivers/built-in.o: In function `usbnet_get_settings':
> (.text+0xf1836): undefined reference to `mii_ethtool_gset'
> drivers/built-in.o: In function `usbnet_get_link':
> (.text+0xf18d6): undefined reference to `mii_link_ok'
> drivers/built-in.o: In function `usbnet_nway_reset':
> (.text+0xf18f6): undefined reference to `mii_nway_restart'
> make: *** [.tmp_vmlinux1] Error 1
>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Applied, thanks Adrian.
^ permalink raw reply
* Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':
From: David Miller @ 2007-11-07 8:20 UTC (permalink / raw)
To: david-b; +Cc: randy.dunlap, toralf.foerster, linux-kernel, netdev, greg
In-Reply-To: <200711011632.18333.david-b@pacbell.net>
David, I hate to say this and point you out like this, but you are a
real cancer for bug fixes to USB things in the kernel, and I'm very
tired of seeing things stuck in the mud (and engineering resources
wasted) because of how you handle things. It's very bad for Linux,
and the USB code in particular.
If I had a nickel for every patch from someone else you grinded into
the ground and stalled I'd truly be a millionare.
You absolutely stifle development progress. I thought my OHCI
deadlock patch was an isolated case (and nothing is still applied,
which is just awesome, my original patch was posted more than a month
ago), but you're doing the same exact thing to Adrian here too.
You want to see things fixed your way. But you can get away with the
if, and only if, you can spend every day working on your own version
of fixes when you don't like the submitters version. But unlike me
you don't have that luxury so you have to give patch submitters a
larger level of freedom and, plainly, just "let go".
^ permalink raw reply
* [PATCH] net: Removing duplicit #includes
From: Jiri Olsa @ 2007-11-07 8:29 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA; +Cc: netdev-u79uwXL29TY76Z2rM5mHXA
Removing duplicit #includes for net/
Signed-off-by: Jiri Olsa <olsajiri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/core/dst.c | 1 -
net/ieee80211/ieee80211_crypt_tkip.c | 1 -
net/ieee80211/ieee80211_crypt_wep.c | 1 -
3 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/core/dst.c b/net/core/dst.c
index 16958e6..03daead 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -18,7 +18,6 @@
#include <linux/types.h>
#include <net/net_namespace.h>
-#include <net/net_namespace.h>
#include <net/dst.h>
/*
diff --git a/net/ieee80211/ieee80211_crypt_tkip.c b/net/ieee80211/ieee80211_crypt_tkip.c
index 4cce353..58b2261 100644
--- a/net/ieee80211/ieee80211_crypt_tkip.c
+++ b/net/ieee80211/ieee80211_crypt_tkip.c
@@ -25,7 +25,6 @@
#include <net/ieee80211.h>
#include <linux/crypto.h>
-#include <linux/scatterlist.h>
#include <linux/crc32.h>
MODULE_AUTHOR("Jouni Malinen");
diff --git a/net/ieee80211/ieee80211_crypt_wep.c b/net/ieee80211/ieee80211_crypt_wep.c
index 866fc04..3fa30c4 100644
--- a/net/ieee80211/ieee80211_crypt_wep.c
+++ b/net/ieee80211/ieee80211_crypt_wep.c
@@ -22,7 +22,6 @@
#include <net/ieee80211.h>
#include <linux/crypto.h>
-#include <linux/scatterlist.h>
#include <linux/crc32.h>
MODULE_AUTHOR("Jouni Malinen");
^ permalink raw reply related
* Re: [PATCH] net: Removing duplicit #includes
From: David Miller @ 2007-11-07 8:49 UTC (permalink / raw)
To: olsajiri; +Cc: linux-wireless, netdev
In-Reply-To: <47317771.406@gmail.com>
From: Jiri Olsa <olsajiri@gmail.com>
Date: Wed, 07 Nov 2007 09:29:37 +0100
> Removing duplicit #includes for net/
> Signed-off-by: Jiri Olsa <olsajiri@gmail.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH] net: Removing duplicit #includes
From: Jiri Olsa @ 2007-11-07 9:06 UTC (permalink / raw)
To: netdev
In-Reply-To: <47317771.406@gmail.com>
sorry, the patch is mangled, I will resend another
Jiri Olsa wrote:
> Removing duplicit #includes for net/
> Signed-off-by: Jiri Olsa <olsajiri@gmail.com> ---
> net/core/dst.c | 1 -
> net/ieee80211/ieee80211_crypt_tkip.c | 1 -
> net/ieee80211/ieee80211_crypt_wep.c | 1 -
> 3 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/dst.c b/net/core/dst.c
> index 16958e6..03daead 100644
> --- a/net/core/dst.c
> +++ b/net/core/dst.c
> @@ -18,7 +18,6 @@
> #include <linux/types.h>
> #include <net/net_namespace.h>
>
> -#include <net/net_namespace.h>
> #include <net/dst.h>
>
> /*
> diff --git a/net/ieee80211/ieee80211_crypt_tkip.c
> b/net/ieee80211/ieee80211_crypt_tkip.c
> index 4cce353..58b2261 100644
> --- a/net/ieee80211/ieee80211_crypt_tkip.c
> +++ b/net/ieee80211/ieee80211_crypt_tkip.c
> @@ -25,7 +25,6 @@
> #include <net/ieee80211.h>
>
> #include <linux/crypto.h>
> -#include <linux/scatterlist.h>
> #include <linux/crc32.h>
>
> MODULE_AUTHOR("Jouni Malinen");
> diff --git a/net/ieee80211/ieee80211_crypt_wep.c
> b/net/ieee80211/ieee80211_crypt_wep.c
> index 866fc04..3fa30c4 100644
> --- a/net/ieee80211/ieee80211_crypt_wep.c
> +++ b/net/ieee80211/ieee80211_crypt_wep.c
> @@ -22,7 +22,6 @@
> #include <net/ieee80211.h>
>
> #include <linux/crypto.h>
> -#include <linux/scatterlist.h>
> #include <linux/crc32.h>
>
> MODULE_AUTHOR("Jouni Malinen");
>
^ permalink raw reply
* [PATCH] net: Removing duplicit #includes
From: Jiri Olsa @ 2007-11-07 9:09 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Removing duplicit #includes for net/
Signed-off-by: Jiri Olsa <olsajiri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/core/dst.c | 1 -
net/ieee80211/ieee80211_crypt_tkip.c | 1 -
net/ieee80211/ieee80211_crypt_wep.c | 1 -
3 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/core/dst.c b/net/core/dst.c
index 16958e6..03daead 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -18,7 +18,6 @@
#include <linux/types.h>
#include <net/net_namespace.h>
-#include <net/net_namespace.h>
#include <net/dst.h>
/*
diff --git a/net/ieee80211/ieee80211_crypt_tkip.c b/net/ieee80211/ieee80211_crypt_tkip.c
index 4cce353..58b2261 100644
--- a/net/ieee80211/ieee80211_crypt_tkip.c
+++ b/net/ieee80211/ieee80211_crypt_tkip.c
@@ -25,7 +25,6 @@
#include <net/ieee80211.h>
#include <linux/crypto.h>
-#include <linux/scatterlist.h>
#include <linux/crc32.h>
MODULE_AUTHOR("Jouni Malinen");
diff --git a/net/ieee80211/ieee80211_crypt_wep.c b/net/ieee80211/ieee80211_crypt_wep.c
index 866fc04..3fa30c4 100644
--- a/net/ieee80211/ieee80211_crypt_wep.c
+++ b/net/ieee80211/ieee80211_crypt_wep.c
@@ -22,7 +22,6 @@
#include <net/ieee80211.h>
#include <linux/crypto.h>
-#include <linux/scatterlist.h>
#include <linux/crc32.h>
MODULE_AUTHOR("Jouni Malinen");
^ permalink raw reply related
* Re: Endianness problem with u32 classifier hash masks
From: David Miller @ 2007-11-07 9:22 UTC (permalink / raw)
To: radu.rendec; +Cc: hadi, jarkao2, netdev
In-Reply-To: <1194368416.2987.218.camel@localhost.localdomain>
From: Radu Rendec <radu.rendec@ines.ro>
Date: Tue, 06 Nov 2007 19:00:16 +0200
> On Tue, 2007-11-06 at 09:43 -0500, jamal wrote:
> > On Tue, 2007-06-11 at 15:25 +0100, Jarek Poplawski wrote:
> >
> > > Yes, it saves one htonl() on the slow path!
> >
> > Would it feel better to say grew down exponentially from version 1 to
> > 3? ;->
>
> Not only it saves one htonl(), but also keeps the code readable :)
> Computing offsets within the rtnetlink response skb and applying htonl()
> there is quite tricky and might get broken if RTA_PUT() is changed.
> Unfortunately I spent about an hour figuring out how to do that :))
>
> The bad news is that today I haven't got the chance to work on the two
> patches. But the good news is that I managed to finish the (urgent) task
> that had been assigned to me at work, and tomorrow I will be able to
> work on the kernel and test it leisurely.
I've grown impatient and done the work for you :-) I've applied
the patch below to my tree, thank you!
If someone wants to send me the ffs() thing relative to this,
I'd appreciate it. Thanks again!
>From 8e36263f10a054479636b57943cdeaf37470acc5 Mon Sep 17 00:00:00 2001
From: Radu Rendec <radu.rendec@ines.ro>
Date: Wed, 7 Nov 2007 01:20:12 -0800
Subject: [PATCH] [PKT_SCHED] CLS_U32: Fix endianness problem with u32 classifier hash masks.
From: Radu Rendec <radu.rendec@ines.ro>
While trying to implement u32 hashes in my shaping machine I ran into
a possible bug in the u32 hash/bucket computing algorithm
(net/sched/cls_u32.c).
The problem occurs only with hash masks that extend over the octet
boundary, on little endian machines (where htonl() actually does
something).
Let's say that I would like to use 0x3fc0 as the hash mask. This means
8 contiguous "1" bits starting at b6. With such a mask, the expected
(and logical) behavior is to hash any address in, for instance,
192.168.0.0/26 in bucket 0, then any address in 192.168.0.64/26 in
bucket 1, then 192.168.0.128/26 in bucket 2 and so on.
This is exactly what would happen on a big endian machine, but on
little endian machines, what would actually happen with current
implementation is 0x3fc0 being reversed (into 0xc03f0000) by htonl()
in the userspace tool and then applied to 192.168.x.x in the u32
classifier. When shifting right by 16 bits (rank of first "1" bit in
the reversed mask) and applying the divisor mask (0xff for divisor
256), what would actually remain is 0x3f applied on the "168" octet of
the address.
One could say is this can be easily worked around by taking endianness
into account in userspace and supplying an appropriate mask (0xfc03)
that would be turned into contiguous "1" bits when reversed
(0x03fc0000). But the actual problem is the network address (inside
the packet) not being converted to host order, but used as a
host-order value when computing the bucket.
Let's say the network address is written as n31 n30 ... n0, with n0
being the least significant bit. When used directly (without any
conversion) on a little endian machine, it becomes n7 ... n0 n8 ..n15
etc in the machine's registers. Thus bits n7 and n8 would no longer be
adjacent and 192.168.64.0/26 and 192.168.128.0/26 would no longer be
consecutive.
The fix is to apply ntohl() on the hmask before computing fshift,
and in u32_hash_fold() convert the packet data to host order before
shifting down by fshift.
With helpful feedback from Jamal Hadi Salim and Jarek Poplawski.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/sched/cls_u32.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index 9e98c6e..5317102 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -91,7 +91,7 @@ static struct tc_u_common *u32_list;
static __inline__ unsigned u32_hash_fold(u32 key, struct tc_u32_sel *sel, u8 fshift)
{
- unsigned h = (key & sel->hmask)>>fshift;
+ unsigned h = ntohl(key & sel->hmask)>>fshift;
return h;
}
@@ -615,7 +615,7 @@ static int u32_change(struct tcf_proto *tp, unsigned long base, u32 handle,
n->handle = handle;
{
u8 i = 0;
- u32 mask = s->hmask;
+ u32 mask = ntohl(s->hmask);
if (mask) {
while (!(mask & 1)) {
i++;
--
1.5.3.5
^ permalink raw reply related
* Re: [VLAN]: Fix SET_VLAN_INGRESS_PRIORITY_CMD ioctl
From: David Miller @ 2007-11-07 9:31 UTC (permalink / raw)
To: kaber; +Cc: netdev, rdkehn
In-Reply-To: <472C6882.2070201@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Sat, 03 Nov 2007 13:24:34 +0100
> Fix a regression in 2.6.23. Candidate for -stable IMO.
Applied, and I'll queue it up for -stable, thanks!
^ permalink raw reply
* Why does a connect to IPv6 LLA address fail ?
From: Karsten Keil @ 2007-11-07 9:40 UTC (permalink / raw)
To: netdev
Hi,
currently I do some cerification test for IPv6 with the TAHI ct testsuite.
With the default-addr-select tests for compliance with RFC3484 here are
FAILs with Destination Address Selection Check Rule 2(Prefer matching
scope). Yes I know that Destination Address Selection is done in glibc,
but it seems that the kernel behaves wrong in the connect system call
with IPv6 link local addresses.
The glibc getaddrinfo function try to verify if a address is valid and
examine the source address. For this it create a socket for datagram and
protocol IPPROTO_IP and then try to connect it with the destination
address. This fails in the case of a LLA, because connect returns EINVAL,
since here is no device bind to this socket at this time. So getaddrinfo
mark this candidate address as not reachable and so it will never prefered
because of rule 1 of RFC3484 Destination Address Selection.
Why do we have this check in ip6_datagram_connect() ?
The posix manpage for connect says about EINVAL:
"EINVAL - The address_len argument is not a valid length for the address family; or
invalid address family in the sockaddr structure."
Which is not the case here.
--
Karsten Keil
SuSE Labs
ISDN and VOIP development
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
^ permalink raw reply
* Re: [PATCH] [AF_PACKET]: Allow multicast traffic to be caught by ORIGDEV when bonded
From: David Miller @ 2007-11-07 10:21 UTC (permalink / raw)
To: peter.p.waskiewicz.jr; +Cc: netdev
In-Reply-To: <20071106152547.14672.10821.stgit@localhost.localdomain>
From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
Date: Tue, 06 Nov 2007 07:25:47 -0800
> The socket option for packet sockets to return the original ifindex instead
> of the bonded ifindex will not match multicast traffic. Since this socket
> option is the most useful for layer 2 traffic and multicast traffic, make
> the option multicast-aware.
>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
I agree with you in principle, but I'd like to hear some feedback
from other folks. In particular I'd like a discussion about
what this might break, if anything.
^ permalink raw reply
* Re: Possible BUG on net/ipv4/ipcomp.c, line 358 (fwd)
From: David Miller @ 2007-11-07 10:22 UTC (permalink / raw)
To: herbert; +Cc: jmorris, netdev
In-Reply-To: <20071107011124.GA29479@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 7 Nov 2007 09:11:24 +0800
> [IPSEC]: Fix crypto_alloc_comp error checking
>
> The function crypto_alloc_comp returns an errno instead of NULL
> to indicate error. So it needs to be tested with IS_ERR.
>
> This is based on a patch by Vicenç Beltran Querol.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, and I'll queue this up for -stable too.
Thanks!
^ permalink raw reply
* Re: [PATCH] Clean proto_(un)register from in-code ifdefs
From: David Miller @ 2007-11-07 10:23 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4730A258.2060304@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 06 Nov 2007 20:20:24 +0300
> The struct proto has the per-cpu "inuse" counter, which is handled
> with a special care. All the handling code hides under the ifdef
> CONFIG_SMP and it introduces some code duplication and makes it
> look worse than it could.
>
> Clean this.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks!
^ permalink raw reply
* Re: [2.6 patch] remove Documentation/networking/Configurable
From: David Miller @ 2007-11-07 10:26 UTC (permalink / raw)
To: bunk; +Cc: netdev, linux-kernel
In-Reply-To: <20071105170510.GR12045@stusta.de>
From: Adrian Bunk <bunk@kernel.org>
Date: Mon, 5 Nov 2007 18:05:11 +0100
> After more than 11 years this file does no longer contain much useful
> information.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Applied.
^ permalink raw reply
* Re: [2.6 patch] remove comx driver docs
From: David Miller @ 2007-11-07 10:29 UTC (permalink / raw)
To: alan; +Cc: bunk, jgarzik, netdev, linux-kernel
In-Reply-To: <20071105171837.5324f206@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Mon, 5 Nov 2007 17:18:37 +0000
> On Mon, 5 Nov 2007 18:04:45 +0100
> Adrian Bunk <bunk@kernel.org> wrote:
>
> > The drivers have already been removed 3.5 years ago.
> >
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> Acked-by: Alan Cox <alan@redhat.com>
Applied.
^ permalink raw reply
* Re: [2.6 patch] remove Documentation/networking/ncsa-telnet
From: David Miller @ 2007-11-07 10:29 UTC (permalink / raw)
To: bunk; +Cc: netdev, linux-kernel, pp
In-Reply-To: <20071105170546.GS12045@stusta.de>
From: Adrian Bunk <bunk@kernel.org>
Date: Mon, 5 Nov 2007 18:05:46 +0100
> Newsflash: There once was a version of NCSA telnet that had some bug.
>
> Spotted by Pekka Pietikainen.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Applied.
^ permalink raw reply
* Re: [2.6 patch] remove Documentation/networking/routing.txt
From: David Miller @ 2007-11-07 10:30 UTC (permalink / raw)
To: bunk; +Cc: kuznet, netdev, linux-kernel
In-Reply-To: <20071105170601.GU12045@stusta.de>
From: Adrian Bunk <bunk@kernel.org>
Date: Mon, 5 Nov 2007 18:06:01 +0100
> This file is so outdated that I can't see any value in keeping it.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Agreed, and applied.
^ 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