* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Eric Dumazet @ 2011-11-22 22:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Christian Kujau, Christoph Lameter, Markus Trippelsdorf, Alex,Shi,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, Pekka Enberg,
Matt Mackall, netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <1322000195.14573.13.camel@pasglop>
Le mercredi 23 novembre 2011 à 09:16 +1100, Benjamin Herrenschmidt a
écrit :
> Yes, please try the patch with SLUB and let us know if it makes a
> difference.
>
> Eric, Christoph, the generic version of this_cpu_cmpxchg() is not
> interrupt safe, so I suppose this patch should go in right ?
>
Sure. Dont worry, Christoph is the slub maintainer :)
--
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: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Christoph Lameter @ 2011-11-22 22:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Christian Kujau, Eric Dumazet, Markus Trippelsdorf, Alex,Shi,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, Pekka Enberg,
Matt Mackall, netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <1322000195.14573.13.camel@pasglop>
On Wed, 23 Nov 2011, Benjamin Herrenschmidt wrote:
> Eric, Christoph, the generic version of this_cpu_cmpxchg() is not
> interrupt safe, so I suppose this patch should go in right ?
Correct.
--
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: [PATCH net-next] Sweep away N/A fw_version dustbunnies from the .get_drvinfo routine of a number of drivers
From: Rick Jones @ 2011-11-22 22:35 UTC (permalink / raw)
To: Francois Romieu; +Cc: Rick Jones, netdev
In-Reply-To: <20111122222235.GA24136@electric-eye.fr.zoreil.com>
On 11/22/2011 02:22 PM, Francois Romieu wrote:
> Rick Jones<raj@tardy.cup.hp.com> :
> [...]
>> Per discussion with Ben Hutchings and David Miller, go through and
>> remove assignments of "N/A" to fw_version in various drivers'
>> .get_drvinfo routines. While there clean-up some use of bare
>> constants and such.
>
> Any reason why drivers/net/ethernet/realtek/r8169.c is left in the
> cold ?
No specific reason. I might not have caught it with my find/grep, or it
might not have been built in my build environment - after I cloned
net-next, I brought the .config file from my 64-bit ubuntu virtual
system to the BE (been bringing it along rather like sourdough starter),
did a make oldconfig, took all the defaults, did a "make" and then only
modified those files for which I found the "N/A" in the .c file and
which had a corresponding .o - that way I "knew" that my changes would
at least be compiled subsequently and so minimizing the chances of
incurring davem's wrath by sending him non-compiling code :)
rick jones
^ permalink raw reply
* Re: pull request: wireless 2011-11-22 #2
From: David Miller @ 2011-11-22 22:37 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20111122215611.GI8452@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 22 Nov 2011 16:56:12 -0500
> Here is the latest batch of fixes intended for 3.2. This includes a
> correction for a user-visible error in mac80211's debugfs info, a fix
> for a potential memory corrupter in prism54, an endian fix for rt2x00,
> an endian fix for mac80211, a fix for a NULL derefernce in cfg80211, a
> locking fix for p54spi and a deadlock fix also for p54spi.
>
> This reverts the problematic rt2x00 patches from the earlier pull
> request.
>
> Please let me know if there are problems!
I'm still seeing the problematic rt2x00 changes when I pull:
[davem@boricha net]$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
remote: Counting objects: 112, done.
remote: Compressing objects: 100% (82/82), done.
remote: Total 82 (delta 71), reused 0 (delta 0)
Unpacking objects: 100% (82/82), done.
>From git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
* branch for-davem -> FETCH_HEAD
Updating 5eccdf5..02f1ce3
Fast-forward
drivers/net/wireless/p54/p54spi.c | 5 +++--
drivers/net/wireless/prism54/isl_ioctl.c | 2 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 2 +-
net/mac80211/debugfs_sta.c | 4 ++--
net/mac80211/status.c | 8 ++++----
net/wireless/reg.c | 4 ++++
6 files changed, 15 insertions(+), 10 deletions(-)
[davem@boricha net]$ git format-patch ORIG_HEAD
0001-rt2800pci-handle-spurious-interrupts.patch
0002-rt2x00-handle-spurious-pci-interrupts.patch
0003-rt2x00-Fix-efuse-EEPROM-reading-on-PPC32.patch
0004-p54spi-Add-missing-spin_lock_init.patch
0005-p54spi-Fix-workqueue-deadlock.patch
0006-mac80211-Fix-AMSDU-rate-printout-in-debugfs.patch
0007-mac80211-Fix-endian-bug-in-radiotap-header-generatio.patch
0008-cfg80211-fix-regulatory-NULL-dereference.patch
0009-prism54-potential-memory-corruption-in-prism54_get_e.patch
0010-Revert-rt2x00-handle-spurious-pci-interrupts.patch
0011-Revert-rt2800pci-handle-spurious-interrupts.patch
[davem@boricha net]$ head 0001-rt2800pci-handle-spurious-interrupts.patch
>From 4ba7d9997869d25bd223dea7536fc1ce9fab3b3b Mon Sep 17 00:00:00 2001
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Wed, 16 Nov 2011 11:09:17 +0100
Subject: [PATCH 01/11] rt2800pci: handle spurious interrupts
Some devices may generate spurious interrupts, we have to handle them
otherwise interrupt line will be disabled with below message and driver
will not work:
[ 2052.114334] irq 17: nobody cared (try booting with the "irqpoll" option)
[davem@boricha net]$
^ permalink raw reply
* Re: [PATCH net-next] atm: use SKB_TRUESIZE() in atm_guess_pdu2truesize()
From: chas williams - CONTRACTOR @ 2011-11-22 22:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1321994034.19663.9.camel@edumazet-laptop>
On Tue, 22 Nov 2011 21:33:54 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 22 novembre 2011 à 15:22 -0500, chas williams - CONTRACTOR a
> écrit :
> > it doesnt seem like a good idea to create a wrapper for a one to one
> > call. perhaps this whole bit of nonsense should be removed. the
> > iphase driver should be returning skb->truesize like everyone.
> >
> > if atm_alloc_charge() just uses SKB_TRUESIZE() then we konw that guess
> > will be the same as skb->truesize and atm_alloc_charge() can be
> > simplified by removing atomic_add(skb->truesize - guess, which will be
> > 0 in all cases.
> >
>
> Please note I didnt create a wrapper, only correct existing one :)
>
> Feel free to send a (tested) patch, but be warned that following code is
> not correct :
>
> int size = something;
>
> struct sk_buff *skb = skb_alloc(size);
>
> ASSERT(skb->truesize == SKB_TRUESIZE(size));
>
> (It might be true with SLOB only)
perhaps it is best to say that you discovered an inadvertent wrapper.
given skb->truesize != SKB_TRUESIZE() for all cases, it is certainly
wrong in the iphase driver to return the guessed value. it should be
returning skb->truesize. i will send along a patch shortly to just get
rid of this function.
^ permalink raw reply
* Re: pull request: wireless 2011-11-22 #2
From: John W. Linville @ 2011-11-22 22:41 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20111122.173729.1155753802137219940.davem@davemloft.net>
On Tue, Nov 22, 2011 at 05:37:29PM -0500, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Tue, 22 Nov 2011 16:56:12 -0500
>
> > Here is the latest batch of fixes intended for 3.2. This includes a
> > correction for a user-visible error in mac80211's debugfs info, a fix
> > for a potential memory corrupter in prism54, an endian fix for rt2x00,
> > an endian fix for mac80211, a fix for a NULL derefernce in cfg80211, a
> > locking fix for p54spi and a deadlock fix also for p54spi.
> >
> > This reverts the problematic rt2x00 patches from the earlier pull
> > request.
> >
> > Please let me know if there are problems!
>
> I'm still seeing the problematic rt2x00 changes when I pull:
>
> [davem@boricha net]$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
> remote: Counting objects: 112, done.
> remote: Compressing objects: 100% (82/82), done.
> remote: Total 82 (delta 71), reused 0 (delta 0)
> Unpacking objects: 100% (82/82), done.
> From git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
> * branch for-davem -> FETCH_HEAD
> Updating 5eccdf5..02f1ce3
> Fast-forward
> drivers/net/wireless/p54/p54spi.c | 5 +++--
> drivers/net/wireless/prism54/isl_ioctl.c | 2 +-
> drivers/net/wireless/rt2x00/rt2800lib.c | 2 +-
> net/mac80211/debugfs_sta.c | 4 ++--
> net/mac80211/status.c | 8 ++++----
> net/wireless/reg.c | 4 ++++
> 6 files changed, 15 insertions(+), 10 deletions(-)
> [davem@boricha net]$ git format-patch ORIG_HEAD
> 0001-rt2800pci-handle-spurious-interrupts.patch
> 0002-rt2x00-handle-spurious-pci-interrupts.patch
They're here...
> 0003-rt2x00-Fix-efuse-EEPROM-reading-on-PPC32.patch
> 0004-p54spi-Add-missing-spin_lock_init.patch
> 0005-p54spi-Fix-workqueue-deadlock.patch
> 0006-mac80211-Fix-AMSDU-rate-printout-in-debugfs.patch
> 0007-mac80211-Fix-endian-bug-in-radiotap-header-generatio.patch
> 0008-cfg80211-fix-regulatory-NULL-dereference.patch
> 0009-prism54-potential-memory-corruption-in-prism54_get_e.patch
> 0010-Revert-rt2x00-handle-spurious-pci-interrupts.patch
> 0011-Revert-rt2800pci-handle-spurious-interrupts.patch
And I revert them here.
Linus always says to live with our mistakes? I was trying to avoid
a rebase both for my own pain and that of my downstream maintainers.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH net-next-2.6] atm: eliminate atm_guess_pdu2truesize()
From: chas williams - CONTRACTOR @ 2011-11-22 22:51 UTC (permalink / raw)
To: netdev; +Cc: David Miller
From: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Signed-off-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
---
drivers/atm/iphase.c | 4 ++--
include/linux/atmdev.h | 10 ----------
net/atm/atm_misc.c | 2 +-
3 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/atm/iphase.c b/drivers/atm/iphase.c
index 3d0c2b0..9e373ba 100644
--- a/drivers/atm/iphase.c
+++ b/drivers/atm/iphase.c
@@ -1320,8 +1320,8 @@ static void rx_dle_intr(struct atm_dev *dev)
if (ia_vcc == NULL)
{
atomic_inc(&vcc->stats->rx_err);
+ atm_return(vcc, skb->truesize);
dev_kfree_skb_any(skb);
- atm_return(vcc, atm_guess_pdu2truesize(len));
goto INCR_DLE;
}
// get real pkt length pwang_test
@@ -1334,8 +1334,8 @@ static void rx_dle_intr(struct atm_dev *dev)
atomic_inc(&vcc->stats->rx_err);
IF_ERR(printk("rx_dle_intr: Bad AAL5 trailer %d (skb len %d)",
length, skb->len);)
+ atm_return(vcc, skb->truesize);
dev_kfree_skb_any(skb);
- atm_return(vcc, atm_guess_pdu2truesize(len));
goto INCR_DLE;
}
skb_trim(skb, length);
diff --git a/include/linux/atmdev.h b/include/linux/atmdev.h
index 43ea1b2..f4ff882 100644
--- a/include/linux/atmdev.h
+++ b/include/linux/atmdev.h
@@ -445,16 +445,6 @@ void vcc_insert_socket(struct sock *sk);
void atm_dev_release_vccs(struct atm_dev *dev);
-/*
- * This is approximately the algorithm used by alloc_skb.
- *
- */
-
-static inline int atm_guess_pdu2truesize(int size)
-{
- return SKB_TRUESIZE(size);
-}
-
static inline void atm_force_charge(struct atm_vcc *vcc,int truesize)
{
diff --git a/net/atm/atm_misc.c b/net/atm/atm_misc.c
index f41f026..876fbe8 100644
--- a/net/atm/atm_misc.c
+++ b/net/atm/atm_misc.c
@@ -26,7 +26,7 @@ struct sk_buff *atm_alloc_charge(struct atm_vcc *vcc, int pdu_size,
gfp_t gfp_flags)
{
struct sock *sk = sk_atm(vcc);
- int guess = atm_guess_pdu2truesize(pdu_size);
+ int guess = SKB_TRUESIZE(pdu_size);
atm_force_charge(vcc, guess);
if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf) {
--
1.7.6
^ permalink raw reply related
* Re: [patch v2 1/1] fix error handle in ip_mc_add_src()
From: Jun Zhao @ 2011-11-22 23:08 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, dlstevens
In-Reply-To: <20111122.162237.1924632736368263053.davem@davemloft.net>
On Tue, 2011-11-22 at 16:22 -0500, David Miller wrote:
> From: Jun Zhao <mypopydev@gmail.com>
> Date: Tue, 22 Nov 2011 00:05:16 +0800
>
> > from: Jun Zhao <mypopydev@gmail.com>
> >
> > When add sources to interface failure, need to roll back the sfcount[MODE]
> > to before state. We need to match it corresponding.
> >
> > Acked-by: David L Stevens <dlstevens@us.ibm.com>
> > Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> > Signed-off-by: Jun Zhao <mypopydev@gmail.com>
>
> Please use an appropriate prefix in your subject line after the
> closing "]" bracket. For example, something like "ipv4: " for this
> specific patch is fine.
>
> Your patch has also been corrupted by your email client, it turned tab
> characters into spaces amongst other things. Please correct this,
> email a test patch to yourself, and make absolutely sure you are able
> to successfully apply it before you retry submitting your fix here.
>
> Thank you.
Ok, I will double-check this according to your comments, after that,
re-submit the patch, Tks.
^ permalink raw reply
* Re: [PATCH net-next 4/4] net: Add Open vSwitch kernel components.
From: Jesse Gross @ 2011-11-22 23:11 UTC (permalink / raw)
To: jhs-jkUAjuhPggJWk0Htik3J/w
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
David S. Miller
In-Reply-To: <1321878007.2291.12.camel@mojatatu>
On Mon, Nov 21, 2011 at 4:20 AM, jamal <hadi@cyberus.ca> wrote:
> On Fri, 2011-11-18 at 15:12 -0800, Jesse Gross wrote:
>> Open vSwitch is a multilayer Ethernet switch targeted at virtualized
>> environments. In addition to supporting a variety of features
>> expected in a traditional hardware switch, it enables fine-grained
>> programmatic extension and flow-based control of the network.
>> This control is useful in a wide variety of applications but is
>> particularly important in multi-server virtualization deployments,
>> which are often characterized by highly dynamic endpoints and the need
>> to maintain logical abstractions for multiple tenants.
>>
>> The Open vSwitch datapath provides an in-kernel fast path for packet
>> forwarding. It is complemented by a userspace daemon, ovs-vswitchd,
>> which is able to accept configuration from a variety of sources and
>> translate it into packet processing rules.
>>
>
> So the last time we had a discussion on this on the list, we seemed
> to agree that you could use the tc classifier-action infrastructure.
> For simplicity, we agreed you will need to do a speacilized classifier.
> You may need to add a few more actions. What happened since?
>
> You are replicating a lot of code and semantic that exist (not just on
> classifier actions). You could improve the exisiting infrastructure
> instead. We are eventually going to have two competing interfaces as
> a result. You may only need 1 or 2 different classification schemes
> today and try to justify you need it for simplicity - but in a few
> months you'll need one more then another action and another and
> you'll keep adding to your infrastructure.
As you mention, one of the biggest benefits of Open vSwitch is how
simple the kernel portions are (it's less than 6000 lines). It's
existed as an out-of-tree project for several years now so it's
actually fairly mature already and unlikely that there will be a
sudden influx of new code over the coming months. There's already
quite a bit of functionality that has been implemented on top of it
and it's been mentioned that several other components can be written
in terms of it so I think that it's fairly generic infrastructure that
can be used in many ways. Over time, I think it will result in a net
reduction of code in the kernel as the design is heavily focused on
delegating work to userspace.
I would view it as similar in many ways to the recently added team
device, which is based on the idea of keeping simple things simple.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH net-next 4/4] net: Add Open vSwitch kernel components.
From: Jesse Gross @ 2011-11-22 23:11 UTC (permalink / raw)
To: jhs-jkUAjuhPggJWk0Htik3J/w
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
David S. Miller
In-Reply-To: <1321878574.2291.15.camel@mojatatu>
On Mon, Nov 21, 2011 at 4:29 AM, jamal <hadi-fAAogVwAN2Kw5LPnMra/2Q@public.gmane.org> wrote:
>
> Reading your website - it seems you indicate the code to be portable
> across other platforms. That is a noble reason - but i dont think
> it is good enough a reason in my opinion to have your own
> replicated infrastructure on top of Linux.
It's only the userspace portions that are designed to be portable.
Nothing about the implementation of the kernel module was driven by
portability concerns.
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Christian Kujau @ 2011-11-22 23:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Eric Dumazet, Christoph Lameter, Markus Trippelsdorf, Alex,Shi,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, Pekka Enberg,
Matt Mackall, netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <1321999085.14573.2.camel@pasglop>
On Wed, 23 Nov 2011 at 08:58, Benjamin Herrenschmidt wrote:
> > > --- linux-2.6.orig/mm/slub.c 2011-11-21 21:15:41.575673204 -0600
> > > +++ linux-2.6/mm/slub.c 2011-11-21 21:16:33.442336849 -0600
[...]
> > > - } while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
> > > + } while (irqsafe_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
>
> Christian, can you try it see if that helps in your case ?
Only this one-liner from Christoph or any of the other patches that were
proposed in this thread?
Will test...but this might take a while...
Christian.
--
BOFH excuse #214:
Fluorescent lights are generating negative ions. If turning them off doesn't work, take them out and put tin foil on the ends.
--
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: softirq oops from b44_poll
From: Xander Hover @ 2011-11-22 23:16 UTC (permalink / raw)
To: David Miller; +Cc: peter.p.waskiewicz.jr, linux-kernel, netdev
In-Reply-To: <20111122.155426.1153643155035648664.davem@davemloft.net>
Indeed will the in_irq() test will force dev_kfree_skb_any() to call
dev_kfree_skb_irq().
The kernel warning before this patch was applied, was also trigged by
a WARN_ON_ONCE(in_irq()).
I think David is right on this one.
On Tue, Nov 22, 2011 at 9:54 PM, David Miller <davem@davemloft.net> wrote:
> From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Date: Mon, 21 Nov 2011 15:17:33 -0800
>
>> I suspect the "right" way to fix this is to call dev_kfree_skb_any(skb);
>> instead, since that will handle the in-interrupt case if that's where
>> we're stuck.
>
> Caller is always b44_poll(), and that caller always does spin_lock_irqsave().
>
> Adding the extra tests implied by dev_kfree_skb_any() therefore doesn't
> make any sense, as it will always evaluate to dev_kfree_skb_irq().
>
^ permalink raw reply
* Re: pull request: wireless 2011-11-22 #2
From: David Miller @ 2011-11-22 23:17 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20111122224108.GJ8452@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 22 Nov 2011 17:41:08 -0500
> On Tue, Nov 22, 2011 at 05:37:29PM -0500, David Miller wrote:
> ...
> They're here...
>
>> 0003-rt2x00-Fix-efuse-EEPROM-reading-on-PPC32.patch
>> 0004-p54spi-Add-missing-spin_lock_init.patch
>> 0005-p54spi-Fix-workqueue-deadlock.patch
>> 0006-mac80211-Fix-AMSDU-rate-printout-in-debugfs.patch
>> 0007-mac80211-Fix-endian-bug-in-radiotap-header-generatio.patch
>> 0008-cfg80211-fix-regulatory-NULL-dereference.patch
>> 0009-prism54-potential-memory-corruption-in-prism54_get_e.patch
>> 0010-Revert-rt2x00-handle-spurious-pci-interrupts.patch
>> 0011-Revert-rt2800pci-handle-spurious-interrupts.patch
>
> And I revert them here.
>
> Linus always says to live with our mistakes? I was trying to avoid
> a rebase both for my own pain and that of my downstream maintainers.
Gotcha, I'll repull, thanks.
^ permalink raw reply
* Re: [GIT PULL v2] Open vSwitch
From: Stephen Hemminger @ 2011-11-22 23:18 UTC (permalink / raw)
To: David Miller; +Cc: jesse, netdev, dev
In-Reply-To: <20111122.155006.361847516719132107.davem@davemloft.net>
Maybe someone with more insight than me can explain the relationship
between Openflow and Open vSwitch. It maybe that the portability
of Openflow makes the old qdisc, classifiers to use/implement.
^ permalink raw reply
* Re: [PATCH net-next 4/4] net: Add Open vSwitch kernel components.
From: David Miller @ 2011-11-22 23:19 UTC (permalink / raw)
To: jesse-l0M0P4e3n4LQT0dZR+AlfA
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
jhs-jkUAjuhPggJWk0Htik3J/w
In-Reply-To: <CAEP_g=8puZh8hihoyoHTc4f6cBu4jiDJQ6tqk6suQxR=dchyjA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Date: Tue, 22 Nov 2011 15:11:33 -0800
> As you mention, one of the biggest benefits of Open vSwitch is how
> simple the kernel portions are (it's less than 6000 lines). It's
> existed as an out-of-tree project for several years now so it's
> actually fairly mature already and unlikely that there will be a
> sudden influx of new code over the coming months.
The packet scheduler classification and packet action infrastructure
has been around 5 times longer.
^ permalink raw reply
* [PATCH net-next] corral some wayward N/A fw_version dust bunnies
From: Rick Jones @ 2011-11-23 0:06 UTC (permalink / raw)
To: netdev, Francois Romieu, Jon Mason
From: Rick Jones <rick.jones2@hp.com>
Round-up some wayward "N/A" fw_version dust bunnies as part of that
clean-up.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
---
Compiled only.
diff --git a/drivers/net/ethernet/neterion/s2io.c b/drivers/net/ethernet/neterion/s2io.c
index 76ae476..97f63e1 100644
--- a/drivers/net/ethernet/neterion/s2io.c
+++ b/drivers/net/ethernet/neterion/s2io.c
@@ -5393,7 +5393,6 @@ static void s2io_ethtool_gdrvinfo(struct net_device *dev,
strlcpy(info->driver, s2io_driver_name, sizeof(info->driver));
strlcpy(info->version, s2io_driver_version, sizeof(info->version));
- strlcpy(info->fw_version, "", sizeof(info->fw_version));
strlcpy(info->bus_info, pci_name(sp->pdev), sizeof(info->bus_info));
info->regdump_len = XENA_REG_SPACE;
info->eedump_len = XENA_EEPROM_SPACE;
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index f7bc310..e5a6d8e 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1405,8 +1405,9 @@ static void rtl8169_get_drvinfo(struct net_device *dev,
strlcpy(info->version, RTL8169_VERSION, sizeof(info->version));
strlcpy(info->bus_info, pci_name(tp->pci_dev), sizeof(info->bus_info));
BUILD_BUG_ON(sizeof(info->fw_version) < sizeof(rtl_fw->version));
- strlcpy(info->fw_version, IS_ERR_OR_NULL(rtl_fw) ? "N/A" :
- rtl_fw->version, sizeof(info->fw_version));
+ if (!IS_ERR_OR_NULL(rtl_fw))
+ strlcpy(info->fw_version, rtl_fw->version,
+ sizeof(info->fw_version));
}
static int rtl8169_get_regs_len(struct net_device *dev)
^ permalink raw reply related
* Missing TCP SYN on loopback, retransmits after 1s
From: Jesse Young @ 2011-11-23 0:13 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2855 bytes --]
Hi all,
I am experiencing packet loss over TCP/IPv[46], which causes 1 second
delays when connect()ing to a socket. This happens even on loopback, and
on multiple kernels. On the older kernels, the connect() time is nearly
3 seconds, I believe this is due to a recent TCP connect retrasmit
parameter changed in the kernel.
1. Linux dc-s1000-2114 2.6.32-35-server #78-Ubuntu SMP Tue Oct 11
16:26:12 UTC 2011 x86_64 GNU/Linux
2. Linux dc-a1000-2131.cleversafelabs.com 2.6.39.4-2-clevos+ #1 SMP
Tue Nov 8 09:06:49 CST 2011 x86_64 x86_64 x86_64 GNU/Linux
3. Linux telperion.jlyo.org 3.1.0-4-ARCH #1 SMP PREEMPT Mon Nov 7
22:47:18 CET 2011 x86_64 Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
GenuineIntel GNU/Linux
I have created some test cases which reify this problem, the first set
of tests use select() multiplexing, and have some problems, however,
they exhibit odd behavior as well, especially in the difference between
tcp4 and tcp6.
Please note: these tests will quickly exaust the amount of available
ephemeral TCP ports on your system, which will cause any TCP connect()
calls in other processes to return with EADDRNOTAVAIL. However, ports
will become available after a short while.
The first test fails super quick, while the others haven't timed out
so far. NOTE: The second test requires /proc/sys/net/ipv6/bindv6only
to be set to 1.
./packetloss :: ::1
./packetloss :: 127.0.0.1
./packetloss 0.0.0.0 127.0.0.1
The other tests run a client and server in different processes.
Run the "close" daemon using one of:
./closed ::
./closed 0.0.0.0
And flood connect() pings against 8009, the port closed listens on.
./tcping -f -p8009 ::1
./tcping -f -p8009 127.0.0.1
Wait for a pause, then ^C, and notice the max statistic is ~1000ms.
These tests have been rn between machines on a relativley noiseless
ethernet LAN with similar results.
What's also puzzling, is that I see no packet drop reporting in
$ ifconfig lo
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436 metric 1
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 276411482 bytes 15822880567 (14.7 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 276411482 bytes 15822880567 (14.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions
I'm thinking this may be a bug in the TCP/IP stack, however, I'm not
certain if I'm missing a socket option, or some other configuration
that may elimiate this behavior.
If there's anything else I can help you with, please don't hesitate
to Cc me.
Thanks,
Jesse
Attached: syndrop.pcap
Get the code here
https://github.com/jlyo/packetloss
git clone git://github.com/jlyo/packetloss.git
https://github.com/jlyo/tcping
git clone git://github.com/jlyo/tcping.git
https://github.com/jlyo/closed
git clone git://github.com/jlyo/closed.git
[-- Attachment #2: syndrop.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 622 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2011-11-23 0:17 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Maciej Żenczykowski,
Alexey Dobriyan
[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/ipv4/inet_diag.c between commit 717b6d836646 ("net-netlink: fix diag
to export IPv4 tos for dual-stack IPv6 sockets") from the net tree and
commit 4e3fd7a06dc2 ("net: remove ipv6_addr_copy()") from the net-next
tree.
Just context changes. I fixed it up (see below) can can carry the fix as
necessary,
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/ipv4/inet_diag.c
index ccee270,bbebdec..0000000
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@@ -132,13 -129,10 +132,11 @@@ static int inet_csk_diag_fill(struct so
if (r->idiag_family == AF_INET6) {
const struct ipv6_pinfo *np = inet6_sk(sk);
- *(struct in6_addr *)r->id.idiag_src = np->rcv_saddr;
- *(struct in6_addr *)r->id.idiag_dst = np->daddr;
if (ext & (1 << (INET_DIAG_TCLASS - 1)))
RTA_PUT_U8(skb, INET_DIAG_TCLASS, np->tclass);
+
- ipv6_addr_copy((struct in6_addr *)r->id.idiag_src,
- &np->rcv_saddr);
- ipv6_addr_copy((struct in6_addr *)r->id.idiag_dst,
- &np->daddr);
++ *(struct in6_addr *)r->id.idiag_src = np->rcv_saddr;
++ *(struct in6_addr *)r->id.idiag_dst = np->daddr;
}
#endif
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Benjamin Herrenschmidt @ 2011-11-23 0:18 UTC (permalink / raw)
To: Christian Kujau
Cc: Eric Dumazet, Christoph Lameter, Markus Trippelsdorf, Alex,Shi,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, Pekka Enberg,
Matt Mackall, netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <alpine.DEB.2.01.1111221511070.8000@trent.utfs.org>
On Tue, 2011-11-22 at 15:12 -0800, Christian Kujau wrote:
> On Wed, 23 Nov 2011 at 08:58, Benjamin Herrenschmidt wrote:
> > > > --- linux-2.6.orig/mm/slub.c 2011-11-21 21:15:41.575673204 -0600
> > > > +++ linux-2.6/mm/slub.c 2011-11-21 21:16:33.442336849 -0600
> [...]
> > > > - } while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
> > > > + } while (irqsafe_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
> >
> > Christian, can you try it see if that helps in your case ?
>
> Only this one-liner from Christoph or any of the other patches that were
> proposed in this thread?
>
> Will test...but this might take a while...
I'd say only this one liner for now, just don't do slabinfo :-) I just
want to see whether your network + heavy IO load problem goes away with
that one patch.
Thanks !
Cheers,
Ben.
--
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: Missing TCP SYN on loopback, retransmits after 1s
From: David Miller @ 2011-11-23 0:23 UTC (permalink / raw)
To: jlyo; +Cc: netdev
In-Reply-To: <20111122181320.38a70cf8@telperion.jlyo.org>
From: Jesse Young <jlyo@jlyo.org>
Date: Tue, 22 Nov 2011 18:13:20 -0600
> What's also puzzling, is that I see no packet drop reporting in
> $ ifconfig lo
> lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436 metric 1
> inet 127.0.0.1 netmask 255.0.0.0
> inet6 ::1 prefixlen 128 scopeid 0x10<host>
> loop txqueuelen 0 (Local Loopback)
> RX packets 276411482 bytes 15822880567 (14.7 GiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 276411482 bytes 15822880567 (14.7 GiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions
The device driver therefore isn't even seeing the packets, they are
being dropped elsewhere.
Why is this "puzzling"?
There's layers upon layers and thousands of places where packets can
be dropped between the originating network stack and the actual device
driver.
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: David Miller @ 2011-11-23 0:23 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, maze, adobriyan
In-Reply-To: <20111123111751.60b1e8ba032f6077fa03ca13@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 23 Nov 2011 11:17:51 +1100
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> net/ipv4/inet_diag.c between commit 717b6d836646 ("net-netlink: fix diag
> to export IPv4 tos for dual-stack IPv6 sockets") from the net tree and
> commit 4e3fd7a06dc2 ("net: remove ipv6_addr_copy()") from the net-next
> tree.
>
> Just context changes. I fixed it up (see below) can can carry the fix as
> necessary,
Yep, I anticipated this one too, thanks Stephen.
^ permalink raw reply
* Re: [PATCH net-next] Sweep away N/A fw_version dustbunnies from the .get_drvinfo routine of a number of drivers
From: Rick Jones @ 2011-11-23 0:32 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <4ECC23AB.5060808@hp.com>
On 11/22/2011 02:35 PM, Rick Jones wrote:
> On 11/22/2011 02:22 PM, Francois Romieu wrote:
>> Rick Jones<raj@tardy.cup.hp.com> :
>> [...]
>>> Per discussion with Ben Hutchings and David Miller, go through and
>>> remove assignments of "N/A" to fw_version in various drivers'
>>> .get_drvinfo routines. While there clean-up some use of bare
>>> constants and such.
>>
>> Any reason why drivers/net/ethernet/realtek/r8169.c is left in the
>> cold ?
>
> No specific reason. I might not have caught it with my find/grep, or it
> might not have been built in my build environment - after I cloned
> net-next, I brought the .config file from my 64-bit ubuntu virtual
> system to the BE (been bringing it along rather like sourdough starter),
> did a make oldconfig, took all the defaults, did a "make" and then only
> modified those files for which I found the "N/A" in the .c file and
> which had a corresponding .o - that way I "knew" that my changes would
> at least be compiled subsequently and so minimizing the chances of
> incurring davem's wrath by sending him non-compiling code :)
I've sent a follow-up patch under separate cover.
FWIW, there are a number of other drivers which don't seem to be enabled
by the .config I'm using, so I've not done any clean-ups on those. Is
there an easy way to light them all up?
rick
^ permalink raw reply
* Re: Missing TCP SYN on loopback, retransmits after 1s
From: Jesse Young @ 2011-11-23 0:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111122.192338.1206677511966747729.davem@davemloft.net>
On Tue, 22 Nov 2011 19:23:38 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> From: Jesse Young <jlyo@jlyo.org>
> Date: Tue, 22 Nov 2011 18:13:20 -0600
>
> > What's also puzzling, is that I see no packet drop reporting in
> > $ ifconfig lo
> > lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436 metric 1
> > inet 127.0.0.1 netmask 255.0.0.0
> > inet6 ::1 prefixlen 128 scopeid 0x10<host>
> > loop txqueuelen 0 (Local Loopback)
> > RX packets 276411482 bytes 15822880567 (14.7 GiB)
> > RX errors 0 dropped 0 overruns 0 frame 0
> > TX packets 276411482 bytes 15822880567 (14.7 GiB)
> > TX errors 0 dropped 0 overruns 0 carrier 0 collisions
>
> The device driver therefore isn't even seeing the packets, they are
> being dropped elsewhere.
>
> Why is this "puzzling"?
>
> There's layers upon layers and thousands of places where packets can
> be dropped between the originating network stack and the actual device
> driver.
Maybe puzzling isn't the best word... just some more relevant
information. Also, this is the loopback interface, there is no device
driver, PHY or DLL layer in question here (just the loopback's mock
driver/PHY/DLL).
I presume that the drop is occuring in between the NET layer, and the sys
call interface, do you agree? Where should I begin looking?
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Christian Kujau @ 2011-11-23 1:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Eric Dumazet, Christoph Lameter, Markus Trippelsdorf, Alex,Shi,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, Pekka Enberg,
Matt Mackall, netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <1322007501.14573.15.camel@pasglop>
On Wed, 23 Nov 2011 at 11:18, Benjamin Herrenschmidt wrote:
> I'd say only this one liner for now, just don't do slabinfo :-)
It's still building, for 2hrs now, must be those debug options I added, a
"normal" build on this machine "only" takes 30min otherwise. Unfortunately
I failed to setup a crosscompile env with the latest crosstool checkout :(
> I just want to see whether your network + heavy IO load problem goes
> away with that one patch.
Sorry, I should have been clearer in that mail: the high "load" value
isn't a problem - the intermittent panics are. What I meant to say was:
the panics usually occur when lots of disk & cpu IO is in progress (rsync
to an external but local disk over firewire). While doing this the load is
usally at 3-5, but that's "normal" and expected for a machine of that age.
But then the machine crashes with recent kernels. After setting the
cpu_partial files to 0 I tried to reproduce the same I/O pattern, *plus* a
bit more, to really stress the machine, so load went up to 6-7 and the
machine did not crash. So the load of 6-7 was expected and I'm glad that
the machine did not crash with that workaround. I don't know of the
implications of setting cpu_partial to 0 though.
As soon as the build with Christoph's one-liner is done I'll test w/o
setting cpu_partial to 0 and see what it gives.
Thanks,
Christian.
--
BOFH excuse #380:
Operators killed when huge stack of backup tapes fell over.
--
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: [PATCH 7/8] net/mlx4_en: adding loopback support
From: Mahesh Bandewar @ 2011-11-23 1:34 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: davem, netdev, ogerlitz, oren, amirv
In-Reply-To: <4ECA0F4A.30308@mellanox.co.il>
On Mon, Nov 21, 2011 at 12:43 AM, Yevgeny Petrilin
<yevgenyp@mellanox.co.il> wrote:
>
> From: Amir Vadai <amirv@mellanox.co.il>
>
> Device must be in promiscious mode or DMAC must be same as the host MAC, or
> else packet will be dropped by the HW rx filtering.
>
> Signed-off-by: Amir Vadai <amirv@mellanox.co.il>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1 +
> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 3 +++
> include/linux/mlx4/qp.h | 1 +
> 3 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 78d776b..55fdbce 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -1088,6 +1088,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
> dev->features = dev->hw_features | NETIF_F_HIGHDMA |
> NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX |
> NETIF_F_HW_VLAN_FILTER;
> + dev->hw_features |= NETIF_F_LOOPBACK;
>
> mdev->pndev[port] = dev;
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> index 3094f94..f9093b5 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> @@ -681,6 +681,9 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
> tx_desc->ctrl.fence_size = (real_size / 16) & 0x3f;
> tx_desc->ctrl.srcrb_flags = cpu_to_be32(MLX4_WQE_CTRL_CQ_UPDATE |
> MLX4_WQE_CTRL_SOLICITED);
> + if (dev->features & NETIF_F_LOOPBACK)
> + tx_desc->ctrl.srcrb_flags |=
> + cpu_to_be32(MLX4_WQE_CTRL_FORCE_LOOPBACK);
This is re-calculated for every xmit. Is it required to be that way?
May be you can pre-calculate it and just assign / add it to the
control-flags here.
> if (likely(skb->ip_summed == CHECKSUM_PARTIAL)) {
> tx_desc->ctrl.srcrb_flags |= cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM |
> MLX4_WQE_CTRL_TCP_UDP_CSUM);
> diff --git a/include/linux/mlx4/qp.h b/include/linux/mlx4/qp.h
> index 6562ff6..bee8fa2 100644
> --- a/include/linux/mlx4/qp.h
> +++ b/include/linux/mlx4/qp.h
> @@ -210,6 +210,7 @@ struct mlx4_wqe_ctrl_seg {
> * [4] IP checksum
> * [3:2] C (generate completion queue entry)
> * [1] SE (solicited event)
> + * [0] FL (force loopback)
> */
> __be32 srcrb_flags;
> /*
> --
> 1.7.7
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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