* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Vlad Yasevich @ 2013-09-16 17:49 UTC (permalink / raw)
To: Toshiaki Makita
Cc: David Miller, makita.toshiaki, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <1379074013.1678.16.camel@localhost.localdomain>
On 09/13/2013 08:06 AM, Toshiaki Makita wrote:
> On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>> Date: Tue, 10 Sep 2013 19:27:54 +0900
>>
>>> There seem to be some undesirable behaviors related with PVID.
>>> 1. It has no effect assigning PVID to a port. PVID cannot be applied
>>> to any frame regardless of whether we set it or not.
>>> 2. FDB entries learned via frames applied PVID are registered with
>>> VID 0 rather than VID value of PVID.
>>> 3. We can set 0 or 4095 as a PVID that are not allowed in IEEE 802.1Q.
>>> This leads interoperational problems such as sending frames with VID
>>> 4095, which is not allowed in IEEE 802.1Q, and treating frames with VID
>>> 0 as they belong to VLAN 0, which is expected to be handled as they have
>>> no VID according to IEEE 802.1Q.
>>>
>>> Note: 2nd and 3rd problems are potential and not exposed unless 1st problem
>>> is fixed, because we cannot activate PVID due to it.
>>
>> Please work out the issues in patch #2 with Vlad and resubmit this
>> series.
>>
>> Thank you.
>
> I'm hovering between whether we should fix the issue by changing vlan 0
> interface behavior in 8021q module or enabling a bridge port to sending
> priority-tagged frames, or another better way.
>
> If you could comment it, I'd appreciate it :)
>
>
> BTW, I think what is discussed in patch #2 is another problem about
> handling priority-tags, and it exists without this patch set applied.
> It looks like that we should prepare another patch set than this to fix
> that problem.
>
> Should I include patches that fix the priority-tags problem in this
> patch set and resubmit them all together?
>
I am thinking that we might need to do it in bridge and it looks like
the simplest way to do it is to have default priority regeneration table
(table 6-5 from 802.1Q doc).
That way I think we would conform to the spec.
-vlad
>
> Thanks,
>
> Toshiaki Makita
>
>>
>> --
>> 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 2/2] bridge: fix NULL pointer deref of br_port_get_rcu
From: Vlad Yasevich @ 2013-09-16 17:58 UTC (permalink / raw)
To: Hong Zhiguo; +Cc: netdev, davem, eric.dumazet, Hong Zhiguo
In-Reply-To: <1379169748-767-3-git-send-email-zhiguohong@tencent.com>
On 09/14/2013 10:42 AM, Hong Zhiguo wrote:
> From: Hong Zhiguo <zhiguohong@tencent.com>
>
> The NULL deref happens when br_handle_frame is called between these
> 2 lines of del_nbp:
> dev->priv_flags &= ~IFF_BRIDGE_PORT;
> /* --> br_handle_frame is called at this time */
> netdev_rx_handler_unregister(dev);
>
> In br_handle_frame the return of br_port_get_rcu(dev) is dereferenced
> without check but br_port_get_rcu(dev) returns NULL if:
> !(dev->priv_flags & IFF_BRIDGE_PORT)
>
> Eric Dumazet pointed out the testing of IFF_BRIDGE_PORT is not necessary
> here since we're in rcu_read_lock and we have synchronize_net() in
> netdev_rx_handler_unregister. So remove the testing of IFF_BRIDGE_PORT
> and by the previous patch, make sure br_port_get_rcu is called in
> bridging code.
>
> Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com>
I think would be better to also include your initial patch to move the
call netdev_rx_handler_unregister(dev) up higher as it would reduce the
racy nature of input processing and port removal.
As it is now, up until netdev_rx_handler_unregister(dev) call, the input
process may call into the bridge code only to drop the packet. With
ebtables, that can consume considerable time that is wasted. By
performing the unregister() sooner we reduce the racy nature of the two
calls.
-vlad
> ---
> net/bridge/br_private.h | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 49fb43e..1aaca0e 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -202,10 +202,7 @@ struct net_bridge_port
>
> static inline struct net_bridge_port *br_port_get_rcu(const struct net_device *dev)
> {
> - struct net_bridge_port *port =
> - rcu_dereference_rtnl(dev->rx_handler_data);
> -
> - return br_port_exists(dev) ? port : NULL;
> + return rcu_dereference(dev->rx_handler_data);
> }
>
> static inline struct net_bridge_port *br_port_get_rtnl(const struct net_device *dev)
>
^ permalink raw reply
* Re: mvneta: oops in __rcu_read_lock on mirabox
From: Russell King - ARM Linux @ 2013-09-16 18:25 UTC (permalink / raw)
To: Willy Tarreau
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, netdev, Ethan Tuttle,
Ezequiel Garcia, Gregory Clément, linux-arm-kernel
In-Reply-To: <20130916174514.GF3188@1wt.eu>
On Mon, Sep 16, 2013 at 07:45:14PM +0200, Willy Tarreau wrote:
> This board has a really clean routing and placement, chips are very close.
> That does not rule out the possibility of a lacking termination, but it
> would probably affect more users.
True - though in your photographs, we can't see the tracking for the
data bus, because that's all buried in the inner board layers.
However, there is some evidence in there of trace lengths being matched
which is a good sign. :)
> On Mon, Sep 16, 2013 at 06:14:16PM +0100, Russell King - ARM Linux wrote:
> > Marginal or noisy power supplies could also be a problem - for example,
> > if the impedance of the power supply connections is too great, it may
> > work with some patterns of use but not others.
>
> We have some margin here, I measured less than 1 Amp to boot and something
> like 6-700 mA in idle if my memory serves me correctly. The 3A PSU and its
> thicker-than-average wires seem safe. I think that Globalscale learned a
> lot from the horrible Guruplug design that all this part needs to be done
> correctly and they did a very clean job this time.
Not quite the power supply I was referring to - I'm talking about the
on-board regulators which supply the 3.3V and other lower voltages to
the SDRAM and SoC - and the quality of their decoupling. The on-board
regulators will have a certain degree of "line" noise immunity.
If I had to guess, I'd say C366 is probably the output bulk capacitor on
the CPU core supply (which comes via BIT7, C273, L1, U19 being the
switching regulator chip.
I'd also guess one of C370, C396 or C398 supplies the SDRAM - and of
those C370 is the most likely - the resistors in the boxes marked K and
B, and R123 I suspect may be the SDRAM data bus termination (that
covers R107 to R136), though I only count a total of 30 of those
connecting to U5 pin 4 - and that point looks _well_ decoupled with lots
of capacitors (C8-C16, C287 on one side, C7, C246, C247 on the other.)
The other two? Maybe R105/106 which are on the underside of the CPU,
though they're a long way from that well decoupled point. R137/138?
They're up by the NAND chip and connect to ground. Though... if one
of those is for D8...
Anyway, that's all speculation.
^ permalink raw reply
* Re: mvneta: oops in __rcu_read_lock on mirabox
From: Russell King - ARM Linux @ 2013-09-16 18:28 UTC (permalink / raw)
To: Willy Tarreau
Cc: Ethan Tuttle, Thomas Petazzoni, Andrew Lunn, Jason Cooper, netdev,
Ezequiel Garcia, Gregory Clément, linux-arm-kernel
In-Reply-To: <20130916174708.GG3188@1wt.eu>
On Mon, Sep 16, 2013 at 07:47:08PM +0200, Willy Tarreau wrote:
> I'll have to rebuild with your config and exact 3.11 to test again.
> Can you check the packet rate of your ping flood to give an order of
> magnitude so that we're sure to be in the same conditions ?
Also, try swapping kernel binaries between yourselves, so that you can
be sure you're running the exact same kernel on different hardware.
^ permalink raw reply
* Re: [PATCH net-next 2/2] bridge: fix NULL pointer deref of br_port_get_rcu
From: Stephen Hemminger @ 2013-09-16 18:32 UTC (permalink / raw)
To: vyasevic; +Cc: Hong Zhiguo, netdev, davem, eric.dumazet, Hong Zhiguo
In-Reply-To: <523746C6.3010700@redhat.com>
On Mon, 16 Sep 2013 13:58:30 -0400
Vlad Yasevich <vyasevic@redhat.com> wrote:
> On 09/14/2013 10:42 AM, Hong Zhiguo wrote:
> > From: Hong Zhiguo <zhiguohong@tencent.com>
> >
> > The NULL deref happens when br_handle_frame is called between these
> > 2 lines of del_nbp:
> > dev->priv_flags &= ~IFF_BRIDGE_PORT;
> > /* --> br_handle_frame is called at this time */
> > netdev_rx_handler_unregister(dev);
> >
> > In br_handle_frame the return of br_port_get_rcu(dev) is dereferenced
> > without check but br_port_get_rcu(dev) returns NULL if:
> > !(dev->priv_flags & IFF_BRIDGE_PORT)
> >
> > Eric Dumazet pointed out the testing of IFF_BRIDGE_PORT is not necessary
> > here since we're in rcu_read_lock and we have synchronize_net() in
> > netdev_rx_handler_unregister. So remove the testing of IFF_BRIDGE_PORT
> > and by the previous patch, make sure br_port_get_rcu is called in
> > bridging code.
> >
> > Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com>
>
> I think would be better to also include your initial patch to move the
> call netdev_rx_handler_unregister(dev) up higher as it would reduce the
> racy nature of input processing and port removal.
>
> As it is now, up until netdev_rx_handler_unregister(dev) call, the input
> process may call into the bridge code only to drop the packet. With
> ebtables, that can consume considerable time that is wasted. By
> performing the unregister() sooner we reduce the racy nature of the two
> calls.
>
> -vlad
The change to just use rcu_dereference is safe.
The flag ordering doesn't matter. it is only valid to check it under RTNL.
^ permalink raw reply
* Re: [PATCH net-next 2/2] bridge: fix NULL pointer deref of br_port_get_rcu
From: Vlad Yasevich @ 2013-09-16 18:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Hong Zhiguo, netdev, davem, eric.dumazet, Hong Zhiguo
In-Reply-To: <20130916113242.38562647@nehalam.linuxnetplumber.net>
On 09/16/2013 02:32 PM, Stephen Hemminger wrote:
> On Mon, 16 Sep 2013 13:58:30 -0400
> Vlad Yasevich <vyasevic@redhat.com> wrote:
>
>> On 09/14/2013 10:42 AM, Hong Zhiguo wrote:
>>> From: Hong Zhiguo <zhiguohong@tencent.com>
>>>
>>> The NULL deref happens when br_handle_frame is called between these
>>> 2 lines of del_nbp:
>>> dev->priv_flags &= ~IFF_BRIDGE_PORT;
>>> /* --> br_handle_frame is called at this time */
>>> netdev_rx_handler_unregister(dev);
>>>
>>> In br_handle_frame the return of br_port_get_rcu(dev) is dereferenced
>>> without check but br_port_get_rcu(dev) returns NULL if:
>>> !(dev->priv_flags & IFF_BRIDGE_PORT)
>>>
>>> Eric Dumazet pointed out the testing of IFF_BRIDGE_PORT is not necessary
>>> here since we're in rcu_read_lock and we have synchronize_net() in
>>> netdev_rx_handler_unregister. So remove the testing of IFF_BRIDGE_PORT
>>> and by the previous patch, make sure br_port_get_rcu is called in
>>> bridging code.
>>>
>>> Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com>
>>
>> I think would be better to also include your initial patch to move the
>> call netdev_rx_handler_unregister(dev) up higher as it would reduce the
>> racy nature of input processing and port removal.
>>
>> As it is now, up until netdev_rx_handler_unregister(dev) call, the input
>> process may call into the bridge code only to drop the packet. With
>> ebtables, that can consume considerable time that is wasted. By
>> performing the unregister() sooner we reduce the racy nature of the two
>> calls.
>>
>> -vlad
>
> The change to just use rcu_dereference is safe.
> The flag ordering doesn't matter. it is only valid to check it under RTNL.
>
Yes, I agree. I am just saying that that there are other things that
will be happening at the same time as input processing like port state
change and fdb table change and it might be worthwhile to easily prevent
this racy processing.
-vlad
^ permalink raw reply
* Re: [PATCH net-next 2/2] bridge: fix NULL pointer deref of br_port_get_rcu
From: Stephen Hemminger @ 2013-09-16 18:44 UTC (permalink / raw)
To: vyasevic; +Cc: Hong Zhiguo, netdev, davem, eric.dumazet, Hong Zhiguo
In-Reply-To: <52374FDF.2060301@redhat.com>
On Mon, 16 Sep 2013 14:37:19 -0400
Vlad Yasevich <vyasevic@redhat.com> wrote:
> On 09/16/2013 02:32 PM, Stephen Hemminger wrote:
> > On Mon, 16 Sep 2013 13:58:30 -0400
> > Vlad Yasevich <vyasevic@redhat.com> wrote:
> >
> >> On 09/14/2013 10:42 AM, Hong Zhiguo wrote:
> >>> From: Hong Zhiguo <zhiguohong@tencent.com>
> >>>
> >>> The NULL deref happens when br_handle_frame is called between these
> >>> 2 lines of del_nbp:
> >>> dev->priv_flags &= ~IFF_BRIDGE_PORT;
> >>> /* --> br_handle_frame is called at this time */
> >>> netdev_rx_handler_unregister(dev);
> >>>
> >>> In br_handle_frame the return of br_port_get_rcu(dev) is dereferenced
> >>> without check but br_port_get_rcu(dev) returns NULL if:
> >>> !(dev->priv_flags & IFF_BRIDGE_PORT)
> >>>
> >>> Eric Dumazet pointed out the testing of IFF_BRIDGE_PORT is not necessary
> >>> here since we're in rcu_read_lock and we have synchronize_net() in
> >>> netdev_rx_handler_unregister. So remove the testing of IFF_BRIDGE_PORT
> >>> and by the previous patch, make sure br_port_get_rcu is called in
> >>> bridging code.
> >>>
> >>> Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com>
> >>
> >> I think would be better to also include your initial patch to move the
> >> call netdev_rx_handler_unregister(dev) up higher as it would reduce the
> >> racy nature of input processing and port removal.
> >>
> >> As it is now, up until netdev_rx_handler_unregister(dev) call, the input
> >> process may call into the bridge code only to drop the packet. With
> >> ebtables, that can consume considerable time that is wasted. By
> >> performing the unregister() sooner we reduce the racy nature of the two
> >> calls.
> >>
> >> -vlad
> >
> > The change to just use rcu_dereference is safe.
> > The flag ordering doesn't matter. it is only valid to check it under RTNL.
> >
>
> Yes, I agree. I am just saying that that there are other things that
> will be happening at the same time as input processing like port state
> change and fdb table change and it might be worthwhile to easily prevent
> this racy processing.
Port state change is protected by RTNL.
FDB table is fine, it is RCU protected.
^ permalink raw reply
* [PATCH 2/8 V2] rtlwifi: rtl8192de: Fix smatch warnings in rtl8192de/hw.c
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>
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.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
---
drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
index 7dd8f6d..c9b0894 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
@@ -1194,6 +1194,7 @@ void rtl92d_linked_set_reg(struct ieee80211_hw *hw)
* mac80211 will send pkt when scan */
void rtl92de_set_qos(struct ieee80211_hw *hw, int aci)
{
+/*
struct rtl_priv *rtlpriv = rtl_priv(hw);
rtl92d_dm_init_edca_turbo(hw);
return;
@@ -1213,6 +1214,7 @@ void rtl92de_set_qos(struct ieee80211_hw *hw, int aci)
RT_ASSERT(false, "invalid aci: %d !\n", aci);
break;
}
+ */
}
void rtl92de_enable_interrupt(struct ieee80211_hw *hw)
--
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 4/8 V2] rtlwifi: rtl8192_common: Fix smatch errors and warnings in rtl8192c/dm_common.c
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>
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.
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);
+ */
}
void rtl92c_dm_init_edca_turbo(struct ieee80211_hw *hw)
@@ -673,7 +675,7 @@ static void rtl92c_dm_txpower_tracking_callback_thermalmeter(struct ieee80211_hw
s8 cck_index = 0;
int i;
bool is2t = IS_92C_SERIAL(rtlhal->version);
- s8 txpwr_level[2] = {0, 0};
+ s8 txpwr_level[3] = {0, 0, 0};
u8 ofdm_min_index = 6, rf;
rtlpriv->dm.txpower_trackinginit = true;
--
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 5/8 V2] [PATCH 5/7: rtlwifi: Fix smatch warning in pci.c
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>
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.
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,
};
int index = rtlpci->rx_ring[rx_queue_idx].idx;
--
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 6/8 V2] rtlwifi: Fix smatch warnings in usb.c
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>
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. 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))
return 0;
+#if NET_IP_ALIGN != 0
/* alignment calculation as in lbtf_rx() / carl9170_rx_copy_data() */
/* TODO: deduplicate common code, define helper function instead? */
@@ -608,6 +609,7 @@ static unsigned int _rtl_rx_get_padding(struct ieee80211_hdr *hdr,
padding ^= NET_IP_ALIGN;
return padding;
+#endif
}
#define __RADIO_TAP_SIZE_RSV 32
--
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 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
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