* Re: IPv6 DNSSL (rfc6106): please include the patch to pass it to user space
From: David Miller @ 2011-06-06 19:40 UTC (permalink / raw)
To: carlos; +Cc: netdev
In-Reply-To: <19949.87.934341.698604@fisica.ufpr.br>
From: Carlos Carvalho <carlos@fisica.ufpr.br>
Date: Mon, 6 Jun 2011 13:29:11 -0300
> Currently the kernel doesn't pass DNSSL lists received by router
> advertsiments (rfc 6106) to user space via netlink. Pierre Ossman sent
> a patch for it about 6 months ago:
> http://patchwork.ozlabs.org/patch/75243. Could you please include it
> in mainline? This is a very useful feature.
The submitter marked that patch as "RFC", he must make a new formal
submission and indicate that it's in a final form and ready to be
actually applied.
You are intelligent enough to find the patch in patchwork, yet you
totally ignore the state that the patch was put into and didn't
even bother considering what it might mean.
What's the point of having something like patchwork if I still have to
explain things to people by hand? It doesn't save me any time, since
the whole point of patchwork is that I can communicate to the entire
world what state the patch is in and that tells what (if anything) can
happen next for that patch.
^ permalink raw reply
* [RFC] should we care of COMPAT mode in bridge ?
From: Eric Dumazet @ 2011-06-06 19:45 UTC (permalink / raw)
To: netdev
While trying Alexander Holler patch, I found a 32bit brctl program was
not able to work on a 64bit kernel. So I had to switch to another
machine for my tests.
brctl addbr mybridge
->
socket(PF_FILE, SOCK_STREAM, 0) = 3
ioctl(3, SIOCSIFBR, 0xffd509c0) = -1 EINVAL (Invalid argument)
Should we care or not ?
^ permalink raw reply
* Re: linux-next: Tree for June 6 (sctp)
From: Randy Dunlap @ 2011-06-06 19:55 UTC (permalink / raw)
To: Stephen Rothwell, linux-sctp; +Cc: linux-next, LKML, netdev
In-Reply-To: <20110606132036.aebd73a4.sfr@canb.auug.org.au>
On Mon, 6 Jun 2011 13:20:36 +1000 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20110603:
when CONFIG_IPV6 is not enabled:
ERROR: "ipv6_chk_addr" [net/sctp/sctp.ko] undefined!
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [RFC] should we care of COMPAT mode in bridge ?
From: David Miller @ 2011-06-06 20:03 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1307389540.2642.3.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 06 Jun 2011 21:45:40 +0200
> While trying Alexander Holler patch, I found a 32bit brctl program was
> not able to work on a 64bit kernel. So I had to switch to another
> machine for my tests.
>
> brctl addbr mybridge
> ->
> socket(PF_FILE, SOCK_STREAM, 0) = 3
> ioctl(3, SIOCSIFBR, 0xffd509c0) = -1 EINVAL (Invalid argument)
>
> Should we care or not ?
I think we should make an effort to fix this.
^ permalink raw reply
* Re: small RPS cache for fragments?
From: Rick Jones @ 2011-06-06 20:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110606.122217.2183968212149987796.davem@davemloft.net>
On Mon, 2011-06-06 at 12:22 -0700, David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Mon, 06 Jun 2011 10:08:52 -0700
>
> > Mode-rr bonding reorders TCP segments all the time.
>
> Oh well, then don't use this if you care about performance at all.
> And therefore it's not even worth considering for our RPS fragment
> cache.
Heh - the (or at least a) reason people use mode-rr is to make a single
(TCP) stream go faster :) Without buying the next-up NIC speed.
rick jones
^ permalink raw reply
* Re: linux-next: Tree for June 6 (sctp)
From: David Miller @ 2011-06-06 20:06 UTC (permalink / raw)
To: randy.dunlap; +Cc: sfr, linux-sctp, linux-next, linux-kernel, netdev
In-Reply-To: <20110606125532.793b3cfd.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 6 Jun 2011 12:55:32 -0700
> On Mon, 6 Jun 2011 13:20:36 +1000 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20110603:
>
>
> when CONFIG_IPV6 is not enabled:
>
> ERROR: "ipv6_chk_addr" [net/sctp/sctp.ko] undefined!
I'll push the following after some build testing, thanks.
--------------------
sctp: Guard IPV6 specific code properly.
Outside of net/sctp/ipv6.c, IPV6 specific code needs to
be ifdef guarded.
This fixes build failures with IPV6 disabled.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/sctp/protocol.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index af0a6b0..ab5ded2 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -637,6 +637,7 @@ void sctp_addr_wq_timeout_handler(unsigned long arg)
" for cmd %d at entry %p\n", &sctp_addr_waitq, &addrw->a, addrw->state,
addrw);
+#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
/* Now we send an ASCONF for each association */
/* Note. we currently don't handle link local IPv6 addressees */
if (addrw->a.sa.sa_family == AF_INET6) {
@@ -659,7 +660,7 @@ void sctp_addr_wq_timeout_handler(unsigned long arg)
break;
}
}
-
+#endif
list_for_each_entry(sp, &sctp_auto_asconf_splist, auto_asconf_list) {
struct sock *sk;
--
1.7.5.2
^ permalink raw reply related
* Re: [RFC] should we care of COMPAT mode in bridge ?
From: Arnd Bergmann @ 2011-06-06 20:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1307389540.2642.3.camel@edumazet-laptop>
On Monday 06 June 2011 21:45:40 Eric Dumazet wrote:
> While trying Alexander Holler patch, I found a 32bit brctl program was
> not able to work on a 64bit kernel. So I had to switch to another
> machine for my tests.
>
> brctl addbr mybridge
> ->
> socket(PF_FILE, SOCK_STREAM, 0) = 3
> ioctl(3, SIOCSIFBR, 0xffd509c0) = -1 EINVAL (Invalid argument)
>
> Should we care or not ?
>
Generally, we try to make all ioctls work in compat mode. For the old
bridge ioctls, this is currently impossible because it uses SIOCPRIVATE
ioctls, but it would be easy to add an ndo_do_compat_ioctl.
The solution that is documented in net/socket.c is to return
an invalid version number for BRCTL_VERSION, in the hope that
brctl would switch to the newer interfaces. The new style bridge
ioctls (SIOCBRADDBR, SIOCBRADDIF, ...) are actually supposed to work,
but I've never tried that.
Arnd
^ permalink raw reply
* Re: [RFC] should we care of COMPAT mode in bridge ?
From: David Miller @ 2011-06-06 20:09 UTC (permalink / raw)
To: arnd; +Cc: eric.dumazet, netdev
In-Reply-To: <201106062206.29134.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 6 Jun 2011 22:06:28 +0200
> On Monday 06 June 2011 21:45:40 Eric Dumazet wrote:
>> While trying Alexander Holler patch, I found a 32bit brctl program was
>> not able to work on a 64bit kernel. So I had to switch to another
>> machine for my tests.
>>
>> brctl addbr mybridge
>> ->
>> socket(PF_FILE, SOCK_STREAM, 0) = 3
>> ioctl(3, SIOCSIFBR, 0xffd509c0) = -1 EINVAL (Invalid argument)
>>
>> Should we care or not ?
>>
>
> Generally, we try to make all ioctls work in compat mode. For the old
> bridge ioctls, this is currently impossible because it uses SIOCPRIVATE
> ioctls, but it would be easy to add an ndo_do_compat_ioctl.
Right, we need to funnel compat ioctls down to the device and add a
->ndo_compat_ioctl() or similar, if that is indeed feasible.
^ permalink raw reply
* Re: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Bart De Schuymer @ 2011-06-06 20:10 UTC (permalink / raw)
To: Brad Campbell; +Cc: kvm, linux-mm, linux-kernel, netdev, netfilter-devel
In-Reply-To: <4DE906C0.6060901@fnarfbargle.com>
Hi Brad,
This has probably nothing to do with ebtables, so please rmmod in case
it's loaded.
A few questions I didn't directly see an answer to in the threads I
scanned...
I'm assuming you actually use the bridging firewall functionality. So,
what iptables modules do you use? Can you reduce your iptables rules to
a core that triggers the bug?
Or does it get triggered even with an empty set of firewall rules?
Are you using a stock .35 kernel or is it patched?
Is this something I can trigger on a poor guy's laptop or does it
require specialized hardware (I'm catching up on qemu/kvm...)?
cheers,
Bart
PS: I'm not sure if we should keep CC-ing everybody, netfilter-devel
together with kvm should probably do fine.
Op 3/06/2011 18:07, Brad Campbell schreef:
> On 03/06/11 23:50, Bernhard Held wrote:
>> Am 03.06.2011 15:38, schrieb Brad Campbell:
>>> On 02/06/11 07:03, CaT wrote:
>>>> On Wed, Jun 01, 2011 at 07:52:33PM +0800, Brad Campbell wrote:
>>>>> Unfortunately the only interface that is mentioned by name anywhere
>>>>> in my firewall is $DMZ (which is ppp0 and not part of any bridge).
>>>>>
>>>>> All of the nat/dnat and other horrible hacks are based on IP
>>>>> addresses.
>>>>
>>>> Damn. Not referencing the bridge interfaces at all stopped our host
>>>> from
>>>> going down in flames when we passed it a few packets. These are two
>>>> of the oopses we got from it. Whilst the kernel here is .35 we got the
>>>> same issue from a range of kernels. Seems related.
>>>
>>> Well, I tried sending an explanatory message to netdev, netfilter &
>>> cc'd to kvm,
>>> but it appears not to have made it to kvm or netfilter, and the cc to
>>> netdev has
>>> not elicited a response. My resend to netfilter seems to have dropped
>>> into the
>>> bit bucket also.
>> Just another reference 3.5 months ago:
>> http://www.spinics.net/lists/netfilter-devel/msg17239.html
>
> <waves hands around shouting "I have a reproducible test case for this
> and don't mind patching and crashing the machine to get it fixed">
>
> Attempted to add netfilter-devel to the cc this time.
> --
> To unsubscribe from this list: send the line "unsubscribe
> netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Bart De Schuymer
www.artinalgorithms.be
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC Patch] bonding: move to net/ directory
From: Ben Hutchings @ 2011-06-06 20:11 UTC (permalink / raw)
To: Joe Perches
Cc: Eric Dumazet, Américo Wang, Jeffrey Kirsher,
Michał Mirosław, Neil Horman, Andy Gospodarek,
Linux Kernel Network Developers, David Miller, Jay Vosburgh
In-Reply-To: <1307380827.4994.8.camel@Joe-Laptop>
On Mon, 2011-06-06 at 10:20 -0700, Joe Perches wrote:
> On Mon, 2011-06-06 at 19:04 +0200, Eric Dumazet wrote:
> > Le lundi 06 juin 2011 à 09:50 -0700, Joe Perches a écrit :
> > > There is a proposal to move some drivers/net content to
> > > drivers/net/sw/
> > > http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
> > > I think that'd be fine too.
> > > I believe Jeff is going to submit patches soonish.
> > > http://comments.gmane.org/gmane.linux.network/197232
> > As long as the re-organization is done without loosing "git blame"
> > information on current files, I am fine.
> > If not, this is a showstopper and not worth the pain, exactly like other
> > cleanup patches.
>
> To preserve history, all of this should be done via:
> git mv oldpath/file newpath/file
> git commit -m newpath/file
> with some extra cleanups to Kconfig/Makefile files
> so no worries.
git doesn't explicitly record moves; it just recognises moves if you
tell it to look for them (e.g. 'git diff -M' and 'git log --follow').
'git mv' is essentially shorthand for mv && git add && git rm. And
specifying the old or new path on the 'git commit' line is redundant,
because the changes are already in the index.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
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: [RFC] should we care of COMPAT mode in bridge ?
From: Eric Dumazet @ 2011-06-06 20:12 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: netdev
In-Reply-To: <201106062206.29134.arnd@arndb.de>
Le lundi 06 juin 2011 à 22:06 +0200, Arnd Bergmann a écrit :
> On Monday 06 June 2011 21:45:40 Eric Dumazet wrote:
> > While trying Alexander Holler patch, I found a 32bit brctl program was
> > not able to work on a 64bit kernel. So I had to switch to another
> > machine for my tests.
> >
> > brctl addbr mybridge
> > ->
> > socket(PF_FILE, SOCK_STREAM, 0) = 3
> > ioctl(3, SIOCSIFBR, 0xffd509c0) = -1 EINVAL (Invalid argument)
> >
> > Should we care or not ?
> >
>
> Generally, we try to make all ioctls work in compat mode. For the old
> bridge ioctls, this is currently impossible because it uses SIOCPRIVATE
> ioctls, but it would be easy to add an ndo_do_compat_ioctl.
>
> The solution that is documented in net/socket.c is to return
> an invalid version number for BRCTL_VERSION, in the hope that
> brctl would switch to the newer interfaces. The new style bridge
> ioctls (SIOCBRADDBR, SIOCBRADDIF, ...) are actually supposed to work,
> but I've never tried that.
>
I see... problem is brctl does :
int br_add_bridge(const char *brname)
{
int ret;
#ifdef SIOCBRADDBR
ret = ioctl(br_socket_fd, SIOCBRADDBR, brname);
if (ret < 0)
#endif
{
char _br[IFNAMSIZ];
unsigned long arg[3]
= { BRCTL_ADD_BRIDGE, (unsigned long) _br };
strncpy(_br, brname, IFNAMSIZ);
ret = ioctl(br_socket_fd, SIOCSIFBR, arg);
}
return ret < 0 ? errno : 0;
}
So for an old binary, compiled at the time SIOCBRADDBR wasnt there (in
include file I mean), we ended doing :
{
char _br[IFNAMSIZ];
unsigned long arg[3]
= { BRCTL_ADD_BRIDGE, (unsigned long) _br };
strncpy(_br, brname, IFNAMSIZ);
ret = ioctl(br_socket_fd, SIOCSIFBR, arg);
}
And this breaks on 64bit kernel
I guess we shall add some logic in kernel to support SIOCSIFBR
afterall ;)
Thanks !
BTW: I confirm that compiling an up2date 32bit brctl with an up2date
include files is OK on 64bit kernel.
^ permalink raw reply
* Re: [E1000-devel] [PATCH] e100: Fix inconsistency in bad frames handling
From: Ben Hutchings @ 2011-06-06 20:15 UTC (permalink / raw)
To: Ben Greear
Cc: Brandeburg, Jesse, Andrea Merello,
e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <4DED14E7.2050405@candelatech.com>
On Mon, 2011-06-06 at 10:56 -0700, Ben Greear wrote:
> On 06/06/2011 10:49 AM, Brandeburg, Jesse wrote:
> >
> > <added netdev>, removed other useless lists.
> >
> > On Sat, 4 Jun 2011, Andrea Merello wrote:
> >> In e100 driver it seems that the intention was to accept bad frames in
> >> promiscuous mode and loopback mode.
> >> I think this is evident because of the following code in the driver:
> >>
> >> if (nic->flags& promiscuous || nic->loopback) {
> >> config->rx_save_bad_frames = 0x1; /* 1=save, 0=discard */
> >> config->rx_discard_short_frames = 0x0; /* 1=discard, 0=save */
> >> config->promiscuous_mode = 0x1; /* 1=on, 0=off */
> >> }
> >>
> >
> > Hi, thanks for your work on e100.
> >
> >> However this intention is not really realized because bad frames are
> >> discarded later by SW check.
> >> This patch finally honors the above intention, making the RX code to
> >> let bad frames to pass when the NIC is in promiscuous or loopback
> >> mode.
> >
> > I think this may be a mistake by the authors of the software developers
> > manual. The manual suggests that save bad frames and save short frames
> > should be enabled in promisc mode, but all of our other drivers *do not*
> > save bad frames when in promiscuous mode (by design). This is intentional
> > because a bad frame is just that, bad, and with no hope of knowing if the
> > data in it is okay/malicious/other. I understand your reasoning above,
> > but realistically the rx_save_bad_frames should NOT be set. I'd ack a
> > patch to comment that line out.
> >
> >> This helped me a lot to debug an FPGA ethernet core.
> >> Maybe it can be also useful to someone else..
> >
> > I think this patch is just that, debug only. As a developer I understand
> > why this is useful, but there is no reason any normal user would be able
> > to benefit from this, so for now, sorry:
> >
> > NACK.
>
> I think anyone sniffing a funky network would have benefit in
> receiving all frames. So, while it shouldn't be enabled by default,
> it would be nice to have an ethtool command to turn on receiving
> bad-crc frames, as well as receiving the 4-byte CRC on the end of
> the packets.
>
> It just so happens I have such a patch, in case others agree :)
How would a received skb be flagged as having a CRC error?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
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: [RFC] should we care of COMPAT mode in bridge ?
From: Arnd Bergmann @ 2011-06-06 20:19 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20110606.130958.1488166895702555231.davem@davemloft.net>
On Monday 06 June 2011 22:09:58 David Miller wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Mon, 6 Jun 2011 22:06:28 +0200
>
> > On Monday 06 June 2011 21:45:40 Eric Dumazet wrote:
> >> While trying Alexander Holler patch, I found a 32bit brctl program was
> >> not able to work on a 64bit kernel. So I had to switch to another
> >> machine for my tests.
> >>
> >> brctl addbr mybridge
> >> ->
> >> socket(PF_FILE, SOCK_STREAM, 0) = 3
> >> ioctl(3, SIOCSIFBR, 0xffd509c0) = -1 EINVAL (Invalid argument)
> >>
> >> Should we care or not ?
> >>
> >
> > Generally, we try to make all ioctls work in compat mode. For the old
> > bridge ioctls, this is currently impossible because it uses SIOCPRIVATE
> > ioctls, but it would be easy to add an ndo_do_compat_ioctl.
>
> Right, we need to funnel compat ioctls down to the device and add a
> ->ndo_compat_ioctl() or similar, if that is indeed feasible.
I think it would be good to first understand why it doesn't work with the
new style ioctls that are in the kernel. The source code of brctl that
I'm looking at here contains:
int br_add_bridge(const char *brname)
{
int ret;
#ifdef SIOCBRADDBR
ret = ioctl(br_socket_fd, SIOCBRADDBR, brname);
if (ret < 0)
#endif
{
char _br[IFNAMSIZ];
unsigned long arg[3]
= { BRCTL_ADD_BRIDGE, (unsigned long) _br };
strncpy(_br, brname, IFNAMSIZ);
ret = ioctl(br_socket_fd, SIOCSIFBR, arg);
}
return ret < 0 ? errno : 0;
}
This means it should first attempt to call SIOCBRADDBR, which has
32 bit compat support in the kernel. The only reasons I can see why
this would not work are:
* the brctl tool in question is built from really old sources that
don't have the SIOCBRADDBR option.
* it is built against really old kernel headers that do not export
the SIOCBRADDBR definition.
If neither of the two is true, there is probably a bug somewhere that
wants to get fixed.
Arnd
^ permalink raw reply
* Re: [PATCH] e100: Fix inconsistency in bad frames handling
From: Ben Greear @ 2011-06-06 20:20 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrea Merello, e1000-devel@lists.sourceforge.net,
Brandeburg, Jesse, netdev
In-Reply-To: <1307391315.22348.454.camel@localhost>
On 06/06/2011 01:15 PM, Ben Hutchings wrote:
> On Mon, 2011-06-06 at 10:56 -0700, Ben Greear wrote:
>> On 06/06/2011 10:49 AM, Brandeburg, Jesse wrote:
>>>
>>> <added netdev>, removed other useless lists.
>>>
>>> On Sat, 4 Jun 2011, Andrea Merello wrote:
>>>> In e100 driver it seems that the intention was to accept bad frames in
>>>> promiscuous mode and loopback mode.
>>>> I think this is evident because of the following code in the driver:
>>>>
>>>> if (nic->flags& promiscuous || nic->loopback) {
>>>> config->rx_save_bad_frames = 0x1; /* 1=save, 0=discard */
>>>> config->rx_discard_short_frames = 0x0; /* 1=discard, 0=save */
>>>> config->promiscuous_mode = 0x1; /* 1=on, 0=off */
>>>> }
>>>>
>>>
>>> Hi, thanks for your work on e100.
>>>
>>>> However this intention is not really realized because bad frames are
>>>> discarded later by SW check.
>>>> This patch finally honors the above intention, making the RX code to
>>>> let bad frames to pass when the NIC is in promiscuous or loopback
>>>> mode.
>>>
>>> I think this may be a mistake by the authors of the software developers
>>> manual. The manual suggests that save bad frames and save short frames
>>> should be enabled in promisc mode, but all of our other drivers *do not*
>>> save bad frames when in promiscuous mode (by design). This is intentional
>>> because a bad frame is just that, bad, and with no hope of knowing if the
>>> data in it is okay/malicious/other. I understand your reasoning above,
>>> but realistically the rx_save_bad_frames should NOT be set. I'd ack a
>>> patch to comment that line out.
>>>
>>>> This helped me a lot to debug an FPGA ethernet core.
>>>> Maybe it can be also useful to someone else..
>>>
>>> I think this patch is just that, debug only. As a developer I understand
>>> why this is useful, but there is no reason any normal user would be able
>>> to benefit from this, so for now, sorry:
>>>
>>> NACK.
>>
>> I think anyone sniffing a funky network would have benefit in
>> receiving all frames. So, while it shouldn't be enabled by default,
>> it would be nice to have an ethtool command to turn on receiving
>> bad-crc frames, as well as receiving the 4-byte CRC on the end of
>> the packets.
>>
>> It just so happens I have such a patch, in case others agree :)
>
> How would a received skb be flagged as having a CRC error?
We could add an skb flag? Or just pass it straight up and let
the receiving code deal with it (if we pass up the CRC as well, receiving
code has all info needed).
There are other errors possible as well, I think...maybe short frames, etc,
so it might be nice to have some way to mark what the NIC thinks is wrong
with the pkt.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Eric Dumazet @ 2011-06-06 20:22 UTC (permalink / raw)
To: Brad Campbell
Cc: Avi Kivity, CaT, Hugh Dickins, Andrea Arcangeli, Borislav Petkov,
linux-kernel, kvm, linux-mm, netdev
In-Reply-To: <4DEB8872.2060801@fnarfbargle.com>
Le dimanche 05 juin 2011 à 21:45 +0800, Brad Campbell a écrit :
> On 05/06/11 16:14, Avi Kivity wrote:
> > On 06/03/2011 04:38 PM, Brad Campbell wrote:
> >>
> >> Is there anyone who can point me at the appropriate cage to rattle? I
> >> know it appears to be a netfilter issue, but I don't seem to be able
> >> to get a message to the list (and I am subscribed to it and have been
> >> getting mail for months) and I'm not sure who to pester. The other
> >> alternative is I just stop doing "that" and wait for it to bite
> >> someone else.
> >
> > The mailing list might be set not to send your own mails back to you.
> > Check the list archive.
>
> Yep, I did that first..
>
> Given the response to previous issues along the same line, it looks a
> bit like I just remember not to actually use the system in the way that
> triggers the bug and be happy that 99% of the time the kernel does not
> panic, but have that lovely feeling in the back of the skull that says
> "any time now, and without obvious reason the whole machine might just
> come crashing down"..
>
> I guess it's still better than running Xen or Windows..
Could you please try latest linux-2.6 tree ?
We fixed many networking bugs that could explain your crash.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Eric Dumazet @ 2011-06-06 20:23 UTC (permalink / raw)
To: Bart De Schuymer
Cc: Brad Campbell, kvm, linux-mm, linux-kernel, netdev,
netfilter-devel
In-Reply-To: <4DED344D.7000005@pandora.be>
Le lundi 06 juin 2011 à 22:10 +0200, Bart De Schuymer a écrit :
> Hi Brad,
>
> This has probably nothing to do with ebtables, so please rmmod in case
> it's loaded.
> A few questions I didn't directly see an answer to in the threads I
> scanned...
> I'm assuming you actually use the bridging firewall functionality. So,
> what iptables modules do you use? Can you reduce your iptables rules to
> a core that triggers the bug?
> Or does it get triggered even with an empty set of firewall rules?
> Are you using a stock .35 kernel or is it patched?
> Is this something I can trigger on a poor guy's laptop or does it
> require specialized hardware (I'm catching up on qemu/kvm...)?
>
Keep netdev, as this most probably is a networking bug.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC] should we care of COMPAT mode in bridge ?
From: David Miller @ 2011-06-06 20:23 UTC (permalink / raw)
To: arnd; +Cc: eric.dumazet, netdev
In-Reply-To: <201106062219.33432.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 6 Jun 2011 22:19:33 +0200
> I think it would be good to first understand why it doesn't work with the
> new style ioctls that are in the kernel. The source code of brctl that
> I'm looking at here contains:
Eric's 32-bit binary was built against older headers that didn't
define the new ioctls.
That makes it pretty clear to me that we have to support those
older ioctls in compat mode even after all these years.
^ permalink raw reply
* Re: pull request: wireless-2.6 2011-06-06
From: David Miller @ 2011-06-06 20:25 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20110606190427.GH2604@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 6 Jun 2011 15:04:27 -0400
> Here are a few more fixes intended for 3.0 -- a libertas fix for a
> regression related to spurious interrupts, an ath5k fix to disable
> "fast" channel switching (since it caused a number of devices to
> regress in performance), an ssb fix for a regression that was applying
> PCIe workarounds to PCI devices (causing a machine check), an fix for an
> iwlagn locking regression, and a mac80211 fix for a device-naming
> regression.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [RFC] should we care of COMPAT mode in bridge ?
From: Arnd Bergmann @ 2011-06-06 20:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1307391174.2642.8.camel@edumazet-laptop>
On Monday 06 June 2011 22:12:54 Eric Dumazet wrote:
> So for an old binary, compiled at the time SIOCBRADDBR wasnt there (in
> include file I mean), we ended doing :
>
> {
> char _br[IFNAMSIZ];
> unsigned long arg[3]
> = { BRCTL_ADD_BRIDGE, (unsigned long) _br };
>
> strncpy(_br, brname, IFNAMSIZ);
> ret = ioctl(br_socket_fd, SIOCSIFBR, arg);
> }
>
> And this breaks on 64bit kernel
Ah, you were quicker than me at posting this ;-)
> I guess we shall add some logic in kernel to support SIOCSIFBR
> afterall ;)
>
> Thanks !
>
> BTW: I confirm that compiling an up2date 32bit brctl with an up2date
> include files is OK on 64bit kernel.
I did a little more digging in the history and found that the code in
brctl was added in this commit:
commit 328f4711bbc369dcccf8f8cfba2adf5dd0f74479
Author: shemminger <shemminger>
Date: Fri May 21 17:41:48 2004 +0000
New version of command and library that use sysfs.
Update make system to build with or without sysfs.
It's not completely clear to me if it's worth supporting older
user space than this, but it's certainly possible.
Arnd
^ permalink raw reply
* Re: [RFC] should we care of COMPAT mode in bridge ?
From: Chris Friesen @ 2011-06-06 20:23 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20110606.130309.847468074358617705.davem@davemloft.net>
On 06/06/2011 02:03 PM, David Miller wrote:
> From: Eric Dumazet<eric.dumazet@gmail.com>
> Date: Mon, 06 Jun 2011 21:45:40 +0200
>
>> While trying Alexander Holler patch, I found a 32bit brctl program was
>> not able to work on a 64bit kernel. So I had to switch to another
>> machine for my tests.
>>
>> brctl addbr mybridge
>> ->
>> socket(PF_FILE, SOCK_STREAM, 0) = 3
>> ioctl(3, SIOCSIFBR, 0xffd509c0) = -1 EINVAL (Invalid argument)
>>
>> Should we care or not ?
>
> I think we should make an effort to fix this.
For current status of affairs, this makes sense.
It raises an interesting question though...do we plan on supporting
compat indefinitely?
As I see it x86 generally makes more sense to run as 64-bit when
possible due to the extra register availability. Compat is primarily
useful for the embedded space and for backwards compatibility, and
ripping it out would cause a lot of grief for legacy 32-bit apps. It
would simplify the userspace/kernel interface though.
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: [PATCH] e100: Fix inconsistency in bad frames handling
From: Eric Dumazet @ 2011-06-06 20:29 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrea Merello, e1000-devel@lists.sourceforge.net,
Brandeburg, Jesse, netdev
In-Reply-To: <1307391315.22348.454.camel@localhost>
Le lundi 06 juin 2011 à 21:15 +0100, Ben Hutchings a écrit :
> On Mon, 2011-06-06 at 10:56 -0700, Ben Greear wrote:
> > On 06/06/2011 10:49 AM, Brandeburg, Jesse wrote:
> > >
> > > <added netdev>, removed other useless lists.
> > >
> > > On Sat, 4 Jun 2011, Andrea Merello wrote:
> > >> In e100 driver it seems that the intention was to accept bad frames in
> > >> promiscuous mode and loopback mode.
> > >> I think this is evident because of the following code in the driver:
> > >>
> > >> if (nic->flags& promiscuous || nic->loopback) {
> > >> config->rx_save_bad_frames = 0x1; /* 1=save, 0=discard */
> > >> config->rx_discard_short_frames = 0x0; /* 1=discard, 0=save */
> > >> config->promiscuous_mode = 0x1; /* 1=on, 0=off */
> > >> }
> > >>
> > >
> > > Hi, thanks for your work on e100.
> > >
> > >> However this intention is not really realized because bad frames are
> > >> discarded later by SW check.
> > >> This patch finally honors the above intention, making the RX code to
> > >> let bad frames to pass when the NIC is in promiscuous or loopback
> > >> mode.
> > >
> > > I think this may be a mistake by the authors of the software developers
> > > manual. The manual suggests that save bad frames and save short frames
> > > should be enabled in promisc mode, but all of our other drivers *do not*
> > > save bad frames when in promiscuous mode (by design). This is intentional
> > > because a bad frame is just that, bad, and with no hope of knowing if the
> > > data in it is okay/malicious/other. I understand your reasoning above,
> > > but realistically the rx_save_bad_frames should NOT be set. I'd ack a
> > > patch to comment that line out.
> > >
> > >> This helped me a lot to debug an FPGA ethernet core.
> > >> Maybe it can be also useful to someone else..
> > >
> > > I think this patch is just that, debug only. As a developer I understand
> > > why this is useful, but there is no reason any normal user would be able
> > > to benefit from this, so for now, sorry:
> > >
> > > NACK.
> >
> > I think anyone sniffing a funky network would have benefit in
> > receiving all frames. So, while it shouldn't be enabled by default,
> > it would be nice to have an ethtool command to turn on receiving
> > bad-crc frames, as well as receiving the 4-byte CRC on the end of
> > the packets.
> >
> > It just so happens I have such a patch, in case others agree :)
>
> How would a received skb be flagged as having a CRC error?
>
maybe some skb->pkt_type = PACKET_INVALID; or something...
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [RFC] should we care of COMPAT mode in bridge ?
From: Arnd Bergmann @ 2011-06-06 20:31 UTC (permalink / raw)
To: Chris Friesen; +Cc: David Miller, eric.dumazet, netdev
In-Reply-To: <4DED3759.7030209@genband.com>
On Monday 06 June 2011 22:23:53 Chris Friesen wrote:
> It raises an interesting question though...do we plan on supporting
> compat indefinitely?
>
> As I see it x86 generally makes more sense to run as 64-bit when
> possible due to the extra register availability. Compat is primarily
> useful for the embedded space and for backwards compatibility, and
> ripping it out would cause a lot of grief for legacy 32-bit apps. It
> would simplify the userspace/kernel interface though.
There are a lot of applications that require being run as 32 bit,
and some of them are much happier in a chroot environment. Removing
the compat support entirely won't be an option for the next 10 years
at least, AFAICT. Even if we get all x86 folks to migrate to 64 bits
at some point in the distant future, there will always be other
architectures that make the move to 64 bits.
Note that there is currently work going on to add a new x32 ABI
to arch/x86 which makes it possible to use 32 bit pointers with the
full 64 bit register set. If this becomes a success, we will never
be able to build x86 kernels without compat support.
Arnd
^ permalink raw reply
* Re: [RFC] should we care of COMPAT mode in bridge ?
From: Andreas Schwab @ 2011-06-06 20:31 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20110606.130309.847468074358617705.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 06 Jun 2011 21:45:40 +0200
>
>> While trying Alexander Holler patch, I found a 32bit brctl program was
>> not able to work on a 64bit kernel. So I had to switch to another
>> machine for my tests.
>>
>> brctl addbr mybridge
>> ->
>> socket(PF_FILE, SOCK_STREAM, 0) = 3
>> ioctl(3, SIOCSIFBR, 0xffd509c0) = -1 EINVAL (Invalid argument)
>>
>> Should we care or not ?
>
> I think we should make an effort to fix this.
OTOH, the SIOCSIFBR and SIOCGIFBR ioctls are obsoleted by the
SIOCBRADDBR, SIOCBRDELBR, SIOCBRADDIF, SIOCBRDELIF ioctls and bridge
sysfs files (which have no compat issues).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [RFC] should we care of COMPAT mode in bridge ?
From: Eric Dumazet @ 2011-06-06 20:32 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: netdev
In-Reply-To: <201106062226.02635.arnd@arndb.de>
Le lundi 06 juin 2011 à 22:26 +0200, Arnd Bergmann a écrit :
> On Monday 06 June 2011 22:12:54 Eric Dumazet wrote:
> > So for an old binary, compiled at the time SIOCBRADDBR wasnt there (in
> > include file I mean), we ended doing :
> >
> > {
> > char _br[IFNAMSIZ];
> > unsigned long arg[3]
> > = { BRCTL_ADD_BRIDGE, (unsigned long) _br };
> >
> > strncpy(_br, brname, IFNAMSIZ);
> > ret = ioctl(br_socket_fd, SIOCSIFBR, arg);
> > }
> >
> > And this breaks on 64bit kernel
>
> Ah, you were quicker than me at posting this ;-)
>
> > I guess we shall add some logic in kernel to support SIOCSIFBR
> > afterall ;)
> >
> > Thanks !
> >
> > BTW: I confirm that compiling an up2date 32bit brctl with an up2date
> > include files is OK on 64bit kernel.
>
> I did a little more digging in the history and found that the code in
> brctl was added in this commit:
>
> commit 328f4711bbc369dcccf8f8cfba2adf5dd0f74479
> Author: shemminger <shemminger>
> Date: Fri May 21 17:41:48 2004 +0000
>
> New version of command and library that use sysfs.
> Update make system to build with or without sysfs.
>
> It's not completely clear to me if it's worth supporting older
> user space than this, but it's certainly possible.
>
> Arnd
In my case, I used latest bridge-utils tree, but compiled on a RHEL4
machine :)
# ls -l /usr/include/linux/sockios.h
-rw-r--r-- 1 root root 5369 Mar 18 2002 /usr/include/linux/sockios.h
# rpm -qf /usr/include/linux/sockios.h
glibc-kernheaders-2.4-9.1.100.EL
Please note that pretty everything works on this 32bit distro machine,
but a 64bit kernel.
^ permalink raw reply
* Re: [RFC] should we care of COMPAT mode in bridge ?
From: Arnd Bergmann @ 2011-06-06 20:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1307392352.2642.16.camel@edumazet-laptop>
On Monday 06 June 2011 22:32:32 Eric Dumazet wrote:
> In my case, I used latest bridge-utils tree, but compiled on a RHEL4
> machine :)
>
> # ls -l /usr/include/linux/sockios.h
> -rw-r--r-- 1 root root 5369 Mar 18 2002 /usr/include/linux/sockios.h
> # rpm -qf /usr/include/linux/sockios.h
> glibc-kernheaders-2.4-9.1.100.EL
>
> Please note that pretty everything works on this 32bit distro machine,
> but a 64bit kernel.
>
Ok, that is indeed an excellent reason to make it work.
Arnd
^ 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