* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: Joe Perches @ 2013-10-17 17:23 UTC (permalink / raw)
To: Kristian Evensen; +Cc: netdev
In-Reply-To: <1382028894-14236-1-git-send-email-kristian.evensen@gmail.com>
On Thu, 2013-10-17 at 18:54 +0200, Kristian Evensen wrote:
> From: Kristian Evensen <kristian.evensen@gmail.com>
>
> When a link is set as down using for example "ip link set dev X down", routes
> are deleted, but RTM_DELROUTE messages are not sent to RTNLGRP_IPV4_ROUTE. This
> patch makes trie_flush_list() send a RTM_DELROUTE for each route that is
> removed, and makes rtnelink route deletion behavior consistent across commands.
> The parameter lists for trie_flush_list() and trie_flush_leaf() are expanded to
> include required information otherwise unavailable in trie_flush_list().
[]
> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
[]
> @@ -1698,15 +1698,23 @@ int fib_table_delete(struct fib_table *tb, struct fib_config *cfg)
> return 0;
> }
>
> -static int trie_flush_list(struct list_head *head)
> +static int trie_flush_list(struct list_head *head, u32 tb_id, t_key key,
> + int plen)
> {
> struct fib_alias *fa, *fa_node;
> int found = 0;
> + struct nl_info cfg;
> +
> + memset(&cfg, 0, sizeof(cfg));
Perhaps this memset should be moved into the
list_for_each_entry_safe loop where cfg is used.
> list_for_each_entry_safe(fa, fa_node, head, fa_list) {
> struct fib_info *fi = fa->fa_info;
>
> if (fi && (fi->fib_flags & RTNH_F_DEAD)) {
memset(&cfg, 0, sizeof(cfg));
?
> + cfg.nl_net = fi->fib_net;
> + rtmsg_fib(RTM_DELROUTE, htonl(key), fa, plen, tb_id,
> + &cfg, 0);
^ permalink raw reply
* [PATCH] sctp: Do not trigger BUG_ON when deleting assoc without primary path
From: Vlad Yasevich @ 2013-10-17 17:30 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp, Vlad Yasevich, Mark Thomas, Daniel Borkmann,
Neil Horman
It is possible to enter sctp_cmd_delete_tcb() without having a
primary path. The situations this most often happens in is
when duplication cookie processing is triggered. In this
case, we are deleting a temporarily created association that
is not fully populated. Additially, at the time we
are deleting the offending association, it is really too
late to issue a BUG!
This was introduced by:
commit f9e42b853523cda0732022c2e0473c183f7aec65
net: sctp: sideeffect: throw BUG if primary_path is NULL
This patch fixes the following observed crash:
[ 42.325370] ------------[ cut here ]------------
[ 42.329216] kernel BUG at net/sctp/sm_sideeffect.c:863!
[ 42.329216] invalid opcode: 0000 [#1] SMP
[ 42.329216] Modules linked in: hmac sctp crc32c libcrc32c cls_u32
sch_netem sch_prio rfcomm bnep bluetooth rfkill nfsd auth_rpcgss
oid_registry nfs_acl nfs lockd fscache sunrpc loop joydev hid_generic
usbhid hid snd_intel8x0 snd_ac97_codec snd_pcm snd_page_alloc snd_seq
snd_timer snd_seq_device psmouse snd ohci_pci evdev parport_pc parport
pcspkr serio_raw ohci_hcd ehci_hcd usbcore ac processor thermal_sys
soundcore ac97_bus microcode usb_common button i2c_piix4 i2c_core ext4
crc16 jbd2 mbcache sd_mod sg sr_mod cdrom crc_t10dif crct10dif_common
ata_generic ahci libahci ata_piix e1000 libata scsi_mod
[ 42.329216] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0-rc5+ #2
[ 42.329216] Hardware name: innotek GmbH VirtualBox, BIOS VirtualBox
12/01/2006
[ 42.329216] task: ffffffff81610440 ti: ffffffff81600000 task.ti:
ffffffff81600000
[ 42.329216] RIP: 0010:[<ffffffffa03add10>] [<ffffffffa03add10>]
sctp_do_sm+0x159/0x1091 [sctp]
[ 42.329216] RSP: 0018:ffff88007fc03990 EFLAGS: 00010246
[ 42.329216] RAX: ffff8800000829c0 RBX: ffff88002fd0a000 RCX:
ffff88002fd0a6e0
[ 42.329216] RDX: 0000000000002710 RSI: 0000000000000000 RDI:
ffff88007fc03900
[ 42.329216] RBP: ffff88007ca1ce80 R08: ffff88002fd0a6e0 R09:
0000000072a65008
[ 42.329216] R10: 0000000072a65008 R11: 519a9b1ce38676a9 R12:
ffff88007fc039e8
[ 42.329216] R13: ffff88007fc03a08 R14: 0000000000000000 R15:
ffff88000003dbc0
[ 42.329216] FS: 0000000000000000(0000) GS:ffff88007fc00000(0000)
knlGS:0000000000000000
[ 42.329216] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 42.329216] CR2: ffffffffff600400 CR3: 000000002fd43000 CR4:
00000000000006f0
[ 42.329216] Stack:
[ 42.329216] 0000000000000001 0000000000000286 ffff8800615d31c0
0000000100000000
[ 42.329216] 0000000a00000001 ffff880075107000 0000000100000003
ffff88000003dbc0
[ 42.329216] 0000000000000000 ffff88007d3b7000 ffff8800615d31c0
ffff88007ca1cc80
[ 42.329216] Call Trace:
[ 42.329216] <IRQ>
[ 42.329216] [<ffffffffa03b10ac>] ? sctp_assoc_bh_rcv+0xe0/0x11d
[sctp]
[ 42.329216] [<ffffffffa03c1cb2>] ? sctp_rcv+0x7c2/0x896 [sctp]
[ 42.329216] [<ffffffff812eca5b>] ?
ip_local_deliver_finish+0x105/0x17b
[ 42.329216] [<ffffffff812c42d5>] ?
__netif_receive_skb_core+0x44e/0x4c6
[ 42.329216] [<ffffffff812c450f>] ? netif_receive_skb+0x4c/0x7d
[ 42.329216] [<ffffffff812c4c69>] ? napi_gro_receive+0x35/0x76
[ 42.329216] [<ffffffffa007ad4c>] ? e1000_clean_rx_irq+0x330/0x3cd
[e1000]
[ 42.329216] [<ffffffffa0079cc5>] ? e1000_clean+0x5b9/0x725 [e1000]
[ 42.329216] [<ffffffff81051442>] ? autoremove_wake_function+0x9/0x2a
[ 42.329216] [<ffffffff81056e7f>] ? __wake_up_common+0x42/0x78
[ 42.329216] [<ffffffff812c4a15>] ? net_rx_action+0xa2/0x1c6
[ 42.329216] [<ffffffff8103ae04>] ? __do_softirq+0xe8/0x201
[ 42.329216] [<ffffffff813838dc>] ? call_softirq+0x1c/0x30
[ 42.329216] [<ffffffff81003b7c>] ? do_softirq+0x2c/0x60
[ 42.329216] [<ffffffff8103afe2>] ? irq_exit+0x3b/0x7f
[ 42.329216] [<ffffffff81003803>] ? do_IRQ+0x81/0x98
[ 42.329216] [<ffffffff8137d46a>] ? common_interrupt+0x6a/0x6a
[ 42.329216] <EOI>
[ 42.329216] [<ffffffff81008aa3>] ? default_idle+0x15/0x3d
[ 42.329216] [<ffffffff81009021>] ? arch_cpu_idle+0x6/0x17
[ 42.329216] [<ffffffff8106fbad>] ? cpu_startup_entry+0x10d/0x180
[ 42.329216] [<ffffffff816adcd8>] ? start_kernel+0x3be/0x3c9
[ 42.329216] [<ffffffff816ad730>] ? repair_env_string+0x57/0x57
[ 42.329216] Code: 50 12 80 fa 0a 75 1a f6 83 dc 07 00 00 02 75 11 8a
80 30 01 00 00 83 e0 03 3c 03 0f 85 1e 0f 00 00 48 83 bb 48 01 00 00 00
75 02 <0f> 0b 48 89 df e8 56 47 01 00 48 89 df e8 e3 41 00 00 e9 fd 0e
[ 42.329216] RIP [<ffffffffa03add10>] sctp_do_sm+0x159/0x1091 [sctp]
[ 42.329216] RSP <ffff88007fc03990>
Reported-by: Mark Thomas <Mark.Thomas@metaswitch.com>
CC: Mark Thomas <Mark.Thomas@metaswitch.com>
CC: Daniel Borkmann <dborkman@redhat.com>
CC: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
---
net/sctp/sm_sideeffect.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index 666c668..1a6eef3 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -860,7 +860,6 @@ static void sctp_cmd_delete_tcb(sctp_cmd_seq_t *cmds,
(!asoc->temp) && (sk->sk_shutdown != SHUTDOWN_MASK))
return;
- BUG_ON(asoc->peer.primary_path == NULL);
sctp_unhash_established(asoc);
sctp_association_free(asoc);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 0/4] dm9000 improvements
From: David Miller @ 2013-10-17 17:36 UTC (permalink / raw)
To: nikita; +Cc: netdev, jg1.han, mugunthanvnm, michael.abbott, grinberg
In-Reply-To: <1381912894-4780-1-git-send-email-nikita@compulab.co.il>
From: Nikita Kiryanov <nikita@compulab.co.il>
Date: Wed, 16 Oct 2013 11:41:30 +0300
> This is a collection of improvements and bug fixes for dm9000, mostly
> related to its startup and resume-from-suspend sequences.
>
> Patch "Implement full reset of DM9000 network device" was submitted to the
> linux-kernel mailing list but never applied.
> An archive of the submission and the following conversation can be found here:
> http://lkml.indiana.edu/hypermail/linux/kernel/1205.2/02817.html
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 net 2/4] bridge: Apply the PVID to priority-tagged frames
From: Vlad Yasevich @ 2013-10-17 17:39 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Stephen Hemminger, David S . Miller, netdev, Toshiaki Makita,
Fernando Luis Vazquez Cao
In-Reply-To: <1382012042.3746.67.camel@ubuntu-vm-makita>
On 10/17/2013 08:14 AM, Toshiaki Makita wrote:
> On Wed, 2013-10-16 at 12:16 -0400, Vlad Yasevich wrote:
>> On 10/16/2013 11:55 AM, Stephen Hemminger wrote:
>>> On Wed, 16 Oct 2013 17:07:14 +0900
>>> Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
>>>
>>>> IEEE 802.1Q says that when we receive priority-tagged (VID 0) frames
>>>> use the PVID for the port as its VID.
>>>> (See IEEE 802.1Q-2011 6.9.1 and Table 9-2)
>>>>
>>>> Apply the PVID to not only untagged frames but also priority-tagged frames.
>>>>
>>>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>> ---
>>>> net/bridge/br_vlan.c | 27 ++++++++++++++++++++-------
>>>> 1 file changed, 20 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
>>>> index 21b6d21..5a9c44a 100644
>>>> --- a/net/bridge/br_vlan.c
>>>> +++ b/net/bridge/br_vlan.c
>>>> @@ -189,6 +189,8 @@ out:
>>>> bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
>>>> struct sk_buff *skb, u16 *vid)
>>>> {
>>>> + int err;
>>>> +
>>>> /* If VLAN filtering is disabled on the bridge, all packets are
>>>> * permitted.
>>>> */
>>>> @@ -201,20 +203,31 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
>>>> if (!v)
>>>> return false;
>>>>
>>>> - if (br_vlan_get_tag(skb, vid)) {
>>>> + err = br_vlan_get_tag(skb, vid);
>>>> + if (!*vid) {
>>>> u16 pvid = br_get_pvid(v);
>>>
>>> Ok, but it looks like br_vlan_get_tag() could be cleaner if it just returned
>>> the tag, and there was another br_vlan_tag_present() function.
>
> Thank you for reviewing.
> I agree with you.
> I had been afraid that if it affects other codes because
> br_vlan_get_tag() is used in many places else, but now I have decided
> not to hesitate to change its signature and behavior.
>
>>
>> I was just thinking about that as well. If we make br_vlan_get_tag()
>> return either the actual tag (if the packet is tagged), or the pvid
>> if (untagged/prio_tagged), then we can skp most of this.
>
> Hmm... maybe I don't fully understand you.
>
> Is what you intend something like
> br_allowed_ingress(...) {
> ...
> vid = br_vlan_get_tag(skb, v);
> if (!tagged(skb)) put_tag(skb, vid); /* untagged */
> else if (!get_vid(skb)) update_vid(skb, vid); /* prio_tagged */
> ...
> }
>
> br_vlan_get_tag(skb, v) {
> if (tagged(skb)) {
> vid = get_vid(skb);
> if (!vid) return get_pvid(v); /* prio_tagged */
> return vid;
> }
> return get_pvid(v); /* untagged */
> }
>
> This needs double check for prio_tagged at br_allowed_ingress() and
> br_vlan_get_tag().
>
> Or if we modify skb->vlan_tci at br_vlan_get_tag(), isn't it a little
> dangerous to other codes that use this function in order to just get
> vid?
>
> I am thinking it makes things simple that br_vlan_get_tag() returns 0 if
> (untagged/prio_tagged).
>
> br_allowed_ingress(...) {
> ...
> vid = br_vlan_get_tag(skb);
> if (!vid) {
> vid = get_pvid(v);
> if (!tagged(skb)) put_tag(skb, vid);/* untagged */
> else update_vid(skb, vid); /* prio_tagged */
> }
> ...
> }
>
> br_vlan_get_tag(skb) {
> if (tagged(skb)) return get_vid(skb);
> return 0;
> }
With this you end up checking if the patcket is tagged quite a lot of times.
What I am thinking is that once we perform a get_tag, we should get
the vlan tag that the current packet belongs to. We can then safely
use that tag everywhere and not have to worry too much about it.
We can pass that tag to br_allowed_ingress to verify that it is
permitted to enter.
You made a valid point about multicast code using br_vlan_get_tag
incorrectly and I plan on addressing that.
As it is, the current series addresses bugs in the implementation
that should be fixed.
We can make the code better/nicer as a next step.
-vlad
>
> Thanks,
>
> Toshiaki Makita
>
>>
>>>
>>> Also, does this still work if CONFIG_BRIDGE_VLAN_FILTERING is disabled?
>>
>> Yes. br_allowed_ingress becomes an inline if the config option is disabled.
>>
>> -vlad
>
>
^ permalink raw reply
* Re: transmit lockup using smsc95xx ethernet on usb3
From: Sarah Sharp @ 2013-10-17 17:43 UTC (permalink / raw)
To: David Laight; +Cc: netdev, linux-usb, Xenia Ragiadakou
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7394@saturn3.aculab.com>
On Thu, Oct 17, 2013 at 03:30:56PM +0100, David Laight wrote:
> > From: Sarah Sharp [mailto:sarah.a.sharp@linux.intel.com]
>
> Thanks for taking an interest.
>
> > On Tue, Oct 15, 2013 at 10:59:18AM +0100, David Laight wrote:
> > > We are seeing complete lockups of the transmit side when using
> > > the smsc95xx driver connected to a USB3 port on an i7 (Ivybridge) cpu.
> > > These errors are very intermittent - less than once a day, and
> > > it isn't actually clear that they are related to traffic load.
> > >
> > > Most of the systems are running the 3.2 kernel from Ubuntu 12.04
> > > but I've seen the same problem when running a 3.4 kernel.
> >
> > Have you tried the latest stable kernel or the latest -rc kernel?
>
> No. Although I've written a lot of device driver and comms protocol
> stack code over the years I've not had to work out how to build
> linux kernels - this may be the time I start!
It's not too hard. Here's some directions:
http://kernelnewbies.org/KernelBuild
Try building the latest stable tree, and let me know if you still have
issues. If so, we'll figure out a plan to add some pretty small
debugging to the xHCI driver.
> Given the difficulty (or rather the infrequency) of reproducing the
> problem I'd like to sort out the failing code path before changing
> kernels so that I can then verify that a more recent kernel fixes it.
The problem is that -ESHUTDOWN usually means there's a driver or host
controller issue. Numerous bug fixes have gone in since 3.4 to avoid
such host controller issues. It would be a waste of time for me to
attempt debug your issue, only to discover it had been fixed in a more
recent kernel. So I would really rather you test on a stable kernel,
see if the issue still occurs, and then we can work from a known good
base to figure out where the problem is.
> ...
> > > We are also seeing similar problems if we connect to a USB2
> > > header.
> >
> > Do you mean a USB 2.0 port under the xHCI host controller? What does
> > `lsusb -t` show as the parent host controller in that case?
>
> To clarify the fail trace below is from an xhci controller, but
> I'm pretty sure we've seen a tx lockup when using ohci.
Then it might not be an xHCI host specific issue.
> The usbmon trace when the tx locks up starts with:
>
> > > Two Bo 'fail -71', 6 succeed, one fails -32 the rest fail -104.
> > > done:9871:6913:60 ffff88020ea16a80 293818155 C Bo:3:003:2 -71 EPROTO 512 >
> > > done:9872:6927:59 ffff88020ea16f00 293818235 C Bo:3:003:2 -71 EPROTO 0
> > > done:9873:6875:58 ffff88020ea16480 293818313 C Bo:3:003:2 0 1514 >
> > > done:9874:6786:57 ffff88020c7c83c0 293818353 C Bo:3:003:2 0 1514 >
> > > done:9875:6794:56 ffff88020c7c80c0 293818470 C Bo:3:003:2 0 1514 >
> > > done:9876:6789:55 ffff88020c7c8e40 293818589 C Bo:3:003:2 0 1514 >
> > > done:9877:6775:54 ffff88020c7c8240 293818702 C Bo:3:003:2 0 1090 >
> > > done:9878:6751:53 ffff88020c7c8180 293818803 C Bo:3:003:2 0 1514 >
> > > done:9879:6735:52 ffff88020c7c89c0 293818885 C Bo:3:003:2 -32 EPIPE 0
> > > done:9880:6671:51 ffff88020c7c8900 293818925 C Bo:3:003:2 -104 ECONNRESET 0
> > > ... the ring is cleared in a software loop
> > > done:9927:1292:4 ffff88020cf0c480 293819015 C Bo:3:003:2 -104 0
> > > done:9928:1170:3 ffff88020ea160c0 293819016 C Bo:3:003:2 -104 0
> > > Something is known to be wrong...
> > > start:9931 ffff88020ea160c0 293819037 S Co:3:003:0
> > > s 02 01 0000 0002 0000 0
> > > done:9929:1080:3 ffff88020ea16780 293819044 C Bo:3:003:2 -104 0
> > > done:9930:945:2 ffff88020ea16000 293819044 C Bo:3:003:2 -104 0
> > > done:9931:48:1 ffff88020ea160c0 293819085 C Co:3:003:0 0 0
>
> I've also seen resets that start with an interrupt from device 1.
> In this case the ring is cleared with ESHUTDOWN and dmesg traces what looks
> like an unplug-plug action.
I really care a lot more about dmesg than a usbmon trace.
> Last successful ethernet transmit
> ffff88020c4870c0 701760986 C Bo:3:018:2 0 1090 >
> ffff88020c4870c0 701760992 S Bo:3:018:2 -115 1090
> = 3a340000 3a440000 22003200 00224d98
> d8460002 1f0057d7 08004500 042879ca
> Interrupt - I think from the root hub.
> ffff88020c8570c0 701761038 C Ii:3:001:1 0:2048 1 = 02
> ffff88020c8570c0 701761042 S Ii:3:001:1 -115:2048 4 <
> ffff88020ea16840 701761046 C Ii:3:018:3 -71:1 0 EPROTO
> ffff88020ea16840 701761047 S Ii:3:018:3 -115:1 16 <
> ffff88020c53c480 701761051 C Bi:3:018:1 -71 0
> ffff88020c487180 701761054 C Bo:3:018:2 -71 1024 >
> ffff880210570240 701761063 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
> ffff880210570240 701761071 C Ci:3:001:0 0 4 = 00010100
> ffff880210570240 701761074 S Co:3:001:0 s 23 01 0010 0001 0000 0
> ffff88020c53c540 701761076 C Bi:3:018:1 -71 0
> ffff880210570240 701761078 C Co:3:001:0 0 0
> ffff88020c487240 701761117 C Bo:3:018:2 -71 0
> ffff88020c53cd80 701761156 C Bi:3:018:1 -108 0 ESHITDOWN
I assume you meant "ESHUTDOWN" instead of "ESHITDOWN". :)
> ffff88020c53c9c0 701761158 C Bi:3:018:1 -108 0
> ffff88020c487840 701761196 C Bo:3:018:2 -108 0
> ffff88020c487900 701761201 C Bo:3:018:2 -108 0
> ... lots of similar lines deleted
> ffff88020c487540 701761299 C Bo:3:018:2 -108 0
> ffff88020c4870c0 701761300 C Bo:3:018:2 -108 0
> ffff88020ea16840 701761304 C Ii:3:018:3 -71:1 0
> ffff88020c8570c0 701782179 C Ii:3:001:1 0:2048 1 = 02
> ffff88020c8570c0 701782183 S Ii:3:001:1 -115:2048 4 <
> ffff88020c95be40 703089906 C Ii:3:020:1 -108:8 0
> device 17 will be the hub on the smsc95xx chip
> ffff88020c95b240 703427572 C Ii:3:017:1 -108:2048 0
> ffff88020c487540 703427788 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
> ffff88020c487540 703427803 C Ci:3:001:0 0 4 = 01010100
>
> ...
> > I would suggest you try with the latest stable kernel, with
> > CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING enabled. If you try
> > the latest 3.12-rc, you will only need the CONFIG_USB_DEBUG. Or, if
> > that output is too much (it will spew on short packets, which may be an
> > issue with your ethernet adapter),
>
> The only way I've got the above usbmon trace is by reading 1000000
> lines (with dd) and saving the file if the last line output by dmesg
> changes. I suspect the above might trace too much for that!
> I think the kernel I have has the xhci_warn() compiled out - I'm not
> seeing any of those reported by dmesg. I looked at the .h files and
> couldn't see where xhci_warn() gets suppressed.
If CONFIG_USB_DEBUG isn't set, then the calls to dev_dbg and dev_warn
are suppressed.
> > with the 3.12-rc kernel, you can turn
> > off CONFIG_USB_DEBUG and capture command trace events through the xHCI
> > trace infrastructure. Xenia can help you with that if necessary (I'm
> > going to be at a conference starting Friday).
> >
> > Without that dmesg, I really can't tell what's happening at an xHCI
> > level.
>
> Have you any idea which code loops are clearing the ring with ECONNRESET
> and ESHUTDOWN and where they might be being called from?
> I've been reading the code but couldn't see any obvious paths that would
> lead to the ring being cleared with those codes.
There's a lot of cases in the host controller drivers in
drivers/usb/host/ where URBs are returned with ESHUTDOWN.
If you look in the xHCI driver, ESHUTDOWN occurs when the host "dies",
usually because it stopped responding to commands. There were several
fixes that went into the kernel relating to command handling that could
help you. So, as I said, I would like you to test from a known good
base (the latest stable kernel) and we can debug from there.
Sarah Sharp
^ permalink raw reply
* Any suggestions for a 40G Ethernet NIC?
From: Ben Greear @ 2013-10-17 17:55 UTC (permalink / raw)
To: netdev
I'd like to start playing around with 40G, but doesn't seem to be too
many such NICs available. Does anyone have any suggestions for 40G NICs
that work well with Linux?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] sctp: Do not trigger BUG_ON when deleting assoc without primary path
From: Daniel Borkmann @ 2013-10-17 18:01 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, linux-sctp, Mark Thomas, Neil Horman
In-Reply-To: <1382031042-27339-1-git-send-email-vyasevich@gmail.com>
On 10/17/2013 07:30 PM, Vlad Yasevich wrote:
> It is possible to enter sctp_cmd_delete_tcb() without having a
> primary path. The situations this most often happens in is
> when duplication cookie processing is triggered. In this
> case, we are deleting a temporarily created association that
> is not fully populated. Additially, at the time we
> are deleting the offending association, it is really too
> late to issue a BUG!
>
> This was introduced by:
> commit f9e42b853523cda0732022c2e0473c183f7aec65
> net: sctp: sideeffect: throw BUG if primary_path is NULL
Sure, lets remove it, but then we could still get a WARN() [sure,
better than BUG], if the user at the very same time checks procfs
through sctp_seq_dump_local_addrs(), see discussion we had here [1]:
It may trigger the crash later if the user performs some action on the
association that touches the primary. That's the reason why I was
proposing the checks below.
With the checks in command interpreter, we are only left with the
possibility that primary_path changes to NULL during the association
lifetime, which code audit doesn't support right now. If that ever
changes we would at least have a bit more information to go on.
[1] http://patchwork.ozlabs.org/patch/251099/
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index 666c668..1a6eef3 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -860,7 +860,6 @@ static void sctp_cmd_delete_tcb(sctp_cmd_seq_t *cmds,
> (!asoc->temp) && (sk->sk_shutdown != SHUTDOWN_MASK))
> return;
>
> - BUG_ON(asoc->peer.primary_path == NULL);
> sctp_unhash_established(asoc);
> sctp_association_free(asoc);
> }
>
^ permalink raw reply
* Re: transmit lockup using smsc95xx ethernet on usb3
From: Alan Stern @ 2013-10-17 18:07 UTC (permalink / raw)
To: Sarah Sharp
Cc: David Laight, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Xenia Ragiadakou
In-Reply-To: <20131017174329.GB6256@xanatos>
On Thu, 17 Oct 2013, Sarah Sharp wrote:
> > Given the difficulty (or rather the infrequency) of reproducing the
> > problem I'd like to sort out the failing code path before changing
> > kernels so that I can then verify that a more recent kernel fixes it.
>
> The problem is that -ESHUTDOWN usually means there's a driver or host
> controller issue. Numerous bug fixes have gone in since 3.4 to avoid
> such host controller issues. It would be a waste of time for me to
> attempt debug your issue, only to discover it had been fixed in a more
> recent kernel. So I would really rather you test on a stable kernel,
> see if the issue still occurs, and then we can work from a known good
> base to figure out where the problem is.
-ESHUTDOWN really indicates either that the system believes the device
has been disconnected from the USB bus or that the host controller
itself has stopped working.
> > To clarify the fail trace below is from an xhci controller, but
> > I'm pretty sure we've seen a tx lockup when using ohci.
>
> Then it might not be an xHCI host specific issue.
Undoubtedly not.
> > The usbmon trace when the tx locks up starts with:
> >
> > > > Two Bo 'fail -71', 6 succeed, one fails -32 the rest fail -104.
> > > > done:9871:6913:60 ffff88020ea16a80 293818155 C Bo:3:003:2 -71 EPROTO 512 >
> > > > done:9872:6927:59 ffff88020ea16f00 293818235 C Bo:3:003:2 -71 EPROTO 0
Those -71 errors indicate a low-level problem. It generally means that
the device has stopped sending packets. Perhaps its firmware has
crashed, or perhaps it has disconnected itself electrically from the
bus.
> > Last successful ethernet transmit
> > ffff88020c4870c0 701760986 C Bo:3:018:2 0 1090 >
> > ffff88020c4870c0 701760992 S Bo:3:018:2 -115 1090
> > = 3a340000 3a440000 22003200 00224d98
> > d8460002 1f0057d7 08004500 042879ca
> > Interrupt - I think from the root hub.
> > ffff88020c8570c0 701761038 C Ii:3:001:1 0:2048 1 = 02
> > ffff88020c8570c0 701761042 S Ii:3:001:1 -115:2048 4 <
> > ffff88020ea16840 701761046 C Ii:3:018:3 -71:1 0 EPROTO
> > ffff88020ea16840 701761047 S Ii:3:018:3 -115:1 16 <
> > ffff88020c53c480 701761051 C Bi:3:018:1 -71 0
> > ffff88020c487180 701761054 C Bo:3:018:2 -71 1024 >
> > ffff880210570240 701761063 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
> > ffff880210570240 701761071 C Ci:3:001:0 0 4 = 00010100
These last two lines show the host controller telling the system that
the device has disconnected. Once that happens, any future
communication with the device is hopeless.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
From: H. Peter Anvin @ 2013-10-17 18:19 UTC (permalink / raw)
To: Ingo Molnar, Neil Horman
Cc: Eric Dumazet, linux-kernel, sebastien.dugue, Thomas Gleixner,
Ingo Molnar, x86, netdev
In-Reply-To: <20131017084121.GC22705@gmail.com>
On 10/17/2013 01:41 AM, Ingo Molnar wrote:
>
> To correctly simulate the workload you'd have to:
>
> - allocate a buffer larger than your L2 cache.
>
> - to measure the effects of the prefetches you'd also have to randomize
> the individual buffer positions. See how 'perf bench numa' implements a
> random walk via --data_rand_walk, in tools/perf/bench/numa.c.
> Otherwise the CPU might learn your simplistic stream direction and the
> L2 cache might hw-prefetch your data, interfering with any explicit
> prefetches the code does. In many real-life usecases packet buffers are
> scattered.
>
> Also, it would be nice to see standard deviation noise numbers when two
> averages are close to each other, to be able to tell whether differences
> are statistically significant or not.
>
Seriously, though, how much does it matter? All the above seems likely
to do is to drown the signal by adding noise.
If the parallel (threaded) checksumming is faster, which theory says it
should and microbenchmarking confirms, how important are the
macrobenchmarks?
-hpa
^ permalink raw reply
* Re: [PATCH net 2/9] bnx2x: Prevent an illegal pointer dereference during panic
From: David Miller @ 2013-10-17 18:21 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, ariele, eilong, dmitry
In-Reply-To: <1381847335-32662-3-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Tue, 15 Oct 2013 16:28:48 +0200
> @@ -775,6 +775,15 @@ void bnx2x_fw_dump_lvl(struct bnx2x *bp, const char *lvl)
> trace_shmem_base = bp->common.shmem_base;
> else
> trace_shmem_base = SHMEM2_RD(bp, other_shmem_base_addr);
> +
> + /* sanity */
> + if (trace_shmem_base < MCPR_SCRATCH_BASE(bp) ||
> + trace_shmem_base > MCPR_SCRATCH_BASE(bp) + 0x28000) {
I would say that this second test should be ">=" rather than ">".
Actually, there are a lot of holes still remaining here.
trace_shmem_base is validated, but then you access the signature at
0x800 bytes before trace_shmem_base value. That should be accounted
for in the test above too.
And what about that 'mark' value you read? Any validations needed on
that?
And then you read from "addr" to "mark", and I see no checks that this
range makes any sense either.
^ permalink raw reply
* Re: [PATCH] sctp: Do not trigger BUG_ON when deleting assoc without primary path
From: Daniel Borkmann @ 2013-10-17 18:25 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, linux-sctp, Mark Thomas, Neil Horman
In-Reply-To: <526025F2.2040304@redhat.com>
On 10/17/2013 08:01 PM, Daniel Borkmann wrote:
> On 10/17/2013 07:30 PM, Vlad Yasevich wrote:
>> It is possible to enter sctp_cmd_delete_tcb() without having a
>> primary path. The situations this most often happens in is
>> when duplication cookie processing is triggered. In this
>> case, we are deleting a temporarily created association that
>> is not fully populated. Additially, at the time we
>> are deleting the offending association, it is really too
>> late to issue a BUG!
>>
>> This was introduced by:
>> commit f9e42b853523cda0732022c2e0473c183f7aec65
>> net: sctp: sideeffect: throw BUG if primary_path is NULL
>
> Sure, lets remove it, but then we could still get a WARN() [sure,
> better than BUG], if the user at the very same time checks procfs
> through sctp_seq_dump_local_addrs(), see discussion we had here [1]:
>
> It may trigger the crash later if the user performs some action on the
> association that touches the primary. That's the reason why I was
> proposing the checks below.
>
> With the checks in command interpreter, we are only left with the
> possibility that primary_path changes to NULL during the association
> lifetime, which code audit doesn't support right now. If that ever
> changes we would at least have a bit more information to go on.
>
> [1] http://patchwork.ozlabs.org/patch/251099/
Meaning, all I'm saying is that with f9e42b853 we wanted to find exactly
such a case we have right now, that is, that an assoc could enter the
hashtable w/o primary path, no?
^ permalink raw reply
* Re: pull request: batman-adv 2013-10-13
From: David Miller @ 2013-10-17 18:27 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Sun, 13 Oct 2013 13:22:45 +0200
> this is our second pull request intended for net-next/linux-3.13.
>
> The most important piece in this patchset is the new packet fragmentation code
> implemented by Martin Hundebøll during his Google Summer of Code 2012[1]. This
> code is entirely substituting the current fragmentation mechanism.
>
> Other than this you have:
> - the creation of a common BAT ICMP header which makes the ICMP subsystem more
> flexible and extensible
> - the addition of a dummy rx mode handler for the soft-interface which allows
> users to set static multicast listeners
> - some minor improvements and code cleanups
>
>
> Please pull or let me know of any problem.
Pulled, thanks Antonio.
^ permalink raw reply
* pull request: wireless-next 2013-10-17
From: John W. Linville @ 2013-10-17 18:23 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
[-- Attachment #1: Type: text/plain, Size: 11716 bytes --]
Dave,
This is a batch of updates intended for the 3.13 stream...
The biggest item of interest in here is wcn36xx, the new mac80211
driver for Qualcomm WCN3660/WCN3680 hardware.
Regarding the mac80211 bits, Johannes says:
"We have an assortment of cleanups and new features, of which the
biggest one is probably the channel-switch support in IBSS. Nothing
else really stands out much."
On top of that, the ath9k and rt2x00 get a lot of update action from
Felix Fietkau and Gabor Juhos, respectively. There are a handful of
updates to other drivers here and there as well.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit ccdbb6e96beca362db876d820ac1e560ff6d9579:
tcp: tcp_transmit_skb() optimizations (2013-10-11 17:48:18 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
for you to fetch changes up to 9f96da4dd2ccf685b506a21104cb13b1aadd907a:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem (2013-10-17 14:02:07 -0400)
----------------------------------------------------------------
Amitkumar Karwar (1):
mwifiex: use alloc_workqueue() function
Arik Nemtsov (1):
mac80211: implement STA CSA for drivers using channel contexts
Eliad Peller (2):
mac80211: fix some snprintf misuses
ieee80211: fix vht cap definitions
Eugene Krasnikov (1):
wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware
Felipe Balbi (1):
net: wireless: wl1251: update firmware path
Felix Fietkau (10):
ath9k: use a separate data structure for rx buffers
ath9k_hw: remove direct accesses to channel mode flags
ath9k_hw: remove IS_CHAN_B()
ath9k_hw: remove IS_CHAN_OFDM()
ath9k_hw: simplify channel flags
ath9k: make ath9k_cmn_update_ichannel static
ath9k: move channel change code to ath_set_channel
ath9k: remove sc->config.cabqReadyTime
ath9k: make ath9k_uses_beacons static
ath9k_hw: remove references to hw->conf
Fengguang Wu (1):
wcn36xx: fix coccinelle warnings
Fred Zhou (2):
mac80211: use exact-size allocation for authentication frame
mac80211: improve default WMM parameter setting
Gabor Juhos (14):
rt2x00: rt2800lib: remove TXMIXER_GAIN entries from the extended EEPROM map
rt2x00: rt2800lib: remove TXPOWER_DELTA entry from extended EEPROM map
rt2x00: rt2800lib: fix default VGC values for RT3593
rt2x00: rt2800lib: fix VGC programming for RT3572 and RT3593
rt2x00: rt2800lib: fix default VGC values for RT3572 for the 5GHz band
rt2x00: use generic EWMA functions for average RSSI calculations
rt2x00: rt2800lib: fix VGC adjustment for RT5592
rt2x00: rt2800lib: fix VGC adjustment for RT3572 and RT3593
rt2x00: cleanup indentation in rt2800.h
rt2x00: add rt2x00_has_cap_* helpers
rt2x00: rt2x00lib: use rt2x00_has_cap_* helpers
rt2x00: rt2800lib: use rt2x00_has_cap_* helpers
rt2x00: rt61pci: use rt2x00_has_cap_* helpers
rt2x00: rt73usb: use rt2x00_has_cap_* helpers
Hauke Mehrtens (3):
bcma: reject PCI cards in bcma.
bcma: add PCI id 0x4313
brcmsmac: add support for a BCM4313 with PCI id 0x4313
Janusz Dziedzic (1):
cfg80211: parse dfs region for internal regdb option
Johannes Berg (4):
mac80211: add ieee80211_iterate_active_interfaces_rtnl()
mac80211: use ERR_CAST()
mac80211: add explicit IBSS driver operations
regulatory: enable channels 52-64 and 100-144 for world roaming
John W. Linville (2):
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211-next
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Kevin Lo (3):
rt2x00: rt2800lib: no need to toggle RF R30 bit 7 twice
rt2x00: rt2800lib: fix RF registers for RT5390/RT5392
rt2x00: rt2800lib: remove duplicate rf_vals for RF3053
Kirill Tkhai (1):
rt2x00_pci: Fix interrupt handler name (visible at /proc/interrupts)
Lorenzo Bianconi (2):
mac80211: add fixed_rate management to minstrel rc
mac80211: do not override fixed_rate_idx in minstrel_ht_update_stats
Michael Opdenacker (1):
net: p54spi: remove deprecated IRQF_DISABLED
Michal Kazior (1):
mac80211: support reporting A-MSDU subframes individually
Peter Senna Tschudin (1):
mwifiex: Change variable type to bool
Sergey Ryazanov (1):
mac80211: Remove superfluous is_multicast_ether_addr() call
Simon Wunderlich (7):
cfg80211: export cfg80211_chandef_dfs_required
mac80211: split off channel switch parsing function
mac80211: split off ibss disconnect
mac80211: add support for CSA in IBSS mode
mac80211: send a CSA action frame when changing channel
nl80211: enable IBSS support for channel switch announcements
nl80211: allow CAC only if no operation is going on
Stanislaw Gruszka (2):
mac80211: change beacon/connection polling
rt2x00: do not pause queue on flush
cedric Voncken (1):
cfg80211: vlan priority handling in WMM
MAINTAINERS | 8 +
drivers/bcma/host_pci.c | 8 +-
drivers/net/wireless/ath/Kconfig | 1 +
drivers/net/wireless/ath/Makefile | 1 +
drivers/net/wireless/ath/ath9k/ani.c | 6 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 43 +-
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 7 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 26 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 113 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 12 +-
drivers/net/wireless/ath/ath9k/calib.c | 9 +-
drivers/net/wireless/ath/ath9k/common.c | 91 +-
drivers/net/wireless/ath/ath9k/common.h | 7 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 32 +-
drivers/net/wireless/ath/ath9k/hw.c | 67 +-
drivers/net/wireless/ath/ath9k/hw.h | 82 +-
drivers/net/wireless/ath/ath9k/init.c | 87 +-
drivers/net/wireless/ath/ath9k/mac.c | 6 +-
drivers/net/wireless/ath/ath9k/mac.h | 2 -
drivers/net/wireless/ath/ath9k/main.c | 157 +-
drivers/net/wireless/ath/ath9k/mci.c | 8 +-
drivers/net/wireless/ath/ath9k/recv.c | 48 +-
drivers/net/wireless/ath/ath9k/xmit.c | 12 +-
drivers/net/wireless/ath/wcn36xx/Kconfig | 16 +
drivers/net/wireless/ath/wcn36xx/Makefile | 7 +
drivers/net/wireless/ath/wcn36xx/debug.c | 181 +
drivers/net/wireless/ath/wcn36xx/debug.h | 49 +
drivers/net/wireless/ath/wcn36xx/dxe.c | 805 ++++
drivers/net/wireless/ath/wcn36xx/dxe.h | 284 ++
drivers/net/wireless/ath/wcn36xx/hal.h | 4657 ++++++++++++++++++++++++
drivers/net/wireless/ath/wcn36xx/main.c | 1036 ++++++
drivers/net/wireless/ath/wcn36xx/pmc.c | 62 +
drivers/net/wireless/ath/wcn36xx/pmc.h | 33 +
drivers/net/wireless/ath/wcn36xx/smd.c | 2126 +++++++++++
drivers/net/wireless/ath/wcn36xx/smd.h | 127 +
drivers/net/wireless/ath/wcn36xx/txrx.c | 284 ++
drivers/net/wireless/ath/wcn36xx/txrx.h | 160 +
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 238 ++
drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
drivers/net/wireless/mwifiex/cmdevt.c | 2 +-
drivers/net/wireless/mwifiex/join.c | 2 +-
drivers/net/wireless/mwifiex/main.c | 4 +-
drivers/net/wireless/mwifiex/sta_cmd.c | 2 +-
drivers/net/wireless/mwifiex/wmm.c | 2 +-
drivers/net/wireless/p54/p54spi.c | 2 +-
drivers/net/wireless/rt2x00/Kconfig | 1 +
drivers/net/wireless/rt2x00/rt2800.h | 42 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 173 +-
drivers/net/wireless/rt2x00/rt2x00.h | 103 +-
drivers/net/wireless/rt2x00/rt2x00crypto.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00debug.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00link.c | 74 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 6 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 39 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 2 +
drivers/net/wireless/rt2x00/rt61pci.c | 20 +-
drivers/net/wireless/rt2x00/rt73usb.c | 18 +-
drivers/net/wireless/ti/wl1251/wl1251.h | 4 +-
include/linux/ieee80211.h | 4 +-
include/net/cfg80211.h | 9 +
include/net/mac80211.h | 42 +
net/mac80211/cfg.c | 92 +-
net/mac80211/chan.c | 5 -
net/mac80211/debugfs.c | 55 +-
net/mac80211/driver-ops.h | 27 +
net/mac80211/ibss.c | 608 +++-
net/mac80211/ieee80211_i.h | 30 +-
net/mac80211/iface.c | 4 +
net/mac80211/key.c | 2 +-
net/mac80211/mlme.c | 334 +-
net/mac80211/rc80211_minstrel.c | 14 +
net/mac80211/rc80211_minstrel_ht.c | 23 +-
net/mac80211/rc80211_pid_debugfs.c | 26 +-
net/mac80211/rx.c | 39 +-
net/mac80211/scan.c | 3 +-
net/mac80211/spectmgmt.c | 162 +
net/mac80211/trace.h | 35 +
net/mac80211/tx.c | 39 +-
net/mac80211/util.c | 162 +-
net/mac80211/vht.c | 4 +-
net/wireless/chan.c | 1 +
net/wireless/core.h | 9 -
net/wireless/debugfs.c | 24 +-
net/wireless/genregdb.awk | 6 +
net/wireless/nl80211.c | 52 +-
net/wireless/reg.c | 14 +-
net/wireless/util.c | 9 +
89 files changed, 11937 insertions(+), 1309 deletions(-)
create mode 100644 drivers/net/wireless/ath/wcn36xx/Kconfig
create mode 100644 drivers/net/wireless/ath/wcn36xx/Makefile
create mode 100644 drivers/net/wireless/ath/wcn36xx/debug.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/debug.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/dxe.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/dxe.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/hal.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/main.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/pmc.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/pmc.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/smd.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/smd.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/txrx.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/txrx.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/wcn36xx.h
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] sctp: Do not trigger BUG_ON when deleting assoc without primary path
From: Vlad Yasevich @ 2013-10-17 18:35 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-sctp, Mark Thomas, Neil Horman
In-Reply-To: <52602BA3.5020405@redhat.com>
On 10/17/2013 02:25 PM, Daniel Borkmann wrote:
> On 10/17/2013 08:01 PM, Daniel Borkmann wrote:
>> On 10/17/2013 07:30 PM, Vlad Yasevich wrote:
>>> It is possible to enter sctp_cmd_delete_tcb() without having a
>>> primary path. The situations this most often happens in is
>>> when duplication cookie processing is triggered. In this
>>> case, we are deleting a temporarily created association that
>>> is not fully populated. Additially, at the time we
>>> are deleting the offending association, it is really too
>>> late to issue a BUG!
>>>
>>> This was introduced by:
>>> commit f9e42b853523cda0732022c2e0473c183f7aec65
>>> net: sctp: sideeffect: throw BUG if primary_path is NULL
>>
>> Sure, lets remove it, but then we could still get a WARN() [sure,
>> better than BUG], if the user at the very same time checks procfs
>> through sctp_seq_dump_local_addrs(), see discussion we had here [1]:
>>
>> It may trigger the crash later if the user performs some action on the
>> association that touches the primary. That's the reason why I was
>> proposing the checks below.
>>
>> With the checks in command interpreter, we are only left with the
>> possibility that primary_path changes to NULL during the association
>> lifetime, which code audit doesn't support right now. If that ever
>> changes we would at least have a bit more information to go on.
>>
>> [1] http://patchwork.ozlabs.org/patch/251099/
>
> Meaning, all I'm saying is that with f9e42b853 we wanted to find exactly
> such a case we have right now, that is, that an assoc could enter the
> hashtable w/o primary path, no?
But it didn't enter a hash table in this case. SCTP_CMD_NEW_ASOC
was never issued. The sequence was:
SCTP_CMD_SET_ASOC
SCTP_CMD_DELETE_TCB
Such association would never be found through /proc since it was never
hashed. Such association would never be found the user since it
is only really alive while the packet is processed. By all rights
it should be marked as 'temp', but it isn't due to cookie processing.
May be we should update cookie processing function to allow it
to create temp associations if so desired.
-vlad
^ permalink raw reply
* Re: [PATCH net 2/9] bnx2x: Prevent an illegal pointer dereference during panic
From: Eilon Greenstein @ 2013-10-17 18:47 UTC (permalink / raw)
To: David Miller; +Cc: yuvalmin, netdev, ariele, dmitry
In-Reply-To: <20131017.142134.1058688642083607743.davem@davemloft.net>
On Thu, 2013-10-17 at 14:21 -0400, David Miller wrote:
> From: "Yuval Mintz" <yuvalmin@broadcom.com>
> Date: Tue, 15 Oct 2013 16:28:48 +0200
>
> > @@ -775,6 +775,15 @@ void bnx2x_fw_dump_lvl(struct bnx2x *bp, const char *lvl)
> > trace_shmem_base = bp->common.shmem_base;
> > else
> > trace_shmem_base = SHMEM2_RD(bp, other_shmem_base_addr);
> > +
> > + /* sanity */
> > + if (trace_shmem_base < MCPR_SCRATCH_BASE(bp) ||
> > + trace_shmem_base > MCPR_SCRATCH_BASE(bp) + 0x28000) {
>
> I would say that this second test should be ">=" rather than ">".
>
> Actually, there are a lot of holes still remaining here.
>
> trace_shmem_base is validated, but then you access the signature at
> 0x800 bytes before trace_shmem_base value. That should be accounted
> for in the test above too.
>
> And what about that 'mark' value you read? Any validations needed on
> that?
>
> And then you read from "addr" to "mark", and I see no checks that this
> range makes any sense either.
The failure that we saw was due to PCI read failure, so we could have
checked that we did not read all 1's, but then we thought about a
stronger validation to make sure this address is not being overrun for
some unknown reason (maybe stack overflow of the FW, after all, we are
at a FW bug handling routine) so this added condition validate that the
address is within the scratchpad limitation. To make it more precious,
we should account for the differences between the different silicon
revisions, but we did not really see such a failure - the failure we saw
was reading all 1's, the extra sanity will catch some more failure, but
obviously not all.
I guess we should really re-spin and check for all 1's, or add some more
code to make it really accurate, or at least fix the ">" to ">=". We
will send a revised series with a fix.
Thanks,
Eilon
^ permalink raw reply
* Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
From: Eric Dumazet @ 2013-10-17 18:48 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, Neil Horman, linux-kernel, sebastien.dugue,
Thomas Gleixner, Ingo Molnar, x86, netdev
In-Reply-To: <52602A29.506@zytor.com>
On Thu, 2013-10-17 at 11:19 -0700, H. Peter Anvin wrote:
> Seriously, though, how much does it matter? All the above seems likely
> to do is to drown the signal by adding noise.
I don't think so.
>
> If the parallel (threaded) checksumming is faster, which theory says it
> should and microbenchmarking confirms, how important are the
> macrobenchmarks?
Seriously, micro benchmarks are very misleading.
I spent time on this patch, and found no changes on real workloads.
I was excited first, then disappointed.
I hope we will find the real issue, as I really don't care of micro
benchmarks.
^ permalink raw reply
* Re: [PATCH] sctp: Do not trigger BUG_ON when deleting assoc without primary path
From: Daniel Borkmann @ 2013-10-17 18:52 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, linux-sctp, Mark Thomas, Neil Horman
In-Reply-To: <52602E0C.6000300@gmail.com>
On 10/17/2013 08:35 PM, Vlad Yasevich wrote:
> On 10/17/2013 02:25 PM, Daniel Borkmann wrote:
>> On 10/17/2013 08:01 PM, Daniel Borkmann wrote:
>>> On 10/17/2013 07:30 PM, Vlad Yasevich wrote:
>>>> It is possible to enter sctp_cmd_delete_tcb() without having a
>>>> primary path. The situations this most often happens in is
>>>> when duplication cookie processing is triggered. In this
>>>> case, we are deleting a temporarily created association that
>>>> is not fully populated. Additially, at the time we
>>>> are deleting the offending association, it is really too
>>>> late to issue a BUG!
>>>>
>>>> This was introduced by:
>>>> commit f9e42b853523cda0732022c2e0473c183f7aec65
>>>> net: sctp: sideeffect: throw BUG if primary_path is NULL
>>>
>>> Sure, lets remove it, but then we could still get a WARN() [sure,
>>> better than BUG], if the user at the very same time checks procfs
>>> through sctp_seq_dump_local_addrs(), see discussion we had here [1]:
>>>
>>> It may trigger the crash later if the user performs some action on the
>>> association that touches the primary. That's the reason why I was
>>> proposing the checks below.
>>>
>>> With the checks in command interpreter, we are only left with the
>>> possibility that primary_path changes to NULL during the association
>>> lifetime, which code audit doesn't support right now. If that ever
>>> changes we would at least have a bit more information to go on.
>>>
>>> [1] http://patchwork.ozlabs.org/patch/251099/
>>
>> Meaning, all I'm saying is that with f9e42b853 we wanted to find exactly
>> such a case we have right now, that is, that an assoc could enter the
>> hashtable w/o primary path, no?
>
> But it didn't enter a hash table in this case. SCTP_CMD_NEW_ASOC
> was never issued. The sequence was:
> SCTP_CMD_SET_ASOC
> SCTP_CMD_DELETE_TCB
>
> Such association would never be found through /proc since it was never
> hashed. Such association would never be found the user since it
> is only really alive while the packet is processed. By all rights
> it should be marked as 'temp', but it isn't due to cookie processing.
>
> May be we should update cookie processing function to allow it
> to create temp associations if so desired.
Yes, I think that might be the better way to move on.
> -vlad
^ permalink raw reply
* Re: [PATCH net-next] inet_diag: use sock_gen_put()
From: David Miller @ 2013-10-17 19:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381506889.4971.104.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 11 Oct 2013 08:54:49 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP listener refactoring, part 6 :
>
> Use sock_gen_put() from inet_diag_dump_one_icsk() for future
> SYN_RECV support.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next v3 7/9] qlcnic: Validate Tx queue only for 82xx adapters.
From: David Miller @ 2013-10-17 19:07 UTC (permalink / raw)
To: himanshu.madhani; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <21b377dba7708434c344a9204afd460c9b43af3c.1381882600.git.himanshu.madhani@qlogic.com>
From: Himanshu Madhani <himanshu.madhani@qlogic.com>
Date: Tue, 15 Oct 2013 12:57:52 -0400
> From: Himanshu Madhani <himanshu.madhani@qlogic.com>
>
> o validate Tx queue only in case of adapters which supports
> multi Tx queue.
>
> This patch is to fix regression introduced in commit
> aa4a1f7df7cbb98797c9f4edfde3c726e2b3841f
> "qlcnic: Enable Tx queue changes using ethtool for 82xx Series adapter"
>
> Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Do not submit bug fixes for "net-next" if they are for problems
that exist in 'net'.
What do several driver maintainers do this repeatedly?
Are you scared I'll reject the submission? If it's really a bug fix
I won't, 'net' is where it really belongs.
I'm not applying this series, submit it properly.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/4] net/mlx4: Mellanox driver update 15-10-2013
From: David Miller @ 2013-10-17 19:13 UTC (permalink / raw)
To: amirv; +Cc: netdev, eyalpe
In-Reply-To: <1381848924-18992-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Tue, 15 Oct 2013 16:55:20 +0200
> This patchset contains small code cleaning patches, and a patch to make
> mlx4_core use module_request() in order to load the relevant link layer module
> (mlx4_en or mlx4_ib) according to the port type.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] isdn: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-10-17 19:14 UTC (permalink / raw)
To: michael.opdenacker; +Cc: mac, isdn, netdev, linux-kernel
In-Reply-To: <1381641869-7709-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Sun, 13 Oct 2013 07:24:29 +0200
> This patch proposes to remove the use of the IRQF_DISABLED flag
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] irda: update comment mentioning IRQF_DISABLED
From: David Miller @ 2013-10-17 19:15 UTC (permalink / raw)
To: michael.opdenacker; +Cc: samuel, netdev, linux-kernel
In-Reply-To: <1381645591-9565-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Sun, 13 Oct 2013 08:26:31 +0200
> This patch removes a comment mentioning IRQF_DISABLED,
> which is deprecated.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 00/17] netfilter updates: nf_tables pull request
From: David Miller @ 2013-10-17 19:23 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, kaber, netdev
In-Reply-To: <1381768738-17739-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 14 Oct 2013 18:38:41 +0200
> The following patchset contains the current original nf_tables tree
> condensed in 17 patches. I have organized them by chronogical order
> since the original nf_tables code was released in 2009 and by
> dependencies between the different patches.
...
> There is still work to do to fully replace x_tables [4] [5] but that can
> be done incrementally by extending our netlink API. Moreover, looking at
> netfilter-devel and the amount of contributions to nf_tables we've been
> getting, I think it would be good to have it mainstream to avoid accumulating
> large patchsets skip continuous rebases.
>
> I tried to provide a reasonable patchset, we have more than 100 accumulated
> patches in the original nf_tables tree, so I collapsed many of the small
> fixes to the main patch we had since 2009 and provide a small batch for
> review to netdev, while trying to retain part of the history.
>
> For those who didn't give a try to nf_tables yet, there's a quick howto
> available from Eric Leblond that describes how to get things working [6].
>
> Comments/reviews welcome.
This looks great, pulled, thanks a lot!!
^ permalink raw reply
* Re: [PATCH v4 net 0/3] sctp: Use software checksum under certain
From: David Miller @ 2013-10-17 19:26 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, linux-sctp, fan.du
In-Reply-To: <1381888891-31186-1-git-send-email-vyasevich@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Tue, 15 Oct 2013 22:01:28 -0400
> There are some cards that support SCTP checksum offloading. When using
> these cards with IPSec or forcing IP fragmentation of SCTP traffic,
> the checksum is computed incorrectly due to the fact that xfrm and IP/IPv6
> fragmentation code do not know that this is SCTP traffic and do not
> know that checksum has to be computed differently.
>
> To fix this, we let SCTP detect these conditions and perform software
> checksum calculation.
Series applied, thanks Vlad.
^ permalink raw reply
* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: Eric W. Biederman @ 2013-10-17 19:28 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: Stephen Hemminger, David Miller, yamato, netdev
In-Reply-To: <52600ABC.1030701@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
> Le 16/10/2013 21:53, Eric W. Biederman a écrit :
>> The age old question why can't we have global identifiers for
>> namespaces?
>>
>> The answer is that I don't want to implement a namespace for namespaces.
> Sorry, but I don't understand the problem. This ID is owned by the kernel, like
> the netns list (for_each_net()) is owned by it.
The scenario where problem are likely to show up is something like this.
For testing it would be reasonable to setup two linux containers that
look like full linux systems. In those containers you run one instance
of your virtual router managment daemons, and you arrange to synchronize
between the two linux containers for testing.
It becomes even more interesting when we want to migrate one of those
linux containers to another physical machine.
Global identifiers start breaking the first scenario, and really trash
the second scenario.
At the same time migration of configuration and replication of
configuration are essentially the same problem, so it would be very
silly to design such that will cause problems.
>> While the proc inode does work today across different mounts of proc, I
>> reserve the right at some future date (if it solves a technical problem)
>> to give each namespace a different inode number in each different mount
>> of proc. So the inode number is not quite the unique identifier you
>> want. The inode number is a close as I am willing to get to a namespace
>> of namespaces.
>>
>> I think the simplest solution is to just not worry about which namespace
>> the other half of a veth pair is in. But I have not encountered the
>> problem where I need to know exactly which namespace we are worrying
>> about.
> Ok, let's start by explaining our usecase.
>
> We are using namespaces only to implement virtual routers (VR), ie only
> the networking stack is virtualized. We don't care about other namespaces, we
> just want to run several network stacks and beeing able to manage them.
>
> For example, providers use this feature to isolate clients, one VR is opened
> for each client. You can have a large number of clients (+10 000) and thus the
> same number of netns.
> Considering these numbers, we don't want to run one instance per VR for all of
> our network daemons, but have only one instance that manage all VR.
>
> You also have daemons that monitor the system and synchronize network objects
> (interfaces, routes, etc.) on another linux. Goal is to implement an high
> availablity system: it's possible to switch to the other linux to avoid service
> interruption.
> This kind of daemon wants to have the full information about interfaces to be
> able to build/configure them on the other linux.
>
>>
>> Global identifiers are easy until you hit the cases where they make
>> things impossible.
> I don't want specially to use ID, but I fear that the solution with file
> descriptors will be a nightmare.
I can certainly see challenges. In asking for symmetry between set and
get the solution with file descriptors is the obvious answer and the
first answer I have been able to come up with so far.
My original answer was that the ifindex happened to be unique across
namespaces but that actually turned out to be a problem for migration
so that abandoned.
Namespace file descriptors are the solution that I know semantically
will work. Beyond that I don't have any good ideas right now.
I just know that local names (aka file descriptors) are much easier to
work with semantically than global names.
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