* [PATCH 4/3] rtnetlink: ignore NETDEV_RELEASE and NETDEV_JOIN event
From: Amerigo Wang @ 2011-05-20 9:06 UTC (permalink / raw)
To: netdev; +Cc: WANG Cong
In-Reply-To: <1305877152-30970-1-git-send-email-amwang@redhat.com>
These two events are not expected to be caught by userspace.
Signed-off-by: WANG Cong <amwang@redhat.com>
---
net/core/rtnetlink.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index d2ba259..d1644e3 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1956,6 +1956,8 @@ static int rtnetlink_event(struct notifier_block *this, unsigned long event, voi
case NETDEV_GOING_DOWN:
case NETDEV_UNREGISTER:
case NETDEV_UNREGISTER_BATCH:
+ case NETDEV_RELEASE:
+ case NETDEV_JOIN:
break;
default:
rtmsg_ifinfo(RTM_NEWLINK, dev, 0);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next-2.6] net: avoid synchronize_rcu() in dev_deactivate_many
From: Eric Dumazet @ 2011-05-20 9:42 UTC (permalink / raw)
To: David Miller; +Cc: Ben Greear, netdev, Patrick McHardy
dev_deactivate_many() issues one synchronize_rcu() call after qdiscs set
to noop_qdisc.
This call is here to make sure they are no outstanding qdisc-less
dev_queue_xmit calls before returning to caller.
But in dismantle phase, we dont have to wait, because we wont activate
again the device, and we are going to wait one rcu grace period later in
rollback_registered_many().
After this patch, device dismantle uses one synchronize_net() and one
rcu_barrier() call only, so we have a ~30% speedup and a smaller RTNL
latency.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Patrick McHardy <kaber@trash.net>,
CC: Ben Greear <greearb@candelatech.com>
---
net/sched/sch_generic.c | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index c84b659..b1721d7 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -815,9 +815,17 @@ static bool some_qdisc_is_busy(struct net_device *dev)
return false;
}
+/**
+ * dev_deactivate_many - deactivate transmissions on several devices
+ * @head: list of devices to deactivate
+ *
+ * This function returns only when all outstanding transmissions
+ * have completed, unless all devices are in dismantle phase.
+ */
void dev_deactivate_many(struct list_head *head)
{
struct net_device *dev;
+ bool sync_needed = false;
list_for_each_entry(dev, head, unreg_list) {
netdev_for_each_tx_queue(dev, dev_deactivate_queue,
@@ -827,10 +835,15 @@ void dev_deactivate_many(struct list_head *head)
&noop_qdisc);
dev_watchdog_down(dev);
+ sync_needed |= !dev->dismantle;
}
- /* Wait for outstanding qdisc-less dev_queue_xmit calls. */
- synchronize_rcu();
+ /* Wait for outstanding qdisc-less dev_queue_xmit calls.
+ * This is avoided if all devices are in dismantle phase :
+ * Caller will call synchronize_net() for us
+ */
+ if (sync_needed)
+ synchronize_net();
/* Wait for outstanding qdisc_run calls. */
list_for_each_entry(dev, head, unreg_list)
^ permalink raw reply related
* Re: [PATCH] tcp: Expose the initial RTO via a new sysctl.
From: H.K. Jerry Chu @ 2011-05-20 10:27 UTC (permalink / raw)
To: Hagen Paul Pfeifer
Cc: David Miller, tsunanet, kuznet, pekkas, jmorris, yoshfuji, kaber,
netdev, linux-kernel
In-Reply-To: <20110518202025.GC4175@nuttenaction>
On Wed, May 18, 2011 at 1:20 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> * David Miller | 2011-05-18 15:52:00 [-0400]:
>
>>I've already changed the initial TCP congestion window in Linux to 10
>>without some stupid draft being fully accepted.
>>
>>I'll just as easily accept right now a patch right now which lowers
>>the initial RTO to 1 second and adds the 3 second RTO fallback.
>
> I like the idea to make the initial RTO a knob because we in a isolated MANET
> environment have a RTT larger then 1 second. Especially the link layer setup
> procedure over several hops demand some time-costly setup time. After that the
> RTT is <1 second. The current algorithm works great for us. So this RTO change
> will be counterproductive: it will always trigger a needless timeout.
>
> The main problem for us is that Google at all pushing their view of Internet
> with a lot of pressure. The same is true for the IETF IW adjustments, which is
> unsuitable for networks which operates at a bandwidth characteristic some
> years ago. The _former_ conservative principle "TCP over everything" is
> forgotten.
Not sure how our various parameter tuning proposals deviate from the "TCP over
everything" principle?
Note that the design goal of rfc2988bis is to try to benefit 98% of
traffic while
keeping any negative impact to the remaining 2% at a minimum. This is why we
limit the use of < 3sec initRTO to at most once. This way the negative impact
of the 1sec initRTO to a path with RTT > 1sec is limited mostly to one
additional,
small, spuriously retransmitted SYN or SYN-ACK pkt, and the unnecessary
reduction of IW to 1 segment.
We actually thought about removing the IW reduction part but unfortunately the
text belongs to a different rfc5681, which is at a higher maturity
level ("draft-standard")
than rfc2988 hence can't be done as part of rfc2988bis. Anyway I have
since added
the recommendation to the IW10 draft. See draft-ietf-tcpm-initcwnd-01.txt.
The bottom line is the damage of rfc2988bis to any network with
initRTT > 1sec is
limited to one spurious retransmitted SYN/SYN-ACK. In the current Linux code,
the SYN/SYN-ACK retransmit is forgotten on the passive open side by the time
3WHS is completed so there is nothing needed to be done. But for the active
open side SYN retransmit will cause not long IW to be reduced to 1, but also
reduction of ssthresh, which is not part of rfc5681 so some more work is needed.
I can provide a patch (or work with tsuna) to ensure a correct fix is made.
Jerry
>
> Hagen
> --
> 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
* Re: [PATCH] tcp: Expose the initial RTO via a new sysctl.
From: Hagen Paul Pfeifer @ 2011-05-20 11:00 UTC (permalink / raw)
To: H.K. Jerry Chu
Cc: David Miller, tsunanet, kuznet, pekkas, jmorris, yoshfuji, kaber,
netdev, linux-kernel
In-Reply-To: <BANLkTimtA9BB7g5cOm8c9sGChQjf1P0Q-Q@mail.gmail.com>
On Fri, 20 May 2011 03:27:37 -0700, "H.K. Jerry Chu" wrote:
Hi Jerry
> Not sure how our various parameter tuning proposals deviate from the
"TCP
> over everything" principle?
For our environment it hurts because we _always_ have an initial RTO >1. I
understand and accept that 98% will benefit of this modification, no doubt
Jerry! Try to put yourself in our situation: imaging a proposal of an init
RTO modification to 0.5 seconds. Maybe because 98% of Internet traffic is
now localized and the RTO is average now 0.2 seconds. Anyway, this will
penalize your network always and this will be the situation for one of my
customer. I can live with that, I see the benefits for the rest of the
world. But I am happy to see a knob where I can restore the old behavior.
Maybe some other environments will benefit from a even lower or higher
initial RTO.
Hagen
^ permalink raw reply
* Re: [RFC/PATCH 01/13] net: wl12xx: sdio: id_tables should be __devinitconst
From: Luciano Coelho @ 2011-05-20 12:02 UTC (permalink / raw)
To: Felipe Balbi; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1305321990-22041-2-git-send-email-balbi@ti.com>
On Sat, 2011-05-14 at 00:26 +0300, Felipe Balbi wrote:
> That's only needed during init anyway, let's free
> some space after we're done probing.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
Applied, this one. Thanks, Felipe!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [RFC/PATCH 03/13] net: wl12xx: remove some unnecessary prints
From: Luciano Coelho @ 2011-05-20 12:03 UTC (permalink / raw)
To: Felipe Balbi; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1305321990-22041-4-git-send-email-balbi@ti.com>
On Sat, 2011-05-14 at 00:26 +0300, Felipe Balbi wrote:
> Those have little value. Remove those to make
> the driver less noisy.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
Applied also this one. Thanks!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [RFC/PATCH 04/13] net: wl12xx: care for optional operations
From: Luciano Coelho @ 2011-05-20 12:03 UTC (permalink / raw)
To: Felipe Balbi; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1305321990-22041-5-git-send-email-balbi@ti.com>
On Sat, 2011-05-14 at 00:26 +0300, Felipe Balbi wrote:
> ->init and ->reset are optional - at least
> sdio.c doesn't implement them - so allow those
> pointers to be NULL.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
Applied.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [RFC/PATCH 05/13] net: wl12xx: remove the nops
From: Luciano Coelho @ 2011-05-20 12:04 UTC (permalink / raw)
To: Felipe Balbi; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1305321990-22041-6-git-send-email-balbi@ti.com>
On Sat, 2011-05-14 at 00:26 +0300, Felipe Balbi wrote:
> Nops aren't needed. When we actually need
> those calls, then we add them with meat
> and barbecue sauce.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
Applied the parts that are still relevant (some of the calls already
have saucy beef in them ;).
--
Cheers,
Luca.
^ permalink raw reply
* Re: [RFC/PATCH 06/13] net: wl12xx: remove unnecessary prints
From: Luciano Coelho @ 2011-05-20 12:04 UTC (permalink / raw)
To: Felipe Balbi; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1305321990-22041-7-git-send-email-balbi@ti.com>
On Sat, 2011-05-14 at 00:26 +0300, Felipe Balbi wrote:
> Those have little value. Remove those to
> make the driver less noisy.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
Applied, thanks dude!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v3 0/2] Fix uevent race in register_netdevice()
From: Kalle Valo @ 2011-05-20 12:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless, linux-kernel
In-Reply-To: <20110516.141158.1777924960833804150.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Kalle Valo <kvalo@adurom.com>
> Date: Mon, 16 May 2011 17:46:30 +0300
>
>> I'm trying to fix a race in register_netdevice(). The problem is that
>> there's a uevent to userspace before the netdevice is ready for use. The
>> problem is described here:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=15606
>>
>> I have sent few different ways to fix this, but none of them have been
>> really usable. Now I came up with a way which changes the driver core
>> to make it possible send the uevent in a separate call. This is a clean
>> and safe way to fix the race. Downside is that two new functions are
>> added to the driver core interface.
>>
>> Please comment.
>
> This doesn't work.
>
> The sysfs file will still be there before the uevent, so any
> process can go in there, and see the inconsistent state.
I considered that user space would not notice the device until the
uevent is emitted so that wouldn't matter that much.
But it's back to the drawing board again. I'm running out of options
how to do this in a not so intrusive way. Do you have any tips how to
fix the race for good?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] tcp: Expose the initial RTO via a new sysctl.
From: Alan Cox @ 2011-05-20 12:37 UTC (permalink / raw)
To: Hagen Paul Pfeifer
Cc: H.K. Jerry Chu, David Miller, tsunanet, kuznet, pekkas, jmorris,
yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <fc49a1b4c32eee9b5cbfbeec4729eef5@localhost>
> For our environment it hurts because we _always_ have an initial RTO >1. I
> understand and accept that 98% will benefit of this modification, no doubt
> Jerry! Try to put yourself in our situation: imaging a proposal of an init
> RTO modification to 0.5 seconds. Maybe because 98% of Internet traffic is
> now localized and the RTO is average now 0.2 seconds. Anyway, this will
> penalize your network always and this will be the situation for one of my
> customer. I can live with that, I see the benefits for the rest of the
> world. But I am happy to see a knob where I can restore the old behavior.
> Maybe some other environments will benefit from a even lower or higher
> initial RTO.
AX.25 is definitely happier with a multi-second round trip but it's a
special case. Some X.25 networks are going to have similar behaviour.
It shouldn't be penalising each connection (and it's worse than that of
course because each node on a shared media network gets in the way of the
rest, plus the queueing effect of all the extra blockages) because done
right multiple connections to the same host can use the previous
connections as estimates (and indeed for the initial RTO there's a good
argument for treating estimates as 'host, then x.y.z.* match, then
average of previous except the x.y.z.* match, then unknown')
The latter would fix an awful lot of the weird cases pretty effectively.
Alan
^ permalink raw reply
* ppp, "Features changed" flooding the log
From: Denys Fedoryshchenko @ 2011-05-20 13:42 UTC (permalink / raw)
To: netdev
Hi
Is it supposed to be like this?
[ 41.575487] ppp313: Features changed: 0x00006800 -> 0x00006000
[ 41.681499] ppp314: Features changed: 0x00006800 -> 0x00006000
[ 41.796728] ppp315: Features changed: 0x00006800 -> 0x00006000
[ 41.909575] ppp316: Features changed: 0x00006800 -> 0x00006000
[ 42.027802] ppp317: Features changed: 0x00006800 -> 0x00006000
[ 42.142698] ppp318: Features changed: 0x00006800 -> 0x00006000
[ 42.292753] ppp319: Features changed: 0x00006800 -> 0x00006000
[ 42.408706] ppp320: Features changed: 0x00006800 -> 0x00006000
[ 42.544745] ppp321: Features changed: 0x00006800 -> 0x00006000
[ 42.634743] ppp322: Features changed: 0x00006800 -> 0x00006000
[ 42.740747] ppp323: Features changed: 0x00006800 -> 0x00006000
[ 42.856579] ppp324: Features changed: 0x00006800 -> 0x00006000
I guess ppp dropping GSO, but is it should be there on first place?
GSO is disabled on all ethernet interfaces.
^ permalink raw reply
* Re: ppp, "Features changed" flooding the log
From: Denys Fedoryshchenko @ 2011-05-20 13:44 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <a08c037f093701d9a2d187d04ac85fee@visp.net.lb>
On Fri, 20 May 2011 16:42:08 +0300, Denys Fedoryshchenko wrote:
> Hi
>
> Is it supposed to be like this?
> [ 41.575487] ppp313: Features changed: 0x00006800 -> 0x00006000
> [ 41.681499] ppp314: Features changed: 0x00006800 -> 0x00006000
> [ 41.796728] ppp315: Features changed: 0x00006800 -> 0x00006000
> [ 41.909575] ppp316: Features changed: 0x00006800 -> 0x00006000
> [ 42.027802] ppp317: Features changed: 0x00006800 -> 0x00006000
> [ 42.142698] ppp318: Features changed: 0x00006800 -> 0x00006000
> [ 42.292753] ppp319: Features changed: 0x00006800 -> 0x00006000
> [ 42.408706] ppp320: Features changed: 0x00006800 -> 0x00006000
> [ 42.544745] ppp321: Features changed: 0x00006800 -> 0x00006000
> [ 42.634743] ppp322: Features changed: 0x00006800 -> 0x00006000
> [ 42.740747] ppp323: Features changed: 0x00006800 -> 0x00006000
> [ 42.856579] ppp324: Features changed: 0x00006800 -> 0x00006000
>
> I guess ppp dropping GSO, but is it should be there on first place?
> GSO is disabled on all ethernet interfaces.
And as i see GRO enabled there, i guess it can be harmful for shapers,
how to disable it?
NewNet-PPPoE ~ # ethtool -K ppp0 gro off
Cannot set device GRO settings: Operation not supported
Or there is no need for that?
^ permalink raw reply
* Re: ppp, "Features changed" flooding the log
From: Eric Dumazet @ 2011-05-20 14:00 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <e04d91916983d0a9274087cd2f5ef64d@visp.net.lb>
Le vendredi 20 mai 2011 à 16:44 +0300, Denys Fedoryshchenko a écrit :
> And as i see GRO enabled there, i guess it can be harmful for shapers,
> how to disable it?
> NewNet-PPPoE ~ # ethtool -K ppp0 gro off
> Cannot set device GRO settings: Operation not supported
> Or there is no need for that?
> --
No need, since GRO sits on top of NAPI (physical devices)
ppp is done after this layer, frames are directly delivered to IP layer.
But yes, this log flood is nasty.
^ permalink raw reply
* Equity Business Investment
From: PROF.MAURICE IWU @ 2011-05-20 14:43 UTC (permalink / raw)
Equity Business Investment
>From Prof. Maurice Iwu
Dear Friend,
I am Prof. Maurice M. Iwu, Former Chairman Independent Electoral Commission
(INEC).Currently, I am on compulsory terminal leave presently in UK ,
leading up to my final retirement from public service.
I am seeking your partnership in a mutual benefit project involving
investing into your company and secondly on properties and to be precise Estate Development or any other profitable venture of your great idea for our mutual benefit of Equity Market Investment.,
Sincerely,
Prof. Maurice M.Iwu.
{INEC.}
^ permalink raw reply
* Fwd: pktgen with vlan packets
From: Lynch, Jonathan @ 2011-05-20 15:03 UTC (permalink / raw)
To: netdev
In-Reply-To: <BANLkTinybQHjqXe-0SOU4wHTJg0M=QX=ow@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 918 bytes --]
Hi,
Im running 2.6.35 kernel with an Intel 82599 NIC.
I want to send packets using pktgen via a number of vlan interfaces (1
physical interface) created via vconfig but I get an OOPs when I try
and send via the vlan interface. See attached log file for the oops.
Im not using the pgset "vlan_id 77" params because I want to send
packets with more than 1 VLAN tag to one interface. (If it was
possible to send packets with different vlan tags over the one
interface with pktgen I would use it)
my config is as follows:
ifconfig eth4 up
modprobe 8021q
vconfig add eth4 256
ifconfig eth4.256 up
My pktgen config is the exact same as
ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/pktgen.conf-1-1
except that instead of eth1, I have eth4.256.
Any ideas as to how I can send packets with multiple VLAN tags over
the same interface with pktgen?
Regards
Jonathan
[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 5827 bytes --]
1711.681495] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 1711.689373] IP: [<ffffffff81469014>] pfifo_fast_dequeue+0x54/0xa0
[ 1711.695496] PGD 0
[ 1711.697535] Oops: 0002 [#1] SMP
[ 1711.700808] last sysfs file: /sys/devices/virtual/net/eth4.256/type
[ 1711.707078] CPU 0
[ 1711.708923] Modules linked in: pktgen 8021q garp stp nls_cp437 cifs ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ixgbe iptable_filter ip_tables x_tables ioatdma lp dca mdio parport e1000e
[ 1711.729308]
[ 1711.730806] Pid: 10970, comm: kpktgend_0 Not tainted 2.6.35 #1 Greencity/Greencity
[ 1711.738379] RIP: 0010:[<ffffffff81469014>] [<ffffffff81469014>] pfifo_fast_dequeue+0x54/0xa0
[ 1711.746927] RSP: 0018:ffff880001e03e50 EFLAGS: 00010206
[ 1711.752242] RAX: ffff880134b0c000 RBX: ffff880233e39a00 RCX: 0000000000000001
[ 1711.759380] RDX: ffff880233e39b00 RSI: 0000000000000001 RDI: ffff880233e39a00
[ 1711.766534] RBP: ffff880001e03e50 R08: ffff880134b0c000 R09: ffff880233e39b20
[ 1711.773687] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880134e1dfd8
[ 1711.780839] R13: ffff880233e39a9c R14: 000000010002288b R15: ffff880134e1dfd8
[ 1711.787991] FS: 0000000000000000(0000) GS:ffff880001e00000(0000) knlGS:0000000000000000
[ 1711.796112] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1711.801874] CR2: 0000000000000008 CR3: 0000000001a2a000 CR4: 00000000000006f0
[ 1711.809026] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1711.816179] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1711.823331] Process kpktgend_0 (pid: 10970, threadinfo ffff880134e1c000, task ffff8801332ead60)
[ 1711.832058] Stack:
[ 1711.834089] ffff880001e03e90 ffffffff81469fe3 ffff880001e03ec0 ffffffff814503f2
[ 1711.841391] <0> 0000000000000000 ffff880233e39a9c 0000000000016240 ffff880233e39a00
[ 1711.849181] <0> ffff880001e03ec0 ffffffff8144e6e8 0000000000000010 0000000000000001
[ 1711.857175] Call Trace:
[ 1711.859640] <IRQ>
[ 1711.861778] [<ffffffff81469fe3>] __qdisc_run+0x43/0x130
[ 1711.867111] [<ffffffff814503f2>] ? net_rx_action+0x192/0x230
[ 1711.872876] [<ffffffff8144e6e8>] net_tx_action+0x118/0x190
[ 1711.878469] [<ffffffff8105ea35>] __do_softirq+0xb5/0x1f0
[ 1711.883890] [<ffffffff810b4308>] ? handle_IRQ_event+0x48/0x160
[ 1711.889828] [<ffffffff8100addc>] call_softirq+0x1c/0x30
[ 1711.895159] [<ffffffff8100c905>] do_softirq+0x65/0xa0
[ 1711.900315] [<ffffffff8105e8fd>] irq_exit+0x7d/0x90
[ 1711.905298] [<ffffffff8100be60>] do_IRQ+0x70/0xf0
[ 1711.910109] [<ffffffff8154ea13>] ret_from_intr+0x0/0x11
[ 1711.915438] <EOI>
[ 1711.917577] [<ffffffff810319a0>] ? __ticket_spin_unlock+0x0/0x10
[ 1711.923690] [<ffffffffa00f7dca>] ? pktgen_thread_worker+0x14a/0x840 [pktgen]
[ 1711.930845] [<ffffffff81075700>] ? autoremove_wake_function+0x0/0x40
[ 1711.937305] [<ffffffff81075700>] ? autoremove_wake_function+0x0/0x40
[ 1711.943764] [<ffffffffa00f7c80>] ? pktgen_thread_worker+0x0/0x840 [pktgen]
[ 1711.950743] [<ffffffff810751ce>] kthread+0x8e/0xa0
[ 1711.955640] [<ffffffff8100ace4>] kernel_thread_helper+0x4/0x10
[ 1711.961578] [<ffffffff81075140>] ? kthread+0x0/0xa0
[ 1711.966561] [<ffffffff8100ace0>] ? kernel_thread_helper+0x0/0x10
[ 1711.972671] Code: 40 08 4d 8d 48 08 49 39 c1 74 5c 48 85 c0 74 2d 41 83 68 18 01 4c 8b 40 08 4c 8b 10 48 c7 40 08 00 00 00 00 48 c7 00 00 00 00 00 <4d> 89 42 08 4d 89 10 44 8b 40 28 44 29 87 b0 00 00 00 48 8d 34
[ 1711.992874] RIP [<ffffffff81469014>] pfifo_fast_dequeue+0x54/0xa0
[ 1711.999094] RSP <ffff880001e03e50>
[ 1712.002600] CR2: 0000000000000008
[ 1712.006230] ---[ end trace 3bdc909dc99f9fd5 ]---
[ 1712.010907] Kernel panic - not syncing: Fatal exception in interrupt
[ 1712.017317] Pid: 10970, comm: kpktgend_0 Tainted: G D 2.6.35 #1
[ 1712.024077] Call Trace:
[ 1712.026579] <IRQ> [<ffffffff8154b7f4>] panic+0x8b/0x10c
[ 1712.032095] [<ffffffff8154f9ca>] oops_end+0xea/0xf0
[ 1712.037118] [<ffffffff81038693>] no_context+0xf3/0x260
[ 1712.042405] [<ffffffffa00bda04>] ? ixgbe_xmit_frame+0xaf4/0x1060 [ixgbe]
[ 1712.049248] [<ffffffff81038915>] __bad_area_nosemaphore+0x115/0x1d0
[ 1712.055664] [<ffffffff81290810>] ? swiotlb_map_page+0x0/0xf0
[ 1712.061470] [<ffffffff810389de>] bad_area_nosemaphore+0xe/0x10
[ 1712.067446] [<ffffffff815520ef>] do_page_fault+0x26f/0x310
[ 1712.073078] [<ffffffff8154ecf5>] page_fault+0x25/0x30
[ 1712.078274] [<ffffffff81469014>] ? pfifo_fast_dequeue+0x54/0xa0
[ 1712.084340] [<ffffffff81469fe3>] __qdisc_run+0x43/0x130
[ 1712.089707] [<ffffffff814503f2>] ? net_rx_action+0x192/0x230
[ 1712.095514] [<ffffffff8144e6e8>] net_tx_action+0x118/0x190
[ 1712.101147] [<ffffffff8105ea35>] __do_softirq+0xb5/0x1f0
[ 1712.106602] [<ffffffff810b4308>] ? handle_IRQ_event+0x48/0x160
[ 1712.112581] [<ffffffff8100addc>] call_softirq+0x1c/0x30
[ 1712.117949] [<ffffffff8100c905>] do_softirq+0x65/0xa0
[ 1712.123147] [<ffffffff8105e8fd>] irq_exit+0x7d/0x90
[ 1712.128166] [<ffffffff8100be60>] do_IRQ+0x70/0xf0
[ 1712.133017] [<ffffffff8154ea13>] ret_from_intr+0x0/0x11
[ 1712.138383] <EOI> [<ffffffff810319a0>] ? __ticket_spin_unlock+0x0/0x10
[ 1712.145202] [<ffffffffa00f7dca>] ? pktgen_thread_worker+0x14a/0x840 [pktgen]
[ 1712.152397] [<ffffffff81075700>] ? autoremove_wake_function+0x0/0x40
[ 1712.158893] [<ffffffff81075700>] ? autoremove_wake_function+0x0/0x40
[ 1712.165394] [<ffffffffa00f7c80>] ? pktgen_thread_worker+0x0/0x840 [pktgen]
[ 1712.172413] [<ffffffff810751ce>] kthread+0x8e/0xa0
[ 1712.177346] [<ffffffff8100ace4>] kernel_thread_helper+0x4/0x10
[ 1712.183327] [<ffffffff81075140>] ? kthread+0x0/0xa0
[ 1712.188346] [<ffffffff8100ace0>] ? kernel_thread_helper+0x0/0x10
^ permalink raw reply
* Re: Fwd: pktgen with vlan packets
From: Eric Dumazet @ 2011-05-20 15:20 UTC (permalink / raw)
To: Lynch, Jonathan; +Cc: netdev
In-Reply-To: <BANLkTinBGkApfasGywg888wDXZBYPOpQDQ@mail.gmail.com>
Le vendredi 20 mai 2011 à 16:03 +0100, Lynch, Jonathan a écrit :
> Hi,
>
> Im running 2.6.35 kernel with an Intel 82599 NIC.
> I want to send packets using pktgen via a number of vlan interfaces (1
> physical interface) created via vconfig but I get an OOPs when I try
> and send via the vlan interface. See attached log file for the oops.
> Im not using the pgset "vlan_id 77" params because I want to send
> packets with more than 1 VLAN tag to one interface. (If it was
> possible to send packets with different vlan tags over the one
> interface with pktgen I would use it)
>
> my config is as follows:
> ifconfig eth4 up
> modprobe 8021q
> vconfig add eth4 256
> ifconfig eth4.256 up
>
> My pktgen config is the exact same as
> ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/pktgen.conf-1-1
> except that instead of eth1, I have eth4.256.
>
> Any ideas as to how I can send packets with multiple VLAN tags over
> the same interface with pktgen?
I am afraid you cant yet.
About the crash, you can either :
1) delete qdisc on eth4
ifconfig eth4 txqueuelen 0
tc qdisc add dev eth0 root sfq
tc qdisc del dev eth0 root
2) use clone_skb 0 only
(Or else, same skb can be queued several time on eth4 qdisc) -> crash
^ permalink raw reply
* [PATCH] netdev: stop Features changed message
From: Stephen Hemminger @ 2011-05-20 16:02 UTC (permalink / raw)
To: netdev, David Miller
The new in 2.6.39 message "Features changed:" occurs a lot
on many configurations. It provides information to driver developers
but is not user friendly. Printing out hex values is just confusing.
Reduce priority so that it doesn't show up unless debugging.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/core/dev.c 2011-05-20 08:59:40.248885114 -0700
+++ b/net/core/dev.c 2011-05-20 09:00:32.925437770 -0700
@@ -5258,7 +5258,7 @@ void netdev_update_features(struct net_d
if (dev->features == features)
return;
- netdev_info(dev, "Features changed: 0x%08x -> 0x%08x\n",
+ netdev_dbg(dev, "Features changed: 0x%08x -> 0x%08x\n",
dev->features, features);
if (dev->netdev_ops->ndo_set_features)
^ permalink raw reply
* Re: [RFC/PATCH 01/13] net: wl12xx: sdio: id_tables should be __devinitconst
From: Ohad Ben-Cohen @ 2011-05-20 16:02 UTC (permalink / raw)
To: Felipe Balbi; +Cc: Luciano Coelho, linux-wireless, netdev, linux-kernel
In-Reply-To: <1305321990-22041-2-git-send-email-balbi@ti.com>
On Sat, May 14, 2011 at 12:26 AM, Felipe Balbi <balbi@ti.com> wrote:
> That's only needed during init anyway, let's free
> some space after we're done probing.
sdio devices are dynamically created whenever the hw is plugged into
the mmc slot by the user. that can happen anytime while the system is
up, not only during init.
> -static const struct sdio_device_id wl1271_devices[] = {
> +static const struct sdio_device_id wl1271_devices[] __devinitconst = {
it looks to me that sdio_match_device is going to be surprised if
->id_table won't be valid.
i wouldn't do this, unless you have a good explanation otherwise.
^ permalink raw reply
* Re: [RFC/PATCH 01/13] net: wl12xx: sdio: id_tables should be __devinitconst
From: Michał Mirosław @ 2011-05-20 16:14 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Felipe Balbi, Luciano Coelho, linux-wireless, netdev,
linux-kernel
In-Reply-To: <BANLkTinsSuDj8vMYG-40aAw0UVwLDo2KDQ@mail.gmail.com>
2011/5/20 Ohad Ben-Cohen <ohad@wizery.com>:
> On Sat, May 14, 2011 at 12:26 AM, Felipe Balbi <balbi@ti.com> wrote:
>> That's only needed during init anyway, let's free
>> some space after we're done probing.
> sdio devices are dynamically created whenever the hw is plugged into
> the mmc slot by the user. that can happen anytime while the system is
> up, not only during init.
>> -static const struct sdio_device_id wl1271_devices[] = {
>> +static const struct sdio_device_id wl1271_devices[] __devinitconst = {
> it looks to me that sdio_match_device is going to be surprised if
> ->id_table won't be valid.
>
> i wouldn't do this, unless you have a good explanation otherwise.
devinit sections are not freed if device hotplug is enabled.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] netdev: stop Features changed message
From: Michał Mirosław @ 2011-05-20 16:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20110520090208.7709bec3@nehalam>
2011/5/20 Stephen Hemminger <shemminger@vyatta.com>:
> The new in 2.6.39 message "Features changed:" occurs a lot
> on many configurations. It provides information to driver developers
> but is not user friendly. Printing out hex values is just confusing.
> Reduce priority so that it doesn't show up unless debugging.
The same patch is already in net-next:
604ae14ffb6d75d6eef4757859226b758d6bf9e3. Wasn't it meat for
net/stable back then?
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH v3 1/1] igmp: call ip_mc_clear_src() only when we have no users of ip_mc_list
From: Veaceslav Falico @ 2011-05-20 16:27 UTC (permalink / raw)
To: David Stevens
Cc: David Miller, jmorris, kaber, kuznet, linux-kernel, mmarek,
netdev, pekkas, yoshfuji
In-Reply-To: <OF11F57B2A.6B43B7E6-ON88257893.005490B0-88257893.00615176@us.ibm.com>
On Tue, May 17, 2011 at 10:42:59AM -0700, David Stevens wrote:
> Veaceslav,
> It looks to me like this will leak the source filters if we are
> called from ip_mc_destroy_dev(),
> Even with your previous patch, you're assuming that we don't free the
> ip_mc_list and so we have the
> same one when we up the device, but if there are no timers running, it
> looks like refcnt canl go to 0 and free
> it. If we can ever free the ip_mc_list when users != 0 (or going to 0
> immediately after the drop), we
> have to do the ip_mc_clear_src() or leak the list. I haven't looked at
> this code in years, so I'll need
> to refresh my memory.
> So, I'll look at that a bit more; at a minimum, I think you need
> to do the clear_src
> also in the destroy case. We could lose the filters and set the exclude
> count to users, instead
> of 1; but I like the idea of keeping the source filters across a down/up,
> if we can be sure there
> are no cases where we free the ip_mc_list without first freeing all the
> filters.
>
> +-DLS
Yes, you are completely right, we can leak the sources on
ip_mc_destroy_dev() when we've ip_ma_put() it inside all the timers. Also,
I've seen that we called igmp_group_dropped() for every mc in dev->mc_list,
however we've done it already in ip_mc_down() before, which wouldn't lead
to anything (cause the device is already ->dead, and all timers are
stopped), but just would be a waste of time.
So, does this patch seem ok? If yes, I'll send it with the changelog.
---
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 1fd3d9c..57ca93a 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1169,20 +1169,18 @@ static void igmp_group_dropped(struct ip_mc_list *im)
if (!in_dev->dead) {
if (IGMP_V1_SEEN(in_dev))
- goto done;
+ return;
if (IGMP_V2_SEEN(in_dev)) {
if (reporter)
igmp_send_report(in_dev, im, IGMP_HOST_LEAVE_MESSAGE);
- goto done;
+ return;
}
/* IGMPv3 */
igmpv3_add_delrec(in_dev, im);
igmp_ifc_event(in_dev);
}
-done:
#endif
- ip_mc_clear_src(im);
}
static void igmp_group_added(struct ip_mc_list *im)
@@ -1319,6 +1317,7 @@ void ip_mc_dec_group(struct in_device *in_dev, __be32 addr)
*ip = i->next_rcu;
in_dev->mc_count--;
igmp_group_dropped(i);
+ ip_mc_clear_src(i);
if (!in_dev->dead)
ip_rt_multicast_event(in_dev);
@@ -1428,7 +1427,8 @@ void ip_mc_destroy_dev(struct in_device *in_dev)
in_dev->mc_list = i->next_rcu;
in_dev->mc_count--;
- igmp_group_dropped(i);
+ /* We've dropped the groups in ip_mc_down already */
+ ip_mc_clear_src(i);
ip_ma_put(i);
}
}
^ permalink raw reply related
* Re: Fwd: pktgen with vlan packets
From: Lynch, Jonathan @ 2011-05-20 16:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1305904837.3173.20.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]
Hi Eric,
Thanks for your quick response.
I tried your suggestion for number 1 and I got the following oops -
see log2 attached
- i ran tc qdisc before testing to confirm there is no qdisc for eth4.
Then I tried suggestion 2, it works and sends packets over multiple
VLAN interfaces using multiple threads.
(When I combine suggestion 1 and 2 it crashes when I try sending to
more than 1 VLAN interface)
thanks again
Jonathan
On 20 May 2011 16:20, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 20 mai 2011 à 16:03 +0100, Lynch, Jonathan a écrit :
>> Hi,
>>
>> Im running 2.6.35 kernel with an Intel 82599 NIC.
>> I want to send packets using pktgen via a number of vlan interfaces (1
>> physical interface) created via vconfig but I get an OOPs when I try
>> and send via the vlan interface. See attached log file for the oops.
>> Im not using the pgset "vlan_id 77" params because I want to send
>> packets with more than 1 VLAN tag to one interface. (If it was
>> possible to send packets with different vlan tags over the one
>> interface with pktgen I would use it)
>>
>> my config is as follows:
>> ifconfig eth4 up
>> modprobe 8021q
>> vconfig add eth4 256
>> ifconfig eth4.256 up
>>
>> My pktgen config is the exact same as
>> ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/pktgen.conf-1-1
>> except that instead of eth1, I have eth4.256.
>>
>> Any ideas as to how I can send packets with multiple VLAN tags over
>> the same interface with pktgen?
>
> I am afraid you cant yet.
>
> About the crash, you can either :
>
> 1) delete qdisc on eth4
>
> ifconfig eth4 txqueuelen 0
> tc qdisc add dev eth0 root sfq
> tc qdisc del dev eth0 root
>
> 2) use clone_skb 0 only
>
> (Or else, same skb can be queued several time on eth4 qdisc) -> crash
>
>
>
>
[-- Attachment #2: log2.txt --]
[-- Type: text/plain, Size: 5292 bytes --]
[ 4798.925030] Virtual device eth4 asks to queue packet!
[ 4798.930130] BUG: unable to handle kernel paging request at 00000000000374be
[ 4798.937151] IP: [<ffffffff81455f2e>] dst_release+0xe/0x30
[ 4798.942593] PGD 0
[ 4798.944636] Oops: 0002 [#1] SMP
[ 4798.947918] last sysfs file: /sys/devices/virtual/net/eth4.256/type
[ 4798.954202] CPU 0
[ 4798.956051] Modules linked in: pktgen 8021q garp stp sch_sfq nls_cp437 cifs ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ixgbe iptable_filter ip_tables x_tables ioatdma dca lp mdio parport e1000e
[ 4798.977215]
[ 4798.978717] Pid: 10764, comm: kpktgend_0 Not tainted 2.6.35 #1 Greencity/Greencity
[ 4798.986307] RIP: 0010:[<ffffffff81455f2e>] [<ffffffff81455f2e>] dst_release+0xe/0x30
[ 4798.994179] RSP: 0018:ffff880137f9dc90 EFLAGS: 00010202
[ 4798.999508] RAX: 00000000ffffffff RBX: ffff880137efa900 RCX: ffff880134e61000
[ 4799.006677] RDX: ffff880134e61000 RSI: ffff880133432e80 RDI: 00000000000373fe
[ 4799.013847] RBP: ffff880137f9dc90 R08: 0000000000000000 R09: 0000000000000000
[ 4799.021016] R10: 0000000000000042 R11: 0000000000000000 R12: 0000000000000000
[ 4799.028185] R13: ffff880132ecc000 R14: ffff880137efaa00 R15: ffff880132ecc000
[ 4799.035355] FS: 0000000000000000(0000) GS:ffff880001e00000(0000) knlGS:0000000000000000
[ 4799.043495] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 4799.049272] CR2: 00000000000374be CR3: 0000000001a2a000 CR4: 00000000000006f0
[ 4799.056441] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4799.063610] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 4799.070778] Process kpktgend_0 (pid: 10764, threadinfo ffff880137f9c000, task ffff880132f016b0)
[ 4799.079526] Stack:
[ 4799.081563] ffff880137f9dcf0 ffffffff8144ea17 0000000000000010 ffff880137f9dd00
[ 4799.088884] <0> ffffffffa00acf20 ffff880134e61000 ffffffffffffff75 ffff880137efaa00
[ 4799.096691] <0> 0000000000000000 ffff880132ecc000 ffff880134e61000 ffff88023578c040
[ 4799.104710] Call Trace:
[ 4799.107187] [<ffffffff8144ea17>] dev_hard_start_xmit+0x177/0x460
[ 4799.113316] [<ffffffff81450ec6>] dev_queue_xmit+0x476/0x590
[ 4799.119011] [<ffffffff8154b8b1>] ? printk+0x3c/0x43
[ 4799.124010] [<ffffffffa00d3690>] ? vlan_dev_hwaccel_hard_start_xmit+0x0/0xb0 [8021q]
[ 4799.131891] [<ffffffffa00d3714>] vlan_dev_hwaccel_hard_start_xmit+0x84/0xb0 [8021q]
[ 4799.139685] [<ffffffffa014c2a5>] pktgen_xmit+0x815/0x11f0 [pktgen]
[ 4799.145988] [<ffffffff8154ea0e>] ? common_interrupt+0xe/0x13
[ 4799.151767] [<ffffffffa014cdf0>] pktgen_thread_worker+0x170/0x840 [pktgen]
[ 4799.158766] [<ffffffff81075700>] ? autoremove_wake_function+0x0/0x40
[ 4799.165242] [<ffffffff81075700>] ? autoremove_wake_function+0x0/0x40
[ 4799.171716] [<ffffffffa014cc80>] ? pktgen_thread_worker+0x0/0x840 [pktgen]
[ 4799.178713] [<ffffffff810751ce>] kthread+0x8e/0xa0
[ 4799.183624] [<ffffffff8100ace4>] kernel_thread_helper+0x4/0x10
[ 4799.189577] [<ffffffff81075140>] ? kthread+0x0/0xa0
[ 4799.194573] [<ffffffff8100ace0>] ? kernel_thread_helper+0x0/0x10
[ 4799.200697] Code: 48 c7 05 da f5 63 00 00 00 00 00 e8 8d 87 0f 00 48 89 1d f6 c5 82 00 eb 88 0f 1f 40 00 55 48 85 ff 48 89 e5 74 12 b8 ff ff ff ff <f0> 0f c1 87 c0 00 00 00 83 e8 01 78 02 c9 c3 be 14 01 00 00 48
[ 4799.220963] RIP [<ffffffff81455f2e>] dst_release+0xe/0x30
[ 4799.226502] RSP <ffff880137f9dc90>
[ 4799.230018] CR2: 00000000000374be
[ 4799.233704] ---[ end trace 9243f25e7d0c2084 ]---
[ 4799.238391] Kernel panic - not syncing: Fatal exception in interrupt
[ 4799.244823] Pid: 10764, comm: kpktgend_0 Tainted: G D 2.6.35 #1
[ 4799.251602] Call Trace:
[ 4799.254119] [<ffffffff8154b7f4>] panic+0x8b/0x10c
[ 4799.258980] [<ffffffff8154f9ca>] oops_end+0xea/0xf0
[ 4799.264023] [<ffffffff81038693>] no_context+0xf3/0x260
[ 4799.269321] [<ffffffff81038915>] __bad_area_nosemaphore+0x115/0x1d0
[ 4799.275754] [<ffffffff810389de>] bad_area_nosemaphore+0xe/0x10
[ 4799.281752] [<ffffffff815520ef>] do_page_fault+0x26f/0x310
[ 4799.287397] [<ffffffff8154ecf5>] page_fault+0x25/0x30
[ 4799.292611] [<ffffffff81455f2e>] ? dst_release+0xe/0x30
[ 4799.297995] [<ffffffff8144ea17>] dev_hard_start_xmit+0x177/0x460
[ 4799.304167] [<ffffffff81450ec6>] dev_queue_xmit+0x476/0x590
[ 4799.309900] [<ffffffff8154b8b1>] ? printk+0x3c/0x43
[ 4799.314943] [<ffffffffa00d3690>] ? vlan_dev_hwaccel_hard_start_xmit+0x0/0xb0 [8021q]
[ 4799.322880] [<ffffffffa00d3714>] vlan_dev_hwaccel_hard_start_xmit+0x84/0xb0 [8021q]
[ 4799.330721] [<ffffffffa014c2a5>] pktgen_xmit+0x815/0x11f0 [pktgen]
[ 4799.337064] [<ffffffff8154ea0e>] ? common_interrupt+0xe/0x13
[ 4799.342889] [<ffffffffa014cdf0>] pktgen_thread_worker+0x170/0x840 [pktgen]
[ 4799.349927] [<ffffffff81075700>] ? autoremove_wake_function+0x0/0x40
[ 4799.356448] [<ffffffff81075700>] ? autoremove_wake_function+0x0/0x40
[ 4799.362970] [<ffffffffa014cc80>] ? pktgen_thread_worker+0x0/0x840 [pktgen]
[ 4799.370006] [<ffffffff810751ce>] kthread+0x8e/0xa0
[ 4799.374960] [<ffffffff8100ace4>] kernel_thread_helper+0x4/0x10
[ 4799.380959] [<ffffffff81075140>] ? kthread+0x0/0xa0
[ 4799.385995] [<ffffffff8100ace0>] ? kernel_thread_helper+0x0/0x10
^ permalink raw reply
* Re: Fwd: pktgen with vlan packets
From: Eric Dumazet @ 2011-05-20 16:43 UTC (permalink / raw)
To: Lynch, Jonathan; +Cc: netdev
In-Reply-To: <BANLkTinTEM4BLzoOQiDFyY13Yj=ZqhXu5w@mail.gmail.com>
Le vendredi 20 mai 2011 à 17:30 +0100, Lynch, Jonathan a écrit :
> Hi Eric,
>
> Thanks for your quick response.
>
> I tried your suggestion for number 1 and I got the following oops -
> see log2 attached
> - i ran tc qdisc before testing to confirm there is no qdisc for eth4.
>
> Then I tried suggestion 2, it works and sends packets over multiple
> VLAN interfaces using multiple threads.
> (When I combine suggestion 1 and 2 it crashes when I try sending to
> more than 1 VLAN interface)
Well, yes, I guess there is nothing we can do about the crash issue,
since pktgen is doing some hacks and we are not going to add additional
tests in xmit fast path.
pktgen should directly work with the lowerdev.
[ going through vlan stack is an addtional overhead anyway ]
To send packets to several vlans, you would need to add a pktgen patch.
[to accept a range of vlan_id, or a list of vlan_id]
Or just use "flag VID_RND" ? (It'll chose a random id in [0..4095])
^ permalink raw reply
* [PATCH] macvlan: fix panic if lowerdev in a bond
From: Eric Dumazet @ 2011-05-20 16:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Patrick McHardy, Jiri Pirko
commit a35e2c1b6d905 (macvlan: use rx_handler_data pointer to store
macvlan_port pointer V2) added a bug in macvlan_port_create()
Steps to reproduce the bug:
# ifenslave bond0 eth0 eth1
# ip link add link eth0 up name eth0#1 type macvlan
->error EBUSY
# ip link add link eth0 up name eth0#1 type macvlan
->panic
Fix: Dont set IFF_MACVLAN_PORT in error case.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Patrick McHardy <kaber@trash.net>
CC: Jiri Pirko <jpirko@redhat.com>
---
This is a stable candidate (2.6.36+)
drivers/net/macvlan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index d7c0bc62..1e12a27 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -584,8 +584,8 @@ static int macvlan_port_create(struct net_device *dev)
err = netdev_rx_handler_register(dev, macvlan_handle_frame, port);
if (err)
kfree(port);
-
- dev->priv_flags |= IFF_MACVLAN_PORT;
+ else
+ dev->priv_flags |= IFF_MACVLAN_PORT;
return err;
}
^ permalink raw reply related
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