* Re: [PATCH] net: xgene: fix possible NULL dereference in xgene_enet_free_desc_rings()
From: David Miller @ 2014-08-22 18:25 UTC (permalink / raw)
To: isubramanian; +Cc: netdev, dan.carpenter
In-Reply-To: <1408653888-10193-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Thu, 21 Aug 2014 13:44:48 -0700
> A NULL pointer dereference is possible for the argument ring->buf_pool
> which is passed to xgene_enet_free_desc_ring(), as ring could be NULL.
>
> And now since NULL pointers are being checked for before the calls to
> xgene_enet_free_desc_ring(), might as well take advantage of them and
> not call the function if the argument would be NULL.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] openvswitch: fix panic with multiple vlan headers
From: David Miller @ 2014-08-22 18:24 UTC (permalink / raw)
To: jbenc; +Cc: netdev, dev
In-Reply-To: <b490744c980813b54d54f628c719e03cdb143302.1408649593.git.jbenc@redhat.com>
From: Jiri Benc <jbenc@redhat.com>
Date: Thu, 21 Aug 2014 21:33:44 +0200
> When there are multiple vlan headers present in a received frame, the first
> one is put into vlan_tci and protocol is set to ETH_P_8021Q. Anything in the
> skb beyond the VLAN TPID may be still non-linear, including the inner TCI
> and ethertype. While ovs_flow_extract takes care of IP and IPv6 headers, it
> does nothing with ETH_P_8021Q. Later, if OVS_ACTION_ATTR_POP_VLAN is
> executed, __pop_vlan_tci pulls the next vlan header into vlan_tci.
>
> This leads to two things:
>
> 1. Part of the resulting ethernet header is in the non-linear part of the
> skb. When eth_type_trans is called later as the result of
> OVS_ACTION_ATTR_OUTPUT, kernel BUGs in __skb_pull. Also, __pop_vlan_tci
> is in fact accessing random data when it reads past the TPID.
>
> 2. network_header points into the ethernet header instead of behind it.
> mac_len is set to a wrong value (10), too.
>
> Reported-by: Yulong Pei <ypei@redhat.com>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
Applied and queued up for -stable, thanks Jiri.
^ permalink raw reply
* Re: TCP output handling bug ?
From: Yuchung Cheng @ 2014-08-22 18:18 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, Dave Jones, Stephen Hemminger, alan, netdev
In-Reply-To: <20140822.104118.710757967194596933.davem@davemloft.net>
On Fri, Aug 22, 2014 at 10:41 AM, David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 22 Aug 2014 06:56:30 -0700
>
> CC:'ing Yuchung Cheng
>
>> On Thu, 2014-08-21 at 22:13 -0400, Dave Jones wrote:
>>> On Thu, Aug 21, 2014 at 05:24:45PM -0700, Stephen Hemminger wrote:
>>> > On Thu, 21 Aug 2014 19:02:08 +0100
>>> > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>> >
>>> > >
>>> > > tcp_send_syn_data:
>>> > >
>>> > > TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
>>> > > TCP_SKB_CB(data)->tcp_flags = (TCPHDR_ACK|TCPHDR_PSH);
>>> > >
>>> > > the reporter has a point 8)
>>> > >
>>> > > https://bugzilla.kernel.org/show_bug.cgi?id=82101
>>> >
>>> > I wonder if covertity or smatch could be smart enough to catch this kind of bug?
>>>
>>> For coverity: it should be, but isn't :)
>>> I've pointed them at the bugzilla, maybe they can add a check in a
>>> future update.
>>>
>>> I bet this isn't the only instance of a bug like this left in the tree.
>>> We've definitely had similar cases before.
>>>
>>> Dave
>>
>> There is no bug here as a matter of fact.
>>
>> You can simply remove the first line, as it is useless.
>>
>> - TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
>>
>> At the end of the day, data segment has ACK and PSH flags only.
>
> What about ECE/CWR?
sorry for the late response. my original intention was
TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
TCP_SKB_CB(data)->tcp_flags |= (TCPHDR_ACK|TCPHDR_PSH);
so that we can keep other flags intact b/c in the future we may have
xmas tree packet :-)
I will send a patch soon.
^ permalink raw reply
* Re: [PATCH v2] net: ipv6: fib: don't sleep inside atomic lock
From: David Miller @ 2014-08-22 17:55 UTC (permalink / raw)
To: bebl; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel, hannes
In-Reply-To: <1408642668-5808-1-git-send-email-bebl@mageta.org>
From: Benjamin Block <bebl@mageta.org>
Date: Thu, 21 Aug 2014 19:37:48 +0200
> The function fib6_commit_metrics() allocates a piece of memory in mode
> GFP_KERNEL while holding an atomic lock from higher up in the stack, in
> the function __ip6_ins_rt(). This produces the following BUG:
...
> Fixing this by replacing the mode GFP_KERNEL with GFP_ATOMIC.
>
> Signed-off-by: Benjamin Block <bebl@mageta.org>
Applied, thanks.
^ permalink raw reply
* Re: [RFC] net: ipv4: drop unicast encapsulated in L2 multicast
From: David Miller @ 2014-08-22 17:54 UTC (permalink / raw)
To: ja-FgGsKACvmQM
Cc: johannes-cdvu00un1VgdHxzADdlk8Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
johannes.berg-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <alpine.LFD.2.11.1408212119510.1896-c1lBKlETG9EWAawoAK+ZAw@public.gmane.org>
From: Julian Anastasov <ja-FgGsKACvmQM@public.gmane.org>
Date: Thu, 21 Aug 2014 22:51:02 +0300 (EEST)
>> if (res.type == RTN_BROADCAST)
>> goto brd_input;
>
> Is this place better, after checking for RTN_BROADCAST?
>
> /* ARP link-layer broadcasts are acceptable here */
> if ((skb->pkt_type == PACKET_BROADCAST ||
> skb->pkt_type == PACKET_MULTICAST) &&
> skb->protocol == htons(ETH_P_IP))
> goto e_inval;
Indeed, this would make ARP happier, but that still leaves open the
issue of CLUSTERIP.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 v5 1/1] net: fec: ptp: avoid register access when ipg clock is disabled
From: David Miller @ 2014-08-22 17:46 UTC (permalink / raw)
To: b38611; +Cc: richardcochran, netdev
In-Reply-To: <1408612178-13906-2-git-send-email-b38611@freescale.com>
From: Fugang Duan <b38611@freescale.com>
Date: Thu, 21 Aug 2014 17:09:38 +0800
> The current kernel hang on i.MX6SX with rootfs mount from MMC.
> The root cause is that ptp uses a periodic timer to access enet register
> even if ipg clock is disabled.
>
> FEC ptp driver start one period timer to read 1588 counter register in the
> ptp init function that is called after FEC driver is probed.
>
> To save power, after FEC probe finish, FEC driver disable all clocks including
> ipg clock that is needed for register access.
>
> i.MX5x, i.MX6q/dl/sl FEC register access don't cause system hang when ipg clock
> is disabled, just return zero value. But for i.MX6sx SOC, it cause system hang.
>
> To avoid the issue, we need to check ptp clock status before ptp timer count access.
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
Applied, thanks.
^ permalink raw reply
* Re: TCP output handling bug ?
From: David Miller @ 2014-08-22 17:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: davej, stephen, alan, netdev, ycheng
In-Reply-To: <1408715790.5604.13.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 22 Aug 2014 06:56:30 -0700
CC:'ing Yuchung Cheng
> On Thu, 2014-08-21 at 22:13 -0400, Dave Jones wrote:
>> On Thu, Aug 21, 2014 at 05:24:45PM -0700, Stephen Hemminger wrote:
>> > On Thu, 21 Aug 2014 19:02:08 +0100
>> > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> >
>> > >
>> > > tcp_send_syn_data:
>> > >
>> > > TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
>> > > TCP_SKB_CB(data)->tcp_flags = (TCPHDR_ACK|TCPHDR_PSH);
>> > >
>> > > the reporter has a point 8)
>> > >
>> > > https://bugzilla.kernel.org/show_bug.cgi?id=82101
>> >
>> > I wonder if covertity or smatch could be smart enough to catch this kind of bug?
>>
>> For coverity: it should be, but isn't :)
>> I've pointed them at the bugzilla, maybe they can add a check in a
>> future update.
>>
>> I bet this isn't the only instance of a bug like this left in the tree.
>> We've definitely had similar cases before.
>>
>> Dave
>
> There is no bug here as a matter of fact.
>
> You can simply remove the first line, as it is useless.
>
> - TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
>
> At the end of the day, data segment has ACK and PSH flags only.
What about ECE/CWR?
^ permalink raw reply
* I NEED YOUR URGENT REPLY
From: Alima Toe @ 2014-08-22 17:38 UTC (permalink / raw)
Dear Friend,
I know that this mail will come to you as a surprise, please pay
attention and understand my reason of contacting you today through
this email; my name is Mrs.Alima Toe, Bill and Exchange Manager in
Bank of Africa Ouagadougou Burkina-Faso. In my department, during the
Auditing of the year I discovered an abounded sum of $15.500.000.00
USD that belongs to one of our Late customer, a foreigner who
unfortunately lost his life and entire family in a plane crash in
the year 2008.
I desperately need your assistance to secure and move this huge sums
of money left behind by my late client to the tune of $15.500.000.00,
(fifteen million Five hundred thousand Dollars) out from Bank Of
Africa to your own account, and according to the laws and constitution
guiding this banking institution, it states that after the expiration
of (10) ten years, if no body or person comes for the claim as the
next of kin, the fund will be transferred to national treasury as
unclaimed fund. Because of the static of this transaction I want you
to stand as the next of kin so that our bank will accord you the
recognition and have the fund transferred to your account.and l have
all his documents.
that will back you up to claimed this $15.500.000.00,
without any thing problem or Questions in this business transaction
Meanwhile, for your smoothness of this transaction, our sharing ratio
will be 50%50 for your co-operation in this matter. If you know that
you are interested and capable to handle this business transaction,
come up with your informations showed below:
please this email is not a joke and dont take it as a joker messngers.
Please I would like you to keep this proposal as a top secret
As possible all these informations are submitted to me, I will
immediately send you the next of kin application form so that you will
proceed with the transaction by sending the Form to bank for the
transferring of this fund into your bank account
Yours Faithfully,
Mrs.Alima Toe
Your Urgent Reply Is Needed
^ permalink raw reply
* [PATCH] drivers: isdn: eicon: xdi_msg.h: Fix typo in #ifndef
From: Rasmus Villemoes @ 2014-08-22 16:39 UTC (permalink / raw)
To: Armin Schindler, Karsten Keil; +Cc: netdev, linux-kernel, Rasmus Villemoes
Test for definedness of the macro which is actually defined (the
change is hard to see: it is s/SSS/SSA/).
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
drivers/isdn/hardware/eicon/xdi_msg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/eicon/xdi_msg.h b/drivers/isdn/hardware/eicon/xdi_msg.h
index 58368f7..2498c34 100644
--- a/drivers/isdn/hardware/eicon/xdi_msg.h
+++ b/drivers/isdn/hardware/eicon/xdi_msg.h
@@ -1,6 +1,6 @@
/* $Id: xdi_msg.h,v 1.1.2.2 2001/02/16 08:40:36 armin Exp $ */
-#ifndef __DIVA_XDI_UM_CFG_MESSSGE_H__
+#ifndef __DIVA_XDI_UM_CFG_MESSAGE_H__
#define __DIVA_XDI_UM_CFG_MESSAGE_H__
/*
--
2.0.4
^ permalink raw reply related
* Technical Support Team
From: Webmail Admin @ 2014-08-22 16:18 UTC (permalink / raw)
Our records indicate that your E-mail® Account could not be automatically
updated with our F-Secure R-HTK4S new(2014) version
anti-spam/anti-virus/anti-spyware. Please click this link below to update
manually
http://free.allforms.mailjol.net/u/405ee038.php
We Are Sorry For Any Inconvenience.
Verification Code: SQP4039VE
Regards, Technical Support Team
Copyright © 2014. All Rights Reserved
--
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. Before opening any mail and attachments please check them for viruses and defect If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
-------------------------------------------------------------------------------------------------------------------------
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
Regional Cancer Centre, Thiruvananthapuram
www.rcctvm.org
^ permalink raw reply
* Re: Routes with unreachable gateways are staying in the routing table and they are functional
From: Julian Anastasov @ 2014-08-22 16:28 UTC (permalink / raw)
To: Fedor Babkin; +Cc: netdev
In-Reply-To: <trinity-f1954363-c4ef-47d2-9508-7174b7e2501e-1408720289787@3capp-gmx-bs15>
Hello,
On Fri, 22 Aug 2014, Fedor Babkin wrote:
> Hello,
>
> I noticed that in case a network interface has two addresses assigned (no matter if IPv4 or IPv6) from subnets A and B, the route to reach subnet C via the gateway in A is staying configured and functional when subnet A is removed from the interface. Let me illustrate the behavior with IPv4 example.
>
> Starting point. eth0 has 2 subnets, the route to reach 3-rd subnet via gw in one of them is present:
> eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
> link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff
> inet 10.20.10.3/24 brd 10.20.10.255 scope global eth0
> valid_lft forever preferred_lft forever
> inet 10.30.10.3/24 brd 10.30.10.255 scope global eth0
> valid_lft forever preferred_lft forever
> inet6 fe80::5054:ff:fe12:3457/64 scope link
> valid_lft forever preferred_lft forever
> root@ubuntu14-4-vm:~# ip ro ls
> 10.11.10.0/24 via 10.30.10.1 dev eth0
> 10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.3
> 10.30.10.0/24 dev eth0 proto kernel scope link src 10.30.10.3
>
> Delete 10.30.10.3/24, the indirect route persists:
> root@ubuntu14-4-vm:~# ip ro ls
> 10.11.10.0/24 via 10.30.10.1 dev eth0
> 10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.3
>
> Ping to destinations in 10.11.10.0/24 works, unreachable gateway 10.30.10.1 is resolved, even recovers in case of neighbor flushes.
> root@ubuntu14-4-vm:~# ping 10.11.10.1
> PING 10.11.10.1 (10.11.10.1) 56(84) bytes of data.
> 64 bytes from 10.11.10.1: icmp_seq=1 ttl=64 time=0.706 ms
> root@ubuntu14-4-vm:~# ip n l
> 10.30.10.1 dev eth0 lladdr 52:54:00:12:34:56 REACHABLE
>
> The above was observed with kernel version 2.6.32 and confirmed with 3.13.0 In case of IPv6 this behavior is more disturbing as there is always LLA assigned, so applications have to orchestrate the removal of unreachable routes.
> If it's an intended implementation, would be helpful to know a reason behind it. Thanks for your support.
It is expensive to implement solution for this
problem. If we try to be very strict by handling it
at FIB level (catch route removal) simple operations
like secondary address promotion or route replacement
can lead to cascade of route removals. At the end,
it is again the user who have to take care to add
all lost routes back. So, it is a complex task to
solve.
Here is recent discussion on such topic:
http://marc.info/?t=139030500700005&r=1&w=2
http://marc.info/?t=139055890700002&r=1&w=2
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* skb_warn_bad_offload warnings with FreeBSD guests
From: Brian Rak @ 2014-08-22 16:19 UTC (permalink / raw)
To: netdev
We have a number of machines running qemu with bridged networking. We
have noticed that *sometimes* FreeBSD guests cause this warning to flood
the host "WARNING: CPU: 5 PID: 3705 at net/core/dev.c:2238
skb_warn_bad_offload+0xc3/0xd0()". I haven't been able to come up with
any sort of reproduction steps, it just seems to happen to some FreeBSD
guests, but not others.
A full stack trace looks like this:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 7147 at net/core/dev.c:2233
skb_warn_bad_offload+0xc3/0xd0()
igb: caps=(0x0000000190114bb3, 0x0000000000000000) len=2962 data_len=0
gso_size=1448 gso_type=5 ip_summed=0
Modules linked in: dm_snapshot dm_bufio ipmi_devintf xt_physdev ebt_arp
ebt_ip ebtable_nat ebtables cls_fw sch_sfq sch_htb tun kvm_intel kvm
8021q garp nfnetlink_queue nfnetlink_log nfnetlink bluetooth rfkill
bridge stp llc xt_CHECKSUM iptable_mangle ipt_REJECT iptable_filter ip
_tables ip6t_REJECT ip6table_filter ip6_tables ipv6 iTCO_wdt
iTCO_vendor_support ipmi_si ipmi_msghandler microcode pcspkr i2c_i801
joydev sg lpc_ich shpchp igb dca ptp pps_core hwmon ext4 jbd2 mbcache
sd_mod crc_t10dif crct10dif_common video ahci libahci xhci_hcd ast ttm
drm_kms
_helper sysimgblt sysfillrect syscopyarea dm_mirror dm_region_hash
dm_log dm_mod
CPU: 1 PID: 7147 Comm: qemu-kvm Tainted: G W
3.15.5-1.el6.elrepo.x86_64 #1
Hardware name: Supermicro X10SLE-F/HF/X10SLE, BIOS 1.1 07/19/2013
00000000000008b9 ffff88081fc435d8 ffffffff8163ba90 00000000000008b9
ffff88081fc43628 ffff88081fc43618 ffffffff8106c30c ffffc90007a06e30
0000000000000000 ffff8807f2b64000 ffff8807f2b64000 0000000000000000
Call Trace:
<IRQ> [<ffffffff8163ba90>] dump_stack+0x49/0x61
[<ffffffff8106c30c>] warn_slowpath_common+0x8c/0xc0
[<ffffffff8106c3f6>] warn_slowpath_fmt+0x46/0x50
[<ffffffff8156ce93>] skb_warn_bad_offload+0xc3/0xd0
[<ffffffff81574a29>] ? dev_hard_start_xmit+0x339/0x640
[<ffffffff81574699>] __skb_gso_segment+0x89/0xe0
[<ffffffff81574876>] dev_hard_start_xmit+0x186/0x640
[<ffffffff81594f5a>] sch_direct_xmit+0xfa/0x1d0
[<ffffffff81574f2f>] __dev_queue_xmit+0x1ff/0x4f0
[<ffffffff81575240>] dev_queue_xmit+0x10/0x20
[<ffffffffa02e6612>] br_dev_queue_push_xmit+0x82/0xb0 [bridge]
[<ffffffffa02ee680>] br_nf_dev_queue_xmit+0x20/0x90 [bridge]
[<ffffffffa02ef4b8>] br_nf_post_routing+0x2d8/0x300 [bridge]
[<ffffffffa02e6590>] ? deliver_clone+0x60/0x60 [bridge]
[<ffffffff815a357e>] nf_iterate+0x8e/0xc0
[<ffffffffa02e6590>] ? deliver_clone+0x60/0x60 [bridge]
[<ffffffff815a37ad>] nf_hook_slow+0x7d/0x150
[<ffffffffa02e6590>] ? deliver_clone+0x60/0x60 [bridge]
[<ffffffffa02ee6f0>] ? br_nf_dev_queue_xmit+0x90/0x90 [bridge]
[<ffffffffa02e6b43>] br_forward_finish+0x43/0x60 [bridge]
[<ffffffffa02ee8a8>] br_nf_forward_finish+0x1b8/0x1d0 [bridge]
[<ffffffffa02ef178>] br_nf_forward_ip+0x3a8/0x410 [bridge]
[<ffffffffa02e6b00>] ? br_flood_deliver+0x20/0x20 [bridge]
[<ffffffff815a357e>] nf_iterate+0x8e/0xc0
[<ffffffffa02e6b00>] ? br_flood_deliver+0x20/0x20 [bridge]
[<ffffffff815a37ad>] nf_hook_slow+0x7d/0x150
[<ffffffffa02e6b00>] ? br_flood_deliver+0x20/0x20 [bridge]
[<ffffffffa02e66e4>] __br_forward+0xa4/0x100 [bridge]
[<ffffffffa02e7800>] ? NF_HOOK.clone.0+0x70/0x70 [bridge]
[<ffffffffa02e67d6>] br_forward+0x96/0xb0 [bridge]
[<ffffffffa02e7800>] ? NF_HOOK.clone.0+0x70/0x70 [bridge]
[<ffffffffa02e7997>] br_handle_frame_finish+0x197/0x3f0 [bridge]
[<ffffffffa02e7800>] ? NF_HOOK.clone.0+0x70/0x70 [bridge]
[<ffffffffa02ef790>] br_nf_pre_routing_finish+0x2b0/0x370 [bridge]
[<ffffffffa02ef4e0>] ? br_nf_post_routing+0x300/0x300 [bridge]
[<ffffffffa02ed986>] NF_HOOK_THRESH+0x56/0x60 [bridge]
[<ffffffffa02eed2b>] br_nf_pre_routing+0x2fb/0x3a0 [bridge]
[<ffffffff815a357e>] nf_iterate+0x8e/0xc0
[<ffffffffa02e7800>] ? NF_HOOK.clone.0+0x70/0x70 [bridge]
[<ffffffff815a37ad>] nf_hook_slow+0x7d/0x150
[<ffffffffa02e7800>] ? NF_HOOK.clone.0+0x70/0x70 [bridge]
[<ffffffffa02e7d8c>] br_handle_frame+0x19c/0x240 [bridge]
[<ffffffffa02e7bf0>] ? br_handle_frame_finish+0x3f0/0x3f0 [bridge]
[<ffffffff81572fa5>] __netif_receive_skb_core+0x1e5/0x620
[<ffffffff81573407>] __netif_receive_skb+0x27/0x70
[<ffffffff81573553>] process_backlog+0x103/0x200
[<ffffffff81573d62>] net_rx_action+0x112/0x2a0
[<ffffffff8107111c>] __do_softirq+0xfc/0x2b0
[<ffffffff810713cd>] ? irq_exit+0xad/0xd0
[<ffffffff8164a81c>] do_softirq_own_stack+0x1c/0x30
<EOI> [<ffffffff81070e75>] do_softirq+0x55/0x60
[<ffffffff81571e19>] netif_rx_ni+0x39/0x70
[<ffffffffa03e84e0>] tun_get_user+0x310/0x6c0 [tun]
[<ffffffffa03e8995>] tun_chr_aio_write+0x85/0xa0 [tun]
[<ffffffff811beb9d>] do_sync_readv_writev+0x4d/0x80
[<ffffffff811c0128>] do_readv_writev+0xc8/0x2c0
[<ffffffff811bebd0>] ? do_sync_readv_writev+0x80/0x80
[<ffffffff811d2c45>] ? poll_select_set_timeout+0x95/0xb0
[<ffffffff811c0357>] vfs_writev+0x37/0x50
[<ffffffff811c0496>] SyS_writev+0x56/0xf0
[<ffffffff81648ee9>] system_call_fastpath+0x16/0x1b
---[ end trace d26e70ba037ab631 ]---
gso_type=5 and ip_summed=0 are always the same (though len, data_len,
and gso_size vary).
What is causing this? I've tried kernels as new as 3.15.5-1, which do
not appear to help.
^ permalink raw reply
* Routes with unreachable gateways are staying in the routing table and they are functional
From: Fedor Babkin @ 2014-08-22 15:11 UTC (permalink / raw)
To: netdev
Hello,
I noticed that in case a network interface has two addresses assigned (no matter if IPv4 or IPv6) from subnets A and B, the route to reach subnet C via the gateway in A is staying configured and functional when subnet A is removed from the interface. Let me illustrate the behavior with IPv4 example.
Starting point. eth0 has 2 subnets, the route to reach 3-rd subnet via gw in one of them is present:
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff
inet 10.20.10.3/24 brd 10.20.10.255 scope global eth0
valid_lft forever preferred_lft forever
inet 10.30.10.3/24 brd 10.30.10.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe12:3457/64 scope link
valid_lft forever preferred_lft forever
root@ubuntu14-4-vm:~# ip ro ls
10.11.10.0/24 via 10.30.10.1 dev eth0
10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.3
10.30.10.0/24 dev eth0 proto kernel scope link src 10.30.10.3
Delete 10.30.10.3/24, the indirect route persists:
root@ubuntu14-4-vm:~# ip ro ls
10.11.10.0/24 via 10.30.10.1 dev eth0
10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.3
Ping to destinations in 10.11.10.0/24 works, unreachable gateway 10.30.10.1 is resolved, even recovers in case of neighbor flushes.
root@ubuntu14-4-vm:~# ping 10.11.10.1
PING 10.11.10.1 (10.11.10.1) 56(84) bytes of data.
64 bytes from 10.11.10.1: icmp_seq=1 ttl=64 time=0.706 ms
root@ubuntu14-4-vm:~# ip n l
10.30.10.1 dev eth0 lladdr 52:54:00:12:34:56 REACHABLE
The above was observed with kernel version 2.6.32 and confirmed with 3.13.0 In case of IPv6 this behavior is more disturbing as there is always LLA assigned, so applications have to orchestrate the removal of unreachable routes.
If it's an intended implementation, would be helpful to know a reason behind it. Thanks for your support.
Regards,
Fedor
^ permalink raw reply
* Re: [PATCH net 2/2] net: sctp: fix suboptimal edge-case on non-active active/retrans path selection
From: Vlad Yasevich @ 2014-08-22 14:39 UTC (permalink / raw)
To: Daniel Borkmann, davem; +Cc: netdev, linux-sctp
In-Reply-To: <1408705410-28558-3-git-send-email-dborkman@redhat.com>
On 08/22/2014 07:03 AM, Daniel Borkmann wrote:
> In SCTP, selection of active (T.ACT) and retransmission (T.RET)
> transports is being done whenever transport control operations
> (UP, DOWN, PF, ...) are engaged through sctp_assoc_control_transport().
>
> Commits 4c47af4d5eb2 ("net: sctp: rework multihoming retransmission
> path selection to rfc4960") and a7288c4dd509 ("net: sctp: improve
> sctp_select_active_and_retran_path selection") have both improved
> it towards a more fine-grained and optimal path selection.
>
.. snip excellent changelog description ...
> T2 S(ACTIVE) T.RET
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
> ---
> net/sctp/associola.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index 104fae4..a88b852 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -1356,14 +1356,11 @@ static void sctp_select_active_and_retran_path(struct sctp_association *asoc)
> trans_sec = trans_pri;
>
> /* If we failed to find a usable transport, just camp on the
> - * primary or retran, even if they are inactive, if possible
> - * pick a PF iff it's the better choice.
> + * active or pick a PF iff it's the better choice.
> */
> if (trans_pri == NULL) {
> - trans_pri = sctp_trans_elect_best(asoc->peer.primary_path,
> - asoc->peer.retran_path);
> - trans_pri = sctp_trans_elect_best(trans_pri, trans_pf);
> - trans_sec = asoc->peer.primary_path;
> + trans_pri = sctp_trans_elect_best(asoc->peer.active_path, trans_pf);
> + trans_sec = trans_pri;
> }
>
> /* Set the active and retran transports. */
>
^ permalink raw reply
* Re: [PATCH net 1/2] net: sctp: spare unnecessary comparison in sctp_trans_elect_best
From: Vlad Yasevich @ 2014-08-22 14:38 UTC (permalink / raw)
To: Daniel Borkmann, davem; +Cc: netdev, linux-sctp
In-Reply-To: <1408705410-28558-2-git-send-email-dborkman@redhat.com>
On 08/22/2014 07:03 AM, Daniel Borkmann wrote:
> When both transports are the same, we don't have to go down that
> road only to realize that we will return the very same transport.
> We are guaranteed that curr is always non-NULL. Therefore, just
> short-circuit this special case.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> net/sctp/associola.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index aaafb32..104fae4 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -1245,7 +1245,7 @@ static struct sctp_transport *sctp_trans_elect_best(struct sctp_transport *curr,
> {
> u8 score_curr, score_best;
>
> - if (best == NULL)
> + if (best == NULL || curr == best)
> return curr;
>
> score_curr = sctp_trans_score(curr);
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
From: Eric Dumazet @ 2014-08-22 14:16 UTC (permalink / raw)
To: Jason Wang
Cc: Ingo Molnar, Mike Galbraith, davem, netdev, linux-kernel, mst,
Peter Zijlstra, Ingo Molnar
In-Reply-To: <53F70887.8030602@redhat.com>
On Fri, 2014-08-22 at 17:08 +0800, Jason Wang wrote:
> But this is just for current process. We want to determine whether or
> not it was worth to loop busily in current process by checking if
> there's any another runnable processes or callbacks. And what we need
> here is just a simple and lockless hint which can't be wrong but may be
> inaccurate to exit the busy loop. The net code does not depends on this
> hint to do scheduling or yielding.
>
> How about just introducing a boolean helper like current_can_busy_loop()
> and return true in one of the following conditions:
>
> - Current task is SCHED_FIFO
> - Current task is neither SCHED_FIFO nor SCHED_IDLE and no other
> runnable processes or pending RCU callbacks in current cpu
>
> And add warns to make sure it can only be called in process context.
1) Any reasons Eliezer Tamir is not included in the CC list ?
He is the busypoll author after all, and did nothing wrong to be
banned from these patches ;)
2) It looks like sk_buy_loop() should not be inlined, its is already too
big.
^ permalink raw reply
* Re: TCP output handling bug ?
From: Eric Dumazet @ 2014-08-22 13:56 UTC (permalink / raw)
To: Dave Jones; +Cc: Stephen Hemminger, Alan Cox, netdev
In-Reply-To: <20140822021341.GB14353@redhat.com>
On Thu, 2014-08-21 at 22:13 -0400, Dave Jones wrote:
> On Thu, Aug 21, 2014 at 05:24:45PM -0700, Stephen Hemminger wrote:
> > On Thu, 21 Aug 2014 19:02:08 +0100
> > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >
> > >
> > > tcp_send_syn_data:
> > >
> > > TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
> > > TCP_SKB_CB(data)->tcp_flags = (TCPHDR_ACK|TCPHDR_PSH);
> > >
> > > the reporter has a point 8)
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=82101
> >
> > I wonder if covertity or smatch could be smart enough to catch this kind of bug?
>
> For coverity: it should be, but isn't :)
> I've pointed them at the bugzilla, maybe they can add a check in a
> future update.
>
> I bet this isn't the only instance of a bug like this left in the tree.
> We've definitely had similar cases before.
>
> Dave
There is no bug here as a matter of fact.
You can simply remove the first line, as it is useless.
- TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
At the end of the day, data segment has ACK and PSH flags only.
^ permalink raw reply
* Re: [PATCH] drivers: net: wireless: Add include guards
From: Rasmus Villemoes @ 2014-08-22 13:32 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1408710414-13810-1-git-send-email-linux@rasmusvillemoes.dk>
Rasmus Villemoes <linux@rasmusvillemoes.dk> writes:
> The files ray_cs.h and rayctl.h both contain two thirds of what
> appears to be an include guard using the macro name RAYLINK_H (both
> lack the #define). Since RAYLINK_H is not defined anywhere, the
> guards using different macro names.
>
I need to stop using the # character in my commit messages, or at least
check that git didn't eat any of my lines.
This was supposed to be something like "... defined anywhere, the
#ifndefs are simply confusing no-ops. Add proper include guards using
different macro names".
Rasmus
^ permalink raw reply
* [PATCH] mac80211: scan: Replace rcu_assign_pointer() with RCU_INIT_POINTER()
From: Andreea-Cristina Bernat @ 2014-08-22 13:14 UTC (permalink / raw)
To: linville, johannes, davem, linux-wireless, netdev, linux-kernel; +Cc: paulmck
The use of "rcu_assign_pointer()" is NULLing out the pointer.
According to RCU_INIT_POINTER()'s block comment:
"1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.
The following Coccinelle semantic patch was used:
@@
@@
- rcu_assign_pointer
+ RCU_INIT_POINTER
(..., NULL)
Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
---
net/mac80211/scan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index f40661e..6c69d09 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -1058,7 +1058,7 @@ int ieee80211_request_sched_scan_stop(struct ieee80211_sub_if_data *sdata)
if (rcu_access_pointer(local->sched_scan_sdata)) {
ret = drv_sched_scan_stop(local, sdata);
if (!ret)
- rcu_assign_pointer(local->sched_scan_sdata, NULL);
+ RCU_INIT_POINTER(local->sched_scan_sdata, NULL);
}
out:
mutex_unlock(&local->mtx);
--
1.9.1
^ permalink raw reply related
* [PATCH] br_multicast: Replace rcu_assign_pointer() with RCU_INIT_POINTER()
From: Andreea-Cristina Bernat @ 2014-08-22 13:06 UTC (permalink / raw)
To: stephen, davem, bridge, netdev, linux-kernel; +Cc: paulmck
The use of "rcu_assign_pointer()" is NULLing out the pointer.
According to RCU_INIT_POINTER()'s block comment:
"1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.
The following Coccinelle semantic patch was used:
@@
@@
- rcu_assign_pointer
+ RCU_INIT_POINTER
(..., NULL)
Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
---
net/bridge/br_multicast.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index abfa0b65..9b64383 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1822,7 +1822,7 @@ static void br_multicast_query_expired(struct net_bridge *br,
if (query->startup_sent < br->multicast_startup_query_count)
query->startup_sent++;
- rcu_assign_pointer(querier, NULL);
+ RCU_INIT_POINTER(querier, NULL);
br_multicast_send_query(br, NULL, query);
spin_unlock(&br->multicast_lock);
}
--
1.9.1
^ permalink raw reply related
* Re: [patch net-next RFC 03/12] net: introduce generic switch devices support
From: Jiri Pirko @ 2014-08-22 12:56 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Florian Fainelli, netdev, David Miller, Neil Horman,
Andy Gospodarek, tgraf, dborkman, ogerlitz, jesse, pshelar, azhou,
Ben Hutchings, Stephen Hemminger, Jeff Kirsher, vyasevic,
Cong Wang, John Fastabend, Eric Dumazet, Scott Feldman,
Roopa Prabhu, John Linville, dev, jasowang@redhat.com,
Eric W. Biederman
In-Reply-To: <53F73A9C.4000209@mojatatu.com>
Fri, Aug 22, 2014 at 02:42:04PM CEST, jhs@mojatatu.com wrote:
>On 08/21/14 13:05, Florian Fainelli wrote:
>>2014-08-21 9:18 GMT-07:00 Jiri Pirko <jiri@resnulli.us>:
>>>The goal of this is to provide a possibility to suport various switch
>>>chips. Drivers should implement relevant ndos to do so. Now there is a
>>>couple of ndos defines:
>>>- for getting physical switch id is in place.
>>>- for work with flows.
>>>
>>>Note that user can use random port netdevice to access the switch.
>>
>>I read through this patch set, and I still think that DSA is the
>>generic switch infrastructure we already have because it does provide
>>the following:
>>
>>- taking a generic platform data structure (C struct or Device Tree),
>>validate, parse it and map it to internal kernel structures
>>- instantiate per-port network devices based on the configuration data provided
>>- delegate netdev_ops to the switch driver and/or the CPU NIC when relevant
>>- provide support for hooking RX and TX traffic coming from the CPU NIC
>>
>>I would rather we build on the existing DSA infrastructure and add the
>>flow-related netdev_ops rather than having the two remain in
>>disconnect while flow-oriented switches driver get progressively
>>added. I guess I should take a closer look at the rocker driver to see
>>how hard would that be for you.
>>
>>What do you think?
>
>
>I thought we had concluded that DSA was a good path forward? Or maybe at
>this stage we need to have several alternative approaches
>and we eventually converge?
That is true. I'm still unsure how to fit this on to DSA or how to change DSA
the way this fits. This is my quest now. Will report back in a week or so.
>
>cheers,
>jamal
>
>
^ permalink raw reply
* Re: [patch net-next RFC 03/12] net: introduce generic switch devices support
From: Jamal Hadi Salim @ 2014-08-22 12:42 UTC (permalink / raw)
To: Florian Fainelli, Jiri Pirko
Cc: Sergey Ryazanov, jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
John Fastabend, Neil Jerram, Eric Dumazet, Andy Gospodarek, dev,
Felix Fietkau, ronye-VPRAkNaXOzVWk0Htik3J/w, Jeff Kirsher,
ogerlitz, Ben Hutchings, Lennert Buytenhek, Roopa Prabhu,
Aviad Raveh, Nicolas Dichtel, vyasevic, Neil Horman, netdev,
Stephen Hemminger, dborkman, Eric W. Biederman, David Miller
In-Reply-To: <CAGVrzcYtnpcP4pfCJ0GSya01LTk0WwbSV1f+voF2K=S5CR3Arg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 08/21/14 13:05, Florian Fainelli wrote:
> 2014-08-21 9:18 GMT-07:00 Jiri Pirko <jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>:
>> The goal of this is to provide a possibility to suport various switch
>> chips. Drivers should implement relevant ndos to do so. Now there is a
>> couple of ndos defines:
>> - for getting physical switch id is in place.
>> - for work with flows.
>>
>> Note that user can use random port netdevice to access the switch.
>
> I read through this patch set, and I still think that DSA is the
> generic switch infrastructure we already have because it does provide
> the following:
>
> - taking a generic platform data structure (C struct or Device Tree),
> validate, parse it and map it to internal kernel structures
> - instantiate per-port network devices based on the configuration data provided
> - delegate netdev_ops to the switch driver and/or the CPU NIC when relevant
> - provide support for hooking RX and TX traffic coming from the CPU NIC
>
> I would rather we build on the existing DSA infrastructure and add the
> flow-related netdev_ops rather than having the two remain in
> disconnect while flow-oriented switches driver get progressively
> added. I guess I should take a closer look at the rocker driver to see
> how hard would that be for you.
>
> What do you think?
I thought we had concluded that DSA was a good path forward? Or maybe
at this stage we need to have several alternative approaches
and we eventually converge?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net 2/2] net: sctp: fix suboptimal edge-case on non-active active/retrans path selection
From: Neil Horman @ 2014-08-22 12:30 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, linux-sctp
In-Reply-To: <1408705410-28558-3-git-send-email-dborkman@redhat.com>
On Fri, Aug 22, 2014 at 01:03:30PM +0200, Daniel Borkmann wrote:
> In SCTP, selection of active (T.ACT) and retransmission (T.RET)
> transports is being done whenever transport control operations
> (UP, DOWN, PF, ...) are engaged through sctp_assoc_control_transport().
>
> Commits 4c47af4d5eb2 ("net: sctp: rework multihoming retransmission
> path selection to rfc4960") and a7288c4dd509 ("net: sctp: improve
> sctp_select_active_and_retran_path selection") have both improved
> it towards a more fine-grained and optimal path selection.
>
> Currently, the selection algorithm for T.ACT and T.RET is as follows:
>
> 1) Elect the two most recently used ACTIVE transports T1, T2 for
> T.ACT, T.RET, where T.ACT<-T1 and T1 is most recently used
> 2) In case primary path T.PRI not in {T1, T2} but ACTIVE, set
> T.ACT<-T.PRI and T.RET<-T1
> 3) If only T1 is ACTIVE from the set, set T.ACT<-T1 and T.RET<-T1
> 4) If none is ACTIVE, set T.ACT<-best(T.PRI, T.RET, T3) where
> T3 is the most recently used (if avail) in PF, set T.RET<-T.PRI
>
> Prior to above commits, 4) was simply a camp on T.ACT<-T.PRI and
> T.RET<-T.PRI, ignoring possible paths in PF. Camping on T.PRI is
> still slightly suboptimal as it can lead to the following scenario:
>
> Setup:
> <A> <B>
> T1: p1p1 (10.0.10.10) <==> .'`) <==> p1p1 (10.0.10.12) <= T.PRI
> T2: p1p2 (10.0.10.20) <==> (_ . ) <==> p1p2 (10.0.10.22)
>
> net.sctp.rto_min = 1000
> net.sctp.path_max_retrans = 2
> net.sctp.pf_retrans = 0
> net.sctp.hb_interval = 1000
>
> T.PRI is permanently down, T2 is put briefly into PF state (e.g. due to
> link flapping). Here, the first time transmission is sent over PF path
> T2 as it's the only non-INACTIVE path, but the retransmitted data-chunks
> are sent over the INACTIVE path T1 (T.PRI), which is not good.
>
> After the patch, it's choosing better transports in both cases by
> modifying step 4):
>
> 4) If none is ACTIVE, set T.ACT_new<-best(T.ACT_old, T3) where T3 is
> the most recently used (if avail) in PF, set T.RET<-T.ACT_new
>
> This will still select a best possible path in PF if available (which
> can also include T.PRI/T.RET), and set both T.ACT/T.RET to it.
>
> In case sctp_assoc_control_transport() *just* put T.ACT_old into INACTIVE
> as it transitioned from ACTIVE->PF->INACTIVE and stays in INACTIVE just
> for a very short while before going back ACTIVE, it will guarantee that
> this path will be reselected for T.ACT/T.RET since T3 (PF) is not
> available.
>
> Previously, this was not possible, as we would only select between T.PRI
> and T.RET, and a possible T3 would be NULL due to the fact that we have
> just transitioned T3 in sctp_assoc_control_transport() from PF->INACTIVE
> and would select a suboptimal path when T.PRI/T.RET have worse properties.
>
> In the case that T.ACT_old permanently went to INACTIVE during this
> transition and there's no PF path available, plus T.PRI and T.RET are
> INACTIVE as well, we would now camp on T.ACT_old, but if everything is
> being INACTIVE there's really not much we can do except hoping for a
> successful HB to bring one of the transports back up again and, thus
> cause a new selection through sctp_assoc_control_transport().
>
> Now both tests work fine:
>
> Case 1:
>
> 1. T1 S(ACTIVE) T.ACT
> T2 S(ACTIVE) T.RET
>
> 2. T1 S(ACTIVE) T.ACT, T.RET
> T2 S(PF)
>
> 3. T1 S(ACTIVE) T.ACT, T.RET
> T2 S(INACTIVE)
>
> 5. T1 S(PF) T.ACT, T.RET
> T2 S(INACTIVE)
>
> [ 5.1 T1 S(INACTIVE) T.ACT, T.RET
> T2 S(INACTIVE) ]
>
> 6. T1 S(ACTIVE) T.ACT, T.RET
> T2 S(INACTIVE)
>
> 7. T1 S(ACTIVE) T.ACT
> T2 S(ACTIVE) T.RET
>
> Case 2:
>
> 1. T1 S(ACTIVE) T.ACT
> T2 S(ACTIVE) T.RET
>
> 2. T1 S(PF)
> T2 S(ACTIVE) T.ACT, T.RET
>
> 3. T1 S(INACTIVE)
> T2 S(ACTIVE) T.ACT, T.RET
>
> 5. T1 S(INACTIVE)
> T2 S(PF) T.ACT, T.RET
>
> [ 5.1 T1 S(INACTIVE)
> T2 S(INACTIVE) T.ACT, T.RET ]
>
> 6. T1 S(INACTIVE)
> T2 S(ACTIVE) T.ACT, T.RET
>
> 7. T1 S(ACTIVE) T.ACT
> T2 S(ACTIVE) T.RET
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> net/sctp/associola.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index 104fae4..a88b852 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -1356,14 +1356,11 @@ static void sctp_select_active_and_retran_path(struct sctp_association *asoc)
> trans_sec = trans_pri;
>
> /* If we failed to find a usable transport, just camp on the
> - * primary or retran, even if they are inactive, if possible
> - * pick a PF iff it's the better choice.
> + * active or pick a PF iff it's the better choice.
> */
> if (trans_pri == NULL) {
> - trans_pri = sctp_trans_elect_best(asoc->peer.primary_path,
> - asoc->peer.retran_path);
> - trans_pri = sctp_trans_elect_best(trans_pri, trans_pf);
> - trans_sec = asoc->peer.primary_path;
> + trans_pri = sctp_trans_elect_best(asoc->peer.active_path, trans_pf);
> + trans_sec = trans_pri;
> }
>
> /* Set the active and retran transports. */
> --
> 1.7.11.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* [PATCH] drivers: net: wireless: Add include guards
From: Rasmus Villemoes @ 2014-08-22 12:26 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, netdev, linux-kernel, Rasmus Villemoes
The files ray_cs.h and rayctl.h both contain two thirds of what
appears to be an include guard using the macro name RAYLINK_H (both
lack the #define). Since RAYLINK_H is not defined anywhere, the
guards using different macro names.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
drivers/net/wireless/ray_cs.h | 5 +++--
drivers/net/wireless/rayctl.h | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ray_cs.h b/drivers/net/wireless/ray_cs.h
index e79848f..524c2f0 100644
--- a/drivers/net/wireless/ray_cs.h
+++ b/drivers/net/wireless/ray_cs.h
@@ -3,7 +3,8 @@
Written by Corey Thomas
*/
-#ifndef RAYLINK_H
+#ifndef _RAY_CS_H_
+#define _RAY_CS_H_
struct beacon_rx {
struct mac_header mac;
@@ -69,4 +70,4 @@ typedef struct ray_dev_t {
} ray_dev_t;
/*****************************************************************************/
-#endif /* RAYLINK_H */
+#endif /* _RAY_CS_H_ */
diff --git a/drivers/net/wireless/rayctl.h b/drivers/net/wireless/rayctl.h
index 3c3b98b..b21ed64 100644
--- a/drivers/net/wireless/rayctl.h
+++ b/drivers/net/wireless/rayctl.h
@@ -1,4 +1,5 @@
-#ifndef RAYLINK_H
+#ifndef _RAYCTL_H_
+#define _RAYCTL_H_
typedef unsigned char UCHAR;
@@ -729,4 +730,4 @@ typedef struct snaphdr_t
#define RAY_IPX_TYPE 0x8137
#define APPLEARP_TYPE 0x80f3
/*****************************************************************************/
-#endif /* #ifndef RAYLINK_H */
+#endif /* _RAYCTL_H_ */
--
1.9.2
^ permalink raw reply related
* Re: [PATCH net 1/2] net: sctp: spare unnecessary comparison in sctp_trans_elect_best
From: Neil Horman @ 2014-08-22 12:13 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, linux-sctp
In-Reply-To: <1408705410-28558-2-git-send-email-dborkman@redhat.com>
On Fri, Aug 22, 2014 at 01:03:29PM +0200, Daniel Borkmann wrote:
> When both transports are the same, we don't have to go down that
> road only to realize that we will return the very same transport.
> We are guaranteed that curr is always non-NULL. Therefore, just
> short-circuit this special case.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> net/sctp/associola.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index aaafb32..104fae4 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -1245,7 +1245,7 @@ static struct sctp_transport *sctp_trans_elect_best(struct sctp_transport *curr,
> {
> u8 score_curr, score_best;
>
> - if (best == NULL)
> + if (best == NULL || curr == best)
> return curr;
>
> score_curr = sctp_trans_score(curr);
Acked-by: Neil Horman <nhorman@tuxdriver.com>
> --
> 1.7.11.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox