* [PATCH 8/8 V2] rtlwifi: Remove variable 'noise' from rtl_stats struct
From: Larry Finger @ 2013-09-16 18:55 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Larry Finger,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1379357722-17687-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
All uses of this variable have been removed. Now delete it from the struct
and from a few places that use it in commented-out lines.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
---
drivers/net/wireless/rtlwifi/rtl8188ee/trx.c | 1 -
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 1 -
drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 1 -
drivers/net/wireless/rtlwifi/rtl8723ae/trx.c | 1 -
drivers/net/wireless/rtlwifi/wifi.h | 1 -
5 files changed, 5 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c b/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c
index a8871d6..5e628ab 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/trx.c
@@ -477,7 +477,6 @@ bool rtl88ee_rx_query_desc(struct ieee80211_hw *hw,
/*rx_status->qual = status->signal; */
rx_status->signal = status->recvsignalpower + 10;
- /*rx_status->noise = -status->noise; */
if (status->packet_report_type == TX_REPORT2) {
status->macid_valid_entry[0] =
GET_RX_RPT2_DESC_MACID_VALID_1(pdesc);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
index 6ad23b4..52abf0a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
@@ -420,7 +420,6 @@ bool rtl92ce_rx_query_desc(struct ieee80211_hw *hw,
/*rx_status->qual = stats->signal; */
rx_status->signal = stats->recvsignalpower + 10;
- /*rx_status->noise = -stats->noise; */
return true;
}
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
index c709511..222d2e7 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
@@ -330,7 +330,6 @@ bool rtl92se_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *stats,
/*rx_status->qual = stats->signal; */
rx_status->signal = stats->rssi + 10;
- /*rx_status->noise = -stats->noise; */
return true;
}
diff --git a/drivers/net/wireless/rtlwifi/rtl8723ae/trx.c b/drivers/net/wireless/rtlwifi/rtl8723ae/trx.c
index c72758d..e85ec21 100644
--- a/drivers/net/wireless/rtlwifi/rtl8723ae/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8723ae/trx.c
@@ -359,7 +359,6 @@ bool rtl8723ae_rx_query_desc(struct ieee80211_hw *hw,
/*rx_status->qual = status->signal; */
rx_status->signal = status->recvsignalpower + 10;
- /*rx_status->noise = -status->noise; */
return true;
}
diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h
index cc03e7c..284ee8d 100644
--- a/drivers/net/wireless/rtlwifi/wifi.h
+++ b/drivers/net/wireless/rtlwifi/wifi.h
@@ -1535,7 +1535,6 @@ struct rtl_stats {
u32 mac_time[2];
s8 rssi;
u8 signal;
- u8 noise;
u8 rate; /* hw desc rate */
u8 received_channel;
u8 control;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/8i V2] rtlwifi: Patches to fix problems shown by smatch
From: Larry Finger @ 2013-09-16 18:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
Fix smatch warnings and errors in the rtlwifi family of drivers.
V2 addresses comments by David Laight and Sergei Shtylyov.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Larry Finger (8):
rtlwifi: rtl8192du: Fix smatch errors in /rtl8192de/dm.c
rtlwifi: rtl8192de: Fix smatch warnings in rtl8192de/hw.c
rtlwifi: rtl8192cu: Fix smatch warning in rtl8192cu/trx.c
rtlwifi: rtl8192_common: Fix smatch errors and warnings in
rtl8192c/dm_common.c
[PATCH 5/7: rtlwifi: Fix smatch warning in pci.c
rtlwifi: Fix smatch warnings in usb.c
rtlwifi: rtl8188ee: Fix smatch warning in rtl8188ee/hw.c
rtlwifi: Remove variable 'noise' from rtl_stats struct
drivers/net/wireless/rtlwifi/pci.c | 1 -
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c | 1 +
drivers/net/wireless/rtlwifi/rtl8188ee/trx.c | 1 -
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c | 4 +++-
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 1 -
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 2 --
drivers/net/wireless/rtlwifi/rtl8192de/dm.c | 8 ++++++--
drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 2 ++
drivers/net/wireless/rtlwifi/rtl8192de/trx.c | 1 -
drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 1 -
drivers/net/wireless/rtlwifi/rtl8723ae/trx.c | 1 -
drivers/net/wireless/rtlwifi/usb.c | 8 +++++---
drivers/net/wireless/rtlwifi/wifi.h | 1 -
13 files changed, 17 insertions(+), 15 deletions(-)
--
1.8.1.4
^ permalink raw reply
* [PATCH 1/8 V2] rtlwifi: rtl8192du: Fix smatch errors in /rtl8192de/dm.c
From: Larry Finger @ 2013-09-16 18:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
In-Reply-To: <1379357722-17687-1-git-send-email-Larry.Finger@lwfinger.net>
Smatch lists the following:
CHECK drivers/net/wireless/rtlwifi/rtl8192de/dm.c
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1054 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'ofdm_index' 2 <= 2
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1056 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'ofdm_index' 2 <= 2
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1126 rtl92d_dm_txpower_tracking_callback_thermalmeter() debug: remove_pools: nr_children over 4000 (4596). (rtlpriv->dbg.global_debuglevel merged)
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1126 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1129 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1132 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1135 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1138 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1141 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1144 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1147 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1151 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1154 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1157 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1160 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1163 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1166 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1169 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1172 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
This patch fixes several off-by-one errors. It also removes a commented-out line
referincing variable 'noise'. That variable will be removed later in this patch
set.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/rtl8192de/dm.c | 8 ++++++--
drivers/net/wireless/rtlwifi/rtl8192de/trx.c | 1 -
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/dm.c b/drivers/net/wireless/rtlwifi/rtl8192de/dm.c
index 47875ba..eaeee77 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/dm.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/dm.c
@@ -840,9 +840,9 @@ static void rtl92d_dm_txpower_tracking_callback_thermalmeter(
bool internal_pa = false;
long ele_a = 0, ele_d, temp_cck, val_x, value32;
long val_y, ele_c = 0;
- u8 ofdm_index[2];
+ u8 ofdm_index[3];
s8 cck_index = 0;
- u8 ofdm_index_old[2] = {0, 0};
+ u8 ofdm_index_old[3] = {0, 0, 0};
s8 cck_index_old = 0;
u8 index;
int i;
@@ -1118,6 +1118,10 @@ static void rtl92d_dm_txpower_tracking_callback_thermalmeter(
val_x, val_y, ele_a, ele_c, ele_d,
val_x, val_y);
+ if (cck_index >= CCK_TABLE_SIZE)
+ cck_index = CCK_TABLE_SIZE - 1;
+ if (cck_index < 0)
+ cck_index = 0;
if (rtlhal->current_bandtype == BAND_ON_2_4G) {
/* Adjust CCK according to IQK result */
if (!rtlpriv->dm.cck_inch14) {
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/trx.c b/drivers/net/wireless/rtlwifi/rtl8192de/trx.c
index b8ec718..945ddec 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/trx.c
@@ -526,7 +526,6 @@ bool rtl92de_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *stats,
}
/*rx_status->qual = stats->signal; */
rx_status->signal = stats->rssi + 10;
- /*rx_status->noise = -stats->noise; */
return true;
}
--
1.8.1.4
^ permalink raw reply related
* [PATCH 3/8 V2] rtlwifi: rtl8192cu: Fix smatch warning in rtl8192cu/trx.c
From: Larry Finger @ 2013-09-16 18:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
In-Reply-To: <1379357722-17687-1-git-send-email-Larry.Finger@lwfinger.net>
Smatch lists the following:
CHECK drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c:367 _rtl_rx_process() warn: assigning (-98) to unsigned variable 'stats.noise'
This variable is unused, thus it is removed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
index 763cf1d..04c7e57 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
@@ -349,7 +349,6 @@ bool rtl92cu_rx_query_desc(struct ieee80211_hw *hw,
}
/*rx_status->qual = stats->signal; */
rx_status->signal = stats->rssi + 10;
- /*rx_status->noise = -stats->noise; */
return true;
}
@@ -364,7 +363,6 @@ static void _rtl_rx_process(struct ieee80211_hw *hw, struct sk_buff *skb)
u8 *rxdesc;
struct rtl_stats stats = {
.signal = 0,
- .noise = -98,
.rate = 0,
};
struct rx_fwinfo_92c *p_drvinfo;
--
1.8.1.4
^ permalink raw reply related
* [PATCH 7/8 V2] rtlwifi: rtl8188ee: Fix smatch warning in rtl8188ee/hw.c
From: Larry Finger @ 2013-09-16 18:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Stable
In-Reply-To: <1379357722-17687-1-git-send-email-Larry.Finger@lwfinger.net>
Smatch lists the following:
CHECK drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c:149 _rtl88ee_set_fw_clock_on() info: ignoring unreachable code.
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c:149 _rtl88ee_set_fw_clock_on() info: ignoring unreachable code.
This info message is the result of a real error due to a missing break statement
in a "while (1)" loop.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [3.10+]
---
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
index b68cae3..e06971b 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
@@ -143,6 +143,7 @@ static void _rtl88ee_set_fw_clock_on(struct ieee80211_hw *hw,
} else {
rtlhal->fw_clk_change_in_progress = false;
spin_unlock_bh(&rtlpriv->locks.fw_ps_lock);
+ break;
}
}
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH 4/8 V2] rtlwifi: rtl8192_common: Fix smatch errors and warnings in rtl8192c/dm_common.c
From: Sergei Shtylyov @ 2013-09-16 19:02 UTC (permalink / raw)
To: Larry Finger
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1379357722-17687-5-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Hello.
On 09/16/2013 10:55 PM, Larry Finger wrote:
> Smatch lists the following:
> CHECK drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor() info: ignoring unreachable code.
> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor() info: ignoring unreachable code.
> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:882 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:883 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:891 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:892 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
> The unreachable code message is fixed by commenting out the code that follows a return.
You've commented out the whole function body, where is the *return* you're
talking about?
> The code is not deleted in case it is needed later.
> The errors are fixed by increasing the size of txpwr_level.
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> index d2d57a2..0721756 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> @@ -541,6 +541,7 @@ EXPORT_SYMBOL(rtl92c_dm_write_dig);
>
> static void rtl92c_dm_pwdb_monitor(struct ieee80211_hw *hw)
> {
> +/*
> struct rtl_priv *rtlpriv = rtl_priv(hw);
> long tmpentry_max_pwdb = 0, tmpentry_min_pwdb = 0xff;
>
> @@ -564,6 +565,7 @@ static void rtl92c_dm_pwdb_monitor(struct ieee80211_hw *hw)
> h2c_parameter[0] = 0;
>
> rtl92c_fill_h2c_cmd(hw, H2C_RSSI_REPORT, 3, h2c_parameter);
> + */
> }
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 5/8 V2] [PATCH 5/7: rtlwifi: Fix smatch warning in pci.c
From: Sergei Shtylyov @ 2013-09-16 19:04 UTC (permalink / raw)
To: Larry Finger
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1379357722-17687-6-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On 09/16/2013 10:55 PM, Larry Finger wrote:
> Smatch reports the following:
> CHECK drivers/net/wireless/rtlwifi/pci.c
> drivers/net/wireless/rtlwifi/pci.c:739 _rtl_pci_rx_interrupt() warn: assigning (-98) to unsigned variable 'stats.noise'
> This variable is not used and is removed.
It is not a variable but a structure field initializer you're removing.
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
> drivers/net/wireless/rtlwifi/pci.c | 1 -
> 1 file changed, 1 deletion(-)
> diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
> index 703f839..6295ed2 100644
> --- a/drivers/net/wireless/rtlwifi/pci.c
> +++ b/drivers/net/wireless/rtlwifi/pci.c
> @@ -736,7 +736,6 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
>
> struct rtl_stats stats = {
> .signal = 0,
> - .noise = -98,
> .rate = 0,
> };
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/8 V2] rtlwifi: rtl8192cu: Fix smatch warning in rtl8192cu/trx.c
From: Sergei Shtylyov @ 2013-09-16 19:05 UTC (permalink / raw)
To: Larry Finger
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1379357722-17687-4-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On 09/16/2013 10:55 PM, Larry Finger wrote:
> Smatch lists the following:
> CHECK drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
> drivers/net/wireless/rtlwifi/rtl8192cu/trx.c:367 _rtl_rx_process() warn: assigning (-98) to unsigned variable 'stats.noise'
> This variable is unused, thus it is removed.
It's a structure field initializer you're removing, not a variable. And
also a comment.
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
> drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 2 --
> 1 file changed, 2 deletions(-)
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
> index 763cf1d..04c7e57 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
> @@ -349,7 +349,6 @@ bool rtl92cu_rx_query_desc(struct ieee80211_hw *hw,
> }
> /*rx_status->qual = stats->signal; */
> rx_status->signal = stats->rssi + 10;
> - /*rx_status->noise = -stats->noise; */
> return true;
> }
>
> @@ -364,7 +363,6 @@ static void _rtl_rx_process(struct ieee80211_hw *hw, struct sk_buff *skb)
> u8 *rxdesc;
> struct rtl_stats stats = {
> .signal = 0,
> - .noise = -98,
> .rate = 0,
> };
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/8 V2] rtlwifi: rtl8192_common: Fix smatch errors and warnings in rtl8192c/dm_common.c
From: Larry Finger @ 2013-09-16 19:07 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linville, linux-wireless, netdev
In-Reply-To: <523755D1.2010003@cogentembedded.com>
On 09/16/2013 02:02 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 09/16/2013 10:55 PM, Larry Finger wrote:
>
>> Smatch lists the following:
>> CHECK drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor()
>> info: ignoring unreachable code.
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor()
>> info: ignoring unreachable code.
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:882
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:883
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:891
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:892
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>
>> The unreachable code message is fixed by commenting out the code that follows
>> a return.
>
> You've commented out the whole function body, where is the *return* you're
> talking about?
The return is in the middle of the function body just after the variable
declarations. It does not show in the diff listing, but it is there. What should
I do?
Larry
^ permalink raw reply
* Re: [PATCH 6/8 V2] rtlwifi: Fix smatch warnings in usb.c
From: Sergei Shtylyov @ 2013-09-16 19:07 UTC (permalink / raw)
To: Larry Finger
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1379357722-17687-7-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On 09/16/2013 10:55 PM, Larry Finger wrote:
> Smatch displays the following:
> CHECK drivers/net/wireless/rtlwifi/usb.c
> drivers/net/wireless/rtlwifi/usb.c:458 _rtl_usb_rx_process_agg() warn: assigning (-98) to unsigned variable 'stats.noise'
> drivers/net/wireless/rtlwifi/usb.c:503 _rtl_usb_rx_process_noagg() warn: assigning (-98) to unsigned variable 'stats.noise'
> drivers/net/wireless/rtlwifi/usb.c:596 _rtl_rx_get_padding() info: ignoring unreachable code.
> drivers/net/wireless/rtlwifi/usb.c:596 _rtl_rx_get_padding() info: ignoring unreachable code.
> The negative number to an unsigned quantity is fixed by removing the variable
> as it is no longer used.
You're removing only structure field initializer, not a variable.
> The unreachable code info is fixed by including the
> appropriate section inside #ifdef .. #endif constructions.
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
> drivers/net/wireless/rtlwifi/usb.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
> diff --git a/drivers/net/wireless/rtlwifi/usb.c b/drivers/net/wireless/rtlwifi/usb.c
> index e56778c..60cb0b4 100644
> --- a/drivers/net/wireless/rtlwifi/usb.c
> +++ b/drivers/net/wireless/rtlwifi/usb.c
> @@ -455,7 +455,6 @@ static void _rtl_usb_rx_process_agg(struct ieee80211_hw *hw,
> struct ieee80211_rx_status rx_status = {0};
> struct rtl_stats stats = {
> .signal = 0,
> - .noise = -98,
> .rate = 0,
> };
>
> @@ -498,7 +497,6 @@ static void _rtl_usb_rx_process_noagg(struct ieee80211_hw *hw,
> struct ieee80211_rx_status rx_status = {0};
> struct rtl_stats stats = {
> .signal = 0,
> - .noise = -98,
> .rate = 0,
> };
>
> @@ -582,12 +580,15 @@ static void _rtl_rx_work(unsigned long param)
> static unsigned int _rtl_rx_get_padding(struct ieee80211_hdr *hdr,
> unsigned int len)
> {
> +#if NET_IP_ALIGN != 0
> unsigned int padding = 0;
> +#endif
>
> /* make function no-op when possible */
> - if (NET_IP_ALIGN == 0 || len < sizeof(*hdr))
> + if (NET_IP_ALIGN == 0 || len < sizeof(struct ieee80211_hdr))
Hm, I thought you were going to remove this collateral change.
> return 0;
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/8 V2] rtlwifi: rtl8192_common: Fix smatch errors and warnings in rtl8192c/dm_common.c
From: Sergei Shtylyov @ 2013-09-16 19:10 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev
In-Reply-To: <523756DB.90507@lwfinger.net>
Hello.
On 09/16/2013 11:07 PM, Larry Finger wrote:
>>> Smatch lists the following:
>>> CHECK drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor()
>>> info: ignoring unreachable code.
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor()
>>> info: ignoring unreachable code.
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:882
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:883
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:891
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:892
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> The unreachable code message is fixed by commenting out the code that follows
>>> a return.
>> You've commented out the whole function body, where is the *return* you're
>> talking about?
> The return is in the middle of the function body just after the variable
> declarations. It does not show in the diff listing, but it is there. What
> should I do?
Just describe what you really did, I guess.
> Larry
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 5/8 V2] [PATCH 5/7: rtlwifi: Fix smatch warning in pci.c
From: Sergei Shtylyov @ 2013-09-16 19:11 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev
In-Reply-To: <5237562D.4080509@cogentembedded.com>
On 09/16/2013 11:04 PM, Sergei Shtylyov wrote:
>> Smatch reports the following:
>> CHECK drivers/net/wireless/rtlwifi/pci.c
>> drivers/net/wireless/rtlwifi/pci.c:739 _rtl_pci_rx_interrupt() warn:
>> assigning (-98) to unsigned variable 'stats.noise'
>> This variable is not used and is removed.
> It is not a variable but a structure field initializer you're removing.
Meant to also write that your subject is spoiled but forgot. :-)
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] ethernet/arc/arc_emac: Fix huge delays in large file copies
From: greg Kroah-Hartman @ 2013-09-16 19:40 UTC (permalink / raw)
To: Vineet Gupta
Cc: David Miller, netdev, Alexey.Brodkin, linux-kernel,
stable@vger.kernel.org
In-Reply-To: <52369A94.5060900@synopsys.com>
On Mon, Sep 16, 2013 at 11:13:48AM +0530, Vineet Gupta wrote:
> On 09/10/2013 11:57 AM, Vineet Gupta wrote:
> > On 09/05/2013 11:55 PM, David Miller wrote:
> >> From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
> >> Date: Wed, 4 Sep 2013 17:17:15 +0530
> >>
> >>> copying large files to a NFS mounted host was taking absurdly large
> >>> time.
> >>>
> >>> Turns out that TX BD reclaim had a sublte bug.
> >>>
> >>> Loop starts off from @txbd_dirty cursor and stops when it hits a BD
> >>> still in use by controller. However when it stops it needs to keep the
> >>> cursor at that very BD to resume scanning in next iteration. However it
> >>> was erroneously incrementing the cursor, causing the next scan(s) to
> >>> fail too, unless the BD chain was completely drained out.
> >>>
> >>> [ARCLinux]$ ls -l -sh /disk/log.txt
> >>> 17976 -rw-r--r-- 1 root root 17.5M Sep /disk/log.txt
> >>>
> >>> ========== Before =====================
> >>> [ARCLinux]$ time cp /disk/log.txt /mnt/.
> >>> real 31m 7.95s
> >>> user 0m 0.00s
> >>> sys 0m 0.10s
> >>>
> >>> ========== After =====================
> >>> [ARCLinux]$ time cp /disk/log.txt /mnt/.
> >>> real 0m 24.33s
> >>> user 0m 0.00s
> >>> sys 0m 0.19s
> >>>
> >>> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
> >>
> >> Applied.
> >>
> >
> > Hi Greg,
> >
> > This needs a stable backport (3.11).
> > Mainline commit 27082ee1b92f4d41e78b85
> >
> > Thx,
> > -Vineet
>
> Hi Greg,
>
> I didn't spot this one in your stable-queue for 3.11.
> Please apply.
Network patches for the stable tree needs to go through the networking
maintainer. Please let them know about this and they will forward it on
to me if needed.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/1] net: race condition when removing virtual net_device
From: Francesco Ruggeri @ 2013-09-16 20:30 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David S. Miller, Eric Dumazet, Jiri Pirko, Alexander Duyck,
Cong Wang, netdev
In-Reply-To: <87six5kpu5.fsf@xmission.com>
On Mon, Sep 16, 2013 at 3:45 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> I believe the weird reordering of veth devices is solved or largely
> solved by:
>
> commit f45a5c267da35174e22cec955093a7513dc1623d
I looked at d0e2c55e and f45a5c26 in the past and I do not think they
are related to the problem I see, which I think is more related to the
infrastructure. See more below.
>
>> and this is the sequence after pushing the loopback_devs to the tail
>> of net_todo_list:
>>
>> unregister_netdevice_queue: v0 (ns ffff8800379f8000)
>> unregister_netdevice_queue: v1 (ns ffff8800378c0b00)
>> unregister_netdevice_queue: lo (ns ffff8800379f8000)
>> unregister_netdevice_queue: v1 (ns ffff8800378c0b00)
>> unregister_netdevice_queue: v0 (ns ffff8800379f8000)
>> unregister_netdevice_queue: lo (ns ffff8800378c0b00)
>> unregister_netdevice_many: lo (ns ffff8800379f8000) v1 (ns
>> ffff8800378c0b00) v0 (ns ffff8800379f8000) lo (ns ffff8800378c0b00)
>> netdev_run_todo: v1 (ns ffff8800378c0b00) v0 (ns ffff8800379f8000) lo
>> (ns ffff8800379f8000) lo (ns ffff8800378c0b00)
>
> I am scratching my head. That isn't what I would expect from putting
> loopback devices at the end of the list.
The way to read it is as follows:
unregister_netdevice_many gets the sequence lo0 v1 v0 lo1 (lo0 is the
occurrence of "lo" with the same namespace as v0, etc.).
As the interfaces are unlisted the loopback_devs are queued at the end
of net_todo_list, so when netdev_run_todo executes net_todo_list is v1
v0 lo0 lo1.
>
> Even more I am not comfortable with any situation where preserving the
> order in which the devices are unregistered is not sufficient to make
> things work correctly. That quickly gets into fragile layering
> problems, and I don't know how anyone would be able to maintain that.
>
I agree with your general statement, but unfortunately the order in
which the interfaces are unregistered is not preserved even in the
current code, since dev_close_many already rearranges them based on
whether they are UP or not.
If I delete a namespace with only lo and v0 this is the order in which
they are released depending on their state. If lo is DOWN then it will
be processed before v0 in netdev_run_todo.
====== lo down, v0 down
unregister_netdevice_queue: v0 (ns ffff880037bb0b00)
unregister_netdevice_queue: lo (ns ffff880037bb0b00)
unregister_netdevice_many: v0 (ns ffff880037bb0b00) lo (ns ffff880037bb0b00)
netdev_run_todo: lo (ns ffff880037bb0b00) v0 (ns ffff880037bb0b00)
====== lo up, v0 down
unregister_netdevice_queue: v0 (ns ffff8800378a9600)
unregister_netdevice_queue: lo (ns ffff8800378a9600)
unregister_netdevice_many: v0 (ns ffff8800378a9600) lo (ns ffff8800378a9600)
netdev_run_todo: v0 (ns ffff8800378a9600) lo (ns ffff8800378a9600)
====== lo down, v0 up
unregister_netdevice_queue: v0 (ns ffff880037bb0b00)
unregister_netdevice_queue: lo (ns ffff880037bb0b00)
unregister_netdevice_many: v0 (ns ffff880037bb0b00) lo (ns ffff880037bb0b00)
netdev_run_todo: lo (ns ffff880037bb0b00) v0 (ns ffff880037bb0b00)
====== lo up, v0 up
unregister_netdevice_queue: v0 (ns ffff8800378a9600)
unregister_netdevice_queue: lo (ns ffff8800378a9600)
unregister_netdevice_many: v0 (ns ffff8800378a9600) lo (ns ffff8800378a9600)
netdev_run_todo: v0 (ns ffff8800378a9600) lo (ns ffff8800378a9600)
> I still don't see a better solution than dev_change_net_namespace,
> for the network devices that have this problem. Network devices are not
> supposed to be findable after the dance at the start of cleanup_net.
>
I think the problem we are seeing is an infrastructure one. If I can restate it:
1) When destroying a namespace all net_devices in it should be
disposed of before any non-device pernet subsystems exit. The existing
code tries to do this but it does not take into consideration
net_devices that may have been unlisted from the namespace by another
process which is still in the process of destroying them (specifically
in netdev_run_todo/netdev_wait_allrefs).
There is also another issue, separate but related (my diffs did not
try to address it):
2) dev_change_net_namespace does not have the equivalent of
netdev_wait_allrefs. If rebroadcasts are in fact needed when
destroying a net_device then the same should apply when the net_device
is moved out of a namespace. With existing code a net_device can be
moved to a different namespace before its refcount drops to 0. Any
later broadcasts will not trigger any action in the original namespace
where they should have occurred.
I suspect that this is not catastrophic but its effects could be
subtle. This is another reason why I would avoid using
dev_change_net_namespace as a driver level solution for 1) above,
besides the fact that we would have to apply it to all drivers
affected by this (veth, vlan, macvlan, maybe more).
> It might be possible to actually build asynchronous network device
> unregistration and opportunistick batching. Aka cleanup network devices
> much like we clean up network namespaces now, and by funnelling them all
> into a single threaded work queue that would probably stop the races, as
> well as improve performance. I don't have the energy to do that right
> now unfortunately :(
>
That would probably solve it, but as you suggest it will take a
considerable amount of work and code re-structuring.
Francesco
^ permalink raw reply
* PATCH: periodictimer for mrp.c
From: Noel Burton-Krahn @ 2013-09-16 20:32 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
(originally to "David S. Miller" <davem@davemloft.net>, CC'ed to
netdev. Resent in text/plain)
I ran into a problem when testing MVRP support in net/mrp.c: MRP
would transmit JoinIn messages before the network interface was fully
up, the packets would be lost, and MRP would never retry. It looks
like the MRP implementation was missing the periodictimer defined in
[802.1Q-2011] to retry if packets get lost. The attached patch patch
adds the periodictimer.
Note: As far as I can tell in [802.1Q-2011], the periodic timer never
turns off. It fires every second, causing MRP to bounce from state QA
to AA and back. You might think that would stop when the registrar
responds with an JoinIn, but there's no state in the MRP state table
to ignore the periodic timer after getting a reply. The result is MRP
sends a JoinIn message every second. This may not be desirable, but
it's what the spec requires.
[802.1Q-2011]
http://standards.ieee.org/findstds/standard/802.1Q-2011.html
Does this look OK to you?
--
Noel
[-- Attachment #2: mrp-periodictimer.patch --]
[-- Type: application/octet-stream, Size: 2955 bytes --]
diff --git a/include/net/mrp.h b/include/net/mrp.h
index 4fbf02a..0f7558b 100644
--- a/include/net/mrp.h
+++ b/include/net/mrp.h
@@ -112,6 +112,7 @@ struct mrp_applicant {
struct mrp_application *app;
struct net_device *dev;
struct timer_list join_timer;
+ struct timer_list periodic_timer;
spinlock_t lock;
struct sk_buff_head queue;
diff --git a/net/802/mrp.c b/net/802/mrp.c
index 1eb05d8..97566ec 100644
--- a/net/802/mrp.c
+++ b/net/802/mrp.c
@@ -24,6 +24,11 @@
static unsigned int mrp_join_time __read_mostly = 200;
module_param(mrp_join_time, uint, 0644);
MODULE_PARM_DESC(mrp_join_time, "Join time in ms (default 200ms)");
+
+static unsigned int mrp_periodic_time __read_mostly = 1000;
+module_param(mrp_periodic_time, uint, 0644);
+MODULE_PARM_DESC(mrp_periodic_time, "Periodic time in ms (default 1s)");
+
MODULE_LICENSE("GPL");
static const u8
@@ -595,6 +600,43 @@ static void mrp_join_timer(unsigned long data)
mrp_join_timer_arm(app);
}
+static void mrp_periodic_timer_arm(struct mrp_applicant *app)
+{
+ unsigned long delay;
+
+ delay = (u64)msecs_to_jiffies(mrp_periodic_time);
+ mod_timer(&app->periodic_timer, jiffies + delay);
+}
+
+
+/*
+ Added periodic timer from [802.1Q-2011] to retry if MRP loses
+ messages. MRP used to lose JoinIn messages and never retry if it
+ sent messages before the interface becomes ready.
+
+ The periodic timer from the 802.1Q spec never turns off. It fires
+ every second, causing MRP to bounce from state QA to AA and back.
+ You might think that would stop when the registrar responds with an
+ JoinIn, but there's no state in the MRP state table to ignore the
+ periodic timer after getting a reply. The result is MRP sends a
+ JoinIn message every second. This may not be desirable, but it's
+ what the spec requires.
+
+ [802.1Q-2011]
+ http://standards.ieee.org/findstds/standard/802.1Q-2011.html
+*/
+static void mrp_periodic_timer(unsigned long data)
+{
+ struct mrp_applicant *app = (struct mrp_applicant *)data;
+
+ spin_lock(&app->lock);
+ mrp_mad_event(app, MRP_EVENT_PERIODIC);
+ mrp_pdu_queue(app);
+ spin_unlock(&app->lock);
+
+ mrp_periodic_timer_arm(app);
+}
+
static int mrp_pdu_parse_end_mark(struct sk_buff *skb, int *offset)
{
__be16 endmark;
@@ -845,6 +887,8 @@ int mrp_init_applicant(struct net_device *dev, struct mrp_application *appl)
rcu_assign_pointer(dev->mrp_port->applicants[appl->type], app);
setup_timer(&app->join_timer, mrp_join_timer, (unsigned long)app);
mrp_join_timer_arm(app);
+ setup_timer(&app->periodic_timer, mrp_periodic_timer, (unsigned long)app);
+ mrp_periodic_timer_arm(app);
return 0;
err3:
@@ -870,6 +914,7 @@ void mrp_uninit_applicant(struct net_device *dev, struct mrp_application *appl)
* all pending messages before the applicant is gone.
*/
del_timer_sync(&app->join_timer);
+ del_timer_sync(&app->periodic_timer);
spin_lock_bh(&app->lock);
mrp_mad_event(app, MRP_EVENT_TX);
^ permalink raw reply related
* Re: [PATCH v2.39 7/7] datapath: Add basic MPLS support to kernel
From: Jesse Gross @ 2013-09-16 20:38 UTC (permalink / raw)
To: Simon Horman, Ben Pfaff, Pravin Shelar
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, netdev, Ravi K,
Isaku Yamahata
In-Reply-To: <1378711207-29890-8-git-send-email-horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
On Mon, Sep 9, 2013 at 12:20 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> diff --git a/datapath/actions.c b/datapath/actions.c
> index 6741d81..2335014 100644
> --- a/datapath/actions.c
> +++ b/datapath/actions.c
> +/* Push MPLS after the ethernet header. */
> +static int push_mpls(struct sk_buff *skb,
> + const struct ovs_action_push_mpls *mpls)
[...]
> + /* update mac_len for subsequent pop_mpls actions. */
> + skb->mac_len += VLAN_HLEN;
Is this supposed to be part of put_vlan()?
[...]
> + if (skb->ip_summed == CHECKSUM_COMPLETE)
> + skb->csum = csum_add(skb->csum, csum_partial(new_mpls_lse,
> + MPLS_HLEN, 0));
> +
> + hdr = (struct ethhdr *)(skb_mac_header(skb));
I think you could simplify this by using eth_hdr().
> @@ -616,6 +736,13 @@ int ovs_execute_actions(struct datapath *dp, struct sk_buff *skb)
> goto out_loop;
> }
>
> + /* Needed to initialise inner protocol on kernels older
> + * than v3.11 where skb->inner_protocol is not present
> + * and compatibility code uses the OVS_CB(skb) to store
> + * the inner protocol.
> + */
> + ovs_skb_set_inner_protocol(skb, skb->protocol);
The comment makes it sound like this code should just be deleted when
upstreaming. However, I believe that we still need to initialize this
field, right? Is this the best place do it or should it be conditional
on adding a first MPLS header? (i.e. what happens if inner_protocol is
already set and the packet simply passes through OVS?)
> diff --git a/datapath/vport-netdev.c b/datapath/vport-netdev.c
> index 215a47e..69f24d1 100644
> --- a/datapath/vport-netdev.c
> +++ b/datapath/vport-netdev.c
> @@ -287,8 +291,17 @@ static int netdev_send(struct vport *vport, struct sk_buff *skb)
> + inner_protocol = ovs_skb_get_inner_protocol(skb);
> + if (eth_p_mpls(skb->protocol) && !eth_p_mpls(inner_protocol))
> + mpls = true;
> +
> + if (vlan_tx_tag_present(skb) && !dev_supports_vlan_tx(skb->dev))
> + vlan = true;
A couple of thoughts on this:
- I'm not sure that the check on inner_protocol is right since I
don't think it will be set to an MPLS EtherType in any real situation.
I think you can just drop it.
- Can we simplify the loop by just inserting the vlan tag (if
necessary), calling skb_gso_segment(), and sending the packet? I think
it should be possible now that our skb_gso_segment() backport is more
robust and it would make things easier to read.
- Can we have some kind of version check for MPLS, similar to what we
do for VLAN, so that we don't call into this on kernels >= 3.11?
These are all pretty targeted comments though, as was the one in the
previous kernel patch so I am basically happy with this overall.
To move forward with this:
- Pravin, would you mind double checking the GSO compat code?
- Ben, do you want to take over for the userspace portions of the
series on the assumption that the above comments can be fixed fairly
easily?
^ permalink raw reply
* Re: [PATCH v2.39 7/7] datapath: Add basic MPLS support to kernel
From: Ben Pfaff @ 2013-09-16 20:46 UTC (permalink / raw)
To: Jesse Gross
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Ravi K, netdev,
Isaku Yamahata
In-Reply-To: <CAEP_g=8FBQPZ=C6G39YdHRzG57m5MqfXSZFAX2S_KLHRwfzc2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Sep 16, 2013 at 03:38:21PM -0500, Jesse Gross wrote:
> - Ben, do you want to take over for the userspace portions of the
> series on the assumption that the above comments can be fixed fairly
> easily?
Yes, that's fine. Simon, I guess that you are looking at Jesse's
comments about mpls_depth from earlier?
^ permalink raw reply
* Re: [patch 1/4] drivers/net/ethernet/ibm/ehea/ehea_main.c: add alias entry for portN properties
From: Thadeu Lima de Souza Cascardo @ 2013-09-16 20:55 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, ohering, jeffm, jslaby
In-Reply-To: <20130913.195857.1842211951469893139.davem@davemloft.net>
On Fri, Sep 13, 2013 at 07:58:57PM -0400, David Miller wrote:
> From: akpm@linux-foundation.org
> Date: Fri, 13 Sep 2013 14:52:01 -0700
>
> > From: Olaf Hering <ohering@suse.com>
> > Subject: drivers/net/ethernet/ibm/ehea/ehea_main.c: add alias entry for portN properties
> >
> > Use separate table for alias entries in the ehea module, otherwise the
> > probe() function will operate on the separate ports instead of the
> > lhea-"root" entry of the device-tree
> >
> > Addresses https://bugzilla.novell.com/show_bug.cgi?id=435215
> >
> > Signed-off-by: Jeff Mahoney <jeffm@suse.com>
> > Signed-off-by: Olaf Hering <ohering@suse.com>
> > Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> > Cc: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> This can definitely have consequences and in particular potentially cause
> a device to not get probed properly.
>
> Therefore I want an ehea driver maintainer to review and ACK this before
> I apply it.
>
> Thanks.
>
After taking a glance at the patch, it doesn't seem to change probing,
since it keeps the same table for the driver itself. It seems this only
changes alias, so the driver will be loaded under some device-tree
layouts not currently matched by the current alias.
That last part is the one that bothers me. I still need to find a system
where the current modalias won't work and this patch is needed. I'll see
if I can put more effort into that and find a system as described in the
bug.
Regards.
Thadeu Cascardo.
^ permalink raw reply
* Re: [patch 1/4] drivers/net/ethernet/ibm/ehea/ehea_main.c: add alias entry for portN properties
From: Thadeu Lima de Souza Cascardo @ 2013-09-16 21:01 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, ohering, jeffm, jslaby
In-Reply-To: <20130916205543.GA14221@oc0268524204.ibm.com>
On Mon, Sep 16, 2013 at 05:55:43PM -0300, Thadeu Lima de Souza Cascardo wrote:
> On Fri, Sep 13, 2013 at 07:58:57PM -0400, David Miller wrote:
> > From: akpm@linux-foundation.org
> > Date: Fri, 13 Sep 2013 14:52:01 -0700
> >
> > > From: Olaf Hering <ohering@suse.com>
> > > Subject: drivers/net/ethernet/ibm/ehea/ehea_main.c: add alias entry for portN properties
> > >
> > > Use separate table for alias entries in the ehea module, otherwise the
> > > probe() function will operate on the separate ports instead of the
> > > lhea-"root" entry of the device-tree
> > >
> > > Addresses https://bugzilla.novell.com/show_bug.cgi?id=435215
> > >
> > > Signed-off-by: Jeff Mahoney <jeffm@suse.com>
> > > Signed-off-by: Olaf Hering <ohering@suse.com>
> > > Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> > > Cc: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
> > > Cc: "David S. Miller" <davem@davemloft.net>
> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> >
> > This can definitely have consequences and in particular potentially cause
> > a device to not get probed properly.
> >
> > Therefore I want an ehea driver maintainer to review and ACK this before
> > I apply it.
> >
> > Thanks.
> >
>
> After taking a glance at the patch, it doesn't seem to change probing,
> since it keeps the same table for the driver itself. It seems this only
> changes alias, so the driver will be loaded under some device-tree
> layouts not currently matched by the current alias.
>
> That last part is the one that bothers me. I still need to find a system
> where the current modalias won't work and this patch is needed. I'll see
> if I can put more effort into that and find a system as described in the
> bug.
>
> Regards.
> Thadeu Cascardo.
Sorry for the noise. I just checked again the bug, and had to read
between the lines that this issue might happen with the generation of
initrd, when the scripts check for /sys/class/net/eth0/device/modalias,
which links to the port device at
/sys/devices/ibmebus/23c00400.lhea/port0/.
I think that should be clarified in the log message. Besides that, since
this has also been in the field for a long time:
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Regards.
Cascardo.
^ permalink raw reply
* Re: [PATCH stable] ipv6: restrict neighbor entry creation to output flow
From: Jiri Pirko @ 2013-09-16 21:21 UTC (permalink / raw)
To: David Miller; +Cc: hannes, mleitner, netdev, dbanerje, yoshfuji
In-Reply-To: <20130909.132900.704139320855868470.davem@davemloft.net>
Mon, Sep 09, 2013 at 07:29:00PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Mon, 9 Sep 2013 14:17:19 +0200
>
>> When do you plan to push this to stable maintainers?
>
>Jiri, it's in the -stable queue and that means I will send it at an
>appropriate time.
>
>I'm working on a submission at the moment, but every extra query like
>your's that I have to answer takes up time I could be spending on it.
I'm sorry Dave. I'm just worried. I don't want this patch to get lost.
I expected this patch to be part of:
http://git.kernel.org/cgit/linux/kernel/git/bwh/linux-3.2.y-queue.git/commit/?id=dadcb7672a124159630f1f756dea8323bc4976bd
But it is not there.
I'm sorry again :/
Jiri
^ permalink raw reply
* RE: [PATCH] mwifiex: Remove casting the return value which is a void pointer
From: Bing Zhao @ 2013-09-16 21:26 UTC (permalink / raw)
To: Jingoo Han, 'John W. Linville'
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
'David Miller'
In-Reply-To: <004d01cead1d$3058dcf0$910a96d0$%han-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Hi Jingoo,
Thanks for the patch.
> Casting the return value which is a void pointer is redundant.
> The conversion from void pointer to any other pointer type is
> guaranteed by the C programming language.
>
> Signed-off-by: Jingoo Han <jg1.han-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Acked-by: Bing Zhao <bzhao-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Thanks,
Bing
> ---
> drivers/net/wireless/mwifiex/pcie.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/8 V2] rtlwifi: rtl8192de: Fix smatch warnings in rtl8192de/hw.c
From: Kalle Valo @ 2013-09-16 21:44 UTC (permalink / raw)
To: Larry Finger
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1379357722-17687-3-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> writes:
> Smatch lists the following:
> CHECK drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> drivers/net/wireless/rtlwifi/rtl8192de/hw.c:1200 rtl92de_set_qos() info: ignoring unreachable code.
> drivers/net/wireless/rtlwifi/rtl8192de/hw.c:1200 rtl92de_set_qos() info: ignoring unreachable code.
>
> Dead code is commented out. It has not been deleted in case I find a need for
> it later.
We should not have any commented out code. It's better to remove it and
if it's ever needed it can be found from the git history.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next] net loopback: Set loopback_dev to NULL when freed
From: Eric W. Biederman @ 2013-09-16 23:52 UTC (permalink / raw)
To: David S. Miller
Cc: Eric Dumazet, Jiri Pirko, Alexander Duyck, Cong Wang, netdev,
Francesco Ruggeri
In-Reply-To: <CA+HUmGih9akzhpRrb_0WEapi4jGcuSV8qO==QeRWHoqnxzFyng@mail.gmail.com>
It has recently turned up that we have a number of long standing bugs
in the network stack cleanup code with use of the loopback device
after it has been freed that have not turned up because in most cases
the storage allocated to the loopback device is not reused, when those
accesses happen.
Set looback_dev to NULL to trigger oopses instead of silent data corrupt
when we hit this class of bug.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
drivers/net/loopback.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index fcbf680..a17d85a 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -146,6 +146,7 @@ static int loopback_dev_init(struct net_device *dev)
static void loopback_dev_free(struct net_device *dev)
{
+ dev_net(dev)->loopback_dev = NULL;
free_percpu(dev->lstats);
free_netdev(dev);
}
--
1.7.5.4
^ permalink raw reply related
* Pull request: sfc 2013-09-17
From: Ben Hutchings @ 2013-09-17 0:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
The following changes since commit ba39767288661c01ac7797b6b981f73b6513cf55:
Merge branch 'qlcnic' (2013-08-31 22:35:26 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc.git sfc-3.12
for you to fetch changes up to a915ccc9f2c80aa4c329262d89f93ea16d8792c9:
sfc: Reinitialise and re-validate datapath caps after MC reboot (2013-09-11 15:29:53 +0100)
Some bug fixes and future-proofing for the recently added SFC9120
support:
1. Minimal support for the 40G configuration.
2. Disable the incomplete PTP/hardware timestamping support.
3. Reset MAC stats properly after a firmware upgrade.
4. Re-check the datapath firmware capabilities after the controller is
reset.
Ben.
----------------------------------------------------------------
Ben Hutchings (5):
sfc: Minimal support for 40G link speed
sfc: Disable PTP on EF10 until we're ready to handle inline RX timestamps
sfc: Reset derived rx_bad_bytes statistic when EF10 MC is rebooted
sfc: Clean up validation of datapath capabilities
sfc: Reinitialise and re-validate datapath caps after MC reboot
drivers/net/ethernet/sfc/Kconfig | 2 +-
drivers/net/ethernet/sfc/ef10.c | 58 +++++++++++++++++++++++-------------
drivers/net/ethernet/sfc/mcdi_port.c | 2 ++
drivers/net/ethernet/sfc/nic.h | 3 ++
4 files changed, 43 insertions(+), 22 deletions(-)
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net 1/5] sfc: Minimal support for 40G link speed
From: Ben Hutchings @ 2013-09-17 0:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1379376611.1945.11.camel@bwh-desktop.uk.level5networks.com>
Accept and handle 40G link events.
Accept ethtool link settings of speed == 40000 && duplex, and set the
appropriate MCDI PHY capability.
This does not include reporting of 40G media types, as those have not
yet been assigned numbers in the MCDI protocol.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/sfc/Kconfig | 2 +-
drivers/net/ethernet/sfc/mcdi_port.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/Kconfig b/drivers/net/ethernet/sfc/Kconfig
index 8b71525..0889212 100644
--- a/drivers/net/ethernet/sfc/Kconfig
+++ b/drivers/net/ethernet/sfc/Kconfig
@@ -7,7 +7,7 @@ config SFC
select I2C_ALGOBIT
select PTP_1588_CLOCK
---help---
- This driver supports 10-gigabit Ethernet cards based on
+ This driver supports 10/40-gigabit Ethernet cards based on
the Solarflare SFC4000, SFC9000-family and SFC9100-family
controllers.
diff --git a/drivers/net/ethernet/sfc/mcdi_port.c b/drivers/net/ethernet/sfc/mcdi_port.c
index 8d33da6..7b6be61 100644
--- a/drivers/net/ethernet/sfc/mcdi_port.c
+++ b/drivers/net/ethernet/sfc/mcdi_port.c
@@ -556,6 +556,7 @@ static int efx_mcdi_phy_set_settings(struct efx_nic *efx, struct ethtool_cmd *ec
case 100: caps = 1 << MC_CMD_PHY_CAP_100FDX_LBN; break;
case 1000: caps = 1 << MC_CMD_PHY_CAP_1000FDX_LBN; break;
case 10000: caps = 1 << MC_CMD_PHY_CAP_10000FDX_LBN; break;
+ case 40000: caps = 1 << MC_CMD_PHY_CAP_40000FDX_LBN; break;
default: return -EINVAL;
}
} else {
@@ -841,6 +842,7 @@ static unsigned int efx_mcdi_event_link_speed[] = {
[MCDI_EVENT_LINKCHANGE_SPEED_100M] = 100,
[MCDI_EVENT_LINKCHANGE_SPEED_1G] = 1000,
[MCDI_EVENT_LINKCHANGE_SPEED_10G] = 10000,
+ [MCDI_EVENT_LINKCHANGE_SPEED_40G] = 40000,
};
void efx_mcdi_process_link_change(struct efx_nic *efx, efx_qword_t *ev)
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
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