* Re: [PATCH net v2] packet: fix use after free race in send path when dev is released
From: Daniel Borkmann @ 2013-11-21 15:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, Salam Noureddine, Ben Greear
In-Reply-To: <1385044842.10637.41.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/21/2013 03:40 PM, Eric Dumazet wrote:
> On Thu, 2013-11-21 at 10:47 +0100, Daniel Borkmann wrote:
>
>> +static void packet_dev_put_deferred(struct rcu_head *head)
>> +{
>> + struct packet_sock *po = container_of(head, struct packet_sock, rcu);
>> + struct sock *sk = &po->sk;
>> +
>> + spin_lock(&po->bind_lock);
>> + po->ifindex = -1;
>> +
>> + if (po->prot_hook.dev) {
>> + dev_put(po->prot_hook.dev);
>> + po->prot_hook.dev = NULL;
>> + }
>> +
>> + spin_unlock(&po->bind_lock);
>> + sock_put(sk);
>> +}
>
> I dont think this is needed.
>
>>
>> static int packet_notifier(struct notifier_block *this,
>> unsigned long msg, void *ptr)
>> @@ -3325,13 +3354,13 @@ static int packet_notifier(struct notifier_block *this,
>> if (!sock_flag(sk, SOCK_DEAD))
>> sk->sk_error_report(sk);
>> }
>> + spin_unlock(&po->bind_lock);
>> +
>> if (msg == NETDEV_UNREGISTER) {
>> - po->ifindex = -1;
>> - if (po->prot_hook.dev)
>> - dev_put(po->prot_hook.dev);
>> - po->prot_hook.dev = NULL;
>> + sock_hold(sk);
>> + call_rcu(&po->rcu,
>> + packet_dev_put_deferred);
>> }
>> - spin_unlock(&po->bind_lock);
>> }
>
> Its not needed because you now take a reference on dev
> in packet_cached_dev_get()
That was also my first thought, but Salam pointed out to me, that in case
we have a situation such as ...
in packet_cached_dev_get():
rcu_read_lock();
dev = rcu_dereference(po->cached_dev); in packet_notifier():
---> CPU1: dev_put(po->prot_hook.dev);
---> CPU0:
if (dev)
dev_hold(dev);
rcu_read_unlock();
... we could reach a refcount of 0, before we increase it back to 1. Not sure
if this can actually happen, maybe in preemptible RCU where read-side critical
sections to be preempted? So with this rather paranoid approach we make sure
to avoid such a situation as we wait a grace period when readers finished.
> Otherwise, patch looks good !
Thanks!
^ permalink raw reply
* Question about IPv6 neighbor discovery and 6lowpan
From: Jukka Rissanen @ 2013-11-21 15:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Hi,
I am investigating RFC 6775 (Neighbor Discovery Optimization for IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs))
http://tools.ietf.org/html/rfc6775
The RFC suggests some changes to neighbor discovery procedure for the
6LoWPAN networks. I was looking net/ipv6/ndisc.c and it seems that
ARPHRD type (from type field in net_device struct) is the only way to
detect and change the discovery procedure in the ndisc.c code. Am I
right with this assumption here?
Cheers,
Jukka
^ permalink raw reply
* Re: [PATCH 0/4] bonding: L2DA mode
From: Andy Gospodarek @ 2013-11-21 15:09 UTC (permalink / raw)
To: Anton Nayshtut, Jay Vosburgh, Veaceslav Falico, David S. Miller,
Cong Wang, Nicolas Schichan, Eric Dumazet
Cc: linux-kernel, netdev
In-Reply-To: <1385045738-29726-1-git-send-email-Anton.Nayshtut@wilocity.com>
On 11/21/2013 09:55 AM, Anton Nayshtut wrote:
> L2 Destination Address based (L2DA) mode allows bonding to send packets using
> different slaves according to packets L2 Destination Address.
>
> In L2DA mode, the bonding maintains a default slave and DA/slave map.
>
> Upon a packet transmission, the bonding examines DA of the packet and tries to
> find a corresponding slave within the map. If found, the slave is used for the
> packet transmission. Otherwise, the default slave is used. If the default slave
> is unable to transmit at this moment, the bonding tries to fall back to an
> arbitrary slave that can transmit.
>
> Both the default slave and the map can be controlled via sysfs or by ioctls.
>
> Anton Nayshtut (4):
> bonding: L2DA mode added
> bonding: L2DA mode intergated
> bonding: L2DA command IOCTL
> bonding: L2DA query IOCTL
>
> drivers/net/bonding/Makefile | 2 +-
> drivers/net/bonding/bond_l2da.c | 425 +++++++++++++++++++++++++++++++++++++
> drivers/net/bonding/bond_l2da.h | 56 +++++
> drivers/net/bonding/bond_main.c | 172 ++++++++++++++-
> drivers/net/bonding/bond_options.c | 17 +-
> drivers/net/bonding/bond_sysfs.c | 223 ++++++++++++++++++-
> drivers/net/bonding/bonding.h | 7 +
> include/uapi/linux/if_bonding.h | 32 +++
> include/uapi/linux/sockios.h | 4 +-
> net/core/dev_ioctl.c | 4 +
> net/socket.c | 4 +
> 11 files changed, 937 insertions(+), 9 deletions(-)
> create mode 100644 drivers/net/bonding/bond_l2da.c
> create mode 100644 drivers/net/bonding/bond_l2da.h
>
I have not done a full review of this, but I notice right away that
there are no patches to Documentation/networking/bonding.txt. You can
wait until there are more comments before submitting a v2 of this
series, but please make sure it includes a documentation update when
submitted.
^ permalink raw reply
* [PATCHv1 net] xen-netback: stop the VIF thread before unbinding IRQs
From: David Vrabel @ 2013-11-21 15:26 UTC (permalink / raw)
To: xen-devel
Cc: David Vrabel, Konrad Rzeszutek Wilk, Boris Ostrovsky,
Ian Campbell, Wei Liu, netdev
From: David Vrabel <david.vrabel@citrix.com>
If the VIF thread is still running after unbinding the Tx and Rx IRQs
in xenvif_disconnect(), the thread may attempt to raise an event which
will BUG (as the irq is unbound).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
drivers/net/xen-netback/interface.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b78ee10..2329ccc 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -461,6 +461,9 @@ void xenvif_disconnect(struct xenvif *vif)
if (netif_carrier_ok(vif->dev))
xenvif_carrier_off(vif);
+ if (vif->task)
+ kthread_stop(vif->task);
+
if (vif->tx_irq) {
if (vif->tx_irq == vif->rx_irq)
unbind_from_irqhandler(vif->tx_irq, vif);
@@ -471,9 +474,6 @@ void xenvif_disconnect(struct xenvif *vif)
vif->tx_irq = 0;
}
- if (vif->task)
- kthread_stop(vif->task);
-
xenvif_unmap_frontend_rings(vif);
}
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH net v2] packet: fix use after free race in send path when dev is released
From: Eric Dumazet @ 2013-11-21 15:27 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, Salam Noureddine, Ben Greear
In-Reply-To: <528E2099.90208@redhat.com>
On Thu, 2013-11-21 at 16:02 +0100, Daniel Borkmann wrote:
>
> That was also my first thought, but Salam pointed out to me, that in case
> we have a situation such as ...
>
> in packet_cached_dev_get():
> rcu_read_lock();
> dev = rcu_dereference(po->cached_dev); in packet_notifier():
> ---> CPU1: dev_put(po->prot_hook.dev);
> ---> CPU0:
> if (dev)
> dev_hold(dev);
> rcu_read_unlock();
>
> ... we could reach a refcount of 0, before we increase it back to 1. Not sure
> if this can actually happen, maybe in preemptible RCU where read-side critical
> sections to be preempted? So with this rather paranoid approach we make sure
> to avoid such a situation as we wait a grace period when readers finished.
There is no need, because we respect a rcu grace period at dismantle
time already.
Nothing bad can happen inside the rcu_read_lock()/rcu_read_unlock() pair
in packed_cached_dev_get()
Note that dev_put() does not take any immediate action, it only
decrements the refcount.
So if CPU1 does the dev_put(po->prot_hook.dev) after
setting cached_dev to NULL, we should be safe.
^ permalink raw reply
* Re: [PATCH net v2] packet: fix use after free race in send path when dev is released
From: Daniel Borkmann @ 2013-11-21 15:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, Salam Noureddine, Ben Greear
In-Reply-To: <1385047624.10637.48.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/21/2013 04:27 PM, Eric Dumazet wrote:
> On Thu, 2013-11-21 at 16:02 +0100, Daniel Borkmann wrote:
>
>>
>> That was also my first thought, but Salam pointed out to me, that in case
>> we have a situation such as ...
>>
>> in packet_cached_dev_get():
>> rcu_read_lock();
>> dev = rcu_dereference(po->cached_dev); in packet_notifier():
>> ---> CPU1: dev_put(po->prot_hook.dev);
>> ---> CPU0:
>> if (dev)
>> dev_hold(dev);
>> rcu_read_unlock();
>>
>> ... we could reach a refcount of 0, before we increase it back to 1. Not sure
>> if this can actually happen, maybe in preemptible RCU where read-side critical
>> sections to be preempted? So with this rather paranoid approach we make sure
>> to avoid such a situation as we wait a grace period when readers finished.
>
> There is no need, because we respect a rcu grace period at dismantle
> time already.
>
> Nothing bad can happen inside the rcu_read_lock()/rcu_read_unlock() pair
> in packed_cached_dev_get()
>
> Note that dev_put() does not take any immediate action, it only
> decrements the refcount.
>
> So if CPU1 does the dev_put(po->prot_hook.dev) after
> setting cached_dev to NULL, we should be safe.
Ok, then I'll update the patch and send out v3 with that removed.
Thanks for the input Eric!
^ permalink raw reply
* Re: [PATCH 1/4] bonding: L2DA mode added
From: Eric Dumazet @ 2013-11-21 15:32 UTC (permalink / raw)
To: Anton Nayshtut
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David S. Miller,
Cong Wang, Nicolas Schichan, Eric Dumazet, linux-kernel, netdev,
Erez Kirshenbaum, Boris Lapshin
In-Reply-To: <1385045738-29726-2-git-send-email-Anton.Nayshtut@wilocity.com>
On Thu, 2013-11-21 at 16:55 +0200, Anton Nayshtut wrote:
> This patches introduces L2DA bonding module with all the data structures and
> interfaces. It's not integrated yet.
I veto any kind of new bonding mode not using RCU.
Adding another rwlock in 2013 is simply not an option.
Thanks
^ permalink raw reply
* Re: Question about IPv6 neighbor discovery and 6lowpan
From: Alexander Aring @ 2013-11-21 15:34 UTC (permalink / raw)
To: Jukka Rissanen; +Cc: David Miller, netdev
In-Reply-To: <1385046178.2723.17.camel@jrissane-mobl.ger.corp.intel.com>
Hi Jukka,
On Thu, Nov 21, 2013 at 05:02:58PM +0200, Jukka Rissanen wrote:
> Hi,
>
> I am investigating RFC 6775 (Neighbor Discovery Optimization for IPv6
> over Low-Power Wireless Personal Area Networks (6LoWPANs))
> http://tools.ietf.org/html/rfc6775
>
> The RFC suggests some changes to neighbor discovery procedure for the
> 6LoWPAN networks. I was looking net/ipv6/ndisc.c and it seems that
> ARPHRD type (from type field in net_device struct) is the only way to
> detect and change the discovery procedure in the ndisc.c code. Am I
> right with this assumption here?
>
I think you are right, there was some patches on linux-zigbee-devel who
use exact the same idea to check the ARPHRD type.
But I am investigating for rfc6775, too. :-)
At the moment I see too many unsolved issues in the ieee802154/6lowpan
implementation which should be fixed at first. :(
- Alex
^ permalink raw reply
* Re: [PATCH 1/4] bonding: L2DA mode added
From: Nikolay Aleksandrov @ 2013-11-21 15:37 UTC (permalink / raw)
To: Eric Dumazet, Anton Nayshtut
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David S. Miller,
Cong Wang, Nicolas Schichan, Eric Dumazet, linux-kernel, netdev,
Erez Kirshenbaum, Boris Lapshin
In-Reply-To: <1385047978.10637.51.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/21/2013 04:32 PM, Eric Dumazet wrote:
> On Thu, 2013-11-21 at 16:55 +0200, Anton Nayshtut wrote:
>> This patches introduces L2DA bonding module with all the data structures and
>> interfaces. It's not integrated yet.
>
> I veto any kind of new bonding mode not using RCU.
>
> Adding another rwlock in 2013 is simply not an option.
>
> Thanks
>
>
+1
Also,
I haven't read the patch-set closely but based on the description in the first
patch I think you can already get this (or very similar) functionality by using
the slave override option in the bonding. You can match the destination L2
address and override the slave based on that.
Nik
^ permalink raw reply
* pull request: wireless 2013-11-21
From: John W. Linville @ 2013-11-21 15:41 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 25651 bytes --]
Dave,
Please pull this batch of fixes intended for the 3.13 stream!
For the Bluetooth bits, Gustavo says:
"A few fixes for 3.13. There is 3 fixes to the RFCOMM protocol. One
crash fix to L2CAP. A simple fix to a bad behaviour in the SMP
protocol."
On top of that...
Amitkumar Karwar sends a quintet of mwifiex fixes -- two fixes related
to failure handling, two memory leak fixes, and a NULL pointer fix.
Felix Fietkau corrects and earlier rt2x00 HT descriptor handling fix
to address a crash.
Geyslan G. Bem fixes a memory leak in brcmfmac.
Larry Finger address more pointer arithmetic errors in rtlwifi.
Luis R. Rodriguez provides a regulatory fix in the shared ath code.
Sujith Manoharan brings a couple ath9k initialization fixes.
Ujjal Roy offers one more mwifiex fix to avoid invalid memory accesses
when unloading the USB driver.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 68c6beb373955da0886d8f4f5995b3922ceda4be:
net: add BUG_ON if kernel advertises msg_namelen > sizeof(struct sockaddr_storage) (2013-11-20 21:52:30 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to 7acd71879ce408af2d2ca3cd3ec3a86d0667ceae:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-11-21 10:26:17 -0500)
----------------------------------------------------------------
Amitkumar Karwar (5):
mwifiex: use return value of mwifiex_add_virtual_intf() correctly
mwifiex: failure path handling in mwifiex_add_virtual_intf()
mwifiex: fix NULL pointer dereference in mwifiex_fw_dpc
mwifiex: fix potential mem leak in .del_virtual_intf
mwifiex: fix memory leak issue for sdio and pcie cards
Felix Fietkau (1):
rt2x00: fix a crash bug in the HT descriptor handling fix
Geyslan G. Bem (1):
brcmfmac: fix possible memory leak
Johan Hedberg (1):
Bluetooth: Fix rejecting SMP security request in slave role
John W. Linville (2):
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Larry Finger (1):
rtlwifi: rtl8192cu: Fix more pointer arithmetic errors
Luis R. Rodriguez (1):
ath: fix dynamic user regulatory settings
Marcel Holtmann (1):
Bluetooth: Fix issue with RFCOMM getsockopt operation
Seung-Woo Kim (3):
Bluetooth: Fix RFCOMM bind fail for L2CAP sock
Bluetooth: Fix to set proper bdaddr_type for RFCOMM connect
Bluetooth: Fix crash in l2cap_chan_send after l2cap_chan_del
Sujith Manoharan (2):
ath9k: Update AR9462 2.1 initvals
ath9k: Fix issue with MCS15
Ujjal Roy (1):
mwifiex: fix issues in driver unload path for USB chipsets
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 50 ++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 11 +++++
.../net/wireless/ath/ath9k/ar9462_2p1_initvals.h | 6 +--
drivers/net/wireless/ath/regd.c | 3 +-
drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 1 +
drivers/net/wireless/mwifiex/cfg80211.c | 23 ++++++++--
drivers/net/wireless/mwifiex/main.c | 28 +++---------
drivers/net/wireless/mwifiex/pcie.c | 2 +-
drivers/net/wireless/mwifiex/sdio.c | 7 +--
drivers/net/wireless/mwifiex/usb.c | 27 ++++++------
drivers/net/wireless/rt2x00/rt2x00dev.c | 3 +-
drivers/net/wireless/rtlwifi/rtl8192cu/mac.c | 6 +--
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 6 +--
net/bluetooth/l2cap_core.c | 3 ++
net/bluetooth/rfcomm/core.c | 3 ++
net/bluetooth/rfcomm/sock.c | 6 ++-
net/bluetooth/smp.c | 3 ++
17 files changed, 135 insertions(+), 53 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 11f53589a3f3..d39b79f5e841 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -701,6 +701,54 @@ static int ar9550_hw_get_modes_txgain_index(struct ath_hw *ah,
return ret;
}
+static void ar9003_doubler_fix(struct ath_hw *ah)
+{
+ if (AR_SREV_9300(ah) || AR_SREV_9580(ah) || AR_SREV_9550(ah)) {
+ REG_RMW(ah, AR_PHY_65NM_CH0_RXTX2,
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK_S |
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHOVR_MASK_S, 0);
+ REG_RMW(ah, AR_PHY_65NM_CH1_RXTX2,
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK_S |
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHOVR_MASK_S, 0);
+ REG_RMW(ah, AR_PHY_65NM_CH2_RXTX2,
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK_S |
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHOVR_MASK_S, 0);
+
+ udelay(200);
+
+ REG_CLR_BIT(ah, AR_PHY_65NM_CH0_RXTX2,
+ AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK);
+ REG_CLR_BIT(ah, AR_PHY_65NM_CH1_RXTX2,
+ AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK);
+ REG_CLR_BIT(ah, AR_PHY_65NM_CH2_RXTX2,
+ AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK);
+
+ udelay(1);
+
+ REG_RMW_FIELD(ah, AR_PHY_65NM_CH0_RXTX2,
+ AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK, 1);
+ REG_RMW_FIELD(ah, AR_PHY_65NM_CH1_RXTX2,
+ AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK, 1);
+ REG_RMW_FIELD(ah, AR_PHY_65NM_CH2_RXTX2,
+ AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK, 1);
+
+ udelay(200);
+
+ REG_RMW_FIELD(ah, AR_PHY_65NM_CH0_SYNTH12,
+ AR_PHY_65NM_CH0_SYNTH12_VREFMUL3, 0xf);
+
+ REG_RMW(ah, AR_PHY_65NM_CH0_RXTX2, 0,
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK_S |
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHOVR_MASK_S);
+ REG_RMW(ah, AR_PHY_65NM_CH1_RXTX2, 0,
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK_S |
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHOVR_MASK_S);
+ REG_RMW(ah, AR_PHY_65NM_CH2_RXTX2, 0,
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK_S |
+ 1 << AR_PHY_65NM_CH0_RXTX2_SYNTHOVR_MASK_S);
+ }
+}
+
static int ar9003_hw_process_ini(struct ath_hw *ah,
struct ath9k_channel *chan)
{
@@ -726,6 +774,8 @@ static int ar9003_hw_process_ini(struct ath_hw *ah,
modesIndex);
}
+ ar9003_doubler_fix(ah);
+
/*
* RXGAIN initvals.
*/
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.h b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
index fca624322dc8..2af667beb273 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
@@ -656,13 +656,24 @@
#define AR_PHY_SYNTH4_LONG_SHIFT_SELECT ((AR_SREV_9462(ah) || AR_SREV_9565(ah)) ? 0x00000001 : 0x00000002)
#define AR_PHY_SYNTH4_LONG_SHIFT_SELECT_S ((AR_SREV_9462(ah) || AR_SREV_9565(ah)) ? 0 : 1)
#define AR_PHY_65NM_CH0_SYNTH7 0x16098
+#define AR_PHY_65NM_CH0_SYNTH12 0x160ac
#define AR_PHY_65NM_CH0_BIAS1 0x160c0
#define AR_PHY_65NM_CH0_BIAS2 0x160c4
#define AR_PHY_65NM_CH0_BIAS4 0x160cc
+#define AR_PHY_65NM_CH0_RXTX2 0x16104
+#define AR_PHY_65NM_CH1_RXTX2 0x16504
+#define AR_PHY_65NM_CH2_RXTX2 0x16904
#define AR_PHY_65NM_CH0_RXTX4 0x1610c
#define AR_PHY_65NM_CH1_RXTX4 0x1650c
#define AR_PHY_65NM_CH2_RXTX4 0x1690c
+#define AR_PHY_65NM_CH0_SYNTH12_VREFMUL3 0x00780000
+#define AR_PHY_65NM_CH0_SYNTH12_VREFMUL3_S 19
+#define AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK 0x00000004
+#define AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK_S 2
+#define AR_PHY_65NM_CH0_RXTX2_SYNTHOVR_MASK 0x00000008
+#define AR_PHY_65NM_CH0_RXTX2_SYNTHOVR_MASK_S 3
+
#define AR_CH0_TOP (AR_SREV_9300(ah) ? 0x16288 : \
(((AR_SREV_9462(ah) || AR_SREV_9565(ah)) ? 0x1628c : 0x16280)))
#define AR_CH0_TOP_XPABIASLVL (AR_SREV_9550(ah) ? 0x3c0 : 0x300)
diff --git a/drivers/net/wireless/ath/ath9k/ar9462_2p1_initvals.h b/drivers/net/wireless/ath/ath9k/ar9462_2p1_initvals.h
index 4dbc294df7e3..57fc5f459d0a 100644
--- a/drivers/net/wireless/ath/ath9k/ar9462_2p1_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar9462_2p1_initvals.h
@@ -361,7 +361,7 @@ static const u32 ar9462_2p1_baseband_postamble[][5] = {
{0x00009e14, 0x37b95d5e, 0x37b9605e, 0x3236605e, 0x32365a5e},
{0x00009e18, 0x00000000, 0x00000000, 0x00000000, 0x00000000},
{0x00009e1c, 0x0001cf9c, 0x0001cf9c, 0x00021f9c, 0x00021f9c},
- {0x00009e20, 0x000003b5, 0x000003b5, 0x000003ce, 0x000003ce},
+ {0x00009e20, 0x000003a5, 0x000003a5, 0x000003a5, 0x000003a5},
{0x00009e2c, 0x0000001c, 0x0000001c, 0x00000021, 0x00000021},
{0x00009e3c, 0xcf946220, 0xcf946220, 0xcfd5c782, 0xcfd5c282},
{0x00009e44, 0x62321e27, 0x62321e27, 0xfe291e27, 0xfe291e27},
@@ -400,7 +400,7 @@ static const u32 ar9462_2p1_baseband_postamble[][5] = {
{0x0000ae04, 0x001c0000, 0x001c0000, 0x001c0000, 0x00100000},
{0x0000ae18, 0x00000000, 0x00000000, 0x00000000, 0x00000000},
{0x0000ae1c, 0x0000019c, 0x0000019c, 0x0000019c, 0x0000019c},
- {0x0000ae20, 0x000001b5, 0x000001b5, 0x000001ce, 0x000001ce},
+ {0x0000ae20, 0x000001a6, 0x000001a6, 0x000001aa, 0x000001aa},
{0x0000b284, 0x00000000, 0x00000000, 0x00000550, 0x00000550},
};
@@ -472,7 +472,7 @@ static const u32 ar9462_2p1_radio_postamble[][5] = {
static const u32 ar9462_2p1_soc_preamble[][2] = {
/* Addr allmodes */
- {0x000040a4, 0x00a0c1c9},
+ {0x000040a4, 0x00a0c9c9},
{0x00007020, 0x00000000},
{0x00007034, 0x00000002},
{0x00007038, 0x000004c2},
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index c00687e05688..1217c52ab28e 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -362,7 +362,8 @@ static int __ath_reg_dyn_country(struct wiphy *wiphy,
{
u16 country_code;
- if (!ath_is_world_regd(reg))
+ if (request->initiator == NL80211_REGDOM_SET_BY_COUNTRY_IE &&
+ !ath_is_world_regd(reg))
return -EINVAL;
country_code = ath_regd_find_country_by_name(request->alpha2);
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/p2p.c b/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
index 5b5b952d47b1..4a2293041821 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
@@ -823,6 +823,7 @@ static s32 brcmf_p2p_run_escan(struct brcmf_cfg80211_info *cfg,
}
err = brcmf_p2p_escan(p2p, num_nodfs, chanspecs, search_state,
action, P2PAPI_BSSCFG_DEVICE);
+ kfree(chanspecs);
}
exit:
if (err)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c
index fbad00a5abc8..aeaea0e3b4c4 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -2210,8 +2210,10 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
priv->bss_started = 0;
priv->bss_num = 0;
- if (mwifiex_cfg80211_init_p2p_client(priv))
- return ERR_PTR(-EFAULT);
+ if (mwifiex_cfg80211_init_p2p_client(priv)) {
+ wdev = ERR_PTR(-EFAULT);
+ goto done;
+ }
break;
default:
@@ -2224,7 +2226,8 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
if (!dev) {
wiphy_err(wiphy, "no memory available for netdevice\n");
priv->bss_mode = NL80211_IFTYPE_UNSPECIFIED;
- return ERR_PTR(-ENOMEM);
+ wdev = ERR_PTR(-ENOMEM);
+ goto done;
}
mwifiex_init_priv_params(priv, dev);
@@ -2264,7 +2267,9 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
wiphy_err(wiphy, "cannot register virtual network device\n");
free_netdev(dev);
priv->bss_mode = NL80211_IFTYPE_UNSPECIFIED;
- return ERR_PTR(-EFAULT);
+ priv->netdev = NULL;
+ wdev = ERR_PTR(-EFAULT);
+ goto done;
}
sema_init(&priv->async_sem, 1);
@@ -2274,6 +2279,13 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
#ifdef CONFIG_DEBUG_FS
mwifiex_dev_debugfs_init(priv);
#endif
+
+done:
+ if (IS_ERR(wdev)) {
+ kfree(priv->wdev);
+ priv->wdev = NULL;
+ }
+
return wdev;
}
EXPORT_SYMBOL_GPL(mwifiex_add_virtual_intf);
@@ -2298,7 +2310,10 @@ int mwifiex_del_virtual_intf(struct wiphy *wiphy, struct wireless_dev *wdev)
unregister_netdevice(wdev->netdev);
/* Clear the priv in adapter */
+ priv->netdev->ieee80211_ptr = NULL;
priv->netdev = NULL;
+ kfree(wdev);
+ priv->wdev = NULL;
priv->media_connected = false;
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index 9d7c9d354d34..78e8a6666cc6 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -411,13 +411,14 @@ static void mwifiex_terminate_workqueue(struct mwifiex_adapter *adapter)
*/
static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
{
- int ret, i;
+ int ret;
char fmt[64];
struct mwifiex_private *priv;
struct mwifiex_adapter *adapter = context;
struct mwifiex_fw_image fw;
struct semaphore *sem = adapter->card_sem;
bool init_failed = false;
+ struct wireless_dev *wdev;
if (!firmware) {
dev_err(adapter->dev,
@@ -469,14 +470,16 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
priv = adapter->priv[MWIFIEX_BSS_ROLE_STA];
if (mwifiex_register_cfg80211(adapter)) {
dev_err(adapter->dev, "cannot register with cfg80211\n");
- goto err_register_cfg80211;
+ goto err_init_fw;
}
rtnl_lock();
/* Create station interface by default */
- if (!mwifiex_add_virtual_intf(adapter->wiphy, "mlan%d",
- NL80211_IFTYPE_STATION, NULL, NULL)) {
+ wdev = mwifiex_add_virtual_intf(adapter->wiphy, "mlan%d",
+ NL80211_IFTYPE_STATION, NULL, NULL);
+ if (IS_ERR(wdev)) {
dev_err(adapter->dev, "cannot create default STA interface\n");
+ rtnl_unlock();
goto err_add_intf;
}
rtnl_unlock();
@@ -486,17 +489,6 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
goto done;
err_add_intf:
- for (i = 0; i < adapter->priv_num; i++) {
- priv = adapter->priv[i];
-
- if (!priv)
- continue;
-
- if (priv->wdev && priv->netdev)
- mwifiex_del_virtual_intf(adapter->wiphy, priv->wdev);
- }
- rtnl_unlock();
-err_register_cfg80211:
wiphy_unregister(adapter->wiphy);
wiphy_free(adapter->wiphy);
err_init_fw:
@@ -1006,12 +998,6 @@ int mwifiex_remove_card(struct mwifiex_adapter *adapter, struct semaphore *sem)
wiphy_unregister(priv->wdev->wiphy);
wiphy_free(priv->wdev->wiphy);
- for (i = 0; i < adapter->priv_num; i++) {
- priv = adapter->priv[i];
- if (priv)
- kfree(priv->wdev);
- }
-
mwifiex_terminate_workqueue(adapter);
/* Unregister device */
diff --git a/drivers/net/wireless/mwifiex/pcie.c b/drivers/net/wireless/mwifiex/pcie.c
index 33fa9432b241..03688aa14e8a 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -232,7 +232,6 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
}
mwifiex_remove_card(card->adapter, &add_remove_card_sem);
- kfree(card);
}
static void mwifiex_pcie_shutdown(struct pci_dev *pdev)
@@ -2313,6 +2312,7 @@ static void mwifiex_pcie_cleanup(struct mwifiex_adapter *adapter)
pci_release_region(pdev, 0);
pci_set_drvdata(pdev, NULL);
}
+ kfree(card);
}
/*
diff --git a/drivers/net/wireless/mwifiex/sdio.c b/drivers/net/wireless/mwifiex/sdio.c
index 9bf8898743ab..b44a31523461 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -196,7 +196,6 @@ mwifiex_sdio_remove(struct sdio_func *func)
}
mwifiex_remove_card(card->adapter, &add_remove_card_sem);
- kfree(card);
}
/*
@@ -1745,7 +1744,6 @@ mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
sdio_claim_host(card->func);
sdio_disable_func(card->func);
sdio_release_host(card->func);
- sdio_set_drvdata(card->func, NULL);
}
}
@@ -1773,7 +1771,6 @@ static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
return ret;
}
- sdio_set_drvdata(func, card);
adapter->dev = &func->dev;
@@ -1801,6 +1798,8 @@ static int mwifiex_init_sdio(struct mwifiex_adapter *adapter)
int ret;
u8 sdio_ireg;
+ sdio_set_drvdata(card->func, card);
+
/*
* Read the HOST_INT_STATUS_REG for ACK the first interrupt got
* from the bootloader. If we don't do this we get a interrupt
@@ -1883,6 +1882,8 @@ static void mwifiex_cleanup_sdio(struct mwifiex_adapter *adapter)
kfree(card->mpa_rx.len_arr);
kfree(card->mpa_tx.buf);
kfree(card->mpa_rx.buf);
+ sdio_set_drvdata(card->func, NULL);
+ kfree(card);
}
/*
diff --git a/drivers/net/wireless/mwifiex/usb.c b/drivers/net/wireless/mwifiex/usb.c
index 1c70b8d09227..edf5b7a24900 100644
--- a/drivers/net/wireless/mwifiex/usb.c
+++ b/drivers/net/wireless/mwifiex/usb.c
@@ -350,7 +350,6 @@ static int mwifiex_usb_probe(struct usb_interface *intf,
card->udev = udev;
card->intf = intf;
- usb_card = card;
pr_debug("info: bcdUSB=%#x Device Class=%#x SubClass=%#x Protocol=%#x\n",
udev->descriptor.bcdUSB, udev->descriptor.bDeviceClass,
@@ -525,25 +524,28 @@ static int mwifiex_usb_resume(struct usb_interface *intf)
static void mwifiex_usb_disconnect(struct usb_interface *intf)
{
struct usb_card_rec *card = usb_get_intfdata(intf);
- struct mwifiex_adapter *adapter;
- if (!card || !card->adapter) {
- pr_err("%s: card or card->adapter is NULL\n", __func__);
+ if (!card) {
+ pr_err("%s: card is NULL\n", __func__);
return;
}
- adapter = card->adapter;
- if (!adapter->priv_num)
- return;
-
mwifiex_usb_free(card);
- dev_dbg(adapter->dev, "%s: removing card\n", __func__);
- mwifiex_remove_card(adapter, &add_remove_card_sem);
+ if (card->adapter) {
+ struct mwifiex_adapter *adapter = card->adapter;
+
+ if (!adapter->priv_num)
+ return;
+
+ dev_dbg(adapter->dev, "%s: removing card\n", __func__);
+ mwifiex_remove_card(adapter, &add_remove_card_sem);
+ }
usb_set_intfdata(intf, NULL);
usb_put_dev(interface_to_usbdev(intf));
kfree(card);
+ usb_card = NULL;
return;
}
@@ -754,6 +756,7 @@ static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
card->adapter = adapter;
adapter->dev = &card->udev->dev;
strcpy(adapter->fw_name, USB8797_DEFAULT_FW_NAME);
+ usb_card = card;
return 0;
}
@@ -762,7 +765,7 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
{
struct usb_card_rec *card = (struct usb_card_rec *)adapter->card;
- usb_set_intfdata(card->intf, NULL);
+ card->adapter = NULL;
}
static int mwifiex_prog_fw_w_helper(struct mwifiex_adapter *adapter,
@@ -1004,7 +1007,7 @@ static void mwifiex_usb_cleanup_module(void)
if (!down_interruptible(&add_remove_card_sem))
up(&add_remove_card_sem);
- if (usb_card) {
+ if (usb_card && usb_card->adapter) {
struct mwifiex_adapter *adapter = usb_card->adapter;
int i;
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 080b1fcae5fa..9dd92a700442 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -181,6 +181,7 @@ static void rt2x00lib_autowakeup(struct work_struct *work)
static void rt2x00lib_bc_buffer_iter(void *data, u8 *mac,
struct ieee80211_vif *vif)
{
+ struct ieee80211_tx_control control = {};
struct rt2x00_dev *rt2x00dev = data;
struct sk_buff *skb;
@@ -195,7 +196,7 @@ static void rt2x00lib_bc_buffer_iter(void *data, u8 *mac,
*/
skb = ieee80211_get_buffered_bc(rt2x00dev->hw, vif);
while (skb) {
- rt2x00mac_tx(rt2x00dev->hw, NULL, skb);
+ rt2x00mac_tx(rt2x00dev->hw, &control, skb);
skb = ieee80211_get_buffered_bc(rt2x00dev->hw, vif);
}
}
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c b/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c
index 393685390f3e..e26312fb4356 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c
@@ -769,7 +769,7 @@ static long _rtl92c_signal_scale_mapping(struct ieee80211_hw *hw,
static void _rtl92c_query_rxphystatus(struct ieee80211_hw *hw,
struct rtl_stats *pstats,
- struct rx_desc_92c *pdesc,
+ struct rx_desc_92c *p_desc,
struct rx_fwinfo_92c *p_drvinfo,
bool packet_match_bssid,
bool packet_toself,
@@ -784,11 +784,11 @@ static void _rtl92c_query_rxphystatus(struct ieee80211_hw *hw,
u32 rssi, total_rssi = 0;
bool in_powersavemode = false;
bool is_cck_rate;
+ u8 *pdesc = (u8 *)p_desc;
- is_cck_rate = RX_HAL_IS_CCK_RATE(pdesc);
+ is_cck_rate = RX_HAL_IS_CCK_RATE(p_desc);
pstats->packet_matchbssid = packet_match_bssid;
pstats->packet_toself = packet_toself;
- pstats->is_cck = is_cck_rate;
pstats->packet_beacon = packet_beacon;
pstats->is_cck = is_cck_rate;
pstats->RX_SIGQ[0] = -1;
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
index b0c346a9e4b8..1bc21ccfa71b 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
@@ -303,10 +303,10 @@ out:
bool rtl92cu_rx_query_desc(struct ieee80211_hw *hw,
struct rtl_stats *stats,
struct ieee80211_rx_status *rx_status,
- u8 *p_desc, struct sk_buff *skb)
+ u8 *pdesc, struct sk_buff *skb)
{
struct rx_fwinfo_92c *p_drvinfo;
- struct rx_desc_92c *pdesc = (struct rx_desc_92c *)p_desc;
+ struct rx_desc_92c *p_desc = (struct rx_desc_92c *)pdesc;
u32 phystatus = GET_RX_DESC_PHY_STATUS(pdesc);
stats->length = (u16) GET_RX_DESC_PKT_LEN(pdesc);
@@ -345,7 +345,7 @@ bool rtl92cu_rx_query_desc(struct ieee80211_hw *hw,
if (phystatus) {
p_drvinfo = (struct rx_fwinfo_92c *)(skb->data +
stats->rx_bufshift);
- rtl92c_translate_rx_signal_stuff(hw, skb, stats, pdesc,
+ rtl92c_translate_rx_signal_stuff(hw, skb, stats, p_desc,
p_drvinfo);
}
/*rx_status->qual = stats->signal; */
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 0cef67707838..4af3821df880 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -2439,6 +2439,9 @@ int l2cap_chan_send(struct l2cap_chan *chan, struct msghdr *msg, size_t len,
int err;
struct sk_buff_head seg_queue;
+ if (!chan->conn)
+ return -ENOTCONN;
+
/* Connectionless channel */
if (chan->chan_type == L2CAP_CHAN_CONN_LESS) {
skb = l2cap_create_connless_pdu(chan, msg, len, priority);
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 94d06cbfbc18..facd8a79c038 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -694,6 +694,7 @@ static struct rfcomm_session *rfcomm_session_create(bdaddr_t *src,
addr.l2_family = AF_BLUETOOTH;
addr.l2_psm = 0;
addr.l2_cid = 0;
+ addr.l2_bdaddr_type = BDADDR_BREDR;
*err = kernel_bind(sock, (struct sockaddr *) &addr, sizeof(addr));
if (*err < 0)
goto failed;
@@ -719,6 +720,7 @@ static struct rfcomm_session *rfcomm_session_create(bdaddr_t *src,
addr.l2_family = AF_BLUETOOTH;
addr.l2_psm = __constant_cpu_to_le16(RFCOMM_PSM);
addr.l2_cid = 0;
+ addr.l2_bdaddr_type = BDADDR_BREDR;
*err = kernel_connect(sock, (struct sockaddr *) &addr, sizeof(addr), O_NONBLOCK);
if (*err == 0 || *err == -EINPROGRESS)
return s;
@@ -1983,6 +1985,7 @@ static int rfcomm_add_listener(bdaddr_t *ba)
addr.l2_family = AF_BLUETOOTH;
addr.l2_psm = __constant_cpu_to_le16(RFCOMM_PSM);
addr.l2_cid = 0;
+ addr.l2_bdaddr_type = BDADDR_BREDR;
err = kernel_bind(sock, (struct sockaddr *) &addr, sizeof(addr));
if (err < 0) {
BT_ERR("Bind failed %d", err);
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index c80766f892c3..3c2d3e4aa2f5 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -738,8 +738,9 @@ static int rfcomm_sock_setsockopt(struct socket *sock, int level, int optname, c
static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
{
struct sock *sk = sock->sk;
+ struct sock *l2cap_sk;
+ struct l2cap_conn *conn;
struct rfcomm_conninfo cinfo;
- struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
int len, err = 0;
u32 opt;
@@ -782,6 +783,9 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
break;
}
+ l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
+ conn = l2cap_pi(l2cap_sk)->chan->conn;
+
memset(&cinfo, 0, sizeof(cinfo));
cinfo.hci_handle = conn->hcon->handle;
memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 85a2796cac61..4b07acb8293c 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -742,6 +742,9 @@ static u8 smp_cmd_security_req(struct l2cap_conn *conn, struct sk_buff *skb)
BT_DBG("conn %p", conn);
+ if (!(conn->hcon->link_mode & HCI_LM_MASTER))
+ return SMP_CMD_NOTSUPP;
+
hcon->pending_sec_level = authreq_to_seclevel(rp->auth_req);
if (smp_ltk_encrypt(conn, hcon->pending_sec_level))
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: kernel BUG at net/core/skbuff.c:2839 RIP [<ffffffff819109a2>] skb_segment+0x6b2/0x6d0
From: Sander Eikelenboom @ 2013-11-21 15:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Francois Romieu, netdev, David S. Miller
In-Reply-To: <1385043004.10637.34.camel@edumazet-glaptop2.roam.corp.google.com>
Thursday, November 21, 2013, 3:10:04 PM, you wrote:
> On Thu, 2013-11-21 at 13:00 +0100, Sander Eikelenboom wrote:
>> Hello Sander,
>>
>> Sunday, November 17, 2013, 8:17:44 PM, you wrote:
>>
>> > Hi Eric,
>>
>> > With the linux-net changes from this merge window i get the kernel panic below (not with 3.12.0).
>>
>> > It's on a machine running Xen, 2x rtl8169 nic, and using a bridge for guest networking.
>> > This panic in the host kernel only seems to occur when generating a lot of network traffic to and from a guest.
>>
>> > I tried reverting "tcp: gso: fix truesize tracking" 0d08c42cf9a71530fef5ebcfe368f38f2dd0476f, but that didn't help.
>> Hi Eric and Francois,
>>
>> I have tested some more:
>>
>> First tried with switching off GSO and GRO on the bridge, this didn't help.
>> Then i only switched off GRO on eth0 (r8169) and left the bridge alone. That helped to prevent the oops.
>>
>> Below the output of ethtool -k for the bridge and eth0 after boot (so the default situation) with which the oops occurs.
>> And the part of dmesg where the r8169 get initialized on boot (there are 2, eth0 and eth1).
> As mentioned earlier, this problem is known and a patch is under review.
> http://marc.info/?l=linux-netdev&m=138419594024851&w=2
> Thanks
Ok seems to work for me!
Thx,
Sander
^ permalink raw reply
* Re: [PATCHv1 net] xen-netback: stop the VIF thread before unbinding IRQs
From: Wei Liu @ 2013-11-21 15:50 UTC (permalink / raw)
To: David Vrabel
Cc: xen-devel, Konrad Rzeszutek Wilk, Boris Ostrovsky, Ian Campbell,
Wei Liu, netdev
In-Reply-To: <1385047569-23622-1-git-send-email-david.vrabel@citrix.com>
On Thu, Nov 21, 2013 at 03:26:09PM +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> If the VIF thread is still running after unbinding the Tx and Rx IRQs
> in xenvif_disconnect(), the thread may attempt to raise an event which
> will BUG (as the irq is unbound).
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Thanks
Wei.
> ---
> drivers/net/xen-netback/interface.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index b78ee10..2329ccc 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -461,6 +461,9 @@ void xenvif_disconnect(struct xenvif *vif)
> if (netif_carrier_ok(vif->dev))
> xenvif_carrier_off(vif);
>
> + if (vif->task)
> + kthread_stop(vif->task);
> +
> if (vif->tx_irq) {
> if (vif->tx_irq == vif->rx_irq)
> unbind_from_irqhandler(vif->tx_irq, vif);
> @@ -471,9 +474,6 @@ void xenvif_disconnect(struct xenvif *vif)
> vif->tx_irq = 0;
> }
>
> - if (vif->task)
> - kthread_stop(vif->task);
> -
> xenvif_unmap_frontend_rings(vif);
> }
>
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* [PATCH v3] packet: fix use after free race in send path when dev is released
From: Daniel Borkmann @ 2013-11-21 15:50 UTC (permalink / raw)
To: davem; +Cc: netdev, Salam Noureddine, Ben Greear, Eric Dumazet
Salam reported a use after free bug in PF_PACKET that occurs when
we're sending out frames on a socket bound device and suddenly the
net device is being unregistered. It appears that commit 827d9780
introduced a possible race condition between {t,}packet_snd() and
packet_notifier(). In the case of a bound socket, packet_notifier()
can drop the last reference to the net_device and {t,}packet_snd()
might end up suddenly sending a packet over a freed net_device.
To avoid reverting 827d9780 and thus introducing a performance
regression compared to the current state of things, we decided to
hold a cached RCU protected pointer to the net device and maintain
it on write side via bind spin_lock protected register_prot_hook()
and __unregister_prot_hook() calls.
In {t,}packet_snd() path, we access this pointer under rcu_read_lock
through packet_cached_dev_get() that holds reference to the device
to prevent it from being freed through packet_notifier() while
we're in send path. This is okay to do as dev_put()/dev_hold() are
per-cpu counters, so this should not be a performance issue. Also,
the code simplifies a bit as we don't need need_rls_dev anymore.
Fixes: 827d978037d7 ("af-packet: Use existing netdev reference for bound sockets.")
Reported-by: Salam Noureddine <noureddine@aristanetworks.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Salam Noureddine <noureddine@aristanetworks.com>
Cc: Ben Greear <greearb@candelatech.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
---
v1->v2:
- Applied feedback from Dave and Eric, thanks a lot for this!
v2->v3:
- As Eric points out, we're on the safe side w/o call_rcu() deferral,
so remove it, rest stays the same.
net/packet/af_packet.c | 59 ++++++++++++++++++++++++++++++--------------------
net/packet/internal.h | 1 +
2 files changed, 37 insertions(+), 23 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2e8286b..4204846 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -244,11 +244,15 @@ static void __fanout_link(struct sock *sk, struct packet_sock *po);
static void register_prot_hook(struct sock *sk)
{
struct packet_sock *po = pkt_sk(sk);
+
if (!po->running) {
- if (po->fanout)
+ if (po->fanout) {
__fanout_link(sk, po);
- else
+ } else {
dev_add_pack(&po->prot_hook);
+ rcu_assign_pointer(po->cached_dev, po->prot_hook.dev);
+ }
+
sock_hold(sk);
po->running = 1;
}
@@ -266,10 +270,13 @@ static void __unregister_prot_hook(struct sock *sk, bool sync)
struct packet_sock *po = pkt_sk(sk);
po->running = 0;
- if (po->fanout)
+ if (po->fanout) {
__fanout_unlink(sk, po);
- else
+ } else {
__dev_remove_pack(&po->prot_hook);
+ RCU_INIT_POINTER(po->cached_dev, NULL);
+ }
+
__sock_put(sk);
if (sync) {
@@ -2052,12 +2059,24 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
return tp_len;
}
+static struct net_device *packet_cached_dev_get(struct packet_sock *po)
+{
+ struct net_device *dev;
+
+ rcu_read_lock();
+ dev = rcu_dereference(po->cached_dev);
+ if (dev)
+ dev_hold(dev);
+ rcu_read_unlock();
+
+ return dev;
+}
+
static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
{
struct sk_buff *skb;
struct net_device *dev;
__be16 proto;
- bool need_rls_dev = false;
int err, reserve = 0;
void *ph;
struct sockaddr_ll *saddr = (struct sockaddr_ll *)msg->msg_name;
@@ -2070,7 +2089,7 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
mutex_lock(&po->pg_vec_lock);
if (saddr == NULL) {
- dev = po->prot_hook.dev;
+ dev = packet_cached_dev_get(po);
proto = po->num;
addr = NULL;
} else {
@@ -2084,19 +2103,17 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
proto = saddr->sll_protocol;
addr = saddr->sll_addr;
dev = dev_get_by_index(sock_net(&po->sk), saddr->sll_ifindex);
- need_rls_dev = true;
}
err = -ENXIO;
if (unlikely(dev == NULL))
goto out;
-
- reserve = dev->hard_header_len;
-
err = -ENETDOWN;
if (unlikely(!(dev->flags & IFF_UP)))
goto out_put;
+ reserve = dev->hard_header_len;
+
size_max = po->tx_ring.frame_size
- (po->tp_hdrlen - sizeof(struct sockaddr_ll));
@@ -2173,8 +2190,7 @@ out_status:
__packet_set_status(po, ph, status);
kfree_skb(skb);
out_put:
- if (need_rls_dev)
- dev_put(dev);
+ dev_put(dev);
out:
mutex_unlock(&po->pg_vec_lock);
return err;
@@ -2212,7 +2228,6 @@ static int packet_snd(struct socket *sock,
struct sk_buff *skb;
struct net_device *dev;
__be16 proto;
- bool need_rls_dev = false;
unsigned char *addr;
int err, reserve = 0;
struct virtio_net_hdr vnet_hdr = { 0 };
@@ -2228,7 +2243,7 @@ static int packet_snd(struct socket *sock,
*/
if (saddr == NULL) {
- dev = po->prot_hook.dev;
+ dev = packet_cached_dev_get(po);
proto = po->num;
addr = NULL;
} else {
@@ -2240,19 +2255,17 @@ static int packet_snd(struct socket *sock,
proto = saddr->sll_protocol;
addr = saddr->sll_addr;
dev = dev_get_by_index(sock_net(sk), saddr->sll_ifindex);
- need_rls_dev = true;
}
err = -ENXIO;
- if (dev == NULL)
+ if (unlikely(dev == NULL))
goto out_unlock;
- if (sock->type == SOCK_RAW)
- reserve = dev->hard_header_len;
-
err = -ENETDOWN;
- if (!(dev->flags & IFF_UP))
+ if (unlikely(!(dev->flags & IFF_UP)))
goto out_unlock;
+ if (sock->type == SOCK_RAW)
+ reserve = dev->hard_header_len;
if (po->has_vnet_hdr) {
vnet_hdr_len = sizeof(vnet_hdr);
@@ -2386,15 +2399,14 @@ static int packet_snd(struct socket *sock,
if (err > 0 && (err = net_xmit_errno(err)) != 0)
goto out_unlock;
- if (need_rls_dev)
- dev_put(dev);
+ dev_put(dev);
return len;
out_free:
kfree_skb(skb);
out_unlock:
- if (dev && need_rls_dev)
+ if (dev)
dev_put(dev);
out:
return err;
@@ -2614,6 +2626,7 @@ static int packet_create(struct net *net, struct socket *sock, int protocol,
po = pkt_sk(sk);
sk->sk_family = PF_PACKET;
po->num = proto;
+ RCU_INIT_POINTER(po->cached_dev, NULL);
sk->sk_destruct = packet_sock_destruct;
sk_refcnt_debug_inc(sk);
diff --git a/net/packet/internal.h b/net/packet/internal.h
index c4e4b45..1035fa2 100644
--- a/net/packet/internal.h
+++ b/net/packet/internal.h
@@ -113,6 +113,7 @@ struct packet_sock {
unsigned int tp_loss:1;
unsigned int tp_tx_has_off:1;
unsigned int tp_tstamp;
+ struct net_device __rcu *cached_dev;
struct packet_type prot_hook ____cacheline_aligned_in_smp;
};
--
1.8.3.1
^ permalink raw reply related
* Re: Question about IPv6 neighbor discovery and 6lowpan
From: Jukka Rissanen @ 2013-11-21 15:52 UTC (permalink / raw)
To: Alexander Aring; +Cc: David Miller, netdev
In-Reply-To: <20131121153414.GA9960@omega>
On to, 2013-11-21 at 16:34 +0100, Alexander Aring wrote:
> Hi Jukka,
>
> On Thu, Nov 21, 2013 at 05:02:58PM +0200, Jukka Rissanen wrote:
> > Hi,
> >
> > I am investigating RFC 6775 (Neighbor Discovery Optimization for IPv6
> > over Low-Power Wireless Personal Area Networks (6LoWPANs))
> > http://tools.ietf.org/html/rfc6775
> >
> > The RFC suggests some changes to neighbor discovery procedure for the
> > 6LoWPAN networks. I was looking net/ipv6/ndisc.c and it seems that
> > ARPHRD type (from type field in net_device struct) is the only way to
> > detect and change the discovery procedure in the ndisc.c code. Am I
> > right with this assumption here?
> >
> I think you are right, there was some patches on linux-zigbee-devel who
> use exact the same idea to check the ARPHRD type.
Ok. The reason I was interested in about this is that I proposed new
ARPHRD_RAWIP earlier that I could use in BT LE 6lowpan code. Now I think
that type might be too generic and perhaps I should have ARPHRD_6LOWPAN
or even ARPHRD_BT_6LOWPAN.
>
> But I am investigating for rfc6775, too. :-)
>
>
> At the moment I see too many unsolved issues in the ieee802154/6lowpan
> implementation which should be fixed at first. :(
>
> - Alex
No worries, the rfc6775 is common for both zigbee and bluetooth so
whoever implements the rfc gets support for both of them at the same
time.
Cheers,
Jukka
^ permalink raw reply
* Re: Question about IPv6 neighbor discovery and 6lowpan
From: Alexander Aring @ 2013-11-21 16:13 UTC (permalink / raw)
To: Jukka Rissanen; +Cc: David Miller, netdev
In-Reply-To: <1385049135.2723.25.camel@jrissane-mobl.ger.corp.intel.com>
Hi Jukka,
On Thu, Nov 21, 2013 at 05:52:15PM +0200, Jukka Rissanen wrote:
> On to, 2013-11-21 at 16:34 +0100, Alexander Aring wrote:
> > Hi Jukka,
> >
> > On Thu, Nov 21, 2013 at 05:02:58PM +0200, Jukka Rissanen wrote:
> > > Hi,
> > >
> > > I am investigating RFC 6775 (Neighbor Discovery Optimization for IPv6
> > > over Low-Power Wireless Personal Area Networks (6LoWPANs))
> > > http://tools.ietf.org/html/rfc6775
> > >
> > > The RFC suggests some changes to neighbor discovery procedure for the
> > > 6LoWPAN networks. I was looking net/ipv6/ndisc.c and it seems that
> > > ARPHRD type (from type field in net_device struct) is the only way to
> > > detect and change the discovery procedure in the ndisc.c code. Am I
> > > right with this assumption here?
> > >
> > I think you are right, there was some patches on linux-zigbee-devel who
> > use exact the same idea to check the ARPHRD type.
>
> Ok. The reason I was interested in about this is that I proposed new
> ARPHRD_RAWIP earlier that I could use in BT LE 6lowpan code. Now I think
> that type might be too generic and perhaps I should have ARPHRD_6LOWPAN
> or even ARPHRD_BT_6LOWPAN.
>
> >
> > But I am investigating for rfc6775, too. :-)
> >
> >
> > At the moment I see too many unsolved issues in the ieee802154/6lowpan
> > implementation which should be fixed at first. :(
> >
> > - Alex
>
> No worries, the rfc6775 is common for both zigbee and bluetooth so
> whoever implements the rfc gets support for both of them at the same
> time.
>
Yea, I did not begin yet and you are welcome to implement it. :-)
- Alex
^ permalink raw reply
* Re: Get rxhash fixes and RFS support in tun
From: Tom Herbert @ 2013-11-21 16:28 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, Eric Dumazet, Jerry Chu
In-Reply-To: <20131120.215025.590189385589840672.davem@davemloft.net>
On Wed, Nov 20, 2013 at 6:50 PM, David Miller <davem@davemloft.net> wrote:
> From: Tom Herbert <therbert@google.com>
> Date: Wed, 20 Nov 2013 18:42:48 -0800
>
>> We need the rxhash to be the value seen at the point of RPS (to do RFS
>> correctly), which I think probably means we don't ever want to change
>> it after the first calculation! (clearing at tunnel decap wouldn't be
>> correct either) For ESP or AH, I believe it's appropriate to use SPI
>> as a substitute for ports.
>
> But that means that all connections going over the same IPSEC path
> hash to the same value.
>
> I really think that xfrm_input() should zap the rxhash near the
> existing nf_reset() call.
>
> The same argument goes for tunnels, that is why ip_tunnel_core.c does
> what it does with the rxhash clearing right now.
>
I suspect this is not the right thing to do any more. Since we're
doing deep inspection now in flow_dissector, we should already have
the discovered the hash on the inner header if it's a standard encap.
In order to do RFS for tunneled packets at the NIC interface we don't
want recompute to a different L4 hash (which would be common case if
NIC did deep inspection on tunneled packets and we clear hash at
decap).
> In both the IPSEC tunnel (not transport) and normal IP/GRE tunnel
> cases, it's a completely new SKB receive, done via netif_rx(), after
> decapsulation.
>
> That leaves only IPSEC transport mode as the only case where RFS isn't
> (re-)performed but we can build infrastructure to make that happen.
^ permalink raw reply
* Re: [PATCH] net: rework recvmsg handler msg_name and msg_namelen logic
From: Hannes Frederic Sowa @ 2013-11-21 17:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Vlad Yasevich, netdev, davem
In-Reply-To: <1385046014.10637.44.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Nov 21, 2013 at 07:00:14AM -0800, Eric Dumazet wrote:
> On Thu, 2013-11-21 at 09:52 -0500, Vlad Yasevich wrote:
> > On 11/20/2013 07:38 PM, Hannes Frederic Sowa wrote:
> > > diff --git a/include/linux/net.h b/include/linux/net.h
> > > index b292a04..4bcee94 100644
> > > --- a/include/linux/net.h
> > > +++ b/include/linux/net.h
> > > @@ -164,6 +164,14 @@ struct proto_ops {
> > > #endif
> > > int (*sendmsg) (struct kiocb *iocb, struct socket *sock,
> > > struct msghdr *m, size_t total_len);
> > > + /* Notes for implementing recvmsg:
> > > + * ===============================
> > > + * msg->msg_namelen should get updated by the recvmsg handlers
> > > + * iff msg_name != NULL. It is by default 0 to prevent
> > > + * returning uninitialized memory to user space. The recvfrom
> > > + * handlers can assume that msg.msg_name is either NULL or has
> > > + * a minimum size of sizeof(struct sockaddr_storage).
> > ^^^^^^^
> >
> > You meant "maximum", right?
>
> He meant : A protocol can safely assume there are sizeof(struct
> sockaddr_storage) bytes available.
Yes, exactly. Apparently it seems to does cause confusion as I wrote it. Maybe I should
reword it?
^ permalink raw reply
* [PATCH] genetlink: fix genlmsg_multicast() bug
From: Johannes Berg @ 2013-11-21 17:17 UTC (permalink / raw)
To: netdev; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Unfortunately, I introduced a tremendously stupid bug into
genlmsg_multicast() when doing all those multicast group
changes: it adjusts the group number, but then passes it
to genlmsg_multicast_netns() which does that again.
Somehow, my tests failed to catch this, so add a warning
into genlmsg_multicast_netns() and remove the offending
group ID adjustment.
Also add a warning to the similar code in other functions
so people who misuse them are more loudly warned.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/genetlink.h | 5 +----
net/netlink/genetlink.c | 4 ++--
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index ace4abf..771af09 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -265,7 +265,7 @@ static inline int genlmsg_multicast_netns(struct genl_family *family,
struct net *net, struct sk_buff *skb,
u32 portid, unsigned int group, gfp_t flags)
{
- if (group >= family->n_mcgrps)
+ if (WARN_ON_ONCE(group >= family->n_mcgrps))
return -EINVAL;
group = family->mcgrp_offset + group;
return nlmsg_multicast(net->genl_sock, skb, portid, group, flags);
@@ -283,9 +283,6 @@ static inline int genlmsg_multicast(struct genl_family *family,
struct sk_buff *skb, u32 portid,
unsigned int group, gfp_t flags)
{
- if (group >= family->n_mcgrps)
- return -EINVAL;
- group = family->mcgrp_offset + group;
return genlmsg_multicast_netns(family, &init_net, skb,
portid, group, flags);
}
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 7dbc4f7..4518a57 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -1045,7 +1045,7 @@ static int genlmsg_mcast(struct sk_buff *skb, u32 portid, unsigned long group,
int genlmsg_multicast_allns(struct genl_family *family, struct sk_buff *skb,
u32 portid, unsigned int group, gfp_t flags)
{
- if (group >= family->n_mcgrps)
+ if (WARN_ON_ONCE(group >= family->n_mcgrps))
return -EINVAL;
group = family->mcgrp_offset + group;
return genlmsg_mcast(skb, portid, group, flags);
@@ -1062,7 +1062,7 @@ void genl_notify(struct genl_family *family,
if (nlh)
report = nlmsg_report(nlh);
- if (group >= family->n_mcgrps)
+ if (WARN_ON_ONCE(group >= family->n_mcgrps))
return;
group = family->mcgrp_offset + group;
nlmsg_notify(sk, skb, portid, group, report, flags);
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH] genetlink: fix genl_set_err() group ID
From: Johannes Berg @ 2013-11-21 17:20 UTC (permalink / raw)
To: netdev; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Fix another really stupid bug - I introduced genl_set_err()
precisely to be able to adjust the group and reject invalid
ones, but then forgot to do so.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/genetlink.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index 771af09..1b177ed 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -384,6 +384,9 @@ static inline struct sk_buff *genlmsg_new(size_t payload, gfp_t flags)
static inline int genl_set_err(struct genl_family *family, struct net *net,
u32 portid, u32 group, int code)
{
+ if (WARN_ON_ONCE(group >= family->n_mcgrps))
+ return -EINVAL;
+ group = family->mcgrp_offset + group;
return netlink_set_err(net->genl_sock, portid, group, code);
}
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH 0/7] netfilter fixes for net
From: David Miller @ 2013-11-21 17:45 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1385024728-4057-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 21 Nov 2013 10:05:21 +0100
> The following patchset contains fixes for your net tree, they are:
>
> * Remove extra quote from connlimit configuration in Kconfig, from
> Randy Dunlap.
>
> * Fix missing mss option in syn packets sent to the backend in our
> new synproxy target, from Martin Topholm.
>
> * Use window scale announced by client when sending the forged
> syn to the backend, from Martin Topholm.
>
> * Fix IPv6 address comparison in ebtables, from Luís Fernando
> Cornachioni Estrozi.
>
> * Fix wrong endianess in sequence adjustment which breaks helpers
> in NAT configurations, from Phil Oester.
>
> * Fix the error path handling of nft_compat, from me.
>
> * Make sure the global conntrack counter is decremented after the
> object has been released, also from me.
Pulled, thanks a lot Pablo.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
* Re: [PATCH] sh_eth: call phy_scan_fixups() after PHY reset
From: Sergei Shtylyov @ 2013-11-21 17:48 UTC (permalink / raw)
To: Florian Fainelli
Cc: David Miller, nobuhiro.iwamatsu.yj, netdev, linux-sh,
laurent.pinchart+renesas
In-Reply-To: <CAGVrzcaKA7T7Cppg0g29wsUZBu4-6+AY+6teH1SWSiT=D7RQBQ@mail.gmail.com>
Hello.
On 16-11-2013 4:04, Florian Fainelli wrote:
>>>> David, will you ever reply to this mail?
>>> I really haven't had the time with my backlog, and it's been so long ago
>>> that I've forgotten all of the context.
>> Hm, I thought I provided enough context and also that's what mail
>> archives are for... :-)
>>> Sorry, someone will have to start the conversation up anew.
> [snip]
>> Now, about the ways to deal with this issue that I see.
>> First I thought about using PHY platform fixup mechanism which is already
>> hooked up to a PHY reset in phy_mii_ioctl() (the code is somewhat naive
>> though as it doesn't wait for the reset completion before calling fixups and
>> the driver's config_init() method).
> That's something that needs fixing and also a dedicated helper or such
> should be used because we are potentially messing up with the
> configuration the PHY library thinks it has applied to the PHY (e.g:
> disabling auto-negotiation etc...).
Agreed.
>> All I needed is calling fixups after
>> direct PHY reset done via phy_write() but I didn't want to add a hook there
>> due to that reset completion wait loop that was obviously necessary (this
>> function is simple *inline*), so went for a simplistic local
>> phy_scan_fixups() call (that function was helpfully already exported
>> although not called by anyone except phylib itself) after PHY reset in the
>> 'sh_eth' driver which you saw in my patch and which you didn't like; I've
>> also coded the PHY platform fixup which got successfully merged via
>> arch/arm/mach-shmobile/ subtree at that time. Your argument was that the
>> driver is going against the control flow provided by phylib (it's not alone
>> doing PHY reset, I should note) and so you wanted me to embed everything
>> into phylib control flow. I replied that I fear the unexpected consequencies
>> of doing compulsory PHY reset for every driver using phylib (that's how I
>> understood your idea at least)... then, after a long pause, I suggested to
>> code phy_reset() function within phylib which the drivers that currently do
>> reset their PHYs could use instead of open coding the reset bit polling
>> loop, etc. and which would include a hook for the platform fixups and PHY
>> driver config_init() call. I'd still like to hear your opinion on this
>> approach -- which is less invasive.
>> What I can also do in this case is again ignore ETH_LINK signal in the
>> 'sh_eth' driver and stop caring about the LED functions matching to what's
>> designed for the boards. This doesn't need PHY platform fixup or any change
>> in phylib and Ethernet driver.
> This signal is probably present for a good reason: avoiding expensive
> MDIO register access,
As the driver is using phylib (and that in the polled mode) anyway, this
advantage is nullified.
> and if that works for most platforms why not
> keeping it?
Because it starts to bounce on/off after each packet as I've already told
(which most probably affects the packet reception as seen from NFS timeout) in
the default mode of KSZ8041. We had to completely ignore this signal on BOCK-W
where LED mode 00 is used (and yet I had to fix the 'sh_eth' driver's logic
that should have relied on phylib's callback to become aware of the link
state). On the newer boards, we have this issue again after we reset the PHY
when opening 'eth0' device. I'm not sure why I have to repeat the text that
you've skipped.
>> What I also can do is stop resetting PHY in the 'sh_eth' driver (only
>> getting it out of sleep for which the reset doesn't seem necessary),
>> although we'd still need the PHY platform fixup for the PHY resets done via
>> phy_mii_ioctl()... I'm not so much familiar with the driver to be sure it
>> won't hurt (the driver is used on e.g. some SH platforms I don't get any
>> access to) and I couldn't get any useful input from the driver's primary
>> author -- but perhaps it's really not necessary. What do you think?
> Quite a lot of PHYs actually require a reset through BMCR_RESET when
> resuming from S2/S3 sleep states and even if they do not, it does not
I'm not very familiar with PHY power management ATM, and only know about
the BMCR powerdown bit...
> hurt doing so, I would welcome a generic solution to do that which
> would not circumvent the libphy state machine and APIs. So the general
> idea would be to:
> - provide a helper, e.g: phy_reset(phydev) which:
> - toggles BMCR_RESET, waits for it to be clear
> - call fixups on the phy_device
> - call config_init on the phy_device
> - restores any kind of duplex/autoneg settings we enabled/disabled
I'm not sure I follow here. If the driver calls phy_reset(), it should
know already that these settings will be affected, no? This sentence only
makes sense to me if we do phy_reset() somewhere in the PHY PM code as you
have hinted...
> - resume the PHY state machine at the appropriate state
Too bad I'm only slightly familiar with phylib ATM.
Being in hospital also doesn't help to advance on that matter. :-(
> --
> Florian
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] net: rework recvmsg handler msg_name and msg_namelen logic
From: David Miller @ 2013-11-21 17:57 UTC (permalink / raw)
To: eric.dumazet; +Cc: vyasevich, netdev
In-Reply-To: <1385046014.10637.44.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 21 Nov 2013 07:00:14 -0800
> So a protocol should use BUILD_BUG_ON() to make sure sockaddr_storage is
> big enough.
Hannes mentioned trying to do this, somehow, automatically. Best I could
come up with is something like:
#define DECLARE_RECVMSG_HANDLER(name, ..., sockaddr_type) \
static ... __name(...); \
static ... name(...) \
{ \
BUILD_BUG_ON(sizeof(sockaddr_type) > sizeof(sockaddr_storage); \
__name(...); \
} \
static ... __name(...)
And then the protocols go:
DECLARE_RECVMSG_HANDLER(udp_recvmsg, ..., struct sockaddr_in)
{
struct inet_sock *inet = inet_sk(sk);
struct sockaddr_in *sin = (struct sockaddr_in *)msg->msg_name;
...
You get the idea.
Slightly convoluted, and we can do something special with types or the
prot ops member name to enforce usage of the macro.
^ permalink raw reply
* Re: pull request: wireless 2013-11-21
From: David Miller @ 2013-11-21 17:59 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20131121154136.GB2152@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 21 Nov 2013 10:41:37 -0500
> Please pull this batch of fixes intended for the 3.13 stream!
Pulled, thanks John.
^ permalink raw reply
* Re: Get rxhash fixes and RFS support in tun
From: David Miller @ 2013-11-21 18:03 UTC (permalink / raw)
To: therbert; +Cc: netdev, edumazet, hkchu
In-Reply-To: <CA+mtBx_KuiC2KWXKuV-+KBrJ7GhMK0L5kAH8sO7CA3sQqGp+Cg@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Thu, 21 Nov 2013 08:28:18 -0800
> Since we're doing deep inspection now in flow_dissector, we should
> already have the discovered the hash on the inner header if it's a
> standard encap.
For AH and normal IP tunnels, this might be fine. But this is not
possible for ESP since the inner headers are encrypted when the
flow_dissector takes a look.
And again, there is the issue of which hardware devices are doing this
properly.
And for those that do perform inner-tunnel deep inspection for rxhash
generation, how many layers of tunnels are they able to look beneath?
My impression is that they support one level, at best, which means the
rxhash is basically reliable only under a specific set of conditions.
I need you to elaborate with your knowledge of what hardware actually
supports and does in this area a bit more before I can have a real
opinion on what we should be doing.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: Fix ehea warning when built in
From: David Miller @ 2013-11-21 18:07 UTC (permalink / raw)
To: mikey; +Cc: jeffm, ohering, jslaby, netdev, cascardo
In-Reply-To: <11586.1385008609@ale.ozlabs.ibm.com>
From: Michael Neuling <mikey@neuling.org>
Date: Thu, 21 Nov 2013 15:36:49 +1100
> In:
> commit 7a3a62128388a6af771e99df8628ddee2e8be7ca
> Author: Olaf Hering <ohering@suse.com>
> drivers/net/ethernet/ibm/ehea/ehea_main.c: add alias entry for portN properties
> We added ehea_module_device_table. Unfortunately we only use this when
> building as a module so we get the following warning when built in, like
> in pseries_defconfig:
>
> drivers/net/ethernet/ibm/ehea/ehea_main.c:105:1: warning: 'ehea_module_device_table' defined but not used [-Wunused-variable]
>
> This wraps ehea_module_device_table with #if MODULE.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
I think putting an ugly MODULE ifdef into every driver that does something
like this is not going to cut it.
Rather, the MODULE_DEVICE_TABLE() definition when !MODULE should do something
reasonable, like make a void reference to the symbole.
I'm not applying this, the fix belongs in a generic place.
Thanks.
^ 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