summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ipv6: Handle PMTU in ICMP error handlers.David S. Miller2012-06-1510-122/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One tricky issue on the ipv6 side vs. ipv4 is that the ICMP callouts to handle the error pass the 32-bit info cookie in network byte order whereas ipv4 passes it around in host byte order. Like the ipv4 side, we have two helper functions. One for when we have a socket context and one for when we do not. ip6ip6 tunnels are not handled here, because they handle PMTU events by essentially relaying another ICMP packet-too-big message back to the original sender. This patch allows us to get rid of rt6_do_pmtu_disc(). It handles all kinds of situations that simply cannot happen when we do the PMTU update directly using a fully resolved route. In fact, the "plen == 128" check in ip6_rt_update_pmtu() can very likely be removed or changed into a BUG_ON() check. We should never have a prefixed ipv6 route when we get there. Another piece of strange history here is that TCP and DCCP, unlike in ipv4, never invoke the update_pmtu() method from their ICMP error handlers. This is incredibly astonishing since this is the context where we have the most accurate context in which to make a PMTU update, namely we have a fully connected socket and associated cached socket route. Signed-off-by: David S. Miller <davem@davemloft.net>
* ipv4: Handle PMTU in all ICMP error handlers.David S. Miller2012-06-1411-13/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With ip_rt_frag_needed() removed, we have to explicitly update PMTU information in every ICMP error handler. Create two helper functions to facilitate this. 1) ipv4_sk_update_pmtu() This updates the PMTU when we have a socket context to work with. 2) ipv4_update_pmtu() Raw version, used when no socket context is available. For this interface, we essentially just pass in explicit arguments for the flow identity information we would have extracted from the socket. And you'll notice that ipv4_sk_update_pmtu() is simply implemented in terms of ipv4_update_pmtu() Note that __ip_route_output_key() is used, rather than something like ip_route_output_flow() or ip_route_output_key(). This is because we absolutely do not want to end up with a route that does IPSEC encapsulation and the like. Instead, we only want the route that would get us to the node described by the outermost IP header. Reported-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* dcbnl: Use BUG_ON() instead of BUG()Thomas Graf2012-06-141-4/+1
| | | | | Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* dcbnl: Silence harmless gcc warning about uninitialized reply_nlhThomas Graf2012-06-141-1/+1
| | | | | Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* bonding: drop_monitor awareEric Dumazet2012-06-133-13/+13
| | | | | | | | | | | | When packets are dropped in TX path, its better to use kfree_skb() instead of dev_kfree_skb() to give proper drop_monitor events. Also move the kfree_skb() call after read_unlock() in bond_alb_xmit() and bond_xmit_activebackup() Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* dcbnl: Use type safe nlmsg_data()Thomas Graf2012-06-131-1/+1
| | | | | Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* dcbnl: Move dcb app allocation into dcb_app_add()Thomas Graf2012-06-131-25/+22
| | | | | Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* dcbnl: Move dcb app lookup code into dcb_app_lookup()Thomas Graf2012-06-131-46/+35
| | | | | Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* dcbnl: Return consistent error codesThomas Graf2012-06-131-135/+138
| | | | | | | | | | EMSGSIZE - ran out of space while constructing message EOPNOTSUPP - driver/hardware does not support operation ENODEV - network device not found EINVAL - invalid message Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* dcbnl: Use dcbnl_newmsg() where possibleThomas Graf2012-06-131-14/+2
| | | | | Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* dcbnl: Remove now unused dcbnl_reply()Thomas Graf2012-06-131-37/+0
| | | | | Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* dcbnl: Shorten all command handling functionsThomas Graf2012-06-131-550/+172
| | | | | | | | | | | Allocating and sending the skb in dcb_doit() allows for much shorter and cleaner command handling functions. The huge switch statement is replaced with an array based definition of the handling function and reply message type. Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* dcbnl: Prepare framework to shorten handling functionsThomas Graf2012-06-131-0/+71
| | | | | | | | | There is no need to allocate and send the reply message in each handling function separately. Instead, the reply skb can be allocated and sent in dcb_doit() directly. Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2012-06-1247-155/+2180
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: MAINTAINERS drivers/net/wireless/iwlwifi/pcie/trans.c The iwlwifi conflict was resolved by keeping the code added in 'net' that turns off the buggy chip feature. The MAINTAINERS conflict was merely overlapping changes, one change updated all the wireless web site URLs and the other changed some GIT trees to be Johannes's instead of John's. Signed-off-by: David S. Miller <davem@davemloft.net>
| * bonding: Fix corrupted queue_mappingEric Dumazet2012-06-122-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the transmit path of the bonding driver, skb->cb is used to stash the skb->queue_mapping so that the bonding device can set its own queue mapping. This value becomes corrupted since the skb->cb is also used in __dev_xmit_skb. When transmitting through bonding driver, bond_select_queue is called from dev_queue_xmit. In bond_select_queue the original skb->queue_mapping is copied into skb->cb (via bond_queue_mapping) and skb->queue_mapping is overwritten with the bond driver queue. Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes the packet length into skb->cb, thereby overwriting the stashed queue mappping. In bond_dev_queue_xmit (called from hard_start_xmit), the queue mapping for the skb is set to the stashed value which is now the skb length and hence is an invalid queue for the slave device. If we want to save skb->queue_mapping into skb->cb[], best place is to add a field in struct qdisc_skb_cb, to make sure it wont conflict with other layers (eg : Qdiscc, Infiniband...) This patchs also makes sure (struct qdisc_skb_cb)->data is aligned on 8 bytes : netem qdisc for example assumes it can store an u64 in it, without misalignment penalty. Note : we only have 20 bytes left in (struct qdisc_skb_cb)->data[]. The largest user is CHOKe and it fills it. Based on a previous patch from Tom Herbert. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Tom Herbert <therbert@google.com> Cc: John Fastabend <john.r.fastabend@intel.com> Cc: Roland Dreier <roland@kernel.org> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * bonding:record primary when modify it via sysfsWeiping Pan2012-06-121-2/+6
| | | | | | | | | | | | | | | | | | | | | | If we modify primary via sysfs and it is not a valid slave, we should record it for future use, and this behavior is the same with bond_check_params(). Signed-off-by: Weiping Pan <wpan@redhat.com> Acked-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * Merge branch 'master' of git://1984.lsi.us.es/netDavid S. Miller2012-06-123-34/+48
| |\
| | * netfilter: nf_ct_h323: fix bug in rtcp nattingPablo Neira Ayuso2012-06-071-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The nat_rtp_rtcp hook takes two separate parameters port and rtp_port. port is expected to be the real h245 address (found inside the packet). rtp_port is the even number closest to port (RTP ports are even and RTCP ports are odd). However currently, both port and rtp_port are having same value (both are rounded to nearest even numbers). This works well in case of openlogicalchannel with media (RTP/even) port. But in case of openlogicalchannel for media control (RTCP/odd) port, h245 address in the packet is wrongly modified to have an even port. I am attaching a pcap demonstrating the problem, for any further analysis. This behavior was introduced around v2.6.19 while rewriting the helper. Signed-off-by: Jagdish Motwani <jagdish.motwani@elitecore.com> Signed-off-by: Sanket Shah <sanket.shah@elitecore.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
| | * netfilter: xt_HMARK: fix endianness and provide consistent hashingHans Schillstrom2012-06-072-31/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch addresses two issues: a) Fix usage of u32 and __be32 that causes endianess warnings via sparse. b) Ensure consistent hashing in a cluster that is composed of big and little endian systems. Thus, we obtain the same hash mark in an heterogeneous cluster. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Hans Schillstrom <hans@schillstrom.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
| * | tilegx network driver: initial supportChris Metcalf2012-06-113-2/+1902
| | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds support for the tilegx network driver based on the GXIO IORPC support in the tilegx software stack, using the on-chip mPIPE packet processing engine. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | tg3: Apply short DMA frag workaround to 5906Matt Carlson2012-06-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 5906 devices also need the short DMA fragment workaround. This patch makes the necessary change. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Tested-by: Christian Kujau <lists@nerdbynature.de> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: stmmac: Fix clock en-/disable callsStefan Roese2012-06-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clk_{un}prepare is mandatory for platforms using common clock framework. Since these drivers are used by SPEAr platform, which supports common clock framework, add clk_{un}prepare() support for them. Otherwise the clocks are not correctly en-/disabled and ethernet support doesn't work. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Viresh Kumar <viresh.linux@gmail.com> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | lpc_eth: fix tx completionEric Dumazet2012-06-111-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __lpc_handle_xmit() has two bugs : 1) It can leak skbs in case TXSTATUS_ERROR is set 2) It can wake up txqueue while no slot was freed. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Roland Stigge <stigge@antcom.de> Tested-by: Roland Stigge <stigge@antcom.de> Cc: Kevin Wells <kevin.wells@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | lpc_eth: add missing ndo_change_mtu()Eric Dumazet2012-06-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lpc_eth does a copy of transmitted skbs to DMA area, without checking skb lengths, so can trigger buffer overflows : memcpy(pldat->tx_buff_v + txidx * ENET_MAXF_SIZE, skb->data, len); One way to get bigger skbs is to allow MTU changes above the 1500 limit. Calling eth_change_mtu() in ndo_change_mtu() makes sure this cannot happen. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Roland Stigge <stigge@antcom.de> Cc: Kevin Wells <kevin.wells@nxp.com> Acked-by: Roland Stigge <stigge@antcom.de> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | Merge branch 'master' of ↵John W. Linville2012-06-1113-31/+69
| |\ \ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
| | * | mac80211: add back channel change flagStanislaw Gruszka2012-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 24398e39c8ee4a9d9123eed322b859ece4d16cac Author: Johannes Berg <johannes.berg@intel.com> Date: Wed Mar 28 10:58:36 2012 +0200 mac80211: set HT channel before association removed IEEE80211_CONF_CHANGE_CHANNEL argument from ieee80211_hw_config, which is required by iwl4965 driver, otherwise that driver does not configure channel properly and is not able to associate. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | NFC: Fix possible NULL ptr deref when getting the name of a socketSasha Levin2012-06-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | llcp_sock_getname() might get called before the LLCP socket was created. This condition isn't checked, and llcp_sock_getname will simply deref a NULL ptr in that case. This exists starting with d646960 ("NFC: Initial LLCP support"). Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | iwlwifi: disable the buggy chain extension feature in HWEmmanuel Grumbach2012-06-082-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature has been reported to be buggy and enabled by default. We therefore need to disable it manually. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | iwlwifi: don't mess up the SCD when removing a keyEmmanuel Grumbach2012-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we remove a key, we put a key index which was supposed to tell the fw that we are actually removing the key. But instead the fw took that index as a valid index and messed up the SRAM of the device. This memory corruption on the device mangled the data of the SCD. The impact on the user is that SCD queue 2 got stuck after having removed keys. The message is the log that was printed is: Queue 2 stuck for 10000ms This doesn't seem to fix the higher queues that get stuck from time to time. Cc: stable@vger.kernel.org [2.6.27+] Reviewed-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | bcma: fix null pointer in bcma_core_pci_irq_ctlHauke Mehrtens2012-06-081-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pc could be null if hosttype != BCMA_HOSTTYPE_PCI. If we are on a device without a pci core this function is called with pc = null by b43 and brcmsmac. If the host type is PCI we have a pci core as well and pc can not be null. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | b43: do not call ieee80211_unregister_hw if we are not registredOleksij Rempel2012-06-082-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this patch fixes kernel Oops on "rmmod b43" if firmware was not loaded: BUG: unable to handle kernel NULL pointer dereference at 0000000000000088 IP: [<ffffffff8104e988>] drain_workqueue+0x25/0x142 PGD 153ac6067 PUD 153b82067 PMD 0 Oops: 0000 [#1] SMP Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | iwlwifi: use correct supported firmware for 6035 and 6000g2Meenakshi Venkataraman2012-06-081-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My patch iwlwifi: use correct released ucode version did not correctly report supported firmware for the 6035 device. This patch fixes it. The minimum supported firmware version for 6035 is v6. Also correct the minimum supported firmware version for the 6000g2 series of devices. Cc: stable@kernel.org Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | wireless: add my new trees to MAINTAINERSJohannes Berg2012-06-081-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add my new trees to the MAINTAINERS file for the components that I maintain in the new trees. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | mac80211_hwsim: Set IEEE80211_STAT_ACK flag when userspace indicates that ↵Qasim Javed2012-06-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the frame has been acknowledged. The station fail average is not updated correctly since the IEEE80211_STAT_ACK flag is not set when using wmediumd with mac80211_hwsim. Set this flag when wmediumd indicates that the frame was successfully transmitted (eventually). Signed-off-by: Qasim Javed <qasimj@gmail.com> Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | rtl8187: ->brightness_set can not sleepStanislaw Gruszka2012-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix: BUG: sleeping function called from invalid context at kernel/workqueue.c:2547 in_atomic(): 1, irqs_disabled(): 0, pid: 629, name: wpa_supplicant 2 locks held by wpa_supplicant/629: #0: (rtnl_mutex){+.+.+.}, at: [<c08b2b84>] rtnl_lock+0x14/0x20 #1: (&trigger->leddev_list_lock){.+.?..}, at: [<c0867f41>] led_trigger_event+0x21/0x80 Pid: 629, comm: wpa_supplicant Not tainted 3.3.0-0.rc3.git5.1.fc17.i686 Call Trace: [<c046a9f6>] __might_sleep+0x126/0x1d0 [<c0457d6c>] wait_on_work+0x2c/0x1d0 [<c045a09a>] __cancel_work_timer+0x6a/0x120 [<c045a160>] cancel_delayed_work_sync+0x10/0x20 [<f7dd3c22>] rtl8187_led_brightness_set+0x82/0xf0 [rtl8187] [<c0867f7c>] led_trigger_event+0x5c/0x80 [<f7ff5e6d>] ieee80211_led_radio+0x1d/0x40 [mac80211] [<f7ff3583>] ieee80211_stop_device+0x13/0x230 [mac80211] Removing _sync is ok, because if led_on work is currently running it will be finished before led_off work start to perform, since they are always queued on the same mac80211 local->workqueue. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=795176 Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | net/wireless: ipw2100: Fix WARN_ON occurring in wiphy_register called by ↵Stanislav Yakovlev2012-06-081-15/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ipw2100_pci_init_one The problem was found by Larry Finger: http://marc.info/?l=linux-wireless&m=133702401700614&w=2 The problem is identical to the one for ipw2200 which is already fixed: http://marc.info/?l=linux-wireless&m=133457257407196&w=2 [ 17.766431] ------------[ cut here ]------------ [ 17.766467] WARNING: at net/wireless/core.c:562 wiphy_register+0x34c/0x3c0 [cfg80211]() [ 17.766471] Hardware name: Latitude D600 [ 17.766474] Modules linked in: ipw2100(+) libipw pcmcia cfg80211 ppdev parport_pc yenta_socket sr_mod pcmcia_rsrc parport iTCO_wdt cdrom sg rfkill pcmcia_ core lib80211 tg3 video button battery ac iTCO_vendor_support joydev shpchp pcspkr pciehp pci_hotplug autofs4 radeon ttm drm_kms_helper uhci_hcd ehci_hcd rtc _cmos thermal drm hwmon i2c_algo_bit i2c_core processor usbcore usb_common ata_generic ata_piix ahci libahci libata [ 17.766525] Pid: 474, comm: modprobe Not tainted 3.4.0-rc7-wl+ #6 [ 17.766528] Call Trace: [ 17.766541] [<c066ad08>] ? printk+0x28/0x2a [ 17.766552] [<c0230edd>] warn_slowpath_common+0x6d/0xa0 [ 17.766563] [<e0b253bc>] ? wiphy_register+0x34c/0x3c0 [cfg80211] [ 17.766573] [<e0b253bc>] ? wiphy_register+0x34c/0x3c0 [cfg80211] [ 17.766578] [<c0230f2d>] warn_slowpath_null+0x1d/0x20 [ 17.766588] [<e0b253bc>] wiphy_register+0x34c/0x3c0 [cfg80211] [ 17.766605] [<e0b5b0d6>] ipw2100_wdev_init+0x196/0x1c0 [ipw2100] [ 17.766616] [<e0b5d962>] ipw2100_pci_init_one+0x2b2/0x694 [ipw2100] [ 17.766632] [<c047ce52>] local_pci_probe+0x42/0xb0 [ 17.766637] [<c047e2b0>] pci_device_probe+0x60/0x90 [ 17.766645] [<c0376de2>] ? sysfs_create_link+0x12/0x20 [ 17.766654] [<c050f1f6>] really_probe+0x56/0x2e0 [ 17.766659] [<c037636d>] ? create_dir+0x5d/0xa0 [ 17.766667] [<c0518c6b>] ? pm_runtime_barrier+0x3b/0xa0 [ 17.766672] [<c050f5e4>] driver_probe_device+0x44/0xa0 [ 17.766677] [<c047e227>] ? pci_match_device+0x97/0xa0 [ 17.766681] [<c050f6c9>] __driver_attach+0x89/0x90 [ 17.766686] [<c050f640>] ? driver_probe_device+0xa0/0xa0 [ 17.766691] [<c050da2a>] bus_for_each_dev+0x3a/0x70 [ 17.766695] [<c050ee6c>] driver_attach+0x1c/0x30 [ 17.766699] [<c050f640>] ? driver_probe_device+0xa0/0xa0 [ 17.766704] [<c050ea77>] bus_add_driver+0x187/0x280 [ 17.766710] [<c045b9cd>] ? kset_find_obj+0x2d/0x60 [ 17.766715] [<c047e2e0>] ? pci_device_probe+0x90/0x90 [ 17.766719] [<c047e2e0>] ? pci_device_probe+0x90/0x90 [ 17.766724] [<c050fb85>] driver_register+0x65/0x110 [ 17.766729] [<c047e09d>] __pci_register_driver+0x3d/0xa0 [ 17.766738] [<e09f705c>] ipw2100_init+0x5c/0x1000 [ipw2100] [ 17.766743] [<c020110f>] do_one_initcall+0x2f/0x170 [ 17.766749] [<e09f7000>] ? 0xe09f6fff [ 17.766757] [<c0287ce8>] sys_init_module+0xa8/0x210 [ 17.766766] [<c067a075>] syscall_call+0x7/0xb [ 17.766769] ---[ end trace 559898c6bb0d1c75 ]--- [ 17.767093] ipw2100: probe of 0000:02:03.0 failed with error -5 This warning appears only if we apply Ben Hutchings' fix http://marc.info/?l=linux-wireless&m=132720204412667&w=2 for the bug reported by Cesare Leonardi http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656813 with cfg80211 warning during device registration ("cfg80211: failed to add phy80211 symlink to netdev!"). We separate device bring up and registration with network stack to avoid the problem. Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | dummy: fix rcu_sched self-detected stallsEric Dumazet2012-06-111-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trying to "modprobe dummy numdummies=30000" triggers : INFO: rcu_sched self-detected stall on CPU { 8} (t=60000 jiffies) After this splat, RTNL is locked and reboot is needed. We must call cond_resched() to avoid this, even holding RTNL. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | net: Reorder initialization in ip_route_output to fix gcc warningRoland Dreier2012-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If I build with W=1, for every file that includes <net/route.h>, I get the warning include/net/route.h: In function 'ip_route_output': include/net/route.h:135:3: warning: initialized field overwritten [-Woverride-init] include/net/route.h:135:3: warning: (near initialization for 'fl4') [-Woverride-init] (This is with "gcc (Debian 4.6.3-1) 4.6.3") A fix seems pretty trivial: move the initialization of .flowi4_tos earlier. As far as I can tell, this has no effect on code generation. Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | virtio-net: fix a race on 32bit archesEric Dumazet2012-06-101-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 3fa2a1df909 (virtio-net: per cpu 64 bit stats (v2)) added a race on 32bit arches. We must use separate syncp for rx and tx path as they can be run at the same time on different cpus. Thus one sequence increment can be lost and readers spin forever. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Stephen Hemminger <shemminger@vyatta.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.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>
| * | | r8169: avoid NAPI scheduling delay.françois romieu2012-06-101-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While reworking the r8169 driver a few months ago to perform the smallest amount of work in the irq handler, I took care of avoiding any irq mask register operation in the slow work dedicated user context thread. The slow work thread scheduled an extra round of NAPI work which would ultimately set the irq mask register as required, thus keeping such irq mask operations in the NAPI handler. It would eventually race with the irq handler and delay NAPI execution for - assuming no further irq - a whole ksoftirqd period. Mildly a problem for rare link changes or corner case PCI events. The race was always lost after the last bh disabling lock had been removed from the work thread and people started wondering where those pesky "NOHZ: local_softirq_pending 08" messages came from. Actually the irq mask register _can_ be set up directly in the slow work thread. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Reported-by: Dave Jones <davej@redhat.com> Tested-by: Marc Dionne <marc.c.dionne@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | net: Make linux/tcp.h C++ friendly (trivial)Paul Pluzhnikov2012-06-091-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I originally sent this patch to <trivial@kernel.org>, but Jiri Kosina did not feel that this is fully appropriate for the trivial tree. Using linux/tcp.h from C++ results in: cat t.cc #include <linux/tcp.h> int main() { } g++ -c t.cc In file included from t.cc:1: /usr/include/linux/tcp.h:72: error: '__u32 __fswab32(__u32)' cannot appear in a constant-expression /usr/include/linux/tcp.h:72: error: a function call cannot appear in a constant-expression ... Attached trivial patch fixes this problem. Tested: - the t.cc above compiles with g++ and - the following program generates the same output before/after the patch: #include <linux/tcp.h> #include <stdio.h> int main () { #define P(a) printf("%s: %08x\n", #a, (int)a) P(TCP_FLAG_CWR); P(TCP_FLAG_ECE); P(TCP_FLAG_URG); P(TCP_FLAG_ACK); P(TCP_FLAG_PSH); P(TCP_FLAG_RST); P(TCP_FLAG_SYN); P(TCP_FLAG_FIN); P(TCP_RESERVED_BITS); P(TCP_DATA_OFFSET); #undef P return 0; } Signed-off-by: Paul Pluzhnikov <ppluzhnikov@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | netdev: fix drivers/net/phy/ kernel-doc warningsRandy Dunlap2012-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix kernel-doc warnings in drivers/net/phy: Warning(drivers/net/phy/mdio_bus.c:109): No description found for parameter 'mdio_bus_np' Warning(drivers/net/phy/mdio_bus.c:109): Excess function parameter 'mdio_np' description in 'of_mdio_find_bus' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | net/core: fix kernel-doc warningsRandy Dunlap2012-06-082-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix kernel-doc warnings in net/core: Warning(net/core/skbuff.c:3368): No description found for parameter 'delta_truesize' Warning(net/core/filter.c:628): No description found for parameter 'pfp' Warning(net/core/filter.c:628): Excess function parameter 'sk' description in 'sk_unattached_filter_create' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | be2net: fix a race in be_xmit()Eric Dumazet2012-06-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As soon as hardware is notified of a transmit, we no longer can assume skb can be dereferenced, as TX completion might have freed the packet. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | l2tp: fix a race in l2tp_ip_sendmsg()Eric Dumazet2012-06-081-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 081b1b1bb27f (l2tp: fix l2tp_ip_sendmsg() route handling) added a race, in case IP route cache is disabled. In this case, we should not do the dst_release(&rt->dst), since it'll free the dst immediately, instead of waiting a RCU grace period. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: James Chapman <jchapman@katalix.com> Cc: Denys Fedoryshchenko <denys@visp.net.lb> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | Revert "niu: Add support for byte queue limits."David S. Miller2012-06-081-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit efa230f2c68abab817f13473077f8d0cc74f43f3. BQL doesn't work with how this driver currently only takes TX interrupts every 1/4 of the TX ring. That behavior needs to be fixed, but that's a larger non-trivial task and for now we have to revert BQL support as this makes the device currently completely unusable. Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | stmmac: fix driver built w/ w/o both pci and platf modulesGiuseppe CAVALLARO2012-06-073-12/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit ba27ec66ffeb78cbf fixes the Kconfig of the driver when built as module allowing to select/unselect the PCI and Platform modules that are not anymore mutually exclusive. This patch fixes and guarantees that the driver builds on all the platforms w/ w/o PCI and when select/unselect the two stmmac supports. In case of there are some problems on both the configuration and the pci/pltf registration the module_init will fail. v2: set the CONFIG_STMMAC_PLATFORM enabled by default. I've just noticed that this can actually help on some configurations that don't enable any STMMAC options by default (e.g. SPEAr). v3: change printk level when do not register the driver. Reported-by: Fengguang Wu <wfg@linux.intel.com> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | snmp: fix OutOctets counter to include forwarded datagramsVincent Bernat2012-06-074-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC 4293 defines ipIfStatsOutOctets (similar definition for ipSystemStatsOutOctets): The total number of octets in IP datagrams delivered to the lower layers for transmission. Octets from datagrams counted in ipIfStatsOutTransmits MUST be counted here. And ipIfStatsOutTransmits: The total number of IP datagrams that this entity supplied to the lower layers for transmission. This includes datagrams generated locally and those forwarded by this entity. Therefore, IPSTATS_MIB_OUTOCTETS must be incremented when incrementing IPSTATS_MIB_OUTFORWDATAGRAMS. IP_UPD_PO_STATS is not used since ipIfStatsOutRequests must not include forwarded datagrams: The total number of IP datagrams that local IP user-protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ipIfStatsOutForwDatagrams. Signed-off-by: Vincent Bernat <bernat@luffy.cx> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | appletalk: Remove out of date message in printkDave Jones2012-06-071-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I accidentally triggered this printk, which amused me for a few moments. Given we're post 2.2, we could just -EACCES, but does anyone even care about Appletalk now ? I figure it's better to leave sleeping dogs lie, and just update the message. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sky2: fix checksum bit management on some chipsstephen hemminger2012-06-071-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The newer flavors of Yukon II use a different method for receive checksum offload. This is indicated in the driver by the SKY2_HW_NEW_LE flag. On these newer chips, the BMU_ENA_RX_CHKSUM should not be set. The driver would get incorrectly toggle the bit, enabling the old checksum logic on these chips and cause a BUG_ON() assertion. If receive checksum was toggled via ethtool. Reported-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
OpenPOWER on IntegriCloud