aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* mac80211: don't send null data packet when not associatedJohannes Berg2012-11-09
| | | | | | | | | | | | | On resume or firmware recovery, mac80211 sends a null data packet to see if the AP is still around and hasn't disconnected us. However, it always does this even if it wasn't even connected before, leading to a warning in the new channel context code. Fix this by checking that it's associated. Cc: stable@vger.kernel.org Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix memory leak in device registration error pathJohannes Berg2012-11-09
| | | | | | | | If the cipher suites need to be allocated, but this allocation fails, this leaks the internal scan request. Fix that by going to the correct error handling label. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: sync acccess to tx_filtered/ps_tx_buf queuesArik Nemtsov2012-11-05
| | | | | | | | | | | | | These are accessed without a lock when ending STA PSM. If the sta_cleanup timer accesses these lists at the same time, we might crash. This may fix some mysterious crashes we had during ieee80211_sta_ps_deliver_wakeup. Cc: stable@vger.kernel.org Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Ido Yariv <ido@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: init sched_scan_iesDavid Spinadel2012-10-31
| | | | | | | | | | In case that there is an unsupported band, the ie will be unallocated and the free will crash. Cc: stable@vger.kernel.org Signed-off-by: David Spinadel <david.spinadel@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: do not call ieee80211_configure_filter if no interfaces are upFelix Fietkau2012-10-31
| | | | | | | | Drivers are not expected to handle it before drv_start has been called. It will be called again after an interface has been brought up. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: make sure data is accessible in EAPOL checkJohannes Berg2012-10-26
| | | | | | | | | | | | The code to allow EAPOL frames even when the station isn't yet marked associated needs to check that the incoming frame is long enough and due to paged RX it also can't assume skb->data contains the right data, it must use skb_copy_bits(). Fix this to avoid using data that doesn't really exist. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: verify that skb data is presentJohannes Berg2012-10-26
| | | | | | | | | | | | | | A number of places in the mesh code don't check that the frame data is present and in the skb header when trying to access. Add those checks and the necessary pskb_may_pull() calls. This prevents accessing data that doesn't actually exist. To do this, export ieee80211_get_mesh_hdrlen() to be able to use it in mac80211. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: check management frame header lengthJohannes Berg2012-10-26
| | | | | | | | | | | | Due to pskb_may_pull() checking the skb length, all non-management frames are checked on input whether their 802.11 header is fully present. Also add that check for management frames and remove a check that is now duplicate. This prevents accessing skb data beyond the frame end. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wireless: drop invalid mesh address extension framesJohannes Berg2012-10-26
| | | | | | | | | | | The mesh header can have address extension by a 4th or a 5th and 6th address, but never both. Drop such frames in 802.11 -> 802.3 conversion along with any frames that have the wrong extension. Cc: stable@vger.kernel.org Reviewed-by: Javier Cardona <javier@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix SSID copy on IBSS JOINAntonio Quartulli2012-10-26
| | | | | | | | | | | | | | The 'ssid' field of the cfg80211_ibss_params is a u8 pointer and its length is likely to be less than IEEE80211_MAX_SSID_LEN most of the time. This patch fixes the ssid copy in ieee80211_ibss_join() by using the SSID length to prevent it from reading beyond the string. Cc: stable@vger.kernel.org Signed-off-by: Antonio Quartulli <ordex@autistici.org> [rewrapped commit message, small rewording] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: don't inspect Sequence Control field on control framesJavier Cardona2012-10-25
| | | | | | | | | | | Per IEEE Std. 802.11-2012, Sec 8.2.4.4.1, the sequence Control field is not present in control frames. We noticed this problem when processing Block Ack Requests. Cc: stable@vger.kernel.org Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: Javier Lopez <jlopex@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Don't drop frames received with mesh ttl == 1Javier Cardona2012-10-25
| | | | | | | | Prior this fix, those frames were not received, nor forwarded. Fix this to receive and not forward. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Only process mesh config header on frames that RA_MATCHJavier Cardona2012-10-25
| | | | | | | | | | Doing otherwise is wrong, and may wreak havoc on the mpp tables, specially if the frame is encrypted. Cc: stable@vger.kernel.org Reported-by: Chaoxing Lin <Chaoxing.Lin@ultra-3eti.com> Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: use blacklist for duplicate IE checkJohannes Berg2012-10-24
| | | | | | | | | | | | | Instead of the current whitelist which accepts duplicates only for the quiet and vendor IEs, use a blacklist of all IEs (that we currently parse) that can't be duplicated. This avoids detecting a beacon as corrupt in the future when new IEs are added that can be duplicated. Cc: stable@vger.kernel.org Signed-off-by: Paul Stewart <pstew@chromium.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: fix initialization of chan->max_reg_powerFelix Fietkau2012-10-18
| | | | | | | | A few places touch chan->max_power based on updated tx power rules, but forget to do the same to chan->max_reg_power. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: fix antenna gain handlingFelix Fietkau2012-10-18
| | | | | | | | | | | | | | | | No driver initializes chan->max_antenna_gain to something sensible, and the only place where it is being used right now is inside ath9k. This leads to ath9k potentially using less tx power than it can use, which can decrease performance/range in some rare cases. Rather than going through every single driver, this patch initializes chan->orig_mag in wiphy_register(), ignoring whatever value the driver left in there. If a driver for some reason wishes to limit it independent from regulatory rulesets, it can do so internally. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: connect with HT20 if HT40 is not permittedJohannes Berg2012-10-17
| | | | | | | | | | | | | | | | | | | Some changes to fix issues with HT40 APs in Korea and follow-up changes to allow using HT40 even if the local regulatory database disallows it caused issues with iwlwifi (and could cause issues with other devices); iwlwifi firmware would assert if you tried to connect to an AP that has an invalid configuration (e.g. using HT40- on channel 140.) Fix this, while avoiding the "Korean AP" issue by disabling HT40 and advertising HT20 to the AP when connecting. Cc: stable@vger.kernel.org [3.6] Reported-by: Florian Reitmeir <florian@reitmeir.org> Tested-by: Florian Reitmeir <florian@reitmeir.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211/mac80211: avoid state mishmash on deauthStanislaw Gruszka2012-10-15
| | | | | | | | | | | | | Avoid situation when we are on associate state in mac80211 and on disassociate state in cfg80211. This can results on crash during modules unload (like showed on this thread: http://marc.info/?t=134373976300001&r=1&w=2) and possibly other problems. Reported-by: Pedro Francisco <pedrogfrancisco@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge remote-tracking branch 'wireless/master' into mac80211Johannes Berg2012-10-15
|\
| * mac80211: use ieee80211_free_txskb to fix possible skb leaksFelix Fietkau2012-10-08
| | | | | | | | | | | | | | | | | | | | A few places free skbs using dev_kfree_skb even though they're called after ieee80211_subif_start_xmit might have cloned it for tracking tx status. Use ieee80211_free_txskb here to prevent skb leaks. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * carl9170: fix sleep in softirq contextRonald Wahl2012-10-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the following bug: usb 1-1.1: restart device (8) BUG: sleeping function called from invalid context at drivers/usb/core/urb.c:654 in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper (usb_poison_urb+0x1c/0xf8) (usb_poison_anchored_urbs+0x48/0x78) (carl9170_usb_handle_tx_err+0x128/0x150) (carl9170_usb_reset+0xc/0x20) (carl9170_handle_command_response+0x298/0xea8) (carl9170_usb_tasklet+0x68/0x184) (tasklet_hi_action+0x84/0xdc) this only happens if the device is plugged in an USB port, the driver is loaded but inactive (e.g. the wlan interface is down). If the device is active everything is fine. Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * ath5k: fix potential NULL pointer dereference in ath5k_beacon_update()Wei Yongjun2012-10-08
| | | | | | | | | | | | | | | | | | | | The dereference should be moved below the NULL test. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mwifiex: update cfg80211 with correct reason code when connection is lostAmitkumar Karwar2012-10-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Driver gets LINK_LOST, DEAUTHENTICATED and DISASSOCIATED events from firmware when connection is lost in different scenarios. Currently we are using common code WLAN_REASON_DEAUTH_LEAVING for these cases. This patch adds support to parse an actual reason code from firmware event body and send it to cfg80211. WLAN_REASON_DEAUTH_LEAVING code is used if deauth is initiated by our device. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mwifiex: update cfg80211 with correct reason code when association failsAmitkumar Karwar2012-10-08
| | | | | | | | | | | | | | | | | | | | | | This patch adds support to send correct reason code got from firmware when association attempt fails. Also, the error message displayed for association failure due to network incompatibility is modified. Current message "cannot find ssid.." misleads user. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mwifiex: reset scan_processing flag in failure casesAmitkumar Karwar2012-10-08
| | | | | | | | | | | | | | | | | | | | scan_processing flag should be reset when scan request is failed due to some reasons Ex. memory allocation failure etc. Otherwise further scan requests will be blocked. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mwifiex: return -EBUSY if scan request cannot be honoredBing Zhao2012-10-08
| | | | | | | | | | | | | | | | | | | | | | | | There are cases we cannot scan when request is received. For example, during WPA group key negociation the scan request will be blocked. We should return an error code to cfg80211 because cfg80211_scan_done will never be called. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Paul Stewart <pstew@chromium.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: call drv_get_tsf() in sleepable contextThomas Pedersen2012-10-08
| | | | | | | | | | | | | | | | | | | | The call to drv_get/set_tsf() was put on the workqueue to perform tsf adjustments since that function might sleep. However it ended up inside a spinlock, whose critical section must be atomic. Do tsf adjustment outside the spinlock instead, and get rid of a warning. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * rt2x00/rt3352: Fix lnagain assignment to use register 66.Daniel Golle2012-10-05
| | | | | | | | | | | | | | | | | | | | This should be register 66 instead of 62. (probably happened by copy&past'ing from the lines below) Signed-off-by: Daniel Golle <dgolle@allnet.de> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * ath9k: use ieee80211_free_txskbFelix Fietkau2012-10-05
| | | | | | | | | | | | | | | | | | Using ieee80211_free_txskb for tx frames is required, since mac80211 clones skbs for which socket tx status is requested. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * ath9k: improve suspend/resume reliabilityFelix Fietkau2012-10-05
| | | | | | | | | | | | | | | | | | | | Ensure that drv_start() always returns true, as a failing hw start usually eventually leads to crashes when there's still a station entry present. Call a power-on reset after a resume and after a hw reset failure to bring the hardware back to life again. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * ath9k: fix ASPM initialization on resumeFelix Fietkau2012-10-05
| | | | | | | | | | | | | | | | ath_pci_aspm_init is only called on card init, so PCI registers get reset after a suspend/resume cycle. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * ipv6: release reference of ip6_null_entry's dst entry in __ip6_del_rtGao feng2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | as we hold dst_entry before we call __ip6_del_rt, so we should alse call dst_release not only return -ENOENT when the rt6_info is ip6_null_entry. and we already hold the dst entry, so I think it's safe to call dst_release out of the write-read lock. Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * Remove noisy printks from llcp_sock_connectDave Jones2012-10-04
| | | | | | | | | | | | | | Validation of userspace input shouldn't trigger dmesg spamming. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * Merge branch 'fixes-for-3.7' of git://gitorious.org/linux-can/linux-canDavid S. Miller2012-10-04
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Marc Kleine-Budde says: ==================== here are three patches for the v3.7 release cycle. Two patches by Peter Senna Tschudin which fix the return values in the error handling path of the sja1000 peak pci and pcmcia driver. And one patch by myself that fixes a compile breakage of the mpc5xxx_can mscan driver due to a section conflict. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| | * can: mpc5xxx_can: fix section type conflictMarc Kleine-Budde2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit: 6d99c4c can: mpc5xxx_can: make data used as *of_device_id.data const both "struct mpc5xxx_can_data mpc5200_can_data" and "mpc5121_can_data" are marked as "const" but also as "__devinitdata". This leads to the following compile error: drivers/net/can/mscan/mpc5xxx_can.c:383: error: mpc5200_can_data causes a section type conflict drivers/net/can/mscan/mpc5xxx_can.c:383: error: mpc5200_can_data causes a section type conflict drivers/net/can/mscan/mpc5xxx_can.c:388: error: mpc5121_can_data causes a section type conflict drivers/net/can/mscan/mpc5xxx_can.c:388: error: mpc5121_can_data causes a section type conflict This patch changes the "__devinitdata" to "__devinitconst" and marks the "struct of_device_id mpc5xxx_can_table" as "const" and "__devinitconst", too. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
| | * can: peak_pcmcia: fix error return codePeter Senna Tschudin2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert a nonnegative error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
| | * can: peak_pci: fix error return codePeter Senna Tschudin2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert a nonnegative error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
| * | tipc: prevent dropped connections due to rcvbuf overflowErik Hugne2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When large buffers are sent over connected TIPC sockets, it is likely that the sk_backlog will be filled up on the receiver side, but the TIPC flow control mechanism is happily unaware of this since that is based on message count. The sender will receive a TIPC_ERR_OVERLOAD message when this occurs and drop it's side of the connection, leaving it stale on the receiver end. By increasing the sk_rcvbuf to a 'worst case' value, we avoid the overload caused by a full backlog queue and the flow control will work properly. This worst case value is the max TIPC message size times the flow control window, multiplied by two because a sender will transmit up to double the window size before a port is marked congested. We multiply this by 2 to account for the sk_buff and other overheads. Signed-off-by: Erik Hugne <erik.hugne@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | silence some noisy printks in irdaDave Jones2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fuzzing causes these printks to spew constantly. Changing them to DEBUG statements is consistent with other usage in the file, and makes them disappear when CONFIG_IRDA_DEBUG is disabled. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | team: set qdisc_tx_busylock to avoid LOCKDEP splatEric Dumazet2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a qdisc is installed on a team device, its possible to get a lockdep splat under stress, because nested dev_queue_xmit() can lock busylock a second time (on a different device, so its a false positive) Avoid this problem using a distinct lock_class_key for team devices. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jiri Pirko <jpirko@redhat.com> Acked-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | bonding: set qdisc_tx_busylock to avoid LOCKDEP splatEric Dumazet2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a qdisc is installed on a bonding device, its possible to get following lockdep splat under stress : ============================================= [ INFO: possible recursive locking detected ] 3.6.0+ #211 Not tainted --------------------------------------------- ping/4876 is trying to acquire lock: (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+.-...}, at: [<ffffffff8157a191>] dev_queue_xmit+0xe1/0x830 but task is already holding lock: (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+.-...}, at: [<ffffffff8157a191>] dev_queue_xmit+0xe1/0x830 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(dev->qdisc_tx_busylock ?: &qdisc_tx_busylock); lock(dev->qdisc_tx_busylock ?: &qdisc_tx_busylock); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by ping/4876: #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff815e5030>] raw_sendmsg+0x600/0xc30 #1: (rcu_read_lock_bh){.+....}, at: [<ffffffff815ba4bd>] ip_finish_output+0x12d/0x870 #2: (rcu_read_lock_bh){.+....}, at: [<ffffffff8157a0b0>] dev_queue_xmit+0x0/0x830 #3: (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+.-...}, at: [<ffffffff8157a191>] dev_queue_xmit+0xe1/0x830 #4: (&bond->lock){++.?..}, at: [<ffffffffa02128c1>] bond_start_xmit+0x31/0x4b0 [bonding] #5: (rcu_read_lock_bh){.+....}, at: [<ffffffff8157a0b0>] dev_queue_xmit+0x0/0x830 stack backtrace: Pid: 4876, comm: ping Not tainted 3.6.0+ #211 Call Trace: [<ffffffff810a0145>] __lock_acquire+0x715/0x1b80 [<ffffffff810a256b>] ? mark_held_locks+0x9b/0x100 [<ffffffff810a1bf2>] lock_acquire+0x92/0x1d0 [<ffffffff8157a191>] ? dev_queue_xmit+0xe1/0x830 [<ffffffff81726b7c>] _raw_spin_lock+0x3c/0x50 [<ffffffff8157a191>] ? dev_queue_xmit+0xe1/0x830 [<ffffffff8106264d>] ? rcu_read_lock_bh_held+0x5d/0x90 [<ffffffff8157a191>] dev_queue_xmit+0xe1/0x830 [<ffffffff8157a0b0>] ? netdev_pick_tx+0x570/0x570 [<ffffffffa0212a6a>] bond_start_xmit+0x1da/0x4b0 [bonding] [<ffffffff815796d0>] dev_hard_start_xmit+0x240/0x6b0 [<ffffffff81597c6e>] sch_direct_xmit+0xfe/0x2a0 [<ffffffff8157a249>] dev_queue_xmit+0x199/0x830 [<ffffffff8157a0b0>] ? netdev_pick_tx+0x570/0x570 [<ffffffff815ba96f>] ip_finish_output+0x5df/0x870 [<ffffffff815ba4bd>] ? ip_finish_output+0x12d/0x870 [<ffffffff815bb964>] ip_output+0x54/0xf0 [<ffffffff815bad48>] ip_local_out+0x28/0x90 [<ffffffff815bc444>] ip_send_skb+0x14/0x50 [<ffffffff815bc4b2>] ip_push_pending_frames+0x32/0x40 [<ffffffff815e536a>] raw_sendmsg+0x93a/0xc30 [<ffffffff8128d570>] ? selinux_file_send_sigiotask+0x1f0/0x1f0 [<ffffffff8109ddb4>] ? __lock_is_held+0x54/0x80 [<ffffffff815f6730>] ? inet_recvmsg+0x220/0x220 [<ffffffff8109ddb4>] ? __lock_is_held+0x54/0x80 [<ffffffff815f6855>] inet_sendmsg+0x125/0x240 [<ffffffff815f6730>] ? inet_recvmsg+0x220/0x220 [<ffffffff8155cddb>] sock_sendmsg+0xab/0xe0 [<ffffffff810a1650>] ? lock_release_non_nested+0xa0/0x2e0 [<ffffffff810a1650>] ? lock_release_non_nested+0xa0/0x2e0 [<ffffffff8155d18c>] __sys_sendmsg+0x37c/0x390 [<ffffffff81195b2a>] ? fsnotify+0x2ca/0x7e0 [<ffffffff811958e8>] ? fsnotify+0x88/0x7e0 [<ffffffff81361f36>] ? put_ldisc+0x56/0xd0 [<ffffffff8116f98a>] ? fget_light+0x3da/0x510 [<ffffffff8155f6c4>] sys_sendmsg+0x44/0x80 [<ffffffff8172fc22>] system_call_fastpath+0x16/0x1b Avoid this problem using a distinct lock_class_key for bonding devices. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jay Vosburgh <fubar@us.ibm.com> Cc: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | sctp: check src addr when processing SACK to update transport stateNicolas Dichtel2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Suppose we have an SCTP connection with two paths. After connection is established, path1 is not available, thus this path is marked as inactive. Then traffic goes through path2, but for some reasons packets are delayed (after rto.max). Because packets are delayed, the retransmit mechanism will switch again to path1. At this time, we receive a delayed SACK from path2. When we update the state of the path in sctp_check_transmitted(), we do not take into account the source address of the SACK, hence we update the wrong path. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | sctp: fix a typo in prototype of __sctp_rcv_lookup()Nicolas Dichtel2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | Just to avoid confusion when people only reads this prototype. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | Merge branch 'master' of ↵David S. Miller2012-10-04
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net Jeff Kirsher says: ==================== This series contains fixes/updates to ixgbe only. There are three PTP fixes, polling loop fix and the addition of a device id (X540-AT1). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| | * | ixgbe: add support for X540-AT1joshua.a.hay@intel.com2012-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds device support for Ethernet Controller X540-AT1. Signed-off-by: Josh Hay <joshua.a.hay@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| | * | ixgbe: fix poll loop for FDIRCTRL.INIT_DONE bitEmil Tantilov2012-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The loop in ixgbe_reinit_fdir_tables_82599() only polls for up to 100us resulting in failures to update the FDIR filter table at 1Gbps and 10Gbps when under load. The poll times for FDIRCTRL.INIT_DONE are 55us, 550us and 5.5ms for 10Gbps, 1Gbps and 100Mbps respectively. This patch sets the wait time to be the same as in ixgbe_fdir_enable_82599() Reported-by: Bhushan <shashi-sm@users.sf.net> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| | * | ixgbe: fix PTP ethtool timestamping functionJacob Keller2012-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a development issue that occurred due to invalid modes reported in the ethtool get_ts_info function. The issue is resolved by removing unsupported modes from the Rx supported list. CC: stable <stable@vger.kernel.org> [3.5] Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| | * | ixgbe: (PTP) Fix PPS interrupt codeJacob Keller2012-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Driver was enabling PPS interrupt even when user wasn't enabling it via the ptp core. This patch fixes the PPS so that it is only enabled explicitly, and moves the interrupt enabling code into the correct location in the driver Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Cc: Stable <stable@vger.kernel.org> [3.5] Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| | * | ixgbe: Fix PTP X540 SDP alignment code for PPS signalJacob Keller2012-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a bug in the method used for calculating the trigger alignment for SDP0 when enabling a PPS output on the X540. The alignment math wasn't properly taking into account the overflow cyclecounter, and was misaligning the pin triggers so that two X540 devices synced properly had mis-aligned SDP pins. This patch fixes the math to calculate the correct seconds alignment for the PPS signal. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | | ipv4: add a fib_type to fib_infoEric Dumazet2012-10-04
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit d2d68ba9fe8 (ipv4: Cache input routes in fib_info nexthops.) introduced a regression for forwarding. This was hard to reproduce but the symptom was that packets were delivered to local host instead of being forwarded. David suggested to add fib_type to fib_info so that we dont inadvertently share same fib_info for different purposes. With help from Julian Anastasov who provided very helpful hints, reproduced here : <quote> Can it be a problem related to fib_info reuse from different routes. For example, when local IP address is created for subnet we have: broadcast 192.168.0.255 dev DEV proto kernel scope link src 192.168.0.1 192.168.0.0/24 dev DEV proto kernel scope link src 192.168.0.1 local 192.168.0.1 dev DEV proto kernel scope host src 192.168.0.1 The "dev DEV proto kernel scope link src 192.168.0.1" is a reused fib_info structure where we put cached routes. The result can be same fib_info for 192.168.0.255 and 192.168.0.0/24. RTN_BROADCAST is cached only for input routes. Incoming broadcast to 192.168.0.255 can be cached and can cause problems for traffic forwarded to 192.168.0.0/24. So, this patch should solve the problem because it separates the broadcast from unicast traffic. And the ip_route_input_slow caching will work for local and broadcast input routes (above routes 1 and 3) just because they differ in scope and use different fib_info. </quote> Many thanks to Chris Clayton for his patience and help. Reported-by: Chris Clayton <chris2553@googlemail.com> Bisected-by: Chris Clayton <chris2553@googlemail.com> Reported-by: Dave Jones <davej@redhat.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Julian Anastasov <ja@ssi.bg> Tested-by: Chris Clayton <chris2553@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.2 (git 2.25.0) at 2024-10-12 09:28:37 -0400