* [PATCH net 1/4] qlcnic: Use qlcnic_83xx_flash_read32() API instead of lockless version of the API.
From: Manish Chopra @ 2014-09-22 9:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-GELinuxNICDev, Sony Chacko
In-Reply-To: <1411379513-26902-1-git-send-email-manish.chopra@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
In qlcnic_83xx_setup_idc_parameters() routine use qlcnic_83xx_flash_read32() API
which takes flash lock internally instead of the lockless version
qlcnic_83xx_lockless_flash_read32().
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
---
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
index 86783e1..3172cdf 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
@@ -1177,9 +1177,8 @@ static void qlcnic_83xx_setup_idc_parameters(struct qlcnic_adapter *adapter)
{
u32 idc_params, val;
- if (qlcnic_83xx_lockless_flash_read32(adapter,
- QLC_83XX_IDC_FLASH_PARAM_ADDR,
- (u8 *)&idc_params, 1)) {
+ if (qlcnic_83xx_flash_read32(adapter, QLC_83XX_IDC_FLASH_PARAM_ADDR,
+ (u8 *)&idc_params, 1)) {
dev_info(&adapter->pdev->dev,
"%s:failed to get IDC params from flash\n", __func__);
adapter->dev_init_timeo = QLC_83XX_IDC_INIT_TIMEOUT_SECS;
--
1.7.1
^ permalink raw reply related
* [PATCH net 3/4] qlcnic: Remove __QLCNIC_DEV_UP bit check to read TX queues statistics.
From: Manish Chopra @ 2014-09-22 9:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-GELinuxNICDev
In-Reply-To: <1411379513-26902-1-git-send-email-manish.chopra@qlogic.com>
o TX queues stats must be read when queues are allocated regardless
of interface is up or not.
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
---
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
index 2d77b76..863c445 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
@@ -1339,7 +1339,7 @@ static void qlcnic_get_ethtool_stats(struct net_device *dev,
memset(data, 0, stats->n_stats * sizeof(u64));
for (ring = 0, index = 0; ring < adapter->drv_tx_rings; ring++) {
- if (test_bit(__QLCNIC_DEV_UP, &adapter->state)) {
+ if (adapter->is_up == QLCNIC_ADAPTER_UP_MAGIC) {
tx_ring = &adapter->tx_ring[ring];
data = qlcnic_fill_tx_queue_stats(data, tx_ring);
qlcnic_update_stats(adapter);
--
1.7.1
^ permalink raw reply related
* [PATCH net 4/4] qlcnic: Fix ordering of stats in stats buffer.
From: Manish Chopra @ 2014-09-22 9:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-GELinuxNICDev
In-Reply-To: <1411379513-26902-1-git-send-email-manish.chopra@qlogic.com>
o When TX queues are not allocated, driver does not fill TX queues stats in the buffer.
However, it is also not advancing data pointer by TX queue stats length, which would
misplace all successive stats data in the buffer and will result in mismatch between
stats strings and it's values.
o Fix this by advancing data pointer by TX queue stats length when
queues are not allocated.
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
---
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
index 863c445..494e810 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
@@ -1343,6 +1343,8 @@ static void qlcnic_get_ethtool_stats(struct net_device *dev,
tx_ring = &adapter->tx_ring[ring];
data = qlcnic_fill_tx_queue_stats(data, tx_ring);
qlcnic_update_stats(adapter);
+ } else {
+ data += QLCNIC_TX_STATS_LEN;
}
}
--
1.7.1
^ permalink raw reply related
* [PATCH net 2/4] qlcnic: Fix memory corruption while reading stats using ethtool.
From: Manish Chopra @ 2014-09-22 9:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-GELinuxNICDev
In-Reply-To: <1411379513-26902-1-git-send-email-manish.chopra@qlogic.com>
o Driver is doing memset with zero for total number of stats bytes when
it has already filled some data in the stats buffer, which can overwrite
memory area beyond the length of stats buffer.
o Fix this by initializing stats buffer with zero before filling any data in it.
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
---
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
index 141f116..2d77b76 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
@@ -1333,12 +1333,11 @@ static void qlcnic_get_ethtool_stats(struct net_device *dev,
struct qlcnic_host_tx_ring *tx_ring;
struct qlcnic_esw_statistics port_stats;
struct qlcnic_mac_statistics mac_stats;
- int index, ret, length, size, tx_size, ring;
+ int index, ret, length, size, ring;
char *p;
- tx_size = adapter->drv_tx_rings * QLCNIC_TX_STATS_LEN;
+ memset(data, 0, stats->n_stats * sizeof(u64));
- memset(data, 0, tx_size * sizeof(u64));
for (ring = 0, index = 0; ring < adapter->drv_tx_rings; ring++) {
if (test_bit(__QLCNIC_DEV_UP, &adapter->state)) {
tx_ring = &adapter->tx_ring[ring];
@@ -1347,7 +1346,6 @@ static void qlcnic_get_ethtool_stats(struct net_device *dev,
}
}
- memset(data, 0, stats->n_stats * sizeof(u64));
length = QLCNIC_STATS_LEN;
for (index = 0; index < length; index++) {
p = (char *)adapter + qlcnic_gstrings_stats[index].stat_offset;
--
1.7.1
^ permalink raw reply related
* [PATCH net 0/4] qlcnic: Bug fixes.
From: Manish Chopra @ 2014-09-22 9:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-GELinuxNICDev
Hi David,
This patch series contains following bug fixes:
* Fixes related to ethtool statistics.
* Fix for flash read related API.
Please apply this series to 'net'.
Thanks,
Manish
Manish Chopra (3):
qlcnic: Fix memory corruption while reading stats using ethtool.
qlcnic: Remove __QLCNIC_DEV_UP bit check to read TX queues
statistics.
qlcnic: Fix ordering of stats in stats buffer.
Sony Chacko (1):
qlcnic: Use qlcnic_83xx_flash_read32() API instead of lockless
version of the API.
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 5 ++---
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 10 +++++-----
2 files changed, 7 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: [PATCH] brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels()
From: Arend van Spriel @ 2014-09-22 9:56 UTC (permalink / raw)
To: Emil Goode
Cc: Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman,
John W. Linville, Pieter-Paul Giesberts, Daniel Kim,
linux-wireless, brcm80211-dev-list, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <1411253932-27973-1-git-send-email-emilgoode@gmail.com>
On 09/21/14 00:58, Emil Goode wrote:
> In the brcmf_count_20mhz_channels function we are looping through a list
> of channels received from firmware. Since the index of the first channel
> is 0 the condition leads to an off by one bug. This is causing us to hit
> the WARN_ON_ONCE(1) calls in the brcmu_d11n_decchspec function, which is
> how I discovered the bug.
The fix is fine. Would like to know what exactly is going wrong. Can you
provide a kernel log with brcmfmac debugging enabled, ie. insmod
brcmfmac.ko debug=0x1416
Regards,
Arend
> Introduced by:
> commit b48d891676f756d48b4d0ee131e4a7a5d43ca417
> ("brcmfmac: rework wiphy structure setup")
>
> Signed-off-by: Emil Goode<emilgoode@gmail.com>
> ---
> drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> index 02fe706..93b5dd9 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> @@ -4918,7 +4918,7 @@ static void brcmf_count_20mhz_channels(struct brcmf_cfg80211_info *cfg,
> struct brcmu_chan ch;
> int i;
>
> - for (i = 0; i<= total; i++) {
> + for (i = 0; i< total; i++) {
> ch.chspec = (u16)le32_to_cpu(chlist->element[i]);
> cfg->d11inf.decchspec(&ch);
>
^ permalink raw reply
* Re: [PATCH] brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels()
From: Arend van Spriel @ 2014-09-22 9:49 UTC (permalink / raw)
To: Emil Goode
Cc: Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman,
John W. Linville, Pieter-Paul Giesberts, Daniel Kim,
linux-wireless, brcm80211-dev-list, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <1411253932-27973-1-git-send-email-emilgoode@gmail.com>
On 09/21/14 00:58, Emil Goode wrote:
> In the brcmf_count_20mhz_channels function we are looping through a list
> of channels received from firmware. Since the index of the first channel
> is 0 the condition leads to an off by one bug. This is causing us to hit
> the WARN_ON_ONCE(1) calls in the brcmu_d11n_decchspec function, which is
> how I discovered the bug.
>
> Introduced by:
> commit b48d891676f756d48b4d0ee131e4a7a5d43ca417
> ("brcmfmac: rework wiphy structure setup")
My bad :-(. You can add:
Acked-by: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: Emil Goode<emilgoode@gmail.com>
> ---
> drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> index 02fe706..93b5dd9 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> @@ -4918,7 +4918,7 @@ static void brcmf_count_20mhz_channels(struct brcmf_cfg80211_info *cfg,
> struct brcmu_chan ch;
> int i;
>
> - for (i = 0; i<= total; i++) {
> + for (i = 0; i< total; i++) {
> ch.chspec = (u16)le32_to_cpu(chlist->element[i]);
> cfg->d11inf.decchspec(&ch);
>
^ permalink raw reply
* Re: [PATCH] batman-adv: fix potential NULL pointer dereferencing
From: Antonio Quartulli @ 2014-09-22 9:12 UTC (permalink / raw)
To: mpirker, mareklindner@neomailbox.ch, sw@simonwunderlich.de,
davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <DUB123-W2663266CEA8296935E9450A0B30@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]
On 22/09/14 11:11, Mario Pirker wrote:
> From b451e7317148e18bf6c5c8fd747d79ab34260354 Mon Sep 17 00:00:00 2001
> From: Mario Pirker <mario.pirker@kellogg.ox.ac.uk>
> Date: Tue, 16 Sep 2014 17:55:13 +0200
> Subject: [PATCH] batman-adv: fix potential NULL pointer dereferencing
>
> The call batadv_gw_node_get may return NULL. The return value has to
> be sanity checked before the pointer is dereferenced.
>
> Signed-off-by: Mario Pirker <mariopirker@hotmail.com>
> ---
We already have a patch queued to fix this issue
(http://permalink.gmane.org/gmane.org.freifunk.batman/12357).
Actually it is not about a missing check but it is more about a typo in
the check right below the one you added.
Cheers,
> net/batman-adv/gateway_client.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/batman-adv/gateway_client.c b/net/batman-adv/gateway_client.c
> index 90cff58..7ee0913 100644
> --- a/net/batman-adv/gateway_client.c
> +++ b/net/batman-adv/gateway_client.c
> @@ -810,6 +810,11 @@ bool batadv_gw_out_of_range(struct batadv_priv *bat_priv,
> goto out;
>
> gw_node = batadv_gw_node_get(bat_priv, orig_dst_node);
> +
> + /* gw_node can be NULL. We need to check before dereferencing */
> + if (gw_node == NULL)
> + goto out;
> +
> if (!gw_node->bandwidth_down == 0)
> goto out;
>
> --
> 1.8.1.4
>
--
Antonio Quartulli
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] batman-adv: fix potential NULL pointer dereferencing
From: Mario Pirker @ 2014-09-22 9:11 UTC (permalink / raw)
To: mareklindner@neomailbox.ch, sw@simonwunderlich.de,
antonio@meshcoding.com, davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
From b451e7317148e18bf6c5c8fd747d79ab34260354 Mon Sep 17 00:00:00 2001
From: Mario Pirker <mario.pirker@kellogg.ox.ac.uk>
Date: Tue, 16 Sep 2014 17:55:13 +0200
Subject: [PATCH] batman-adv: fix potential NULL pointer dereferencing
The call batadv_gw_node_get may return NULL. The return value has to
be sanity checked before the pointer is dereferenced.
Signed-off-by: Mario Pirker <mariopirker@hotmail.com>
---
net/batman-adv/gateway_client.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/batman-adv/gateway_client.c b/net/batman-adv/gateway_client.c
index 90cff58..7ee0913 100644
--- a/net/batman-adv/gateway_client.c
+++ b/net/batman-adv/gateway_client.c
@@ -810,6 +810,11 @@ bool batadv_gw_out_of_range(struct batadv_priv *bat_priv,
goto out;
gw_node = batadv_gw_node_get(bat_priv, orig_dst_node);
+
+ /* gw_node can be NULL. We need to check before dereferencing */
+ if (gw_node == NULL)
+ goto out;
+
if (!gw_node->bandwidth_down == 0)
goto out;
--
1.8.1.4 --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply related
* Dear Friend !!!
From: Robert Pullman @ 2014-09-22 8:31 UTC (permalink / raw)
Dear Friend,
Do not despair at my sudden contact, there is a business proposal that
I want to initiate with you, and i demand that you can handle this
proposal with a serious mind, as it requires utmost urgency and
attention. I am Robert Pullman, Senior Audit Officer under the City of
New York Office of the Comptroller, John C. liu, and as a matter of
fact i was asked to contact you to draw your attention to this
beneficial matter.
In other words, Am Contacting you in a benevolent spirit; utmost
confidence and trust to provide an account as solution to money
transfer of a huge amount of fund (amount undisclosed), all modalities
has been mapped out, it is legal and confidential.
Contact me for details via my private email; pullman.rb@gmail.com
Best Regard,
Robert Pullman
^ permalink raw reply
* Re: ipv4 dead route delete notification on netdev down
From: Nicolas Dichtel @ 2014-09-22 8:26 UTC (permalink / raw)
To: Roopa Prabhu, netdev; +Cc: David Miller, Stephen Hemminger, Thomas Graf
In-Reply-To: <541E4DD4.1050609@cumulusnetworks.com>
Le 21/09/2014 06:02, Roopa Prabhu a écrit :
> Hi,
>
> The kernel does not send notification for deleted dead ipv4 routes on netdev down.
Not only on netdev down. If you remove the last IPv4 address, the kernel will
also purge its routing table without any notification :/
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Thomas Graf @ 2014-09-22 8:13 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Jiri Pirko, John Fastabend, Jamal Hadi Salim,
netdev@vger.kernel.org, David S. Miller, Neil Horman,
Andy Gospodarek, Daniel Borkmann, Or Gerlitz, Jesse Gross,
Pravin Shelar, Andy Zhou, ben, Stephen Hemminger,
jeffrey.t.kirsher, Vladislav Yasevich, Cong Wang, Eric Dumazet,
Scott Feldman, Florian Fainelli, Roopa Prabhu, John Linville,
dev@openvswitch.org
In-Reply-To: <CAADnVQK0wT2Fjqdg+C=ruSt8jF6sKeMo7cFj7K1fsu7-1u5g=g@mail.gmail.com>
On 09/20/14 at 03:50pm, Alexei Starovoitov wrote:
> I think HW should not be limited by SW abstractions whether
> these abstractions are called flows, n-tuples, bridge or else.
> Really looking forward to see "device reporting the headers as
> header fields (len, offset) and the associated parse graph"
> as the first step.
>
> Another topic that this discussion didn't cover yet is how this
> all connects to tunnels and what is 'tunnel offloading'.
> imo flow offloading by itself serves only academic interest.
We haven't touched encryption yet either ;-)
Certainly true for the host case. The Linux on TOR case is less
dependant on this and L2/L3 offload w/o encap already has value.
I'm with you though, all of this has little value on the host in
the DC if stateful encap offload is not incorporated. I expect the
HW to provide filters on the outer header plus metadata in the
encap. Actually, this was a follow-up question I had for John as
this is not easily describable with offset/len filters. How would
we represent such capabilities?
The TX side of this was one of the reasons why I initially thought
it would be beneficial to implement a cache like offload as we could
serve an initial encap in SW, do the FIB lookup and offload it
transparently to avoid replicating the FIB in user space.
What seems most feasisble to me right now is to separate the offload
of the encap action from the IP -> dev mapping decision. The eSwitch
would send the first encap for an unknown dest IP to the CPU due
to a miss in the IP mapping table, the CPU would do the FIB lookup,
update the table and send it back.
What do you have in mind?
^ permalink raw reply
* [PATCH net 0/3] ipv6: Return an error when adding an already existing tunnel
From: Steffen Klassert @ 2014-09-22 8:07 UTC (permalink / raw)
To: David Miller; +Cc: Steffen Klassert, netdev
The ipv6 tunnel locate functions should not return an existing
tunnel if create is true. Otherwise it is possible to add the
same tunnel multiple times without getting an error.
All our ipv6 tunnels have this bug from the very beginning.
Only the sit tunnel was fixed some years ago with:
commit 8db99e57175 ("sit: Fail to create tunnel, if it already exists").
This patchset fixes the remaining ipv6 tunnels.
^ permalink raw reply
* [PATCH net 2/3] ip6_vti: Return an error when adding an existing tunnel.
From: Steffen Klassert @ 2014-09-22 8:07 UTC (permalink / raw)
To: David Miller; +Cc: Steffen Klassert, netdev
In-Reply-To: <1411373246-22389-1-git-send-email-steffen.klassert@secunet.com>
vti6_locate() should not return an existing tunnel if
create is true. Otherwise it is possible to add the same
tunnel multiple times without getting an error.
So return NULL if the tunnel that should be created already
exists.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv6/ip6_vti.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 7f52fd9..5833a22 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -253,8 +253,12 @@ static struct ip6_tnl *vti6_locate(struct net *net, struct __ip6_tnl_parm *p,
(t = rtnl_dereference(*tp)) != NULL;
tp = &t->next) {
if (ipv6_addr_equal(local, &t->parms.laddr) &&
- ipv6_addr_equal(remote, &t->parms.raddr))
+ ipv6_addr_equal(remote, &t->parms.raddr)) {
+ if (create)
+ return NULL;
+
return t;
+ }
}
if (!create)
return NULL;
--
1.9.1
^ permalink raw reply related
* [PATCH net 1/3] ip6_tunnel: Return an error when adding an existing tunnel.
From: Steffen Klassert @ 2014-09-22 8:07 UTC (permalink / raw)
To: David Miller; +Cc: Steffen Klassert, netdev
In-Reply-To: <1411373246-22389-1-git-send-email-steffen.klassert@secunet.com>
ip6_tnl_locate() should not return an existing tunnel if
create is true. Otherwise it is possible to add the same
tunnel multiple times without getting an error.
So return NULL if the tunnel that should be created already
exists.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv6/ip6_tunnel.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index f9de5a6..69a84b4 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -364,8 +364,12 @@ static struct ip6_tnl *ip6_tnl_locate(struct net *net,
(t = rtnl_dereference(*tp)) != NULL;
tp = &t->next) {
if (ipv6_addr_equal(local, &t->parms.laddr) &&
- ipv6_addr_equal(remote, &t->parms.raddr))
+ ipv6_addr_equal(remote, &t->parms.raddr)) {
+ if (create)
+ return NULL;
+
return t;
+ }
}
if (!create)
return NULL;
--
1.9.1
^ permalink raw reply related
* [PATCH net 3/3] ip6_gre: Return an error when adding an existing tunnel.
From: Steffen Klassert @ 2014-09-22 8:07 UTC (permalink / raw)
To: David Miller; +Cc: Steffen Klassert, netdev
In-Reply-To: <1411373246-22389-1-git-send-email-steffen.klassert@secunet.com>
ip6gre_tunnel_locate() should not return an existing tunnel if
create is true. Otherwise it is possible to add the same
tunnel multiple times without getting an error.
So return NULL if the tunnel that should be created already
exists.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv6/ip6_gre.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 5f19dfb..2e5a882 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -314,6 +314,8 @@ static struct ip6_tnl *ip6gre_tunnel_locate(struct net *net,
struct ip6gre_net *ign = net_generic(net, ip6gre_net_id);
t = ip6gre_tunnel_find(net, parms, ARPHRD_IP6GRE);
+ if (t && create)
+ return NULL;
if (t || !create)
return t;
--
1.9.1
^ permalink raw reply related
* Re: net/fec: Unable to get a permanent link when connecting to a PC
From: Stefan Wahren @ 2014-09-22 8:06 UTC (permalink / raw)
To: to-fleischer@t-online.de, linux-arm-kernel,
netdev@vger.kernel.org
In-Reply-To: <1XUuZV-0zjkn20@fwd01.aul.t-online.de>
Am 19.09.2014 um 11:33 schrieb to-fleischer@t-online.de:
> I have an i.MX283 board with a KSZ8081 PHY that is connected to the controller
> via RMII. The PHY's interrupt line is currently unused, but connected to the
> controller. The board runs the linux version 3.17-rc5.
> When I connect the board directly to a PC the ethernet link goes up and a second
> later down. This is repeated again and again.
> After some investigation I found that this is caused by the reset of the FEC at
> the begin of fec_restart() that is called by fec_enet_adjust_link() if the link
> is up.
> Due to the reset the mode is set to MII. After switching back to RMII the PHY
> seems to restart the autonegotiation. Since this takes a while the next call of
> phy_state_machine() detects that the link is down.
> It would work, if the reset in fec_restart is avoided for the case that the link
> goes up and the fec is still stopped.
>
> Its quite remarkable that this issue does not occur if I connect the board to a
> switch or if I use the PHY's interrupt line.
>
> What do you think?
>
> Best Regards,
> Torsten Fleischer
>
Add netdev list
Best regards
Stefan Wahren
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Jiri Pirko @ 2014-09-22 7:53 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Thomas Graf, John Fastabend, netdev, davem, nhorman, andy,
dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, edumazet, sfeldma,
f.fainelli, roopa, linville, dev, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck
In-Reply-To: <541D65CE.7080108@mojatatu.com>
Sat, Sep 20, 2014 at 01:32:30PM CEST, jhs@mojatatu.com wrote:
>On 09/20/14 07:01, Thomas Graf wrote:
>
>>Nothing speaks against having such a tc classifier. In fact, having
>>the interface consist of only an embedded Netlink attribute structure
>>would allow for such a classifier in a very straight forward way.
>>
>>That doesn't mean everybody should be forced to use the stateful
>>tc interface.
>>
>
>
>Agreed. The response was to Jiri's strange statement that now that
>he cant use OVS, there is no such api. I point to tc as very capable of
>such usage.
Jamal, would you please give us some examples on how to use tc to work
with flows? I have a feeling that you see something other people does not.
Lets get on the same page now.
Thanks.
>
>>No need for false accusations here. Nobody ever mentioned vendor SDKs.
>>
>
>I am sorry to have tied the two together. Maybe not OVS but the approach
>described is heaven for vendor SDKs.
>
>>The statement was that the requirement of deriving hardware flows from
>>software flows *in the kernel* is not flexible enough for the future
>>for reasons such as:
>>
>>1) The OVS software data path might be based on eBPF in the future and
>> it is unclear how we could derive hardware flows from that
>> transparently.
>>
>
>Who says you cant put BPF in hardware?
>And why is OVS defining how BPF should evolve or how it should be used?
>
>>2) Depending on hardware capabilities. Hardware flows might need to be
>> assisted by software flow counterparts and it is believed that it
>> is the wrong approach to push all the necessary context for the
>> decision down into the kernel. This can be argued about and I don't
>> feel strongly either way.
>>
>
>Pointing to the current FDB offload: You can select to bypass
>and not use s/ware.
>
>cheers,
>jamal
^ permalink raw reply
* [PATCH net] ip_tunnel: Don't allow to add the same tunnel multiple times.
From: Steffen Klassert @ 2014-09-22 7:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
When we try to add an already existing tunnel, we don't return
an error. Instead we continue and call ip_tunnel_update().
This means that we can change existing tunnels by adding
the same tunnel multiple times. It is even possible to change
the tunnel endpoints of the fallback device.
We fix this by returning an error if we try to add an existing
tunnel.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
I was not able to find a commit that introduced this bug.
Looks like ipip and ip_gre had similar bugs already with
the initial git commit.
net/ipv4/ip_tunnel.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index afed1aa..8fb8da9 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -764,9 +764,14 @@ int ip_tunnel_ioctl(struct net_device *dev, struct ip_tunnel_parm *p, int cmd)
t = ip_tunnel_find(itn, p, itn->fb_tunnel_dev->type);
- if (!t && (cmd == SIOCADDTUNNEL)) {
- t = ip_tunnel_create(net, itn, p);
- err = PTR_ERR_OR_ZERO(t);
+ if (cmd == SIOCADDTUNNEL) {
+ if (!t) {
+ t = ip_tunnel_create(net, itn, p);
+ err = PTR_ERR_OR_ZERO(t);
+ break;
+ }
+
+ err = -EEXIST;
break;
}
if (dev != itn->fb_tunnel_dev && cmd == SIOCCHGTUNNEL) {
--
1.9.1
^ permalink raw reply related
* pull request (net): ipsec 2014-09-22
From: Steffen Klassert @ 2014-09-22 5:38 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
We generate a blackhole or queueing route if a packet
matches an IPsec policy but a state can't be resolved.
Here we assume that dst_output() is called to kill
these packets. Unfortunately this assumption is not
true in all cases, so it is possible that these packets
leave the system without the necessary transformations.
This pull request contains two patches to fix this issue:
1) Fix for blackhole routed packets.
2) Fix for queue routed packets.
Both patches are serious stable candidates.
Please pull or let me know if there are problems.
Thanks!
The following changes since commit 95cd6f488d164de462a8279e802a0ad05c33d167:
scsi: fix build errors, SCSI_FC_ATTRS needs to depend on SCSI && NET (2014-09-16 00:06:57 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git master
for you to fetch changes up to b8c203b2d2fc961bafd53b41d5396bbcdec55998:
xfrm: Generate queueing routes only from route lookup functions (2014-09-16 10:08:49 +0200)
----------------------------------------------------------------
Steffen Klassert (2):
xfrm: Generate blackhole routes only from route lookup functions
xfrm: Generate queueing routes only from route lookup functions
include/net/dst.h | 16 +++++++++++++++-
net/ipv4/route.c | 6 +++---
net/ipv6/ip6_output.c | 4 ++--
net/xfrm/xfrm_policy.c | 48 ++++++++++++++++++++++++++++++++++++++++--------
4 files changed, 60 insertions(+), 14 deletions(-)
^ permalink raw reply
* [PATCH 2/2] xfrm: Generate queueing routes only from route lookup functions
From: Steffen Klassert @ 2014-09-22 5:38 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1411364320-5309-1-git-send-email-steffen.klassert@secunet.com>
Currently we genarate a queueing route if we have matching policies
but can not resolve the states and the sysctl xfrm_larval_drop is
disabled. Here we assume that dst_output() is called to kill the
queued packets. Unfortunately this assumption is not true in all
cases, so it is possible that these packets leave the system unwanted.
We fix this by generating queueing routes only from the
route lookup functions, here we can guarantee a call to
dst_output() afterwards.
Fixes: a0073fe18e71 ("xfrm: Add a state resolution packet queue")
Reported-by: Konstantinos Kolelis <k.kolelis@sirrix.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
include/net/dst.h | 1 +
net/xfrm/xfrm_policy.c | 32 ++++++++++++++++++++++++--------
2 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index fa11c90..a8ae4e7 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -480,6 +480,7 @@ void dst_init(void);
/* Flags for xfrm_lookup flags argument. */
enum {
XFRM_LOOKUP_ICMP = 1 << 0,
+ XFRM_LOOKUP_QUEUE = 1 << 1,
};
struct flowi;
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 7505674..fdde51f 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -39,6 +39,11 @@
#define XFRM_QUEUE_TMO_MAX ((unsigned)(60*HZ))
#define XFRM_MAX_QUEUE_LEN 100
+struct xfrm_flo {
+ struct dst_entry *dst_orig;
+ u8 flags;
+};
+
static DEFINE_SPINLOCK(xfrm_policy_afinfo_lock);
static struct xfrm_policy_afinfo __rcu *xfrm_policy_afinfo[NPROTO]
__read_mostly;
@@ -1877,13 +1882,14 @@ static int xdst_queue_output(struct sock *sk, struct sk_buff *skb)
}
static struct xfrm_dst *xfrm_create_dummy_bundle(struct net *net,
- struct dst_entry *dst,
+ struct xfrm_flo *xflo,
const struct flowi *fl,
int num_xfrms,
u16 family)
{
int err;
struct net_device *dev;
+ struct dst_entry *dst;
struct dst_entry *dst1;
struct xfrm_dst *xdst;
@@ -1891,9 +1897,12 @@ static struct xfrm_dst *xfrm_create_dummy_bundle(struct net *net,
if (IS_ERR(xdst))
return xdst;
- if (net->xfrm.sysctl_larval_drop || num_xfrms <= 0)
+ if (!(xflo->flags & XFRM_LOOKUP_QUEUE) ||
+ net->xfrm.sysctl_larval_drop ||
+ num_xfrms <= 0)
return xdst;
+ dst = xflo->dst_orig;
dst1 = &xdst->u.dst;
dst_hold(dst);
xdst->route = dst;
@@ -1935,7 +1944,7 @@ static struct flow_cache_object *
xfrm_bundle_lookup(struct net *net, const struct flowi *fl, u16 family, u8 dir,
struct flow_cache_object *oldflo, void *ctx)
{
- struct dst_entry *dst_orig = (struct dst_entry *)ctx;
+ struct xfrm_flo *xflo = (struct xfrm_flo *)ctx;
struct xfrm_policy *pols[XFRM_POLICY_TYPE_MAX];
struct xfrm_dst *xdst, *new_xdst;
int num_pols = 0, num_xfrms = 0, i, err, pol_dead;
@@ -1976,7 +1985,8 @@ xfrm_bundle_lookup(struct net *net, const struct flowi *fl, u16 family, u8 dir,
goto make_dummy_bundle;
}
- new_xdst = xfrm_resolve_and_create_bundle(pols, num_pols, fl, family, dst_orig);
+ new_xdst = xfrm_resolve_and_create_bundle(pols, num_pols, fl, family,
+ xflo->dst_orig);
if (IS_ERR(new_xdst)) {
err = PTR_ERR(new_xdst);
if (err != -EAGAIN)
@@ -2010,7 +2020,7 @@ make_dummy_bundle:
/* We found policies, but there's no bundles to instantiate:
* either because the policy blocks, has no transformations or
* we could not build template (no xfrm_states).*/
- xdst = xfrm_create_dummy_bundle(net, dst_orig, fl, num_xfrms, family);
+ xdst = xfrm_create_dummy_bundle(net, xflo, fl, num_xfrms, family);
if (IS_ERR(xdst)) {
xfrm_pols_put(pols, num_pols);
return ERR_CAST(xdst);
@@ -2104,13 +2114,18 @@ struct dst_entry *xfrm_lookup(struct net *net, struct dst_entry *dst_orig,
}
if (xdst == NULL) {
+ struct xfrm_flo xflo;
+
+ xflo.dst_orig = dst_orig;
+ xflo.flags = flags;
+
/* To accelerate a bit... */
if ((dst_orig->flags & DST_NOXFRM) ||
!net->xfrm.policy_count[XFRM_POLICY_OUT])
goto nopol;
flo = flow_cache_lookup(net, fl, family, dir,
- xfrm_bundle_lookup, dst_orig);
+ xfrm_bundle_lookup, &xflo);
if (flo == NULL)
goto nopol;
if (IS_ERR(flo)) {
@@ -2202,7 +2217,8 @@ struct dst_entry *xfrm_lookup_route(struct net *net, struct dst_entry *dst_orig,
const struct flowi *fl,
struct sock *sk, int flags)
{
- struct dst_entry *dst = xfrm_lookup(net, dst_orig, fl, sk, flags);
+ struct dst_entry *dst = xfrm_lookup(net, dst_orig, fl, sk,
+ flags | XFRM_LOOKUP_QUEUE);
if (IS_ERR(dst) && PTR_ERR(dst) == -EREMOTE)
return make_blackhole(net, dst_orig->ops->family, dst_orig);
@@ -2476,7 +2492,7 @@ int __xfrm_route_forward(struct sk_buff *skb, unsigned short family)
skb_dst_force(skb);
- dst = xfrm_lookup(net, skb_dst(skb), &fl, NULL, 0);
+ dst = xfrm_lookup(net, skb_dst(skb), &fl, NULL, XFRM_LOOKUP_QUEUE);
if (IS_ERR(dst)) {
res = 0;
dst = NULL;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] xfrm: Generate blackhole routes only from route lookup functions
From: Steffen Klassert @ 2014-09-22 5:38 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1411364320-5309-1-git-send-email-steffen.klassert@secunet.com>
Currently we genarate a blackhole route route whenever we have
matching policies but can not resolve the states. Here we assume
that dst_output() is called to kill the balckholed packets.
Unfortunately this assumption is not true in all cases, so
it is possible that these packets leave the system unwanted.
We fix this by generating blackhole routes only from the
route lookup functions, here we can guarantee a call to
dst_output() afterwards.
Fixes: 2774c131b1d ("xfrm: Handle blackhole route creation via afinfo.")
Reported-by: Konstantinos Kolelis <k.kolelis@sirrix.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
include/net/dst.h | 15 ++++++++++++++-
net/ipv4/route.c | 6 +++---
net/ipv6/ip6_output.c | 4 ++--
net/xfrm/xfrm_policy.c | 18 +++++++++++++++++-
4 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index 71c60f4..fa11c90 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -490,7 +490,16 @@ static inline struct dst_entry *xfrm_lookup(struct net *net,
int flags)
{
return dst_orig;
-}
+}
+
+static inline struct dst_entry *xfrm_lookup_route(struct net *net,
+ struct dst_entry *dst_orig,
+ const struct flowi *fl,
+ struct sock *sk,
+ int flags)
+{
+ return dst_orig;
+}
static inline struct xfrm_state *dst_xfrm(const struct dst_entry *dst)
{
@@ -502,6 +511,10 @@ struct dst_entry *xfrm_lookup(struct net *net, struct dst_entry *dst_orig,
const struct flowi *fl, struct sock *sk,
int flags);
+struct dst_entry *xfrm_lookup_route(struct net *net, struct dst_entry *dst_orig,
+ const struct flowi *fl, struct sock *sk,
+ int flags);
+
/* skb attached with this dst needs transformation if dst->xfrm is valid */
static inline struct xfrm_state *dst_xfrm(const struct dst_entry *dst)
{
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index eaa4b00..173e7ea 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2265,9 +2265,9 @@ struct rtable *ip_route_output_flow(struct net *net, struct flowi4 *flp4,
return rt;
if (flp4->flowi4_proto)
- rt = (struct rtable *) xfrm_lookup(net, &rt->dst,
- flowi4_to_flowi(flp4),
- sk, 0);
+ rt = (struct rtable *)xfrm_lookup_route(net, &rt->dst,
+ flowi4_to_flowi(flp4),
+ sk, 0);
return rt;
}
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 315a55d..0a3448b 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1009,7 +1009,7 @@ struct dst_entry *ip6_dst_lookup_flow(struct sock *sk, struct flowi6 *fl6,
if (final_dst)
fl6->daddr = *final_dst;
- return xfrm_lookup(sock_net(sk), dst, flowi6_to_flowi(fl6), sk, 0);
+ return xfrm_lookup_route(sock_net(sk), dst, flowi6_to_flowi(fl6), sk, 0);
}
EXPORT_SYMBOL_GPL(ip6_dst_lookup_flow);
@@ -1041,7 +1041,7 @@ struct dst_entry *ip6_sk_dst_lookup_flow(struct sock *sk, struct flowi6 *fl6,
if (final_dst)
fl6->daddr = *final_dst;
- return xfrm_lookup(sock_net(sk), dst, flowi6_to_flowi(fl6), sk, 0);
+ return xfrm_lookup_route(sock_net(sk), dst, flowi6_to_flowi(fl6), sk, 0);
}
EXPORT_SYMBOL_GPL(ip6_sk_dst_lookup_flow);
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index beeed60..7505674 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2138,7 +2138,7 @@ struct dst_entry *xfrm_lookup(struct net *net, struct dst_entry *dst_orig,
xfrm_pols_put(pols, drop_pols);
XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTNOSTATES);
- return make_blackhole(net, family, dst_orig);
+ return ERR_PTR(-EREMOTE);
}
err = -EAGAIN;
@@ -2195,6 +2195,22 @@ dropdst:
}
EXPORT_SYMBOL(xfrm_lookup);
+/* Callers of xfrm_lookup_route() must ensure a call to dst_output().
+ * Otherwise we may send out blackholed packets.
+ */
+struct dst_entry *xfrm_lookup_route(struct net *net, struct dst_entry *dst_orig,
+ const struct flowi *fl,
+ struct sock *sk, int flags)
+{
+ struct dst_entry *dst = xfrm_lookup(net, dst_orig, fl, sk, flags);
+
+ if (IS_ERR(dst) && PTR_ERR(dst) == -EREMOTE)
+ return make_blackhole(net, dst_orig->ops->family, dst_orig);
+
+ return dst;
+}
+EXPORT_SYMBOL(xfrm_lookup_route);
+
static inline int
xfrm_secpath_reject(int idx, struct sk_buff *skb, const struct flowi *fl)
{
--
1.9.1
^ permalink raw reply related
* Re: [PATCHv6 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6
From: David L Stevens @ 2014-09-22 4:40 UTC (permalink / raw)
To: Raghuram Kothakota; +Cc: David Miller, netdev
In-Reply-To: <541B395D.1000809@oracle.com>
> On 09/18/2014 02:49 PM, Raghuram Kothakota wrote:
>> In the virtualization world, we want resources to be efficiently used and memory is
>> still very important resource. My concern is mostly because this memory usage of
>> 32+MB is on a per LDC basis. LDoms today supports a max of 128 domains, but
>> from my experience seen actual deployments of the order of 50 domains. This is
>> going up as the platforms getting more and more powerful. If there are really
>> that many peers, then the amount of memory consumed by one vnet instance
>> is 50 * 32+MB = 1.6GB+. It's fine if this memory is really used, but it seems like this
>> will be useful only when the peer is another linux guest with this version of vnet and
>> also the MTU is configured to use 64K. The memory is being wasted for all other
>> peers that either don't support 64K MTU or not configured to use it and also
>> the switch port as obviously it doesn't support 64K MTU today.
I think I have a solution for this -- I'm doing some experimenting, but it may be a few days.
However, fundamentally, the problem is that there are n^2-n links both ways, so 50 LDOMs on the same vswitch
will always be 2450X the resources of a single pair, and lead to scary aggregate numbers. Large installations
really need more vswitches with fewer LDOMs per switch, at least with the current code.
+-DLS
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid possible arithmetic overflows
From: Joe Perches @ 2014-09-22 3:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Yuchung Cheng, David Miller, netdev, Neal Cardwell
In-Reply-To: <1411259357.26859.89.camel@edumazet-glaptop2.roam.corp.google.com>
On Sat, 2014-09-20 at 17:29 -0700, Eric Dumazet wrote:
> icsk_rto is a 32bit field, and icsk_backoff can reach 15 by default,
> or more if some sysctl (eg tcp_retries2) are changed.
>
> Better use 64bit to perform icsk_rto << icsk_backoff operations
Thanks Eric.
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
[]
> @@ -3208,9 +3208,10 @@ static void tcp_ack_probe(struct sock *sk)
> * This function is not for random using!
> */
> } else {
> + unsigned long when = inet_csk_rto_backoff(icsk, TCP_RTO_MAX);
> +
> inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0,
> - min(icsk->icsk_rto << icsk->icsk_backoff, TCP_RTO_MAX),
> - TCP_RTO_MAX);
> + when, TCP_RTO_MAX);
Pity about the possible extra compare to TCP_RTO_MAX here.
I hope gcc smart enough to optimize it away.
^ permalink raw reply
* RE: [patch -next] r8169: fix an if condition
From: Hayes Wang @ 2014-09-22 2:30 UTC (permalink / raw)
To: Dan Carpenter, nic_swsd
Cc: netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <20140919104025.GA26391@mwanda>
From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Friday, September 19, 2014 6:40 PM
[...]
> There is an extra semi-colon so __rtl8169_set_features() is
> called every
> time.
Acked-by: Hayes Wang <hayeswang@realtek.com>
^ 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