- 01 Apr, 2012 15 commits
-
-
David S. Miller authored
These macros contain a hidden goto, and are thus extremely error prone and make code hard to audit. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
These macros contain a hidden goto, and are thus extremely error prone and make code hard to audit. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
These macros contain a hidden goto, and are thus extremely error prone and make code hard to audit. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
These macros contain a hidden goto, and are thus extremely error prone and make code hard to audit. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
These macros contain a hidden goto, and are thus extremely error prone and make code hard to audit. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
These macros contain a hidden goto, and are thus extremely error prone and make code hard to audit. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
These macros contain a hidden goto, and are thus extremely error prone and make code hard to audit. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shmulik Ladkani authored
In IPv4, if an RTA_IIF attribute is specified within an RTM_GETROUTE message, then a route is searched as if a packet was received on the specified 'iif' interface. However in IPv6, RTA_IIF is not interpreted in the same way: 'inet6_rtm_getroute()' always calls 'ip6_route_output()', regardless the RTA_IIF attribute. As a result, in IPv6 there's no way to use RTM_GETROUTE in order to look for a route as if a packet was received on a specific interface. Fix 'inet6_rtm_getroute()' so that RTA_IIF is interpreted as "lookup a route as if a packet was received on the specified interface", similar to IPv4's 'inet_rtm_getroute()' interpretation. Reported-by: Ami Koren <amikoren@yahoo.com> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
stigge@antcom.de authored
In parallel to the integration of lpc_eth.c, dev_hw_addr_random() has been renamed to eth_hw_addr_random(). This patch fixes it also in the new driver lpc_eth.c. Signed-off-by: Roland Stigge <stigge@antcom.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Morton authored
There's no known problem here, but this is one of only two non-arch files in the kernel which use asm/atomic.h instead of linux/atomic.h. Acked-by: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Patrick McHardy <kaber@trash.net> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
danborkmann@iogearbox.net authored
If both addresses equal, nothing needs to be done. If the device is down, then we simply copy the new address to dev->dev_addr. If the device is up, then we add another loopback device with the new address, and if that does not fail, we remove the loopback device with the old address. And only then, we update the dev->dev_addr. Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kenth Eriksson authored
The merge done in commit b26e478f undid bug fix in commit c3e072f8 ("net: fsl_pq_mdio: fix non tbi phy access"), with the result that non TBI (e.g. MDIO) PHYs cannot be accessed. Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David Ward authored
An infinite loop occurred if garp_attr_create was called with the values of an existing attribute. This might happen if a previous leave request for the attribute has not yet been followed by a PDU transmission (or, if the application previously issued a join request for the attribute and is now issuing another one, without having issued a leave request). If garp_attr_create finds an existing attribute having the same values, return the address to it. Its state will then get updated (i.e., if it was in a leaving state, it will move into a non-leaving state and not get deleted during the next PDU transmission). To accomplish this fix, collapse garp_attr_insert into garp_attr_create (which is its only caller). Thanks to Jorge Boncompte [DTI2] <jorge@dti2.net> for contributing to this fix. Signed-off-by: David Ward <david.ward@ll.mit.edu> Acked-by: Jorge Boncompte [DTI2] <jorge@dti2.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 29 Mar, 2012 2 commits
-
-
zhuangfeiran@ict.ac.cn authored
When K >= 0xFFFF0000, AND needs the two least significant bytes of K as its operand, but EMIT2() gives it the least significant byte of K and 0x2. EMIT() should be used here to replace EMIT2(). Signed-off-by: Feiran Zhuang <zhuangfeiran@ict.ac.cn> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Weiping Pan authored
When a bonding device is configured with fail_over_mac=active, we expect to see the MAC address of the new active slave as the source MAC address after failover. But we see that the source MAC address is the MAC address of previous active slave. Emit NETDEV_CHANGEADDR event when bonding changes its MAC address, in order to let arp_netdev_event flush neighbour cache and route cache. How to reproduce this bug ? -----------hostB---------------- hostA ----- switch ---|-- eth0--bond0(192.168.100.2/24)| (192.168.100.1/24 \--|-- eth1-/ | -------------------------------- 1 on hostB, modprobe bonding mode=1 miimon=500 fail_over_mac=active downdelay=1000 num_grat_arp=1 ifconfig bond0 192.168.100.2/24 up ifenslave bond0 eth0 ifenslave bond0 eth1 then eth0 is the active slave, and MAC of bond0 is MAC of eth0. 2 on hostA, ping 192.168.100.2 3 on hostB, tcpdump -i bond0 -p icmp -XXX you will see bond0 uses MAC of eth0 as source MAC in icmp reply. 4 on hostB, ifconfig eth0 down tcpdump -i bond0 -p icmp -XXX (just keep it running in step 3) you will see first bond0 uses MAC of eth1 as source MAC in icmp reply, then it will use MAC of eth0 as source MAC. Signed-off-by: Weiping Pan <wpan@redhat.com> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 28 Mar, 2012 23 commits
-
-
Rajkumar Manoharan authored
Whenever the station informs the AP that it is about to leave the operating channel, the timestamp should be recorded. It is handled in scan resume but not in scan start. Fix that. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
The commit "ath9k: Remove aggregation flags" changed how nodes were being initialized. Use the HW HT cap bits to initialize/de-initialize nodes, else we would be accessing an uninitialized entry during a suspend/resume cycle, resulting in a panic. Reported-by: Justin P. Mattock <justinmattock@gmail.com> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislav Yakovlev authored
Add myself as maintainer as suggested by Stanislaw Gruszka. Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Santosh Nayak authored
With flag 'GFP_ATOMIC', probability of allocation failure is more. Add error handling after kmalloc() call to avoid null dereference. Signed-off-by: Santosh Nayak <santoshprasadnayak@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislav Yakovlev authored
Fix comment as well. Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Benjamin LaHaise authored
While investigating another bug, I found that the code on the incoming path in __netif_receive_skb will only set skb->skb_iif if it is already 0. When dev_forward_skb() is used in the case of interfaces like veth, skb_iif may already have been set. Making dev_forward_skb() cause the packet to look like a newly received packet would seem to the the correct behaviour here, as otherwise the wrong incoming interface can be reported for such a packet. Signed-off-by: Benjamin LaHaise <bcrl@kvack.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Benjamin LaHaise authored
When using multicast over a local bridge feeding a number of LXC guests using veth, the LXC guests are unable to get a response from other guests when pinging 224.0.0.1. Multicast packets did not appear to be getting delivered to the network namespaces of the guest hosts, and further inspection showed that the incoming route was pointing to the loopback device of the host, not the guest. This lead to the wrong network namespace being picked up by sockets (like ICMP). Fix this by using the correct network namespace when creating the inbound route entry. Signed-off-by: Benjamin LaHaise <bcrl@kvack.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Rick Jones authored
While it is desirable to rate limit certain messages, it is not desirable to rate limit the incrementing of counters associated with those messages. Signed-off-by: Rick Jones <rick.jones2@hp.com> Acked-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
-
Don Skidmore authored
Update the driver version number to better match version of out of tree driver that has similar functionality. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Don Skidmore authored
This was pointed out to me by Xiaojun Zhang on Source Forge. CC: Xiaojun Zhang <zhangxiaojun@sourceforge.net> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
stephen hemminger authored
Dan Carpenter noticed that ixgbevf initial default was different than the rest. But the problem is broader than that, only one Intel driver (ixgb) was doing it almost right. The convention for default debug level should be consistent among Intel drivers and follow established convention. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Eric Dumazet authored
Now skb_add_rx_frag() has a truesize parameter, we can fix cdc-phonet to properly account truesize of each fragment : a full page. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Rémi Denis-Courmont <remi.denis-courmont@nokia.com> Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Now skb_add_rx_frag() has a truesize parameter, we can fix f_phonet to properly account truesize of each fragment : a full page. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Rémi Denis-Courmont <remi.denis-courmont@nokia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
HZ is more likely to be 1000 these days. timer handlers are run from softirq, no need to disable bh skb priority 1 is TC_PRIO_FILLER Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
There are two channels here. User space starts counting channels at one but in the kernel we start at zero. If the user passes in a zero channel that's invalid and could lead to memory corruption. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dmitry Kravkov authored
Fixes the bug that may prevent from mac to be configured, while there is an empty slot for it. Reported-by: Maciej Żenczykowski <zenczykowski@gmail.com> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
The flow in which the bnx2x driver starts after a previous driver has been terminated in an 'unclean' manner has several bugs and FW risks, which makes it possible for the driver to fail after boot-from-SAN or kdump. This patch contains a revised flow which performs a safer initialization, solving the possible crash scenarios. Notice this patch contains lines with over 80 characters, as it keeps print-strings in a single line. Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com> Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Guan Xin authored
Added Vendor/Device Id of Motorola Rokr E6 (22b8:6027) so it can be recognized by the "zaurus" USBNet driver. Applies to Linux 3.2.13 and 2.6.39.4. Signed-off-by: Guan Xin <guanx.bac@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nobuhiro Iwamatsu authored
Add define of SH7734 register and sh_eth_reset_hw_crc function. V3: Rebase net/HEAD. V2: Do not split line of #if defined. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phil Sutter authored
This way the USB variant of the driver uses usb_make_path in order to provide bus-info compatible to other USB drivers (like e.g. asix.c). Signed-off-by: Phil Sutter <phil.sutter@viprinet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phil Sutter authored
This happened on a machine with a custom hotplug script calling nameif, probably due to slow firmware loading. At the time nameif uses ethtool to gather interface information, i2400m->fw_name is zero and so a null pointer dereference occurs from within i2400m_get_drvinfo(). Signed-off-by: Phil Sutter <phil.sutter@viprinet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-