* Re: [PATCH net-next] bnx2x: add endline at end of message
From: David Miller @ 2011-11-14 19:36 UTC (permalink / raw)
To: dmitry; +Cc: netdev
In-Reply-To: <1321260039-19254-1-git-send-email-dmitry@broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Mon, 14 Nov 2011 10:40:39 +0200
> Reported-by: Joe Perches <joe@perches.com>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH RESUBMIT3 net-next 2/2] IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag
From: David Miller @ 2011-11-14 19:36 UTC (permalink / raw)
To: matti.vaittinen; +Cc: netdev
In-Reply-To: <1321265714.1858.28.camel@hakki>
From: Matti Vaittinen <matti.vaittinen@nsn.com>
Date: Mon, 14 Nov 2011 12:15:14 +0200
>
> The support for NLM_F_* flags at IPv6 routing requests.
>
> If NLM_F_CREATE flag is not defined for RTM_NEWROUTE request,
> warning is printed, but no error is returned. Instead new route is
> added. Later NLM_F_CREATE may be required for
> new route creation.
>
> Exception is when NLM_F_REPLACE flag is given without NLM_F_CREATE, and
> no matching route is found. In this case it should be safe to assume
> that the request issuer is familiar with NLM_F_* flags, and does really
> not want route to be created.
>
> Specifying NLM_F_REPLACE flag will now make the kernel to search for
> matching route, and replace it with new one. If no route is found and
> NLM_F_CREATE is specified as well, then new route is created.
>
> Also, specifying NLM_F_EXCL will yield returning of error if matching
> route is found.
>
> Patch created against linux-3.2-rc1
>
> Signed-off-by: Matti Vaittinen <Mazziesaccount@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH RESUBMIT3 net-next 1/2] IPv6 routing, NLM_F_* flag support: warn if new route is created without NLM_F_CREATE
From: David Miller @ 2011-11-14 19:36 UTC (permalink / raw)
To: matti.vaittinen; +Cc: netdev
In-Reply-To: <1321265689.1858.27.camel@hakki>
From: Matti Vaittinen <matti.vaittinen@nsn.com>
Date: Mon, 14 Nov 2011 12:14:49 +0200
> The support for NLM_F_* flags at IPv6 routing requests.
>
> Warn if NLM_F_CREATE flag is not defined for RTM_NEWROUTE request,
> creating new table. Later NLM_F_CREATE may be required for
> new route creation.
>
> Patch created against linux-3.2-rc1
>
> Signed-off-by: Matti Vaittinen <Mazziesaccount@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/4] ipv4: Update pmtu informations on inetpeer only for output routes
From: David Miller @ 2011-11-14 19:33 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
In-Reply-To: <20111114101244.GB20943@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 14 Nov 2011 11:12:44 +0100
> So for the moment I'm thinking about adding an ip_dst_mtu()
> function that returns dst->ops->default_mtu() for input routes
> and dst_mtu() for output routes. Then we could convert the
> dst_mtu() users in net/ipv4/ over to this one.
We'll need something similar for ipv6 eventually...
I would suggest that we do away with dst_ops->default_mtu() and just
have dst_ops->mtu() which gets invoked unconditionally by dst_mtu().
You can integrate the ->default_mtu() handling and the input route
check into this new method. Then IPv6 can be fixed in a
straightforward manner later.
^ permalink raw reply
* pull request: wireless 2011-11-14
From: John W. Linville @ 2011-11-14 19:32 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is another batch of fixes intended for 3.2. This includes an
mwifiex fix to enable association with "hidden" APs, a fix for avoiding
an unhandled RF kill interrupt when unloading iwlwifi, a NULL pointer
fix in the mac80211 radiotap code, a fix for ieee80211_build_probe_req
to pass-up a proper return code when ieee80211_probereq_get fails, a
race fix for mac80211 to avoid a WARNING in ieee80211_can_queue_work, a
NULL pointer fix in the cfg80211 regulatory code, and a fix for an
unaligned memory access in the libertas driver.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 1e49570171117e547e6324c58371db4a0dc2f1db:
net: Fix references to deleted NET_ETHERNET Kconfig setting. (2011-11-09 19:26:53 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
Amitkumar Karwar (1):
mwifiex: fix association issue with AP configured in hidden SSID mode
Emmanuel Grumbach (1):
iwlwifi: avoid a panic when unloading the module with RF Kill
Johannes Berg (3):
mac80211: fix NULL dereference in radiotap code
mac80211: fix bug in ieee80211_build_probe_req
mac80211: fix race between connection monitor & suspend
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Luis R. Rodriguez (1):
cfg80211: fix bug on regulatory core exit on access to last_request
Steven Miao (1):
wireless: libertas: fix unaligned le64 accesses
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c | 33 +++++++++++++------------
drivers/net/wireless/libertas/cfg.c | 2 +-
drivers/net/wireless/mwifiex/scan.c | 6 +++-
net/mac80211/mlme.c | 2 +-
net/mac80211/rx.c | 9 ++++--
net/mac80211/util.c | 4 +++
net/wireless/reg.c | 3 ++
7 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
index da34110..ce91898 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
@@ -990,29 +990,16 @@ static int iwl_trans_tx_stop(struct iwl_trans *trans)
return 0;
}
-static void iwl_trans_pcie_disable_sync_irq(struct iwl_trans *trans)
+static void iwl_trans_pcie_stop_device(struct iwl_trans *trans)
{
unsigned long flags;
- struct iwl_trans_pcie *trans_pcie =
- IWL_TRANS_GET_PCIE_TRANS(trans);
+ struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
+ /* tell the device to stop sending interrupts */
spin_lock_irqsave(&trans->shrd->lock, flags);
iwl_disable_interrupts(trans);
spin_unlock_irqrestore(&trans->shrd->lock, flags);
- /* wait to make sure we flush pending tasklet*/
- synchronize_irq(bus(trans)->irq);
- tasklet_kill(&trans_pcie->irq_tasklet);
-}
-
-static void iwl_trans_pcie_stop_device(struct iwl_trans *trans)
-{
- /* stop and reset the on-board processor */
- iwl_write32(bus(trans), CSR_RESET, CSR_RESET_REG_FLAG_NEVO_RESET);
-
- /* tell the device to stop sending interrupts */
- iwl_trans_pcie_disable_sync_irq(trans);
-
/* device going down, Stop using ICT table */
iwl_disable_ict(trans);
@@ -1039,6 +1026,20 @@ static void iwl_trans_pcie_stop_device(struct iwl_trans *trans)
/* Stop the device, and put it in low power state */
iwl_apm_stop(priv(trans));
+
+ /* Upon stop, the APM issues an interrupt if HW RF kill is set.
+ * Clean again the interrupt here
+ */
+ spin_lock_irqsave(&trans->shrd->lock, flags);
+ iwl_disable_interrupts(trans);
+ spin_unlock_irqrestore(&trans->shrd->lock, flags);
+
+ /* wait to make sure we flush pending tasklet*/
+ synchronize_irq(bus(trans)->irq);
+ tasklet_kill(&trans_pcie->irq_tasklet);
+
+ /* stop and reset the on-board processor */
+ iwl_write32(bus(trans), CSR_RESET, CSR_RESET_REG_FLAG_NEVO_RESET);
}
static int iwl_trans_pcie_tx(struct iwl_trans *trans, struct sk_buff *skb,
diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
index 4fcd653..a7f1ab2 100644
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@ -634,7 +634,7 @@ static int lbs_ret_scan(struct lbs_private *priv, unsigned long dummy,
if (channel &&
!(channel->flags & IEEE80211_CHAN_DISABLED))
cfg80211_inform_bss(wiphy, channel,
- bssid, le64_to_cpu(*(__le64 *)tsfdesc),
+ bssid, get_unaligned_le64(tsfdesc),
capa, intvl, ie, ielen,
LBS_SCAN_RSSI_TO_MBM(rssi),
GFP_KERNEL);
diff --git a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
index 8a3f959..8d3ab37 100644
--- a/drivers/net/wireless/mwifiex/scan.c
+++ b/drivers/net/wireless/mwifiex/scan.c
@@ -819,8 +819,10 @@ mwifiex_scan_setup_scan_config(struct mwifiex_private *priv,
wildcard_ssid_tlv->header.len = cpu_to_le16(
(u16) (ssid_len + sizeof(wildcard_ssid_tlv->
max_ssid_length)));
- wildcard_ssid_tlv->max_ssid_length =
- user_scan_in->ssid_list[ssid_idx].max_len;
+
+ /* max_ssid_length = 0 tells firmware to perform
+ specific scan for the SSID filled */
+ wildcard_ssid_tlv->max_ssid_length = 0;
memcpy(wildcard_ssid_tlv->ssid,
user_scan_in->ssid_list[ssid_idx].ssid,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 234ffc2..b1b1bb3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2288,6 +2288,7 @@ void ieee80211_sta_quiesce(struct ieee80211_sub_if_data *sdata)
cancel_work_sync(&ifmgd->request_smps_work);
+ cancel_work_sync(&ifmgd->monitor_work);
cancel_work_sync(&ifmgd->beacon_connection_loss_work);
if (del_timer_sync(&ifmgd->timer))
set_bit(TMR_RUNNING_TIMER, &ifmgd->timers_running);
@@ -2296,7 +2297,6 @@ void ieee80211_sta_quiesce(struct ieee80211_sub_if_data *sdata)
if (del_timer_sync(&ifmgd->chswitch_timer))
set_bit(TMR_RUNNING_CHANSW, &ifmgd->timers_running);
- cancel_work_sync(&ifmgd->monitor_work);
/* these will just be re-established on connection */
del_timer_sync(&ifmgd->conn_mon_timer);
del_timer_sync(&ifmgd->bcn_mon_timer);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index bb53726..fb123e2 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -141,8 +141,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
pos++;
/* IEEE80211_RADIOTAP_RATE */
- if (status->flag & RX_FLAG_HT) {
+ if (!rate || status->flag & RX_FLAG_HT) {
/*
+ * Without rate information don't add it. If we have,
* MCS information is a separate field in radiotap,
* added below. The byte here is needed as padding
* for the channel though, so initialise it to 0.
@@ -163,12 +164,14 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
else if (status->flag & RX_FLAG_HT)
put_unaligned_le16(IEEE80211_CHAN_DYN | IEEE80211_CHAN_2GHZ,
pos);
- else if (rate->flags & IEEE80211_RATE_ERP_G)
+ else if (rate && rate->flags & IEEE80211_RATE_ERP_G)
put_unaligned_le16(IEEE80211_CHAN_OFDM | IEEE80211_CHAN_2GHZ,
pos);
- else
+ else if (rate)
put_unaligned_le16(IEEE80211_CHAN_CCK | IEEE80211_CHAN_2GHZ,
pos);
+ else
+ put_unaligned_le16(IEEE80211_CHAN_2GHZ, pos);
pos += 2;
/* IEEE80211_RADIOTAP_DBM_ANTSIGNAL */
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 51e256c..eca0fad 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -881,6 +881,8 @@ struct sk_buff *ieee80211_build_probe_req(struct ieee80211_sub_if_data *sdata,
skb = ieee80211_probereq_get(&local->hw, &sdata->vif,
ssid, ssid_len,
buf, buf_len);
+ if (!skb)
+ goto out;
if (dst) {
mgmt = (struct ieee80211_mgmt *) skb->data;
@@ -889,6 +891,8 @@ struct sk_buff *ieee80211_build_probe_req(struct ieee80211_sub_if_data *sdata,
}
IEEE80211_SKB_CB(skb)->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT;
+
+ out:
kfree(buf);
return skb;
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 6acba9d..e71f5a6 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2265,6 +2265,9 @@ void /* __init_or_exit */ regulatory_exit(void)
kfree(last_request);
+ last_request = NULL;
+ dev_set_uevent_suppress(®_pdev->dev, true);
+
platform_device_unregister(reg_pdev);
spin_lock_bh(®_pending_beacons_lock);
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH] Don't allow sharing of tx skbs on xen-netfront
From: Neil Horman @ 2011-11-14 19:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jeremy.fitzhardinge, konrad.wilk, xen-devel
In-Reply-To: <20111114.142716.615003966880410697.davem@davemloft.net>
On Mon, Nov 14, 2011 at 02:27:16PM -0500, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Mon, 14 Nov 2011 14:22:24 -0500
>
> > It was pointed out to me recently that the xen-netfront driver can't safely
> > support shared skbs on transmit, since, while it doesn't maintain skb state
> > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > the hypervisor may expect the contents of the skb to remain stable. Clearing
> > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
> Please put an appropriate prefix into the subject lines of your patch
> submissions. In this case "[PATCH] xen-netfront: ..." would be appropriate.
>
> I've been letting you get away with this for the past few weeks and I've
> decided that it's your turn to start getting this right :-)
Jeez Dave, I got it right on the cgroups post, you want consistency now
too? :).
Apologies, I need to consult a checklist for myself prior to sending stuff.
Best
Neil
> --
> 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
* Re: [PATCH net-next 1/2] net: introduce build_skb()
From: Eric Dumazet @ 2011-11-14 19:31 UTC (permalink / raw)
To: David Miller
Cc: eilong, pstaszewski, netdev, bhutchings, therbert, hadi,
shemminger, tgraf, herbert, jeffrey.t.kirsher
In-Reply-To: <20111114.142916.2005300491189237669.davem@davemloft.net>
Le lundi 14 novembre 2011 à 14:29 -0500, David Miller a écrit :
> Oh I see, this is for drivers which splat the packet into a linear
> buffer to begin with.
Exact.. We have plenty of them of course :)
^ permalink raw reply
* Re: net/can/mscan: Fix buggy listen only mode setting
From: David Miller @ 2011-11-14 19:30 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
Netdev-u79uwXL29TY76Z2rM5mHXA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-can-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4EC11900.7030005-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Date: Mon, 14 Nov 2011 14:34:56 +0100
> This patch fixes an issue introduced recently with commit
> 452448f9283e1939408b397e87974a418825b0a8.
>
> CC: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: introduce build_skb()
From: David Miller @ 2011-11-14 19:29 UTC (permalink / raw)
To: eric.dumazet
Cc: eilong, pstaszewski, netdev, bhutchings, therbert, hadi,
shemminger, tgraf, herbert, jeffrey.t.kirsher
In-Reply-To: <1321298766.2719.11.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Nov 2011 20:26:06 +0100
> Le lundi 14 novembre 2011 à 14:21 -0500, David Miller a écrit :
>
>> Applied, I'll work on converting NIU over to this if I find some time.
>
> I dont believe NIU needs it, since its a frag enabled driver.
>
> You already allocate a fresh skb (and attach frags to it) right before
> giving it to upper stack.
Oh I see, this is for drivers which splat the packet into a linear
buffer to begin with.
^ permalink raw reply
* Re: [PATCH] Don't allow sharing of tx skbs on xen-netfront
From: David Miller @ 2011-11-14 19:27 UTC (permalink / raw)
To: nhorman; +Cc: netdev, jeremy.fitzhardinge, konrad.wilk, xen-devel
In-Reply-To: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 14 Nov 2011 14:22:24 -0500
> It was pointed out to me recently that the xen-netfront driver can't safely
> support shared skbs on transmit, since, while it doesn't maintain skb state
> directly, it does pass a pointer to the skb to the hypervisor via a list, and
> the hypervisor may expect the contents of the skb to remain stable. Clearing
> the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Please put an appropriate prefix into the subject lines of your patch
submissions. In this case "[PATCH] xen-netfront: ..." would be appropriate.
I've been letting you get away with this for the past few weeks and I've
decided that it's your turn to start getting this right :-)
^ permalink raw reply
* Re: [PATCH Fix V2] mlx4_en: Remove FCS bytes from packet length.
From: David Miller @ 2011-11-14 19:26 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <4EC1446D.4020209@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Mon, 14 Nov 2011 18:40:13 +0200
> When HW doesn't remove FCS bytes they are reported in the completion
> byte count, we don't need to take them to skb.
>
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: introduce build_skb()
From: Eric Dumazet @ 2011-11-14 19:26 UTC (permalink / raw)
To: David Miller
Cc: eilong, pstaszewski, netdev, bhutchings, therbert, hadi,
shemminger, tgraf, herbert, jeffrey.t.kirsher
In-Reply-To: <20111114.142153.804127798975712263.davem@davemloft.net>
Le lundi 14 novembre 2011 à 14:21 -0500, David Miller a écrit :
> Applied, I'll work on converting NIU over to this if I find some time.
I dont believe NIU needs it, since its a frag enabled driver.
You already allocate a fresh skb (and attach frags to it) right before
giving it to upper stack.
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnx2x: uses build_skb() in receive path
From: David Miller @ 2011-11-14 19:22 UTC (permalink / raw)
To: eilong
Cc: eric.dumazet, netdev, bhutchings, therbert, hadi, shemminger,
tgraf, herbert, jeffrey.t.kirsher, pstaszewski
In-Reply-To: <1321289329.3101.7.camel@lb-tlvb-eilong.il.broadcom.com>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Mon, 14 Nov 2011 18:48:49 +0200
> On Mon, 2011-11-14 at 08:05 -0800, Eric Dumazet wrote:
>> bnx2x uses following formula to compute its rx_buf_sz :
>>
>> dev->mtu + 2*L1_CACHE_BYTES + 14 + 8 + 8 + 2
>>
>> Then core network adds NET_SKB_PAD and SKB_DATA_ALIGN(sizeof(struct
>> skb_shared_info))
>>
>> Final allocated size for skb head on x86_64 (L1_CACHE_BYTES = 64,
>> MTU=1500) : 2112 bytes : SLUB/SLAB round this to 4096 bytes.
>>
>> Since skb truesize is then bigger than SK_MEM_QUANTUM, we have lot of
>> false sharing because of mem_reclaim in UDP stack.
>>
>> One possible way to half truesize is to reduce the need by 64 bytes
>> (2112 -> 2048 bytes)
>>
>> Instead of allocating a full cache line at the end of packet for
>> alignment, we can use the fact that skb_shared_info sits at the end of
>> skb->head, and we can use this room, if we convert bnx2x to new
>> build_skb() infrastructure.
>>
>> skb_shared_info will be initialized after hardware finished its
>> transfert, so we can eventually overwrite the final padding.
>>
>> Using build_skb() also reduces cache line misses in the driver, since we
>> use cache hot skb instead of cold ones. Number of in-flight sk_buff
>> structures is lower, they are recycled while still hot.
>>
>> Performance results :
>>
>> (820.000 pps on a rx UDP monothread benchmark, instead of 720.000 pps)
>
> Wow! This is very impressive. The only problem will be to back port this
> driver now... But it is definitely worth the effort :)
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: introduce build_skb()
From: David Miller @ 2011-11-14 19:21 UTC (permalink / raw)
To: eric.dumazet
Cc: eilong, pstaszewski, netdev, bhutchings, therbert, hadi,
shemminger, tgraf, herbert, jeffrey.t.kirsher
In-Reply-To: <1321286614.2272.47.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Nov 2011 17:03:34 +0100
...
> So the deal would be to allocate only the data buffer for the NIC to
> populate its RX ring buffer. And use build_skb() at RX completion to
> attach a data buffer (now filled with an ethernet frame) to a new skb,
> initialize the skb_shared_info portion, and give the hot skb to network
> stack.
>
> build_skb() is the function to allocate an skb, caller providing the
> data buffer that should be attached to it. Drivers are expected to call
> skb_reserve() right after build_skb() to adjust skb->data to the
> Ethernet frame (usually skipping NET_SKB_PAD and NET_IP_ALIGN, but some
> drivers might add a hardware provided alignment)
>
> Data provided to build_skb() MUST have been allocated by a prior
> kmalloc() call, with enough room to add SKB_DATA_ALIGN(sizeof(struct
> skb_shared_info)) bytes at the end of the data without corrupting
> incoming frame.
Applied, I'll work on converting NIU over to this if I find some time.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: reduce skb truesize by 50%
From: David Miller @ 2011-11-14 19:21 UTC (permalink / raw)
To: eric.dumazet
Cc: eilong, bhutchings, pstaszewski, netdev, tgraf, therbert, hadi,
shemminger
In-Reply-To: <1321286265.2272.46.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Nov 2011 16:57:45 +0100
> Le lundi 14 novembre 2011 à 07:25 +0100, Eric Dumazet a écrit :
>> Le lundi 14 novembre 2011 à 00:08 -0500, David Miller a écrit :
>>
>> > I fully support bringing this thing back to life :-)
>>
>> I'll make extensive tests today and provide two patches when ready, with
>> all performance results.
>>
>> Some prefetch() calls will be removed, since build_skb() provides
>> already cache hot skb.
>
> Impressive results :
>
> before : 720.000 pps
> after : 820.000 pps
>
> [ One mono threaded application receiving UDP messages on a single
> socket, asking IP_PKTINFO ancillary info ]
Sweeeeeet.
^ permalink raw reply
* [PATCH] Don't allow sharing of tx skbs on xen-netfront
From: Neil Horman @ 2011-11-14 19:22 UTC (permalink / raw)
To: netdev
Cc: Neil Horman, David S. Miller, Jeremy Fitzhardinge,
Konrad Rzeszutek Wilk, xen-devel
It was pointed out to me recently that the xen-netfront driver can't safely
support shared skbs on transmit, since, while it doesn't maintain skb state
directly, it does pass a pointer to the skb to the hypervisor via a list, and
the hypervisor may expect the contents of the skb to remain stable. Clearing
the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: xen-devel@lists.xensource.com
---
drivers/net/xen-netfront.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 226faab..fb1077b 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1252,6 +1252,12 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
return ERR_PTR(-ENOMEM);
}
+ /*
+ * Since frames remain on a queue after a return from xennet_start_xmit,
+ * we can't support tx shared skbs
+ */
+ netdev->priv_flags &= ~IFF_TX_SKB_SHARING;
+
np = netdev_priv(netdev);
np->xbdev = dev;
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH net-next] Sweep the last of the active .get_drvinfo floors under ethernet/
From: David Miller @ 2011-11-14 19:22 UTC (permalink / raw)
To: raj; +Cc: dwang2, netdev, roprabhu, e1000-devel, benve
In-Reply-To: <20111114181325.217C72900307@tardy>
From: raj@tardy.cup.hp.com (Rick Jones)
Date: Mon, 14 Nov 2011 10:13:25 -0800 (PST)
> From: Rick Jones <rick.jones2@hp.com>
>
> This round of floor sweeping converts strncpy calls in various .get_drvinfo
> routines to the preferred strlcpy. It also does a modicum of other
> cleaning in those routines.
>
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
Applied, thanks for taking care of this.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH Fix V2] mlx4_en: Remove FCS bytes from packet length.
From: Yevgeny Petrilin @ 2011-11-14 16:40 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
When HW doesn't remove FCS bytes they are reported in the completion
byte count, we don't need to take them to skb.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +++++-
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index b89c36d..c2df6c3 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -581,6 +581,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
* Packet is OK - process it.
*/
length = be32_to_cpu(cqe->byte_cnt);
+ length -= ring->fcs_del;
ring->bytes += length;
ring->packets++;
@@ -813,8 +814,11 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv *priv, int qpn,
context->db_rec_addr = cpu_to_be64(ring->wqres.db.dma);
/* Cancel FCS removal if FW allows */
- if (mdev->dev->caps.flags & MLX4_DEV_CAP_FLAG_FCS_KEEP)
+ if (mdev->dev->caps.flags & MLX4_DEV_CAP_FLAG_FCS_KEEP) {
context->param3 |= cpu_to_be32(1 << 29);
+ ring->fcs_del = ETH_FCS_LEN;
+ } else
+ ring->fcs_del = 0;
err = mlx4_qp_to_ready(mdev->dev, &ring->wqres.mtt, context, qp, state);
if (err) {
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 8fda331c..207b5ad 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -272,6 +272,7 @@ struct mlx4_en_rx_ring {
u32 prod;
u32 cons;
u32 buf_size;
+ u8 fcs_del;
void *buf;
void *rx_info;
unsigned long bytes;
--
1.7.7
^ permalink raw reply related
* qfq getting "stuck"
From: Denys Fedoryshchenko @ 2011-11-14 19:01 UTC (permalink / raw)
To: netdev, shemminger
Hi
Just did setup for QFQ (also testing SFB)
i686/kernel 3.1.0
tc utility, iproute2-ss111010
SFB works fine, while QFQ are "freezing" after while.
I cannot apply much patches there, since it is "production" customer,
but i can try few.
Please let me know if you need additional info.
64 bytes from 10.0.1.102: icmp_req=23 ttl=128 time=46.2 ms
64 bytes from 10.0.1.102: icmp_req=24 ttl=128 time=30.6 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
Script:
DEV="tun0"
ethtool -K eth1.732 tso off gso off gro off
ethtool -K eth1 tso off gso off gro off
ethtool -K tun0 tso off gso off gro off
ethtool -K ifb0 tso off gso off gro off
tc qdisc del dev $DEV root
echo add root
tc qdisc add dev $DEV root handle 1 htb default 7
echo add class
tc class add dev $DEV parent 1: classid 1:1 htb rate 3800Kbit ceil
3800Kbit prio 3
tc class add dev $DEV parent 1:1 classid 1:7 htb rate 3800Kbit ceil
3800Kbit prio 3
echo add qdisc
tc qdisc add dev $DEV parent 1:7 handle 11: est 0.5sec 2sec qfq
tc filter add dev $DEV protocol ip parent 11: handle 3 \
flow hash keys dst divisor 64
for i in `seq 1 64`
do
classid=11:$(printf %x $i)
tc class add dev $DEV classid $classid qfq.
tc qdisc add dev $DEV parent $classid pfifo limit 10
done
tc filter add dev $DEV protocol ip parent 1: prio 4 u32 match ip dst
0.0.0.0/0 flowid 1:7
Stats when it is freezed:
class htb 1:1 root rate 3800Kbit ceil 3800Kbit burst 1599b/8 mpu 0b
overhead 0b cburst 1599b/8 mpu 0b overhead 0b level 7
Sent 14289365 bytes 13366 pkt (dropped 0, overlimits 0 requeues 0)
rate 9672bit 1pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: -46804 ctokens: -46804
class htb 1:7 parent 1:1 leaf 11: prio 3 quantum 47500 rate 3800Kbit
ceil 3800Kbit burst 1599b/8 mpu 0b overhead 0b cburst 1599b/8 mpu 0b
overhead 0b level 0
Sent 14348426 bytes 13535 pkt (dropped 3258, overlimits 0 requeues 0)
rate 9856bit 1pps backlog 0b 169p requeues 0
lended: 13366 borrowed: 0 giants: 0
tokens: -46804 ctokens: -46804
class qfq 11:11 root leaf 841b: weight 1 maxpkt 2048
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class qfq 11:10 root leaf 841a: weight 1 maxpkt 2048
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class qfq 11:13 root leaf 841d: weight 1 maxpkt 2048
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class qfq 11:12 root leaf 841c: weight 1 maxpkt 2048
Sent 5712 bytes 39 pkt (dropped 169, overlimits 0 requeues 0)
backlog 1720b 10p requeues 0
class qfq 11:15 root leaf 841f: weight 1 maxpkt 2048
Sent 58 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 29b 1p requeues 0
class qfq 11:14 root leaf 841e: weight 1 maxpkt 2048
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class qfq 11:17 root leaf 8421: weight 1 maxpkt 2048
Sent 27473 bytes 91 pkt (dropped 131, overlimits 0 requeues 0)
backlog 520b 10p requeues 0
class qfq 11:16 root leaf 8420: weight 1 maxpkt 2048
Sent 4037380 bytes 2743 pkt (dropped 261, overlimits 0 requeues 0)
backlog 13584b 10p requeues 0
class qfq 11:19 root leaf 8423: weight 1 maxpkt 2048
Sent 5132 bytes 37 pkt (dropped 131, overlimits 0 requeues 0)
backlog 755b 10p requeues 0
...
class qfq 11:2f root leaf 8439: weight 1 maxpkt 2048
Sent 89 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class qfq 11:2c root leaf 8436: weight 1 maxpkt 2048
Sent 3977870 bytes 3239 pkt (dropped 989, overlimits 0 requeues 0)
backlog 13521b 10p requeues 0
class qfq 11:2d root leaf 8437: weight 1 maxpkt 2048
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class qfq 11:40 root leaf 844a: weight 1 maxpkt 2048
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
---
System administrator
Denys Fedoryshchenko
Virtual ISP S.A.L.
^ permalink raw reply
* Re: [patch net-next V8] net: introduce ethernet teaming device
From: Rick Jones @ 2011-11-14 18:40 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, eric.dumazet, bhutchings, shemminger, fubar, andy,
tgraf, ebiederm, mirqus, kaber, greearb, jesse, fbl,
benjamin.poirier, jzupka, ivecera
In-Reply-To: <1321085808-6871-1-git-send-email-jpirko@redhat.com>
On 11/12/2011 12:16 AM, Jiri Pirko wrote:
> This patch introduces new network device called team. It supposes to be
> very fast, simple, userspace-driven alternative to existing bonding
> driver.
What is the definition of "very" here - relative to bonding I presume?
Are there actual performance figures available at this point? Something
along the lines of test through both on the same hardware. I don't have
HW on which to run myself but would be quite happy to help with say
netperf command selection to demonstrate the difference between the two.
happy benchmrking,
rick jones
^ permalink raw reply
* Re: [patch net-next V8] net: introduce ethernet teaming device
From: Eric Dumazet @ 2011-11-14 18:17 UTC (permalink / raw)
To: Andy Gospodarek
Cc: David Miller, jpirko, netdev, bhutchings, shemminger, fubar,
tgraf, ebiederm, mirqus, kaber, greearb, jesse, fbl,
benjamin.poirier, jzupka, ivecera
In-Reply-To: <20111114173157.GE20605@gospo.rdu.redhat.com>
Le lundi 14 novembre 2011 à 12:31 -0500, Andy Gospodarek a écrit :
> I'm a bit surprised by this. Not only is this new function currently
> difficult to setup (it took me over an hour to go from a a fresh F16
> install to one that had all the necessary libraries and tools to even
> configure a team device for the first time), but I was able to cause an
> Oops with v8 in only a few minutes of testing.
>
> I have no problem with this functionality as an add-on and possibly
> future replacement to some of what currently exists with bonding, but it
> seems like what is included in the initial support should should:
>
> 1. Not panic easily.
> 2. Have userspace bits in place to actually test all the proposed kernel
> code. (Jiri admits there is no way to verify the active-backup code).
> 3. Have some known, published test results.
>
> I hope Jiri will reconsider having a separate team tree for the next few
> weeks or months until these issues are worked out. I think the hard
> work will pay off and it is close to being ready; it just doesn't seem
> like it is right now.
>
Its marked EXPERIMENTAL, so probably some changes are expected before
production mode :)
^ permalink raw reply
* Re: [PATCH 0/5] ks8851 MAC and eeprom updates
From: Stephen Boyd @ 2011-11-14 18:17 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Sebastien Jan, Ben Dooks
In-Reply-To: <1319681870-11972-1-git-send-email-sboyd@codeaurora.org>
On 10/26/11 19:17, Stephen Boyd wrote:
> I pulled this patch series off the netdev list[1] when the eeprom
> reading didn't work for my ks8851 and I wanted the mac address to be
> read out at boot. It all seems to work well, so I'm posting it here
> again, slightly cleaned up and simplified, for inclusion.
[snip]
>
> drivers/misc/eeprom/eeprom_93cx6.c | 88 ++++++
> drivers/net/ethernet/micrel/Kconfig | 2 +
> drivers/net/ethernet/micrel/ks8851.c | 513 ++++++++++++----------------------
> drivers/net/ethernet/micrel/ks8851.h | 15 +-
> include/linux/eeprom_93cx6.h | 8 +
> 5 files changed, 278 insertions(+), 348 deletions(-)
Any comments on this series?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [patch 0/8 2.6.32] CVE-2010-4251: packet backlog can get too large
From: Greg KH @ 2011-11-14 18:11 UTC (permalink / raw)
To: David Miller; +Cc: ben, dan.carpenter, stable, netdev, yi.zhu, eric.dumazet
In-Reply-To: <20111113.222410.315752972470589717.davem@davemloft.net>
On Sun, Nov 13, 2011 at 10:24:10PM -0500, David Miller wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Sun, 13 Nov 2011 23:29:09 +0000
>
> > But you've previously said that you are not submitting networking
> > patches to the longterm series. Did you change your mind?
>
> No, I in fact haven't.
>
> But I will say that if distributions want to apply this thing, that's
> fine, but it doesn't automatically make it a good idea for -stable
> to take it too.
Thanks for letting me know, I'll drop these from my to-apply mbox.
greg k-h
^ permalink raw reply
* [PATCH net-next] Sweep the last of the active .get_drvinfo floors under ethernet/
From: Rick Jones @ 2011-11-14 18:13 UTC (permalink / raw)
To: netdev, Christian Benvenuti, Roopa Prabhu, David Wang,
e1000-devel
From: Rick Jones <rick.jones2@hp.com>
This round of floor sweeping converts strncpy calls in various .get_drvinfo
routines to the preferred strlcpy. It also does a modicum of other
cleaning in those routines.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
---
Compile tested only.
drivers/net/ethernet/cisco/enic/enic_main.c | 8 ++++----
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 13 +++++++------
drivers/net/ethernet/intel/e1000e/ethtool.c | 16 +++++++---------
drivers/net/ethernet/intel/igb/igb_ethtool.c | 15 ++++++---------
drivers/net/ethernet/intel/igbvf/ethtool.c | 12 +++++++-----
drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c | 11 +++++++----
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 16 ++++++----------
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 11 +++++++----
drivers/net/ethernet/sun/cassini.c | 7 +++----
9 files changed, 54 insertions(+), 55 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index c3786fd..1fe5df0 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -217,11 +217,11 @@ static void enic_get_drvinfo(struct net_device *netdev,
enic_dev_fw_info(enic, &fw_info);
- strncpy(drvinfo->driver, DRV_NAME, sizeof(drvinfo->driver));
- strncpy(drvinfo->version, DRV_VERSION, sizeof(drvinfo->version));
- strncpy(drvinfo->fw_version, fw_info->fw_version,
+ strlcpy(drvinfo->driver, DRV_NAME, sizeof(drvinfo->driver));
+ strlcpy(drvinfo->version, DRV_VERSION, sizeof(drvinfo->version));
+ strlcpy(drvinfo->fw_version, fw_info->fw_version,
sizeof(drvinfo->fw_version));
- strncpy(drvinfo->bus_info, pci_name(enic->pdev),
+ strlcpy(drvinfo->bus_info, pci_name(enic->pdev),
sizeof(drvinfo->bus_info));
}
diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
index 2b223ac..63faec6 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -515,14 +515,15 @@ static void e1000_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
- char firmware_version[32];
- strncpy(drvinfo->driver, e1000_driver_name, 32);
- strncpy(drvinfo->version, e1000_driver_version, 32);
+ strlcpy(drvinfo->driver, e1000_driver_name,
+ sizeof(drvinfo->driver));
+ strlcpy(drvinfo->version, e1000_driver_version,
+ sizeof(drvinfo->version));
- sprintf(firmware_version, "N/A");
- strncpy(drvinfo->fw_version, firmware_version, 32);
- strncpy(drvinfo->bus_info, pci_name(adapter->pdev), 32);
+ strlcpy(drvinfo->fw_version, "N/A", sizeof(drvinfo->fw_version));
+ strlcpy(drvinfo->bus_info, pci_name(adapter->pdev),
+ sizeof(drvinfo->bus_info));
drvinfo->regdump_len = e1000_get_regs_len(netdev);
drvinfo->eedump_len = e1000_get_eeprom_len(netdev);
}
diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c b/drivers/net/ethernet/intel/e1000e/ethtool.c
index 69c9d21..6d8f0ed 100644
--- a/drivers/net/ethernet/intel/e1000e/ethtool.c
+++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
@@ -579,26 +579,24 @@ static void e1000_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
- char firmware_version[32];
- strncpy(drvinfo->driver, e1000e_driver_name,
- sizeof(drvinfo->driver) - 1);
+ strlcpy(drvinfo->driver, e1000e_driver_name,
+ sizeof(drvinfo->driver));
strncpy(drvinfo->version, e1000e_driver_version,
- sizeof(drvinfo->version) - 1);
+ sizeof(drvinfo->version));
/*
* EEPROM image version # is reported as firmware version # for
* PCI-E controllers
*/
- snprintf(firmware_version, sizeof(firmware_version), "%d.%d-%d",
+ snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
+ "%d.%d-%d",
(adapter->eeprom_vers & 0xF000) >> 12,
(adapter->eeprom_vers & 0x0FF0) >> 4,
(adapter->eeprom_vers & 0x000F));
- strncpy(drvinfo->fw_version, firmware_version,
- sizeof(drvinfo->fw_version) - 1);
- strncpy(drvinfo->bus_info, pci_name(adapter->pdev),
- sizeof(drvinfo->bus_info) - 1);
+ strlcpy(drvinfo->bus_info, pci_name(adapter->pdev),
+ sizeof(drvinfo->bus_info));
drvinfo->regdump_len = e1000_get_regs_len(netdev);
drvinfo->eedump_len = e1000_get_eeprom_len(netdev);
}
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 43873eb..e9335ef 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -673,25 +673,22 @@ static void igb_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
struct igb_adapter *adapter = netdev_priv(netdev);
- char firmware_version[32];
u16 eeprom_data;
- strncpy(drvinfo->driver, igb_driver_name, sizeof(drvinfo->driver) - 1);
- strncpy(drvinfo->version, igb_driver_version,
- sizeof(drvinfo->version) - 1);
+ strlcpy(drvinfo->driver, igb_driver_name, sizeof(drvinfo->driver));
+ strlcpy(drvinfo->version, igb_driver_version, sizeof(drvinfo->version));
/* EEPROM image version # is reported as firmware version # for
* 82575 controllers */
adapter->hw.nvm.ops.read(&adapter->hw, 5, 1, &eeprom_data);
- sprintf(firmware_version, "%d.%d-%d",
+ snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
+ "%d.%d-%d",
(eeprom_data & 0xF000) >> 12,
(eeprom_data & 0x0FF0) >> 4,
eeprom_data & 0x000F);
- strncpy(drvinfo->fw_version, firmware_version,
- sizeof(drvinfo->fw_version) - 1);
- strncpy(drvinfo->bus_info, pci_name(adapter->pdev),
- sizeof(drvinfo->bus_info) - 1);
+ strlcpy(drvinfo->bus_info, pci_name(adapter->pdev),
+ sizeof(drvinfo->bus_info));
drvinfo->n_stats = IGB_STATS_LEN;
drvinfo->testinfo_len = IGB_TEST_LEN;
drvinfo->regdump_len = igb_get_regs_len(netdev);
diff --git a/drivers/net/ethernet/intel/igbvf/ethtool.c b/drivers/net/ethernet/intel/igbvf/ethtool.c
index 2c25858..e60f1c6 100644
--- a/drivers/net/ethernet/intel/igbvf/ethtool.c
+++ b/drivers/net/ethernet/intel/igbvf/ethtool.c
@@ -191,12 +191,14 @@ static void igbvf_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
struct igbvf_adapter *adapter = netdev_priv(netdev);
- char firmware_version[32] = "N/A";
- strncpy(drvinfo->driver, igbvf_driver_name, 32);
- strncpy(drvinfo->version, igbvf_driver_version, 32);
- strncpy(drvinfo->fw_version, firmware_version, 32);
- strncpy(drvinfo->bus_info, pci_name(adapter->pdev), 32);
+ strlcpy(drvinfo->driver, igbvf_driver_name, sizeof(drvinfo->driver));
+ strlcpy(drvinfo->version, igbvf_driver_version,
+ sizeof(drvinfo->version));
+ strlcpy(drvinfo->fw_version, "N/A",
+ sizeof(drvinfo->fw_version));
+ strlcpy(drvinfo->bus_info, pci_name(adapter->pdev),
+ sizeof(drvinfo->bus_info));
drvinfo->regdump_len = igbvf_get_regs_len(netdev);
drvinfo->eedump_len = igbvf_get_eeprom_len(netdev);
}
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c b/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c
index 9dfce7d..96fcb0e 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c
@@ -473,10 +473,13 @@ ixgb_get_drvinfo(struct net_device *netdev,
{
struct ixgb_adapter *adapter = netdev_priv(netdev);
- strncpy(drvinfo->driver, ixgb_driver_name, 32);
- strncpy(drvinfo->version, ixgb_driver_version, 32);
- strncpy(drvinfo->fw_version, "N/A", 32);
- strncpy(drvinfo->bus_info, pci_name(adapter->pdev), 32);
+ strlcpy(drvinfo->driver, ixgb_driver_name,
+ sizeof(drvinfo->driver));
+ strlcpy(drvinfo->version, ixgb_driver_version,
+ sizeof(drvinfo->version));
+ strlcpy(drvinfo->fw_version, "N/A", sizeof(drvinfo->fw_version));
+ strlcpy(drvinfo->bus_info, pci_name(adapter->pdev),
+ sizeof(drvinfo->bus_info));
drvinfo->n_stats = IXGB_STATS_LEN;
drvinfo->regdump_len = ixgb_get_regs_len(netdev);
drvinfo->eedump_len = ixgb_get_eeprom_len(netdev);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 70d58c3..91f871b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -888,23 +888,19 @@ static void ixgbe_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
- char firmware_version[32];
u32 nvm_track_id;
- strncpy(drvinfo->driver, ixgbe_driver_name,
- sizeof(drvinfo->driver) - 1);
- strncpy(drvinfo->version, ixgbe_driver_version,
- sizeof(drvinfo->version) - 1);
+ strlcpy(drvinfo->driver, ixgbe_driver_name, sizeof(drvinfo->driver));
+ strlcpy(drvinfo->version, ixgbe_driver_version,
+ sizeof(drvinfo->version));
nvm_track_id = (adapter->eeprom_verh << 16) |
adapter->eeprom_verl;
- snprintf(firmware_version, sizeof(firmware_version), "0x%08x",
+ snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version), "0x%08x",
nvm_track_id);
- strncpy(drvinfo->fw_version, firmware_version,
- sizeof(drvinfo->fw_version) - 1);
- strncpy(drvinfo->bus_info, pci_name(adapter->pdev),
- sizeof(drvinfo->bus_info) - 1);
+ strlcpy(drvinfo->bus_info, pci_name(adapter->pdev),
+ sizeof(drvinfo->bus_info));
drvinfo->n_stats = IXGBE_STATS_LEN;
drvinfo->testinfo_len = IXGBE_TEST_LEN;
drvinfo->regdump_len = ixgbe_get_regs_len(netdev);
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index 74e2a2a..ee637a2 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -45,13 +45,16 @@ mlx4_en_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *drvinfo)
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_en_dev *mdev = priv->mdev;
- strncpy(drvinfo->driver, DRV_NAME, 32);
- strncpy(drvinfo->version, DRV_VERSION " (" DRV_RELDATE ")", 32);
- sprintf(drvinfo->fw_version, "%d.%d.%d",
+ strlcpy(drvinfo->driver, DRV_NAME, sizeof(drvinfo->driver));
+ strlcpy(drvinfo->version, DRV_VERSION " (" DRV_RELDATE ")",
+ sizeof(drvinfo->version));
+ snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
+ "%d.%d.%d",
(u16) (mdev->dev->caps.fw_ver >> 32),
(u16) ((mdev->dev->caps.fw_ver >> 16) & 0xffff),
(u16) (mdev->dev->caps.fw_ver & 0xffff));
- strncpy(drvinfo->bus_info, pci_name(mdev->dev->pdev), 32);
+ strlcpy(drvinfo->bus_info, pci_name(mdev->dev->pdev),
+ sizeof(drvinfo->bus_info));
drvinfo->n_stats = 0;
drvinfo->regdump_len = 0;
drvinfo->eedump_len = 0;
diff --git a/drivers/net/ethernet/sun/cassini.c b/drivers/net/ethernet/sun/cassini.c
index fd40988..f10665f 100644
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -4532,10 +4532,9 @@ static void cas_set_multicast(struct net_device *dev)
static void cas_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
{
struct cas *cp = netdev_priv(dev);
- strncpy(info->driver, DRV_MODULE_NAME, ETHTOOL_BUSINFO_LEN);
- strncpy(info->version, DRV_MODULE_VERSION, ETHTOOL_BUSINFO_LEN);
- info->fw_version[0] = '\0';
- strncpy(info->bus_info, pci_name(cp->pdev), ETHTOOL_BUSINFO_LEN);
+ strlcpy(info->driver, DRV_MODULE_NAME, sizeof(info->driver));
+ strlcpy(info->version, DRV_MODULE_VERSION, sizeof(info->version));
+ strlcpy(info->bus_info, pci_name(cp->pdev), sizeof(info->bus_info));
info->regdump_len = cp->casreg_len < CAS_MAX_REGS ?
cp->casreg_len : CAS_MAX_REGS;
info->n_stats = CAS_NUM_STAT_KEYS;
^ permalink raw reply related
* Re: [patch net-next V8] net: introduce ethernet teaming device
From: Andy Gospodarek @ 2011-11-14 17:31 UTC (permalink / raw)
To: David Miller
Cc: jpirko, netdev, eric.dumazet, bhutchings, shemminger, fubar, andy,
tgraf, ebiederm, mirqus, kaber, greearb, jesse, fbl,
benjamin.poirier, jzupka, ivecera
In-Reply-To: <20111113.160951.1905657808657009542.davem@davemloft.net>
On Sun, Nov 13, 2011 at 04:09:51PM -0500, David Miller wrote:
> From: Jiri Pirko <jpirko@redhat.com>
> Date: Sat, 12 Nov 2011 09:16:48 +0100
>
> > This patch introduces new network device called team. It supposes to be
> > very fast, simple, userspace-driven alternative to existing bonding
> > driver.
> >
> > Userspace library called libteam with couple of demo apps is available
> > here:
> > https://github.com/jpirko/libteam
> > Note it's still in its dipers atm.
> >
> > team<->libteam use generic netlink for communication. That and rtnl
> > suppose to be the only way to configure team device, no sysfs etc.
> >
> > Python binding of libteam was recently introduced.
> > Daemon providing arpmon/miimon active-backup functionality will be
> > introduced shortly. All what's necessary is already implemented in
> > kernel team driver.
> >
> > Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
> Applied, thanks for all of your hard work.
I'm a bit surprised by this. Not only is this new function currently
difficult to setup (it took me over an hour to go from a a fresh F16
install to one that had all the necessary libraries and tools to even
configure a team device for the first time), but I was able to cause an
Oops with v8 in only a few minutes of testing.
I have no problem with this functionality as an add-on and possibly
future replacement to some of what currently exists with bonding, but it
seems like what is included in the initial support should should:
1. Not panic easily.
2. Have userspace bits in place to actually test all the proposed kernel
code. (Jiri admits there is no way to verify the active-backup code).
3. Have some known, published test results.
I hope Jiri will reconsider having a separate team tree for the next few
weeks or months until these issues are worked out. I think the hard
work will pay off and it is close to being ready; it just doesn't seem
like it is right now.
^ 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