* Re: [PATCH net-next 0/5] bonding: patchset for rcu use in bonding
From: Ding Tianhong @ 2013-10-22 2:16 UTC (permalink / raw)
To: Veaceslav Falico
Cc: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Netdev
In-Reply-To: <20131021132136.GE692@redhat.com>
On 2013/10/21 21:21, Veaceslav Falico wrote:
> On Mon, Oct 21, 2013 at 02:41:44PM +0200, Veaceslav Falico wrote:
>> On Mon, Oct 21, 2013 at 08:32:11PM +0800, Ding Tianhong wrote:
>>> On 2013/10/21 17:35, Veaceslav Falico wrote:
>>>> On Mon, Oct 21, 2013 at 05:27:51PM +0800, Ding Tianhong wrote:
>>>>> On 2013/10/21 17:13, Veaceslav Falico wrote:
>>>>>> On Mon, Oct 21, 2013 at 04:58:36PM +0800, Ding Tianhong wrote:
>>>>>>> Hi:
>>>>>>>
>>>>>>> The Patch Set will remove the invalid lock for bond work queue and replace it
>>>>>>> with rtnl lock, as read lock for bond could not protect slave list any more.
>>>>>>
>>>>>> rtnl lock is a lot more expensive than bond lock, and not only for bond,
>>>>>> but for all the networking stack.
>>>>>>
>>>>>> Why is the bond->lock invalid? It correctly protects slaves from being
>>>>>> modified concurrently.
>>>>>>
>>>>>> I don't see the point in this patchset.
>>>>>>
>>>>>
>>>>> yes, rtnl lock is a big lock, but I think bond->lock could not protect
>>>>> bond_for_each_slave any more, am I miss something?
>>>>
>>>> Why can't it protect bond_for_each_slave()?
>>>>
>>>
>>> bond_master_upper_dev_link() and bond_upper_dev_unlink() was only in rtnl lock,
>>> bond_for_each_slave may changed while loop in bond read lock, but it sees that
>>> nothing serious will happen yet.
>>> Maybe I miss something.
>>
>> Even if it is unsafe to use bond_for_each_slave() while holding bond->lock
>> - it means that we must protect the list by locking the
>> bond_upper_dev_(un)link() via bond->lock, but not by removing bond->lock
>> from everywhere where it is now. And I'm not that sure if it's safe or not.
>
> I've quickly looked over the code - yes, theoretically we could race
> between bond_for_each_slave() that is not rtnl-protected and
> bond_upper_dev_(un)link().
>
> Your patchset, also, doesn't 'replace' bond->lock with rtnl_lock(), cause
> everywhere the rtnl_lock() is already present, it just moves it around,
> while removing the bond->lock.
>
> The commit message is wrong and says actually nothing why is it done, how
> is it done, why it's safe to do so and what do we get in the end. For every
> patch, and the cover letter is also not an exception.
>
It is my fault, too lazy to describe the detail for the patch and occurs so many
missmatch, I'll fix it later.
> I'd suggest you either:
>
> 1) add bond->lock around bond_upper_dev_(un)link() (GFP_ATOMIC might be needed).
>
bond_upper_dev_(un)link() will call call_netdevice_notifiers(), it is not safe to call it
in read lock, call_netdevice_notifiers() may sleep or schedule, and sometimes
call_netdevice_notifiers() will read bond lock again.
> or
>
> 2) add ASSERT_RTNL() to bond_for_each_slave() macro, catch all the offenders
> and remove the bond->lock from them. Also, I'm not that sure that it's safe
> to do so - cause one of the slaves (not the slave list) might change, and
> we might have race conditions there.
>
yes, it is not a good idea, as your meaning, it is a big cost, but monitor is a slow path,
I think the cost is acceptable,whatever we should find a better way.
> or
>
> 3) move bond_for_each_slave() to bond_for_each_slave_rcu() where appropriate.
>
> And in any case write specific commit messages - bonding's code is really
> old and full of locks that were placed for some reason (and the reason
> might have gone away long ago, too), so it's really hard to say if the
> change is safe or not.
above all, the 3) is the wise idea, rtnl or rcu, every one is enough for
bond_for_each_slave().
>
> I'd personally go for either 3) (preferred), or 1).
>
> Sorry, I'm a bit tired of going in-depth on your patches. Start either
> doing patches with commit messages that *prove* me that you're right (I'll,
> obviously, verify it - but at least I'll know what you're doing, and won't
> have to figure it out from code), or I'll start explicitly NAKing them.
>
> Sorry again, but I don't really have time for that. I didn't have time to
> review your last patchset (RCUifying the remaining transmit path), and now
> I can understand nothing from their commit description, except that you've
> changed bond_for_each_slave() to bond_for_each_slave_rcu() and bond->lock
> to rcu_read_lock(). I'm not saying that they're wrong, just that they're
> really hard to understand.
>
> So, please, start writing commit messages.
>
>>
>>>
>>> Ding
>>>
>>>
>>>>>
>>>>> Ding
>>>>>
>>>>>>>
>>>>>>> Ding Tianhong (5):
>>>>>>> bonding: remove bond read lock for bond_mii_monitor()
>>>>>>> bonding: remove bond read lock for bond_alb_monitor()
>>>>>>> bonding: remove bond read lock for bond_loadbalance_arp_mon()
>>>>>>> bonding: remove bond read lock for bond_activebackup_arp_mon()
>>>>>>> bonding: remove bond read lock for bond_3ad_state_machine_handler()
>>>>>>>
>>>>>>> drivers/net/bonding/bond_3ad.c | 9 ++--
>>>>>>> drivers/net/bonding/bond_alb.c | 20 ++------
>>>>>>> drivers/net/bonding/bond_main.c | 100 +++++++++++++---------------------------
>>>>>>> 3 files changed, 40 insertions(+), 89 deletions(-)
>>>>>>>
>>>>>>> --
>>>>>>> 1.8.2.1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> .
>>>>
>>>
>>>
>> --
>> 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
* [PATCH 1/1] [PATCH] ax88179_178a: Add VID:DID for Samsung USB Ethernet Adapter
From: freddy @ 2013-10-22 2:12 UTC (permalink / raw)
To: davem, linux-usb, linux-kernel, netdev, allan, louis; +Cc: Freddy Xin
From: Freddy Xin <freddy@asix.com.tw>
Add VID:DID for Samsung USB Ethernet Adapter.
Signed-off-by: Freddy Xin <freddy@asix.com.tw>
---
drivers/net/usb/ax88179_178a.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 3569293..3d166ae 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1406,6 +1406,19 @@ static const struct driver_info sitecom_info = {
.tx_fixup = ax88179_tx_fixup,
};
+static const struct driver_info samsung_info = {
+ .description = "Samsung USB Ethernet Adapter",
+ .bind = ax88179_bind,
+ .unbind = ax88179_unbind,
+ .status = ax88179_status,
+ .link_reset = ax88179_link_reset,
+ .reset = ax88179_reset,
+ .stop = ax88179_stop,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .rx_fixup = ax88179_rx_fixup,
+ .tx_fixup = ax88179_tx_fixup,
+};
+
static const struct usb_device_id products[] = {
{
/* ASIX AX88179 10/100/1000 */
@@ -1418,7 +1431,11 @@ static const struct usb_device_id products[] = {
}, {
/* Sitecom USB 3.0 to Gigabit Adapter */
USB_DEVICE(0x0df6, 0x0072),
- .driver_info = (unsigned long) &sitecom_info,
+ .driver_info = (unsigned long)&sitecom_info,
+}, {
+ /* Samsung USB Ethernet Adapter */
+ USB_DEVICE(0x04e8, 0xa100),
+ .driver_info = (unsigned long)&samsung_info,
},
{ },
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/1] [PATCH resubmit] ax88179_178a: Correct the RX error definition in RX header
From: freddy @ 2013-10-22 1:47 UTC (permalink / raw)
To: davem, linux-usb, linux-kernel, netdev, allan, louis; +Cc: Freddy Xin
From: Freddy Xin <freddy@asix.com.tw>
Correct the definition of AX_RXHDR_CRC_ERR and
AX_RXHDR_DROP_ERR. They are BIT29 and BIT31 in pkt_hdr
seperately.
Signed-off-by: Freddy Xin <freddy@asix.com.tw>
---
drivers/net/usb/ax88179_178a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 3569293..3bcd0d9 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -36,8 +36,8 @@
#define AX_RXHDR_L4_TYPE_TCP 16
#define AX_RXHDR_L3CSUM_ERR 2
#define AX_RXHDR_L4CSUM_ERR 1
-#define AX_RXHDR_CRC_ERR ((u32)BIT(31))
-#define AX_RXHDR_DROP_ERR ((u32)BIT(30))
+#define AX_RXHDR_CRC_ERR ((u32)BIT(29))
+#define AX_RXHDR_DROP_ERR ((u32)BIT(31))
#define AX_ACCESS_MAC 0x01
#define AX_ACCESS_PHY 0x02
#define AX_ACCESS_EEPROM 0x04
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/2] fq_codel: keep dropped statistic around
From: Dave Taht @ 2013-10-22 1:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, codel
In-Reply-To: <CAL4Wiio0YThCbT8j92HVn1CmmdvKD=GT30ZtMf=ZvmAj+ZM7Yg@mail.gmail.com>
On Mon, Oct 21, 2013 at 06:27:11PM -0700, Eric Dumazet wrote:
> On Oct 21, 2013 6:20 PM, "Dave Taht" <dave.taht@bufferbloat.net> wrote:
> >
> > Having more accurate dropped information in this qdisc is useful.
> >
> > Signed-off-by: Dave Taht <dave.taht@bufferbloat.net>
> > ---
> > net/sched/sch_fq_codel.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
> > index 5578628..437bc95 100644
> > --- a/net/sched/sch_fq_codel.c
> > +++ b/net/sched/sch_fq_codel.c
> > @@ -193,7 +193,6 @@ static int fq_codel_enqueue(struct sk_buff *skb,
> struct Qdisc *sch)
> > list_add_tail(&flow->flowchain, &q->new_flows);
> > q->new_flow_count++;
> > flow->deficit = q->quantum;
> > - flow->dropped = 0;
> > }
> > if (++sch->q.qlen <= sch->limit)
> > return NET_XMIT_SUCCESS;
> > --
> > 1.7.9.5
> I am travelling to Edinburgh, so will be short.
Wish I could have made it.
> Since fqcodel recycles a slot, we need to clear this counter.
I prefer to think of it as a per "slot dropped counter" and to
have it retain the total number of drops in that slot since
qdisc initialization.
> We do no know
> if slot is reused by previous flow or a new flow hashing to same bucket.
There could also in this case be several flows hashing to the same bucket
and dropping packets.
In most cases with the current zero-ing of "drop", polling "tc -s class"
yields an unrevealing drop statistic of "0" for many workloads against
multiple streams at lower bandwidths.
with it not getting zeroed, as per this patch, clear patterns show over
many seconds as queues empty, get filled by bursts, and get drops.
This patch has been in openwrt and cerowrt since feburary.
^ permalink raw reply
* Re: [PATCH 1/2] fq_codel: keep dropped statistic around
From: Eric Dumazet @ 2013-10-22 1:27 UTC (permalink / raw)
To: Dave Taht; +Cc: netdev, codel
In-Reply-To: <1382404797-17239-2-git-send-email-dave.taht@bufferbloat.net>
[-- Attachment #1.1: Type: text/plain, Size: 1031 bytes --]
On Oct 21, 2013 6:20 PM, "Dave Taht" <dave.taht@bufferbloat.net> wrote:
>
> Having more accurate dropped information in this qdisc is useful.
>
> Signed-off-by: Dave Taht <dave.taht@bufferbloat.net>
> ---
> net/sched/sch_fq_codel.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
> index 5578628..437bc95 100644
> --- a/net/sched/sch_fq_codel.c
> +++ b/net/sched/sch_fq_codel.c
> @@ -193,7 +193,6 @@ static int fq_codel_enqueue(struct sk_buff *skb,
struct Qdisc *sch)
> list_add_tail(&flow->flowchain, &q->new_flows);
> q->new_flow_count++;
> flow->deficit = q->quantum;
> - flow->dropped = 0;
> }
> if (++sch->q.qlen <= sch->limit)
> return NET_XMIT_SUCCESS;
> --
> 1.7.9.5
I am travelling to Edinburgh, so will be short.
Since fqcodel recycles a slot, we need to clear this counter. We do no know
if slot is reused by previous flow or a new flow hashing to same bucket.
[-- Attachment #1.2: Type: text/html, Size: 1411 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
^ permalink raw reply
* [PATCH 2/2] codel: eliminate maxpacket as an inner bound
From: Dave Taht @ 2013-10-22 1:19 UTC (permalink / raw)
To: netdev, codel; +Cc: Dave Taht
In-Reply-To: <1382404797-17239-1-git-send-email-dave.taht@bufferbloat.net>
As there is always at least one packet in the device driver or
rate limiter, the maxpacket bound (an artifact of the ns2 code)
is unneeded.
Also: in the case of TSO/GSO/GRO, it can scale well above
(to 64k) what codel's designers intended.
Someday the maxpacket variable could be eliminated entirely,
but for now it is a useful indicator of "oops, I didn't turn
off tso/gso/gro somewhere".
Signed-off-by: Dave Taht <dave.taht@bufferbloat.net>
---
include/net/codel.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/codel.h b/include/net/codel.h
index 389cf62..319a296 100644
--- a/include/net/codel.h
+++ b/include/net/codel.h
@@ -225,7 +225,7 @@ static bool codel_should_drop(const struct sk_buff *skb,
stats->maxpacket = qdisc_pkt_len(skb);
if (codel_time_before(vars->ldelay, params->target) ||
- sch->qstats.backlog <= stats->maxpacket) {
+ sch->qstats.backlog <= 0) {
/* went below - stay below for at least interval */
vars->first_above_time = 0;
return false;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] fq_codel: keep dropped statistic around
From: Dave Taht @ 2013-10-22 1:19 UTC (permalink / raw)
To: netdev, codel; +Cc: Dave Taht
In-Reply-To: <1382404797-17239-1-git-send-email-dave.taht@bufferbloat.net>
Having more accurate dropped information in this qdisc is useful.
Signed-off-by: Dave Taht <dave.taht@bufferbloat.net>
---
net/sched/sch_fq_codel.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
index 5578628..437bc95 100644
--- a/net/sched/sch_fq_codel.c
+++ b/net/sched/sch_fq_codel.c
@@ -193,7 +193,6 @@ static int fq_codel_enqueue(struct sk_buff *skb, struct Qdisc *sch)
list_add_tail(&flow->flowchain, &q->new_flows);
q->new_flow_count++;
flow->deficit = q->quantum;
- flow->dropped = 0;
}
if (++sch->q.qlen <= sch->limit)
return NET_XMIT_SUCCESS;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] net-next codel enhancements
From: Dave Taht @ 2013-10-22 1:19 UTC (permalink / raw)
To: netdev, codel
These two patches have been extensively tested in openwrt
and cerowrt. Losing the fq_codel drop statistic as a bug.
Checking for a maxpacket size in the qdisc was somewhat
correct for ns2 but not for Linux as all the current
subsystems below htb/hfsc/adsl/bql buffer packets.
IMHO both of these patches are candidates for stable.
^ permalink raw reply
* BUG: scheduling while atomic dev_set_promiscuity->__dev_notify_flags
From: Alexei Starovoitov @ 2013-10-22 1:04 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev
Hi Nicolas,
after commit 991fb3f74c "dev: always advertise rx_flags changes via netlink"
I'm seeing 'sleeping in atomic' bug.
Steps to reproduce:
ip tuntap add dev tap1 mode tap
ifconfig tap1 up
tcpdump -nei tap1
and in different terminal:
ip tuntap del dev tap1 mode tap
[ 271.627994] device tap1 left promiscuous mode
[ 271.639897] BUG: sleeping function called from invalid context at
mm/slub.c:940
[ 271.664491] in_atomic(): 1, irqs_disabled(): 0, pid: 3394, name: ip
[ 271.677525] INFO: lockdep is turned off.
[ 271.690503] CPU: 0 PID: 3394 Comm: ip Tainted: G W 3.12.0-rc3+ #73
[ 271.703996] Hardware name: System manufacturer System Product
Name/P8Z77 WS, BIOS 3007 07/26/2012
[ 271.731254] ffffffff81a58506 ffff8807f0d57a58 ffffffff817544e5
ffff88082fa0f428
[ 271.760261] ffff8808071f5f40 ffff8807f0d57a88 ffffffff8108bad1
ffffffff81110ff8
[ 271.790683] 0000000000000010 00000000000000d0 00000000000000d0
ffff8807f0d57af8
[ 271.822332] Call Trace:
[ 271.838234] [<ffffffff817544e5>] dump_stack+0x55/0x76
[ 271.854446] [<ffffffff8108bad1>] __might_sleep+0x181/0x240
[ 271.870836] [<ffffffff81110ff8>] ? rcu_irq_exit+0x68/0xb0
[ 271.887076] [<ffffffff811a80be>] kmem_cache_alloc_node+0x4e/0x2a0
[ 271.903368] [<ffffffff810b4ddc>] ? vprintk_emit+0x1dc/0x5a0
[ 271.919716] [<ffffffff81614d67>] ? __alloc_skb+0x57/0x2a0
[ 271.936088] [<ffffffff810b4de0>] ? vprintk_emit+0x1e0/0x5a0
[ 271.952504] [<ffffffff81614d67>] __alloc_skb+0x57/0x2a0
[ 271.968902] [<ffffffff8163a0b2>] rtmsg_ifinfo+0x52/0x100
[ 271.985302] [<ffffffff8162ac6d>] __dev_notify_flags+0xad/0xc0
[ 272.001642] [<ffffffff8162ad0c>] __dev_set_promiscuity+0x8c/0x1c0
[ 272.017917] [<ffffffff81731ea5>] ? packet_notifier+0x5/0x380
[ 272.033961] [<ffffffff8162b109>] dev_set_promiscuity+0x29/0x50
[ 272.049855] [<ffffffff8172e937>] packet_dev_mc+0x87/0xc0
[ 272.065494] [<ffffffff81732052>] packet_notifier+0x1b2/0x380
[ 272.080915] [<ffffffff81731ea5>] ? packet_notifier+0x5/0x380
[ 272.096009] [<ffffffff81761c66>] notifier_call_chain+0x66/0x150
[ 272.110803] [<ffffffff8108503e>] __raw_notifier_call_chain+0xe/0x10
[ 272.125468] [<ffffffff81085056>] raw_notifier_call_chain+0x16/0x20
[ 272.139984] [<ffffffff81620190>] call_netdevice_notifiers_info+0x40/0x70
[ 272.154523] [<ffffffff816201d6>] call_netdevice_notifiers+0x16/0x20
[ 272.168552] [<ffffffff816224c5>] rollback_registered_many+0x145/0x240
[ 272.182263] [<ffffffff81622641>] rollback_registered+0x31/0x40
[ 272.195369] [<ffffffff816229c8>] unregister_netdevice_queue+0x58/0x90
[ 272.208230] [<ffffffff81547ca0>] __tun_detach+0x140/0x340
[ 272.220686] [<ffffffff81547ed6>] tun_chr_close+0x36/0x60
packet_notifier() does rcu_read_lock() before calling into packet_dev_mc() .
Not sure how to fix it cleanly, other than disabling a notify here.
Any suggestion?
Thanks
Alexei
^ permalink raw reply
* [PATCH] 3c59x: fix incorrect use of spin_lock_bh in interrupts
From: Mikulas Patocka @ 2013-10-21 23:53 UTC (permalink / raw)
To: Steffen Klassert, David S. Miller; +Cc: netdev
The functions mdio_read and mdio_write may be called from interrupt
context. Consequently, we must use spin_lock_irqsave instead of
spin_lock_bh.
This patch should be backported to stable kernels.
This patch fixes the following warning.
eth0: Host error, FIFO diagnostic register 8000.
eth0: PCI bus error, bus status 80000020
------------[ cut here ]------------
WARNING: at kernel/softirq.c:159 local_bh_enable+0x68/0x90()
Hardware name: Latitude C600
Modules linked in: ipv6 freq_table speedstep_lib parport_pc parport 8250
serial_core apm 8139too bitrev crc32 snd_maestro3 snd_ac97_codec ac97_bus
snd_pcm_oss snd_mixer_oss snd_pcm uhci_hcd microcode
snd_timer snd_page_alloc rtc_cmos ide_cd_mod intel_agp pcspkr usbcore
psmouse snd cdrom intel_gtt soundcore i2c_piix4 3c59x agpgart mii
yenta_socket i2c_core pcmcia_core pcmcia_rsrc usb_common unix
Pid: 1134, comm: ifconfig Tainted: G W 3.4.66 #2
Call Trace:
[<c101ff38>] ? warn_slowpath_common+0x78/0xb0
[<c1024f58>] ? local_bh_enable+0x68/0x90
[<c1024f58>] ? local_bh_enable+0x68/0x90
[<c101ff89>] ? warn_slowpath_null+0x19/0x20
[<c1024f58>] ? local_bh_enable+0x68/0x90
[<d895a1eb>] ? mdio_read+0x11b/0x160 [3c59x]
[<d895a9d6>] ? vortex_up+0x166/0x6c0 [3c59x]
[<d89590f5>] ? issue_and_wait+0x35/0xd0 [3c59x]
[<d895b2ca>] ? vortex_down+0xda/0x170 [3c59x]
[<d895b72e>] ? vortex_error+0x39e/0x3d0 [3c59x]
[<c1183097>] ? serio_interrupt+0x47/0xa0
[<d895c481>] ? boomerang_interrupt+0x241/0x340 [3c59x]
[<c105db7d>] ? handle_irq_event_percpu+0x2d/0x140
[<c105fd20>] ? cond_unmask_irq+0x40/0x40
[<c105dcc6>] ? handle_irq_event+0x36/0x60
[<c105fd73>] ? handle_level_irq+0x53/0xa0
<IRQ> [<c1003a8a>] ? do_IRQ+0x3a/0xa0
[<c1210929>] ? common_interrupt+0x29/0x30
[<c105007b>] ? futex_lock_pi.isra.22+0x23b/0x300
[<c105eb26>] ? __setup_irq+0x1d6/0x410
[<d895c240>] ? rx_oom_timer+0x50/0x50 [3c59x]
[<c105ee12>] ? request_threaded_irq+0xb2/0x150
[<d895afc9>] ? vortex_open+0x39/0x1f0 [3c59x]
[<c11a8ec3>] ? __dev_open+0x83/0xe0
[<c11a9139>] ? __dev_change_flags+0x89/0x170
[<c11a78df>] ? dev_get_by_name_rcu+0x4f/0x70
[<c11a92bb>] ? dev_change_flags+0x1b/0x60
[<c11f301e>] ? devinet_ioctl+0x55e/0x6f0
[<c11a9acf>] ? dev_ioctl+0x35f/0x5a0
[<c11944b4>] ? sock_ioctl+0x54/0x260
[<c1087443>] ? handle_mm_fault+0x123/0x180
[<c1194460>] ? sock_fasync+0x90/0x90
[<c10b00c1>] ? do_vfs_ioctl+0x81/0x5e0
[<c10197f1>] ? do_page_fault+0x161/0x420
[<c109e5b7>] ? fd_install+0x47/0x80
[<c10add76>] ? user_path_at+0x16/0x20
[<c109f0ae>] ? sys_faccessat+0x11e/0x1c0
[<c10b064e>] ? sys_ioctl+0x2e/0x60
[<c1210410>] ? sysenter_do_call+0x12/0x26
---[ end trace 5d85da266ec9ff9b ]---
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/net/ethernet/3com/3c59x.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
Index: linux-3.4.66/drivers/net/ethernet/3com/3c59x.c
===================================================================
--- linux-3.4.66.orig/drivers/net/ethernet/3com/3c59x.c 2013-10-22 01:34:44.000000000 +0200
+++ linux-3.4.66/drivers/net/ethernet/3com/3c59x.c 2013-10-22 01:35:37.000000000 +0200
@@ -3126,8 +3126,9 @@ static int mdio_read(struct net_device *
struct vortex_private *vp = netdev_priv(dev);
int read_cmd = (0xf6 << 10) | (phy_id << 5) | location;
unsigned int retval = 0;
+ unsigned long flags;
- spin_lock_bh(&vp->mii_lock);
+ spin_lock_irqsave(&vp->mii_lock, flags);
if (mii_preamble_required)
mdio_sync(vp, 32);
@@ -3153,7 +3154,7 @@ static int mdio_read(struct net_device *
mdio_delay(vp);
}
- spin_unlock_bh(&vp->mii_lock);
+ spin_unlock_irqrestore(&vp->mii_lock, flags);
return retval & 0x20000 ? 0xffff : retval>>1 & 0xffff;
}
@@ -3163,8 +3164,9 @@ static void mdio_write(struct net_device
struct vortex_private *vp = netdev_priv(dev);
int write_cmd = 0x50020000 | (phy_id << 23) | (location << 18) | value;
int i;
+ unsigned long flags;
- spin_lock_bh(&vp->mii_lock);
+ spin_lock_irqsave(&vp->mii_lock, flags);
if (mii_preamble_required)
mdio_sync(vp, 32);
@@ -3187,7 +3189,7 @@ static void mdio_write(struct net_device
mdio_delay(vp);
}
- spin_unlock_bh(&vp->mii_lock);
+ spin_unlock_irqrestore(&vp->mii_lock, flags);
}
/* ACPI: Advanced Configuration and Power Interface. */
^ permalink raw reply
* Re: [BUG] 3.12.0-rcX IPv6 panic
From: Bob Tracy @ 2013-10-21 23:40 UTC (permalink / raw)
To: linux-kernel, netdev
In-Reply-To: <20131021155252.GA24158@order.stressinduktion.org>
On Mon, Oct 21, 2013 at 05:52:52PM +0200, Hannes Frederic Sowa wrote:
> On Mon, Oct 21, 2013 at 08:18:46AM -0500, Bob Tracy wrote:
> > Actually, a regression: the 3.11 kernel is rock-solid stable on my
> > Alpha.
> >
> > Beginning with 3.12.0-rc1, I can reliably trigger a kernel panic by
> > executing the gogo6.net "gw6c" IPv6 client program. If the networking
> > layer is active, an "Oops" will eventually (within a day) occur regardless
> > of whether I attempt to run "gw6c". 3.12.0-rcX is stable as long as I
> > leave networking completely disabled. The error has persisted up through
> > -rc6. Apologies for not mentioning this earlier, but the state of my
> > PWS-433au has been questionable, and I wanted to make sure I had a
> > legitimate bug sighting.
> >
> > I'll have to transcribe the panic backtrace by hand: nothing makes it
> > into any of the system logs :-(. I *can* recall that every backtrace
> > I've seen thus far has included one of the skb_copy() variants near the
> > top of the list (first or second function).
>
> Try to capture the panic via serial console. Otherwise a picture
> would give us a first hint. Please watch out for lines like
> skb_(over|under)_panic.
I'll get a screen capture of some kind for you within the next day or
so.
> gw6c is a tunnel client? Can you post ip -6 tunnel ls?
Assuming you meant "show [NAME]" (no "ls" option for the tunnel object),
that yields the following with "gw6c" running on a 3.11.0 kernel:
smirkin:~# ip -6 tunnel show sit1
sit1: any/ipv6 remote 4056:5874:: local 4500:0:0:4000:4029:: encaplimit 0 hoplimit 0 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
I'm running the gw6c client in gateway mode: the Alpha is my IPv6
gateway/firewall.
--Bob
^ permalink raw reply
* [PATCH] ixgbe: Reduce memory consumption with larger page sizes
From: Anton Blanchard @ 2013-10-21 23:37 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: netdev, benh
The ixgbe driver allocates pages for its receive rings. It currently
uses 512 pages, regardless of page size. During receive handling it
adds the unused part of the page back into the rx ring, avoiding the
need for a new allocation.
On a ppc64 box with 64 threads and 64kB pages, we end up with
512 entries * 64 rx queues * 64kB = 2GB memory used. Even more of a
concern is that we use up 2GB of IOMMU space in order to map all this
memory.
The driver makes a number of decisions based on if PAGE_SIZE is less
than 8kB, so use this as the breakpoint and only allocate 128 entries
on 8kB or larger page sizes.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Jeff: The breakpoint and the ring size I chose was pretty arbitrary,
feel free to adjust as you see fit. Our main concern is we get that 2GB
consumption down to something more reasonable :)
Index: b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
===================================================================
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -67,7 +67,11 @@
#define IXGBE_MAX_TXD 4096
#define IXGBE_MIN_TXD 64
+#if (PAGE_SIZE < 8192)
#define IXGBE_DEFAULT_RXD 512
+#else
+#define IXGBE_DEFAULT_RXD 128
+#endif
#define IXGBE_MAX_RXD 4096
#define IXGBE_MIN_RXD 64
^ permalink raw reply
* Re: [PATCH net 1/2] sit: allow to use rtnl ops on fb tunnel
From: Willem de Bruijn @ 2013-10-21 23:30 UTC (permalink / raw)
To: nicolas.dichtel
Cc: David Miller, netdev, steffen.klassert, pshelar, gregkh, stable
In-Reply-To: <524BC816.1000702@6wind.com>
On Wed, Oct 2, 2013 at 3:15 AM, Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
> Le 01/10/2013 18:59, David Miller a écrit :
>
>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> Date: Tue, 1 Oct 2013 18:04:59 +0200
>>
>>> rtnl ops where introduced by ba3e3f50a0e5 ("sit: advertise tunnel param
>>> via
>>> rtnl"), but I forget to assign rtnl ops to fb tunnels.
>>>
>>> Now that it is done, we must remove the explicit call to
>>> unregister_netdevice_queue(), because the fallback tunnel is added to
>>> the queue
>>> in sit_destroy_tunnels() when checking rtnl_link_ops of all netdevices
>>> (this
>>> is valid since commit 5e6700b3bf98 ("sit: add support of x-netns")).
>>>
>>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>
>>
>> Applied and queued up for -stable.
>>
>> But I imagine since the x-netns changes aren't in various -stable
>> branches this will need to be adjusted a bit?
>
> Yes, it's what I've tried to say in the commit log ;-)
>
> In fact, before the x-netns changes, we must keep the
> unregister_netdevice_queue() line.
In 3.11 linux-stable, this patch was merged between 3.11.4 and 3.11.5
in commit 3783100, after the x-netns changes in commit 5e6700b3bf, but
the unregister_netdevice_queue was kept.
I think that caused the following bug. In 3.11.6, a simple `modprobe
sit && rmmod sit` hits the BUG at net/core/dev.c:5039:
BUG_ON(dev->reg_state != NETREG_REGISTERED);
The device is actually NETREG_RELEASED at one point because the device
is now unregistered twice. The issue goes away by porting the
remainder of the original commit: the one liner that removes the call
to unregister_netdevice_queue.
+++ b/net/ipv6/sit.c
@@ -1708,7 +1708,6 @@ static void __net_exit sit_exit_net(struct net *net)
sit_destroy_tunnels(sitn, &list);
- unregister_netdevice_queue(sitn->fb_tunnel_dev, &list);
unregister_netdevice_many(&list);
If correct, let me know if I should send a proper one-line patch
against 3.11.y. Since I haven't looked at this code before, I found it
safer to report the issue first.
5e6700b3bf was not applied to 3.10 stable, so that branch is not affected.
^ permalink raw reply
* Re: [PATCH net] tcp: initialize passive-side sk_pacing_rate after 3WHS
From: David Miller @ 2013-10-21 22:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: ncardwell, netdev, edumazet, ycheng
In-Reply-To: <1382387794.3284.87.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 21 Oct 2013 13:36:34 -0700
> On Mon, 2013-10-21 at 15:40 -0400, Neal Cardwell wrote:
>> For passive TCP connections, upon receiving the ACK that completes the
>> 3WHS, make sure we set our pacing rate after we get our first RTT
>> sample.
>
>> Signed-off-by: Neal Cardwell <ncardwell@google.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Cc: Yuchung Cheng <ycheng@google.com>
>> ---
>> net/ipv4/tcp_input.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 53974c7..a16b01b 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -5712,6 +5712,8 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
>> } else
>> tcp_init_metrics(sk);
>>
>> + tcp_update_pacing_rate(sk);
>> +
>> /* Prevent spurious tcp_cwnd_restart() on first data packet */
>> tp->lsndtime = tcp_time_stamp;
>>
>
> Seems good to me, thanks !
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] mac802154: correct a typo in ieee802154_alloc_device() prototype
From: David Miller @ 2013-10-21 22:58 UTC (permalink / raw)
To: alexandre.belloni; +Cc: alex.bluesman.smirnov, netdev, linux-kernel
In-Reply-To: <1382375398-17428-1-git-send-email-alexandre.belloni@free-electrons.com>
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Date: Mon, 21 Oct 2013 19:09:58 +0200
> This has no other impact than a cosmetic one.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] davinci_emac.c: Fix IFF_ALLMULTI setup
From: David Miller @ 2013-10-21 22:57 UTC (permalink / raw)
To: mceier+kernel
Cc: mugunthanvnm, prabhakar.csengg, jg1.han, jiri, netdev,
linux-kernel
In-Reply-To: <1382377504-24688-1-git-send-email-mceier+kernel@gmail.com>
From: Mariusz Ceier <mceier+kernel@gmail.com>
Date: Mon, 21 Oct 2013 19:45:04 +0200
> When IFF_ALLMULTI flag is set on interface and IFF_PROMISC isn't,
> emac_dev_mcast_set should only enable RX of multicasts and reset
> MACHASH registers.
>
> It does this, but afterwards it either sets up multicast MACs
> filtering or disables RX of multicasts and resets MACHASH registers
> again, rendering IFF_ALLMULTI flag useless.
>
> This patch fixes emac_dev_mcast_set, so that multicast MACs filtering and
> disabling of RX of multicasts are skipped when IFF_ALLMULTI flag is set.
>
> Tested with kernel 2.6.37.
>
> Signed-off-by: Mariusz Ceier <mceier+kernel@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] ipv6: probe routes asynchronous in rt6_probe
From: David Miller @ 2013-10-21 22:57 UTC (permalink / raw)
To: hannes; +Cc: netdev, ja
In-Reply-To: <20131021041715.GH27787@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon, 21 Oct 2013 06:17:15 +0200
> Routes need to be probed asynchronous otherwise the call stack gets
> exhausted when the kernel attemps to deliver another skb inline, like
> e.g. xt_TEE does, and we probe at the same time.
>
> We update neigh->updated still at once, otherwise we would send to
> many probes.
>
> Cc: Julian Anastasov <ja@ssi.bg>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Looks good, applied and queued up for -stable, thanks Hannes.
^ permalink raw reply
* Re: [PATCH 1/1] [PATCH] ax88179_178a: Correct the RX error definition in RX header
From: David Miller @ 2013-10-21 22:55 UTC (permalink / raw)
To: freddy; +Cc: linux-usb, linux-kernel, netdev, louis, allan
In-Reply-To: <1382337460-2036-1-git-send-email-freddy@asix.com.tw>
From: freddy@asix.com.tw
Date: Mon, 21 Oct 2013 14:37:40 +0800
> From: Freddy Xin <freddy@asix.com.tw>
>
> Correct the definition of AX_RXHDR_CRC_ERR and
> AX_RXHDR_DROP_ERR. They are BIT29 and BIT31 in pkt_hdr
> seperately.
> Add VID:DID for Samsung USB Ethernet Adapter.
>
> Signed-off-by: Freddy Xin <freddy@asix.com.tw>
Do not do two logically different things in one patch.
Fix the register bit definitions in one patch, then add the
new device IDs in another.
^ permalink raw reply
* Re: [PATCH net-next 0/3] ipv6: sit: Implement TSO/GSO support
From: David Miller @ 2013-10-21 22:50 UTC (permalink / raw)
To: edumazet; +Cc: netdev, hkchu, eilong, ek, therbert
In-Reply-To: <1382327251-21079-1-git-send-email-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sun, 20 Oct 2013 20:47:28 -0700
> This patch serie implements GSO/TSO support for SIT tunnels
Looks good, thanks for the descriptive cover posting it helps
a lot.
All applied to net-next.
^ permalink raw reply
* Re: [PATCH v2] chelsio: remove duplicate defines
From: David Miller @ 2013-10-21 22:47 UTC (permalink / raw)
To: michael.opdenacker; +Cc: divy, netdev, linux-kernel
In-Reply-To: <1382332189-5596-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Mon, 21 Oct 2013 07:09:49 +0200
> This removes multiple duplicate definitions
> in drivers/net/ethernet/chelsio/cxgb3/regs.h
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atm: firestream: remove duplicate define
From: David Miller @ 2013-10-21 22:47 UTC (permalink / raw)
To: chas; +Cc: michael.opdenacker, linux-atm-general, netdev, linux-kernel
In-Reply-To: <20131021075335.5c9e4490@thirdoffive.cmf.nrl.navy.mil>
From: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Date: Mon, 21 Oct 2013 07:53:35 -0400
> Acked-by: Chas Williams <chas@cmf.nrl.navy.mil>
>
> On Mon, 21 Oct 2013 10:12:41 +0200
> Michael Opdenacker <michael.opdenacker@free-electrons.com> wrote:
>
>> This patch removes a duplicate define in drivers/atm/firestream.h
>>
>> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ethernet: moxa: remove duplicate includes
From: David Miller @ 2013-10-21 22:47 UTC (permalink / raw)
To: michael.opdenacker; +Cc: netdev, linux-kernel
In-Reply-To: <1382246036-19253-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Sun, 20 Oct 2013 07:13:56 +0200
> Reported by "make includecheck"
>
> Tested that drivers/net/ethernet/moxa/moxart_ether.c still compiles
> well on ARM
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] cgxb4: remove duplicate include in cxgb4.h
From: David Miller @ 2013-10-21 22:47 UTC (permalink / raw)
To: michael.opdenacker; +Cc: dm, netdev, linux-kernel
In-Reply-To: <1382245801-19192-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Sun, 20 Oct 2013 07:10:01 +0200
> Reported by "make includecheck"
>
> Tested that C sources including this file still compile well on x86
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] Revert "bridge: only expire the mdb entry when query is received"
From: David Miller @ 2013-10-21 22:45 UTC (permalink / raw)
To: linus.luessing; +Cc: stephen, netdev, bridge, linux-kernel, amwang
In-Reply-To: <1382223537-10844-1-git-send-email-linus.luessing@web.de>
From: Linus Lüssing <linus.luessing@web.de>
Date: Sun, 20 Oct 2013 00:58:57 +0200
> While this commit was a good attempt to fix issues occuring when no
> multicast querier is present, this commit still has two more issues:
>
> 1) There are cases where mdb entries do not expire even if there is a
> querier present. The bridge will unnecessarily continue flooding
> multicast packets on the according ports.
>
> 2) Never removing an mdb entry could be exploited for a Denial of
> Service by an attacker on the local link, slowly, but steadily eating up
> all memory.
>
> Actually, this commit became obsolete with
> "bridge: disable snooping if there is no querier" (b00589af3b)
> which included fixes for a few more cases.
>
> Therefore reverting the following commits (the commit stated in the
> commit message plus three of its follow up fixes):
>
> ---
> Revert "bridge: update mdb expiration timer upon reports."
> This reverts commit f144febd93d5ee534fdf23505ab091b2b9088edc.
> Revert "bridge: do not call setup_timer() multiple times"
> This reverts commit 1faabf2aab1fdaa1ace4e8c829d1b9cf7bfec2f1.
> Revert "bridge: fix some kernel warning in multicast timer"
> This reverts commit c7e8e8a8f7a70b343ca1e0f90a31e35ab2d16de1.
> Revert "bridge: only expire the mdb entry when query is received"
> This reverts commit 9f00b2e7cf241fa389733d41b615efdaa2cb0f5b.
> ---
Cong, and other bridge folks, please review this revert.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/6] ipv4: tcp_memcontrol and userns sysctls
From: David Miller @ 2013-10-21 22:44 UTC (permalink / raw)
To: ebiederm-aS9lmoZGLiVWk0Htik3J/w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87r4bghml4.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
Date: Sat, 19 Oct 2013 16:23:19 -0700
> While looking into allowing the ipv4 sysctls to be used in a network
> namespace I stumbled upon the mess that is tcp_memcontrol.
>
> I remove the dead code, broken code, and excessive abstraction in the
> tcp_memcontrols then I clean up up and allow in the user namespace the
> per net ipv4 sysctls.
I wish we hadn't installed this stuff in the first place, but better
to take care of it now than later.
Series applied, thanks Eric.
^ 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