* Re: Help testing for USB ethernet/xHCI regression
From: Sarah Sharp @ 2014-01-29 21:54 UTC (permalink / raw)
To: renevant; +Cc: linux-usb, Mark Lord, Greg Kroah-Hartman, netdev, David Laight
In-Reply-To: <22081260.RNay0J72dY@athas>
On Wed, Jan 29, 2014 at 04:21:00PM +1100, renevant@internode.on.net wrote:
> Hello,
>
> I am someone who has been struggling to get an ax88179 net adapter working
> reliably.
>
> I have an integrated Asmedia 1042 xhci controller that is reportedly version
> 0.96 on an ASUS M5A99FX PRO R2.0, BIOS 2201 motherboard based on the AMD 990FX
> chipset.
>
> The big issue I am currently facing is that I cannot get the device to work at
> all with 3.13 and current 3.14 mainline. This does not occur with 3.12.
With the working kernel, were you using vanilla 3.12, or a later 3.12
stable release, like 3.12.5?
> Current issue is when plugging in the ax88179 there is lag when bringing the
> interface up and a bunch of kernel messages:
With which kernel?
> [ 63.389440] ax88179_178a 2-1:1.0 eth0: register 'ax88179_178a' at
> usb-0000:07:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 80:3f:5d:08:0c:65
> [ 63.389500] usbcore: registered new interface driver ax88179_178a
> [ 63.423942] systemd-udevd[560]: renamed network interface eth0 to enp7s0u1
> [ 79.481028] IPv6: ADDRCONF(NETDEV_UP): enp7s0u1: link is not ready
> [ 82.210721] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [ 82.338947] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [ 82.467148] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped
> [ 82.470028] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [ 82.595364] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped
> [ 82.598312] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [ 82.723580] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped
> [ 82.726487] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [ 82.851796] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped
> [ 82.854642] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [snip]
> [ 87.218379] ax88179_178a 2-1:1.0 enp7s0u1: Failed to write reg index
> 0x0002: -110
Can you enable xHCI debugging as well, and send dmesg? You'll need to
have CONFIG_USB_DEBUG turned on, and also run this command as root:
echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
> Any traffic sent to the nic isn't seen by Linux.
>
>
> I can confirm the following problems for me with 3.14:
>
> reverting the writeq patch made USB 3 work for me again.
>
> http://marc.info/?t=139093294600002&r=1&w=2
So what was the issue that caused you to revert that patch? The traffic
not going to the device, or the device not being enumerated at all?
> and
>
> http://marc.info/?l=linux-usb&m=139092084714232&w=2
>
> got rid of transiever errors
>
>
>
>
> I cannot really test stability for the ax88179 until I can get it to work when
> plugging it in as above. I've tried the frag reversion and it's made no
> difference to this issue.
What about also reverting the writeq patch, on top of the other patches
I asked Mark to try?
Sarah Sharp
^ permalink raw reply
* Re: [PATCH 0/2] DT: net: davinci_emac: couple more properties actually optional
From: Sergei Shtylyov @ 2014-01-29 22:42 UTC (permalink / raw)
To: David Miller
Cc: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree, linux-doc, davinci-linux-open-source
In-Reply-To: <20140128.234315.2164810932256158473.davem@davemloft.net>
Hello.
On 01/29/2014 10:43 AM, David Miller wrote:
>> Though described as required, couple more properties in the DaVinci EMAC
>> binding are actually optional, as the driver will happily function without them.
>> The patchset is against DaveM's 'net.git' tree this time.
>> [1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
>> [2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
> Series applied with the "has/have" thing fixed.
> Thanks.
Thank you!
Unfortunately, this driver presents a bad example of DT bindings overall
(caused in its turn by a misuse of the platform data for the EMAC type
differing instead of the platform device IDs).
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] DT: net: document Ethernet bindings in one place
From: Sergei Shtylyov @ 2014-01-29 23:04 UTC (permalink / raw)
To: Florian Fainelli, Rob Herring
Cc: netdev, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, devicetree@vger.kernel.org, Rob Landley,
linux-doc@vger.kernel.org, Grant Likely
In-Reply-To: <52DEE465.9000202@cogentembedded.com>
Hello.
On 01/22/2014 12:19 AM, Sergei Shtylyov wrote:
>>>>> I'm afraid that's too late, it has spread very far, so that
>>>>> of_get_phy_mode() handles that property, not "phy-connection-type".
>>>> Uggg, I guess this is a case of a defacto standard then if the kernel
>>>> doesn't even support it.
>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a
>>> while ago for of_get_phy_mode() to look for both "phy-mode" and
>>> "phy-connection-type" since the former has been a Linux invention, but
>>> the latter is ePAPR specified.
>> Here is a link to the actual patch in question, not sure which tree
>> Grant applied it to though:
>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html
> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in
> this reply, and I couldn't follow the thread. Here's the actual patch mail:
> http://marc.info/?l=devicetree&m=138449662807254
Florian, I didn't find this patch in Grant's official tree, so maybe you
should ask him where is the patch already?
WBR, Sergei
^ permalink raw reply
* [Patch iproute2] pedit: do not print debugging information by default
From: Cong Wang @ 2014-01-29 23:12 UTC (permalink / raw)
To: netdev; +Cc: Jamal Hadi Salim, Stephen Hemminger, Cong Wang
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
diff --git a/tc/m_pedit.c b/tc/m_pedit.c
index 452d96f..16dd277 100644
--- a/tc/m_pedit.c
+++ b/tc/m_pedit.c
@@ -30,7 +30,7 @@
#include "m_pedit.h"
static struct m_pedit_util *pedit_list;
-int pedit_debug = 1;
+static int pedit_debug;
static void
explain(void)
^ permalink raw reply related
* Re: IPv6 multiple routing tables - all routes were added to main table
From: Ben Greear @ 2014-01-29 23:17 UTC (permalink / raw)
To: Asi Lichtenstein; +Cc: netdev
In-Reply-To: <CAMBtn_0S0K6eydjTLJAsVqbKVuJ+tc7k30OUWRxscm+gP6y2EQ@mail.gmail.com>
On 01/28/2014 01:38 AM, Asi Lichtenstein wrote:
> Hi there,
>
> I'm using an old kernel 2.6.16 where i applied this patchset:
> http://thread.gmane.org/gmane.linux.network/41149/focus=41150
>
> i was able to create new table but all routes I've added to specific
> table were added to main table.
No idea if your patches will work on that ancient kernel. Did you update
your ip tool as well?
try: ip route show table X
and show us what commands you used to try to add the routes to a specific
table?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [Patch net] net: allow setting mac address of loopback device
From: Cong Wang @ 2014-01-29 23:38 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Eric Dumazet, David S. Miller, Cong Wang
We are trying to mirror the local traffic from lo to eth0,
allowing setting mac address of lo to eth0 would make
the ether addresses in these packets correct, so that
we don't have to modify the ether header again.
Since usually no one cares about its mac address (all-zero),
it is safe to allow those who care to set its mac address.
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index c5011e0..a0ee030 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -160,6 +160,7 @@ static const struct net_device_ops loopback_ops = {
.ndo_init = loopback_dev_init,
.ndo_start_xmit= loopback_xmit,
.ndo_get_stats64 = loopback_get_stats64,
+ .ndo_set_mac_address = eth_mac_addr,
};
/*
^ permalink raw reply related
* Re: [PATCH v2 3/4] net: ethoc: set up MII management bus clock
From: Max Filippov @ 2014-01-30 0:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-xtensa@linux-xtensa.org, netdev, LKML, Chris Zankel,
Marc Gauthier, David S. Miller, Ben Hutchings
In-Reply-To: <52E8A74F.9060603@gmail.com>
On Wed, Jan 29, 2014 at 11:01 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Le 28/01/2014 22:00, Max Filippov a écrit :
>
>> MII management bus clock is derived from the MAC clock by dividing it by
>> MIIMODER register CLKDIV field value. This value may need to be set up
>> in case it is undefined or its default value is too high (and
>> communication with PHY is too slow) or too low (and communication with
>> PHY is impossible). The value of CLKDIV is not specified directly, but
>> is derived from the MAC clock for the default MII management bus frequency
>> of 2.5MHz. The MAC clock may be specified in the platform data, or as
>> either 'clock-frequency' or 'clocks' device tree attribute.
>>
>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>> ---
>> Changes v1->v2:
>> - drop MDIO bus frequency configurability, always configure for standard
>> 2.5MHz;
>> - allow using common clock framework to provide ethoc clock.
>>
>> drivers/net/ethernet/ethoc.c | 37 +++++++++++++++++++++++++++++++++++--
>> include/net/ethoc.h | 1 +
>> 2 files changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
>> index 5643b2d..5854d41 100644
>> --- a/drivers/net/ethernet/ethoc.c
>> +++ b/drivers/net/ethernet/ethoc.c
>> @@ -13,6 +13,7 @@
>>
>> #include <linux/dma-mapping.h>
>> #include <linux/etherdevice.h>
>> +#include <linux/clk.h>
>> #include <linux/crc32.h>
>> #include <linux/interrupt.h>
>> #include <linux/io.h>
>> @@ -216,6 +217,7 @@ struct ethoc {
>>
>> struct phy_device *phy;
>> struct mii_bus *mdio;
>> + struct clk *clk;
>> s8 phy_id;
>> };
>>
>> @@ -925,6 +927,8 @@ static int ethoc_probe(struct platform_device *pdev)
>> int num_bd;
>> int ret = 0;
>> bool random_mac = false;
>> + u32 eth_clkfreq = 0;
>> + struct ethoc_platform_data *pdata = dev_get_platdata(&pdev->dev);
>>
>> /* allocate networking device */
>> netdev = alloc_etherdev(sizeof(struct ethoc));
>> @@ -1038,8 +1042,7 @@ static int ethoc_probe(struct platform_device *pdev)
>> }
>>
>> /* Allow the platform setup code to pass in a MAC address. */
>> - if (dev_get_platdata(&pdev->dev)) {
>> - struct ethoc_platform_data *pdata =
>> dev_get_platdata(&pdev->dev);
>> + if (pdata) {
>> memcpy(netdev->dev_addr, pdata->hwaddr, IFHWADDRLEN);
>> priv->phy_id = pdata->phy_id;
>> } else {
>> @@ -1077,6 +1080,32 @@ static int ethoc_probe(struct platform_device
>> *pdev)
>> if (random_mac)
>> netdev->addr_assign_type = NET_ADDR_RANDOM;
>>
>> + /* Allow the platform setup code to adjust MII management bus
>> clock. */
>> + if (pdata)
>> + eth_clkfreq = pdata->eth_clkfreq;
>
> Since this is a new member, why not make it a struct clk pointer directly so
> you could simplify the code path?
Basically this is to provide flexibility for the user: it may be more
appropriate to
specify frequency if it's known and fixed, otherwise clk_get below
would find the
clock registered for this device/generic clock.
>> + else
>> + of_property_read_u32(pdev->dev.of_node,
>> + "clock-frequency", ð_clkfreq);
>> + if (!eth_clkfreq) {
>> + struct clk *clk = clk_get(&pdev->dev, NULL);
This should have been devm_clk_get.
>> +
>> + if (!IS_ERR(clk)) {
>> + priv->clk = clk;
>> + clk_prepare_enable(clk);
>> + eth_clkfreq = clk_get_rate(clk);
>> + }
>> + }
>> + if (eth_clkfreq) {
>> + u32 clkdiv = MIIMODER_CLKDIV(eth_clkfreq / 2500000 + 1);
>> +
>> + if (!clkdiv)
>> + clkdiv = 2;
>> + dev_dbg(&pdev->dev, "setting MII clkdiv to %u\n", clkdiv);
>> + ethoc_write(priv, MIIMODER,
>> + (ethoc_read(priv, MIIMODER) & MIIMODER_NOPRE)
>> |
>> + clkdiv);
>> + }
>
>
> This does look a bit convoluted, and it looks like the clk_get() or getting
> the clock-frequency property should boil down to being the same thing with
> of_clk_get() as it should resolve all clocks phandles and fetch their
> frequencies appropriately.
I can drop clock-frequency property checking to encourage usage of common
clock framework. I don't quite understand the rest of the objection, could you
please rephrase it? clk_get calls of_clk_get internally.
>> +
>> /* register MII bus */
>> priv->mdio = mdiobus_alloc();
>> if (!priv->mdio) {
>> @@ -1141,6 +1170,8 @@ free_mdio:
>> kfree(priv->mdio->irq);
>> mdiobus_free(priv->mdio);
>> free:
>> + if (priv->clk)
>> + clk_disable_unprepare(priv->clk);
>
>
> This should probbaly be if (!IS_ERR(priv-clk)).
No, I haven't changed priv->clk when get_clk returned error.
>> free_netdev(netdev);
>> out:
>> return ret;
>> @@ -1165,6 +1196,8 @@ static int ethoc_remove(struct platform_device
>> *pdev)
>> kfree(priv->mdio->irq);
>> mdiobus_free(priv->mdio);
>> }
>> + if (priv->clk)
>> + clk_disable_unprepare(priv->clk);
>
>
> Same here
Ditto.
>> unregister_netdev(netdev);
>> free_netdev(netdev);
>> }
>> diff --git a/include/net/ethoc.h b/include/net/ethoc.h
>> index 96f3789..2a2d6bb 100644
>> --- a/include/net/ethoc.h
>> +++ b/include/net/ethoc.h
>> @@ -16,6 +16,7 @@
>> struct ethoc_platform_data {
>> u8 hwaddr[IFHWADDRLEN];
>> s8 phy_id;
>> + u32 eth_clkfreq;
>> };
>>
>> #endif /* !LINUX_NET_ETHOC_H */
>>
--
Thanks.
-- Max
^ permalink raw reply
* Re: [PATCH v2 4/4] net: ethoc: implement ethtool operations
From: Ben Hutchings @ 2014-01-30 1:59 UTC (permalink / raw)
To: Max Filippov
Cc: linux-xtensa, netdev, linux-kernel, Chris Zankel, Marc Gauthier,
David S. Miller, Florian Fainelli
In-Reply-To: <1390975218-13863-5-git-send-email-jcmvbkbc@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]
On Wed, 2014-01-29 at 10:00 +0400, Max Filippov wrote:
> The following methods are implemented:
> - get/set settings;
> - get registers length/registers;
> - get link state (standard implementation);
> - get/set ring parameters;
> - get timestamping info (standard implementation).
[...]
> --- a/drivers/net/ethernet/ethoc.c
> +++ b/drivers/net/ethernet/ethoc.c
> [...]
> +static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> + struct phy_device *phydev = priv->phy;
> +
> + if (!phydev)
> + return -ENODEV;
> +
> + return phy_ethtool_gset(phydev, cmd);
> +}
> +
> +static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> + struct phy_device *phydev = priv->phy;
> +
> + if (!phydev)
> + return -ENODEV;
> +
> + return phy_ethtool_sset(phydev, cmd);
> +}
I think these should return -EOPNOTSUPP in the PHY-less case, just as if
the set_settings pointer was not set.
[...]
> +static void ethoc_get_ringparam(struct net_device *dev,
> + struct ethtool_ringparam *ring)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> +
> + ring->rx_max_pending = priv->num_bd;
> + ring->rx_mini_max_pending = 0;
> + ring->rx_jumbo_max_pending = 0;
> + ring->tx_max_pending = priv->num_bd;
> +
> + ring->rx_pending = priv->num_rx;
> + ring->rx_mini_pending = 0;
> + ring->rx_jumbo_pending = 0;
> + ring->tx_pending = priv->num_tx;
> +}
> +
> +static int ethoc_set_ringparam(struct net_device *dev,
> + struct ethtool_ringparam *ring)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> +
> + if (netif_running(dev))
> + return -EBUSY;
This is unhelpful. Most implementations of this operation will restart
the interface if it's running.
> + priv->num_tx = rounddown_pow_of_two(ring->tx_pending);
Range check?
> + priv->num_rx = priv->num_bd - priv->num_tx;
> + if (priv->num_rx > ring->rx_pending)
> + priv->num_rx = ring->rx_pending;
So the RX ring may only ever be shrunk?! Did you mean to compare with
priv->num_bd instead?
> + return 0;
> +}
> +
> +const struct ethtool_ops ethoc_ethtool_ops = {
static
> + .get_settings = ethoc_get_settings,
> + .set_settings = ethoc_set_settings,
> + .get_regs_len = ethoc_get_regs_len,
> + .get_regs = ethoc_get_regs,
> + .get_link = ethtool_op_get_link,
> + .get_ringparam = ethoc_get_ringparam,
> + .set_ringparam = ethoc_set_ringparam,
> + .get_ts_info = ethtool_op_get_ts_info,
> +};
[...]
--
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert Einstein
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/4] net: ethoc: implement ethtool operations
From: Max Filippov @ 2014-01-30 3:04 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-xtensa@linux-xtensa.org, netdev, LKML, Chris Zankel,
Marc Gauthier, David S. Miller, Florian Fainelli
In-Reply-To: <1391047176.4405.43.camel@deadeye.wl.decadent.org.uk>
On Thu, Jan 30, 2014 at 5:59 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Wed, 2014-01-29 at 10:00 +0400, Max Filippov wrote:
>> The following methods are implemented:
>> - get/set settings;
>> - get registers length/registers;
>> - get link state (standard implementation);
>> - get/set ring parameters;
>> - get timestamping info (standard implementation).
> [...]
>> --- a/drivers/net/ethernet/ethoc.c
>> +++ b/drivers/net/ethernet/ethoc.c
>> [...]
>> +static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> + struct phy_device *phydev = priv->phy;
>> +
>> + if (!phydev)
>> + return -ENODEV;
>> +
>> + return phy_ethtool_gset(phydev, cmd);
>> +}
>> +
>> +static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> + struct phy_device *phydev = priv->phy;
>> +
>> + if (!phydev)
>> + return -ENODEV;
>> +
>> + return phy_ethtool_sset(phydev, cmd);
>> +}
>
> I think these should return -EOPNOTSUPP in the PHY-less case, just as if
> the set_settings pointer was not set.
Ok
> [...]
>> +static void ethoc_get_ringparam(struct net_device *dev,
>> + struct ethtool_ringparam *ring)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> +
>> + ring->rx_max_pending = priv->num_bd;
>> + ring->rx_mini_max_pending = 0;
>> + ring->rx_jumbo_max_pending = 0;
>> + ring->tx_max_pending = priv->num_bd;
>> +
>> + ring->rx_pending = priv->num_rx;
>> + ring->rx_mini_pending = 0;
>> + ring->rx_jumbo_pending = 0;
>> + ring->tx_pending = priv->num_tx;
>> +}
>> +
>> +static int ethoc_set_ringparam(struct net_device *dev,
>> + struct ethtool_ringparam *ring)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> +
>> + if (netif_running(dev))
>> + return -EBUSY;
>
> This is unhelpful. Most implementations of this operation will restart
> the interface if it's running.
Ok
>> + priv->num_tx = rounddown_pow_of_two(ring->tx_pending);
>
> Range check?
May there be requested more than ring->tx_max_pending that we
indicated in the get_ringparam?
>> + priv->num_rx = priv->num_bd - priv->num_tx;
>> + if (priv->num_rx > ring->rx_pending)
>> + priv->num_rx = ring->rx_pending;
>
> So the RX ring may only ever be shrunk?! Did you mean to compare with
> priv->num_bd instead?
First all non-TX descriptors are made RX, and if that's more than user
requested I trim it.
>> + return 0;
>> +}
>> +
>> +const struct ethtool_ops ethoc_ethtool_ops = {
>
> static
Ok
--
Thanks.
-- Max
^ permalink raw reply
* [PATCH] rtl8192ce is disabling the irqs for too long
From: Olivier Langlois @ 2014-01-30 6:22 UTC (permalink / raw)
To: Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ,
linville-2XuSBdqkA4R54TAoqtyWWQ,
chaoming_li-kXabqFNEczNtrwSWzY7KCg
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
mlang45-KttuZimePZJWk0Htik3J/w, Olivier Langlois
rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans
The observable symptoms in dmesg can be:
- underruns from ALSA playback
- clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled):
[ 250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100
[ 250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable
[ 250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10
[ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[ 250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32)
[ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0
[ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc
[ 250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!!
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x40000000, ofdm_index=0xc
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <===
[ 250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1
[ 250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3
[ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[ 250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore
[ 251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505)
The exact code flow that causes that is:
1. wpa_supplicant send a start_scan request to the nl80211 driver
2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE
3. rtl_ips_nic_on is called which disable local irqs
4. rtl92c_phy_set_rf_power_state() is called
5. rtl_ps_enable_nic() is called and hw_init()is executed and interrupts on the device
A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled
but a quick and dirty solution that has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed.
Signed-off-by: Olivier Langlois <olivier-VxAV575H0jR+kJTeVDPgHg@public.gmane.org>
---
drivers/net/wireless/rtlwifi/ps.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18 ++++++++++++++++--
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/ps.c b/drivers/net/wireless/rtlwifi/ps.c
index 0d81f76..a56e9b3 100644
--- a/drivers/net/wireless/rtlwifi/ps.c
+++ b/drivers/net/wireless/rtlwifi/ps.c
@@ -48,7 +48,7 @@ bool rtl_ps_enable_nic(struct ieee80211_hw *hw)
/*<2> Enable Adapter */
if (rtlpriv->cfg->ops->hw_init(hw))
- return 1;
+ return false;
RT_CLEAR_PS_LEVEL(ppsc, RT_RF_OFF_LEVL_HALT_NIC);
/*<3> Enable Interrupt */
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index a82b30a..2eb0b38 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -937,14 +937,26 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
bool is92c;
int err;
u8 tmp_u1b;
+ unsigned long flags;
rtlpci->being_init_adapter = true;
+
+ /* Since this function can take a very long time (up to 350 ms)
+ * and can be called with irqs disabled, reenable the irqs
+ * to let the other devices continue being serviced.
+ *
+ * It is safe doing so since our own interrupts will only be enabled
+ * in a subsequent step.
+ */
+ local_save_flags(flags);
+ local_irq_enable();
+
rtlpriv->intf_ops->disable_aspm(hw);
rtstatus = _rtl92ce_init_mac(hw);
if (!rtstatus) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Init MAC failed\n");
err = 1;
- return err;
+ goto exit;
}
err = rtl92c_download_fw(hw);
@@ -952,7 +964,7 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
RT_TRACE(rtlpriv, COMP_ERR, DBG_WARNING,
"Failed to download FW. Init HW without FW now..\n");
err = 1;
- return err;
+ goto exit;
}
rtlhal->last_hmeboxnum = 0;
@@ -1032,6 +1044,8 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE, "under 1.5V\n");
}
rtl92c_dm_init(hw);
+exit:
+ local_irq_restore(flags);
rtlpci->being_init_adapter = false;
return err;
}
--
1.8.5.2
--
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
* Re: [PATCH] ath9k: Fix uninitialized variable in ath9k_has_tx_pending()
From: Felix Fietkau @ 2014-01-30 6:55 UTC (permalink / raw)
To: Geert Uytterhoeven, John W. Linville, QCA ath9k Development
Cc: linux-wireless, ath9k-devel, netdev, linux-kernel
In-Reply-To: <1390733601-11244-1-git-send-email-geert@linux-m68k.org>
On 2014-01-26 11:53, Geert Uytterhoeven wrote:
> drivers/net/wireless/ath/ath9k/main.c: In function ‘ath9k_has_tx_pending’:
> drivers/net/wireless/ath/ath9k/main.c:1869: warning: ‘npend’ may be used uninitialized in this function
>
> Introduced by commit 10e2318103f5941aa70c318afe34bc41f1b98529 ("ath9k:
> optimize ath9k_flush").
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Felix Fietkau <nbd@openwrt.org>
^ permalink raw reply
* Re: kmem_cache_alloc panic in 3.10+
From: dormando @ 2014-01-30 7:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-kernel, Alexei Starovoitov
In-Reply-To: <alpine.DEB.2.02.1401181101220.579@dtop>
> > On Sat, 2014-01-18 at 00:44 -0800, dormando wrote:
> > > Hello again!
> > >
> > > We've had a rare crash that's existed between 3.10.0 and 3.10.15 at least
> > > (trying newer stables now, but I can't tell if it was fixed, and it takes
> > > weeks to reproduce).
> > >
> > > Unfortunately I can only get 8k back from pstore. The panic looks a bit
> > > longer than that is caught in the log, but the bottom part is almost
> > > always this same trace as this one:
> > >
> > > Panic#6 Part1
> > > <4>[1197485.199166] [<ffffffff81611e8c>] tcp_push+0x6c/0x90
> > > <4>[1197485.199171] [<ffffffff816160a9>] tcp_sendmsg+0x109/0xd40
> > > <4>[1197485.199179] [<ffffffff81114b65>] ? put_page+0x35/0x40
> > > <4>[1197485.199185] [<ffffffff8163bf75>] inet_sendmsg+0x45/0xb0
> > > <4>[1197485.199191] [<ffffffff8159da7e>] sock_aio_write+0x11e/0x130
> > > <4>[1197485.199196] [<ffffffff8163b83f>] ? inet_recvmsg+0x4f/0x80
> > > <4>[1197485.199203] [<ffffffff811558ad>] do_sync_readv_writev+0x6d/0xa0
> > > <4>[1197485.199209] [<ffffffff8115722b>] do_readv_writev+0xfb/0x2f0
> > > <4>[1197485.199215] [<ffffffff8110fda5>] ? __free_pages+0x35/0x40
> > > <4>[1197485.199220] [<ffffffff8110fe56>] ? free_pages+0x46/0x50
> > > <4>[1197485.199226] [<ffffffff8112f9e2>] ? SyS_mincore+0x152/0x690
> > > <4>[1197485.199231] [<ffffffff81157468>] vfs_writev+0x48/0x60
> > > <4>[1197485.199236] [<ffffffff811575af>] SyS_writev+0x5f/0xd0
> > > <4>[1197485.199243] [<ffffffff816cf942>] system_call_fastpath+0x16/0x1b
> > > <4>[1197485.199247] Code: 65 4c 03 04 25 c8 cb 00 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 84 00 00 00 48 85 c0 74 7f 49 63 44 24 20 49 8b 3c 24 <49> 8b 5c 05 00 48 8d 4a 01 4c 89 e8 65 48 0f c7 0f 0f 94 c0 3c
> > > <1>[1197485.199290] RIP [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
> > > <4>[1197485.199296] RSP <ffff883171211868>
> > > <4>[1197485.199299] CR2: 0000000100000000
> > > <4>[1197485.199343] ---[ end trace 90fee06aa40b7304 ]---
> > > <1>[1197485.263911] BUG: unable to handle kernel paging request at 0000000100000000
> > > <1>[1197485.263923] IP: [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
> > > <4>[1197485.263932] PGD 3f43e5c067 PUD 0
> > > <4>[1197485.263937] Oops: 0000 [#5] SMP
> > > <4>[1197485.263941] Modules linked in: ntfs vfat msdos fat macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode sb_edac edac_core lpc_ich mfd_core ixgbe igb i2c_algo_bit mdio ptp pps_core
> > > <4>[1197485.263966] CPU: 0 PID: 233846 Comm: cache-worker Tainted: G D 3.10.15 #1
> > > <4>[1197485.263972] Hardware name: Supermicro X9DR3-F/X9DR3-F, BIOS 2.0a 03/07/2013
> > > <4>[1197485.263976] task: ffff883427f9dc00 ti: ffff8830d4312000 task.ti: ffff8830d4312000
> > > <4>[1197485.263982] RIP: 0010:[<ffffffff811476da>] [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
> > > <4>[1197485.263990] RSP: 0018:ffff881fffc038c8 EFLAGS: 00010286
> > > <4>[1197485.263994] RAX: 0000000000000000 RBX: ffffffff81c8c740 RCX: 00000000ffffffff
> > > <4>[1197485.263999] RDX: 0000000029273024 RSI: 0000000000000020 RDI: 0000000000015680
> > > <4>[1197485.264004] RBP: ffff881fffc03908 R08: ffff881fffc15680 R09: ffffffff815bdd4b
> > > <4>[1197485.264009] R10: ffff881c65d21800 R11: 0000000000000000 R12: ffff881fff803800
> > > <4>[1197485.264014] R13: 0000000100000000 R14: 00000000ffffffff R15: 0000000000000000
> > > <4>[1197485.264019] FS: 00007f8d855eb700(0000) GS:ffff881fffc00000(0000) knlGS:0000000000000000
> > > <4>[1197485.264024] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > <4>[1197485.264028] CR2: 0000000100000000 CR3: 000000308f258000 CR4: 00000000000407f0
> > > <4>[1197485.264032] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > <4>[1197485.264037] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > <4>[1197485.264041] Stack:
> > > <4>[1197485.264044] ffff881fffc03928 00000020815d0d95 ffff881fffc03938 ffffffff81c8c740
> > > <4>[1197485.264050] ffff881fce210000 0000000000000001 00000000ffffffff 0000000000000000
> > > <4>[1197485.264056] ffff881fffc03958 ffffffff815bdd4b ffff881fffc039a8 0000000000000000
> > > <4>[1197485.264063] Call Trace:
> > > <4>[1197485.264066] <IRQ>
> > > <4>[1197485.264069] [<ffffffff815bdd4b>] dst_alloc+0x5b/0x190
> > > <4>[1197485.264080] [<ffffffff8160068c>] rt_dst_alloc+0x4c/0x50
> > > <4>[1197485.264085] [<ffffffff81602a30>] __ip_route_output_key+0x270/0x880
> > > <4>[1197485.264092] [<ffffffff8107ee7e>] ? try_to_wake_up+0x23e/0x2b0
> > > <4>[1197485.264097] [<ffffffff81603067>] ip_route_output_flow+0x27/0x60
> > > <4>[1197485.264102] [<ffffffff8160ab8a>] ip_queue_xmit+0x36a/0x390
> > > <4>[1197485.264108] [<ffffffff816207c5>] tcp_transmit_skb+0x485/0x890
> > > <4>[1197485.264113] [<ffffffff81621aa1>] tcp_send_ack+0xf1/0x130
> > > <4>[1197485.264118] [<ffffffff81618d7e>] __tcp_ack_snd_check+0x5e/0xa0
> > > <4>[1197485.264123] [<ffffffff8161f2c2>] tcp_rcv_state_process+0x8b2/0xb20
> > > <4>[1197485.264128] [<ffffffff81627e61>] tcp_v4_do_rcv+0x191/0x4f0
> > > <4>[1197485.264133] [<ffffffff8162984c>] tcp_v4_rcv+0x5fc/0x750
> > > <4>[1197485.264138] [<ffffffff81604c80>] ? ip_rcv+0x350/0x350
> > > <4>[1197485.264143] [<ffffffff815e45cd>] ? nf_hook_slow+0x7d/0x160
> > > <4>[1197485.264147] [<ffffffff81604c80>] ? ip_rcv+0x350/0x350
> > > <4>[1197485.264152] [<ffffffff81604d4e>] ip_local_deliver_finish+0xce/0x250
> > > <4>[1197485.264156] [<ffffffff81604f1c>] ip_local_deliver+0x4c/0x80
> > > <4>[1197485.264161] [<ffffffff816045a9>] ip_rcv_finish+0x119/0x360
> > > <4>[1197485.264165] [<ffffffff81604b60>] ip_rcv+0x230/0x350
> > > <4>[1197485.264170] [<ffffffff815b89f7>] __netif_receive_skb_core+0x477/0x600
> > > <4>[1197485.264175] [<ffffffff815b8ba7>] __netif_receive_skb+0x27/0x70
> > > <4>[1197485.264180] [<ffffffff815b8ce4>] process_backlog+0xf4/0x1e0
> > > <4>[1197485.264184] [<ffffffff815b94e5>] net_rx_action+0xf5/0x250
> > > <4>[1197485.264190] [<ffffffff81053b7f>] __do_softirq+0xef/0x270
> > > <4>[1197485.264196] [<ffffffff816d0b7c>] call_softirq+0x1c/0x30
> > > <4>[1197485.264199] <EOI>
> > > <4>[1197485.264201] [<ffffffff81004495>] do_softirq+0x55/0x90
> > > <4>[1197485.264209] [<ffffffff81053a84>] local_bh_enable+0x94/0xa0
> > > <4>[1197485.264215] [<ffffffff8165567a>] ipt_do_table+0x22a/0x680
> > > <4>[1197485.264221] [<ffffffff815d39c1>] ? skb_clone_tx_timestamp+0x31/0x110
> > > <4>[1197485.264231] [<ffffffffa00ae840>] ? ixgbe_xmit_frame_ring+0x4c0/0xd40 [ixgbe]
> > > <4>[1197485.264239] [<ffffffffa00af103>] ? ixgbe_xmit_frame+0x43/0x90 [ixgbe]
> > > <4>[1197485.264245] [<ffffffff81657a23>] iptable_raw_hook+0x33/0x70
> > > <4>[1197485.264252] [<ffffffff815e43a7>] nf_iterate+0x87/0xb0
> > > <4>[1197485.264256] [<ffffffff81607e20>] ? ip_options_echo+0x420/0x420
> > > <4>[1197485.264261] [<ffffffff815e45cd>] nf_hook_slow+0x7d/0x160
> > > <4>[1197485.264266] [<ffffffff81607e20>] ? ip_options_echo+0x420/0x420
> > > <4>[1197485.264270] [<ffffffff8160a430>] __ip_local_out+0xa0/0xb0
> > > <4>[1197485.264275] [<ffffffff8160a456>] ip_local_out+0x16/0x30
> > > <4>[1197485.264280] [<ffffffff8160a97a>] ip_queue_xmit+0x15a/0x390
> > > <4>[1197485.264286] [<ffffffff81625e73>] ? tcp_v4_md5_lookup+0x13/0x20
> > > <4>[1197485.264290] [<ffffffff816207c5>] tcp_transmit_skb+0x485/0x890
> > > <4>[1197485.264295] [<ffffffff81622e08>] tcp_write_xmit+0x1b8/0xa50
> > > <4>[1197485.264300] [<ffffffff815a7e28>] ? __alloc_skb+0xa8/0x1f0
> > > <4>[1197485.264304] [<ffffffff816236d0>] tcp_push_one+0x30/0x40
> > > <4>[1197485.264309] [<ffffffff81616b84>] tcp_sendmsg+0xbe4/0xd40
> > > <4>[1197485.264315] [<ffffffff81114b65>] ? put_page+0x35/0x40
> > > <4>[1197485.264321] [<ffffffff8163bf75>] inet_sendmsg+0x45/0xb0
> > > <4>[1197485.264326] [<ffffffff8159da7e>] sock_aio_write+0x11e/0x130
> > > <4>[1197485.264331] [<ffffffff8163b83f>] ? inet_recvmsg+0x4f/0x80
> > > <4>[1197485.264337] [<ffffffff811558ad>] do_sync_readv_writev+0x6d/0xa0
> > > <4>[1197485.264343] [<ffffffff8115722b>] do_readv_writev+0xfb/0x2f0
> > > <4>[1197485.264347] [<ffffffff8110fda5>] ? __free_pages+0x35/0x40
> > > <4>[1197485.264352] [<ffffffff8110fe56>] ? free_pages+0x46/0x50
> > > <4>[1197485.264357] [<ffffffff8112f9e2>] ? SyS_mincore+0x152/0x690
> > > <4>[1197485.264363] [<ffffffff81157468>] vfs_writev+0x48/0x60
> > > <4>[1197485.264367] [<ffffffff811575af>] SyS_writev+0x5f/0xd0
> > > <4>[1197485.264373] [<ffffffff816cf942>] system_call_fastpath+0x16/0x1b
> > > <4>[1197485.264377] Code: 65 4c 03 04 25 c8 cb 00 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 84 00 00 00 48 85 c0 74 7f 49 63 44 24 20 49 8b 3c 24 <49> 8b 5c 05 00 48 8d 4a 01 4c 89 e8 65 48 0f c7 0f 0f 94 c0 3c
> > > <1>[1197485.264417] RIP [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
> > > <4>[1197485.264424] RSP <ffff881fffc038c8>
> > > <4>[1197485.264427] CR2: 0000000100000000
> > > <4>[1197485.264431] ---[ end trace 90fee06aa40b7305 ]---
> > > <0>[1197485.325141] Kernel panic - not syncing: Fatal exception in interrupt
> > >
> > > ... way down in the tcp code.
> > >
> > > Any help would be appreciated :) I'll do what I can to help, but iterating
> > > this particular crash is very hard due to the amount of time it takes to
> > > reproduce. Since we have a large number of machines they're always
> > > crashing here and there, but once they do it's not going to happen again
> > > for a while.
> > >
> > > Thanks!
> > > -Dormando
> > > --
> >
>
> Forgot to note: This crash appeared after 3.9 (and not in any of 3.9's
> -stable updates). We had to abandon 3.9 in a hurry due to a bizarre tcp
> corruption bug. Otherwise 3.9 never crashed on us :) 3.10 lacks the
> corruption bug, adds this rare panic.
>
Two fresh traces:
Panic#2 Part1
<1>[6707639.294029] BUG: unable to handle kernel paging request at 0000000100000000
<1>[6707639.294039] IP: [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
<4>[6707639.294050] PGD 618c91a067 PUD 0
<4>[6707639.294053] Oops: 0000 [#1] SMP
<4>[6707639.294057] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan ntfs vfat msdos fat bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich ipmi_watchdog ipmi_devintf microcode sb_edac edac_core isci igb lpc_ich i2c_algo_bit mfd_core libsas ixgbe tpm_tis ptp pps_core tpm mdio tpm_bios ipmi_si ipmi_msghandler
<4>[6707639.294085] CPU: 11 PID: 107657 Comm: sed Tainted: G W 3.10.15 #1
<4>[6707639.294089] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[6707639.294093] task: ffff88bd4fa5ae00 ti: ffff88614bb7c000 task.ti: ffff88614bb7c000
<4>[6707639.294096] RIP: 0010:[<ffffffff811476da>] [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
<4>[6707639.294101] RSP: 0000:ffff88c07fc63b68 EFLAGS: 00010286
<4>[6707639.294103] RAX: 0000000000000000 RBX: ffffffff81c8c740 RCX: 00000000ffffffff
<4>[6707639.294106] RDX: 0000000266ceed70 RSI: 0000000000000020 RDI: 0000000000015680
<4>[6707639.294110] RBP: ffff88c07fc63ba8 R08: ffff88c07fc75680 R09: ffffffff815bdd4b
<4>[6707639.294113] R10: ffff8801d167de00 R11: 0000000000000000 R12: ffff885eff803800
<4>[6707639.294116] R13: 0000000100000000 R14: 00000000ffffffff R15: 0000000000000000
<4>[6707639.294119] FS: 00007f65232637c0(0000) GS:ffff88c07fc60000(0000) knlGS:0000000000000000
<4>[6707639.294122] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[6707639.294125] CR2: 0000000100000000 CR3: 000000618cce7000 CR4: 00000000000407e0
<4>[6707639.294128] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[6707639.294131] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[6707639.294133] Stack:
<4>[6707639.294135] ffff88c07fc63bc8 00000020815d0d95 ffff88c07fc63bd8 ffffffff81c8c740
<4>[6707639.294139] ffff88be6b380000 0000000000000001 00000000ffffffff 0000000000000000
<4>[6707639.294143] ffff88c07fc63bf8 ffffffff815bdd4b ffff88c07fc63c48 ffff886100000000
<4>[6707639.294147] Call Trace:
<4>[6707639.294149] <IRQ>
<4>[6707639.294151] [<ffffffff815bdd4b>] dst_alloc+0x5b/0x190
<4>[6707639.294161] [<ffffffff8160068c>] rt_dst_alloc+0x4c/0x50
<4>[6707639.294165] [<ffffffff81602a30>] __ip_route_output_key+0x270/0x880
<4>[6707639.294168] [<ffffffff81603067>] ip_route_output_flow+0x27/0x60
<4>[6707639.294174] [<ffffffff8163cf29>] inet_sk_rebuild_header+0x139/0x320
<4>[6707639.294179] [<ffffffff81622690>] __tcp_retransmit_skb+0xa0/0x550
<4>[6707639.294186] [<ffffffff810919c6>] ? ktime_get_real+0x16/0x50
<4>[6707639.294191] [<ffffffff8165f5ad>] ? bictcp_state+0xad/0x110
<4>[6707639.294195] [<ffffffff81622b6b>] tcp_retransmit_skb+0x2b/0x110
<4>[6707639.294198] [<ffffffff81625581>] tcp_retransmit_timer+0x261/0x680
<4>[6707639.294201] [<ffffffff81625b70>] ? tcp_write_timer_handler+0x1d0/0x1d0
<4>[6707639.294205] [<ffffffff81625a50>] tcp_write_timer_handler+0xb0/0x1d0
<4>[6707639.294208] [<ffffffff81625b70>] ? tcp_write_timer_handler+0x1d0/0x1d0
<4>[6707639.294211] [<ffffffff81625bd8>] tcp_write_timer+0x68/0x70
<4>[6707639.294217] [<ffffffff8105afa9>] call_timer_fn+0x49/0x120
<4>[6707639.294220] [<ffffffff8105b594>] run_timer_softirq+0x224/0x290
<4>[6707639.294223] [<ffffffff81625b70>] ? tcp_write_timer_handler+0x1d0/0x1d0
<4>[6707639.294227] [<ffffffff81053b7f>] __do_softirq+0xef/0x270
<4>[6707639.294230] [<ffffffff81053dd5>] irq_exit+0x95/0xa0
<4>[6707639.294236] [<ffffffff816d12ee>] smp_apic_timer_interrupt+0x6e/0x99
<4>[6707639.294242] [<ffffffff816d050a>] apic_timer_interrupt+0x6a/0x70
<4>[6707639.294244] <EOI>
<4>[6707639.294246] Code: 65 4c 03 04 25 c8 cb 00 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 84 00 00 00 48 85 c0 74 7f 49 63 44 24 20 49 8b 3c 24 <49> 8b 5c 05 00 48 8d 4a 01 4c 89 e8 65 48 0f c7 0f 0f 94 c0 3c
<1>[6707639.294272] RIP [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
<4>[6707639.294275] RSP <ffff88c07fc63b68>
<4>[6707639.294277] CR2: 0000000100000000
<4>[6707639.294284] ---[ end trace 566552bed9fa5ac5 ]---
<0>[6707639.355743] Kernel panic - not syncing: Fatal exception in interrupt
.. and...
Panic#3 Part1
<4>[7359072.926954] CPU: 11 PID: 234126 Comm: gmond Tainted: G W 3.10.15 #1
<4>[7359072.926969] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[7359072.926988] task: ffff8803f0c0c500 ti: ffff88017f40a000 task.ti: ffff88017f40a000
<4>[7359072.927002] RIP: 0010:[<ffffffff8114106b>] [<ffffffff8114106b>] kmem_cache_alloc_trace+0x5b/0x140
<4>[7359072.927024] RSP: 0018:ffff88017f40be38 EFLAGS: 00010282
<4>[7359072.927034] RAX: 0000000000000000 RBX: ffff88b7aabd8230 RCX: 000000016c1d572d
<4>[7359072.927049] RDX: 000000016c1d572c RSI: 00000000000080d0 RDI: 00000000000156c0
<4>[7359072.927079] RBP: ffff88017f40be88 R08: ffff88c07fc756c0 R09: ffffffff81159904
<4>[7359072.927122] R10: 00007fe2ae0f9300 R11: 0000000000000206 R12: ffff885eff803800
<4>[7359072.927165] R13: 0000000100000000 R14: 0000000000000000 R15: 00007fe2b0e8e0e0
<4>[7359072.927208] FS: 00007fe2b0f02740(0000) GS:ffff88c07fc60000(0000) knlGS:0000000000000000
<4>[7359072.927253] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[7359072.927280] CR2: 0000000100000000 CR3: 00000001c1860000 CR4: 00000000000407e0
<4>[7359072.927323] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[7359072.927367] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[7359072.927410] Stack:
<4>[7359072.927432] ffffffff81169052 0000000000000088 ffff88be6df50000 000080d0aabd8230
<4>[7359072.927483] ffff88be6df50000 ffff88b7aabd8230 ffff88017f40bf40 00000000ffffffe9
<4>[7359072.927535] 0000000000000000 00007fe2b0e8e0e0 ffff88017f40bea8 ffffffff81159904
<4>[7359072.927586] Call Trace:
<4>[7359072.927613] [<ffffffff81169052>] ? inode_init_always+0xf2/0x1b0
<4>[7359072.927643] [<ffffffff81159904>] alloc_pipe_info+0x24/0xb0
<4>[7359072.927671] [<ffffffff81159e8c>] create_pipe_files+0x4c/0x200
<4>[7359072.927699] [<ffffffff8115a082>] __do_pipe_flags+0x42/0xf0
<4>[7359072.927726] [<ffffffff8115a1a0>] SyS_pipe2+0x20/0xa0
<4>[7359072.927757] [<ffffffff816c7f4e>] ? do_page_fault+0xe/0x10
<4>[7359072.927787] [<ffffffff816c46b2>] ? page_fault+0x22/0x30
<4>[7359072.927814] [<ffffffff8115a230>] SyS_pipe+0x10/0x20
<4>[7359072.927842] [<ffffffff816cc702>] system_call_fastpath+0x16/0x1b
<4>[7359072.927869] Code: 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 d3 00 00 00 48 85 c0 0f 84 ca 00 00 00 49 63 44 24 20 48 8d 4a 01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b5 49
<1>[7359072.928084] RIP [<ffffffff8114106b>] kmem_cache_alloc_trace+0x5b/0x140
<4>[7359072.928115] RSP <ffff88017f40be38>
<4>[7359072.928138] CR2: 0000000100000000
<4>[7359072.928477] ---[ end trace 83220393c4cb24ac ]---
<1>[7359072.999784] BUG: unable to handle kernel paging request at 0000000100000000
<1>[7359072.999928] IP: [<ffffffff811421e7>] kmem_cache_alloc+0x57/0x150
<4>[7359073.000032] PGD be41868067 PUD 0
<4>[7359073.000167] Oops: 0000 [#2] SMP
<4>[7359073.000301] Modules linked in: nls_cp437 isofs xt_TEE xt_dscp xt_DSCP macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich ipmi_watchdog ipmi_devintf ixgbe microcode igb sb_edac edac_core lpc_ich i2c_algo_bit mfd_core ptp tpm_tis pps_core tpm mdio tpm_bios ipmi_si ipmi_msghandler
<4>[7359073.001557] CPU: 11 PID: 72986 Comm: cache-worker Tainted: G D W 3.10.15 #1
<4>[7359073.001637] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[7359073.001718] task: ffff8801c07a5c00 ti: ffff88016e9b8000 task.ti: ffff88016e9b8000
<4>[7359073.001797] RIP: 0010:[<ffffffff811421e7>] [<ffffffff811421e7>] kmem_cache_alloc+0x57/0x150
<4>[7359073.001916] RSP: 0018:ffff88c07fc638f8 EFLAGS: 00010282
<4>[7359073.001977] RAX: 0000000000000000 RBX: ffffffff81c8c1c0 RCX: 000000016c1d572d
<4>[7359073.002055] RDX: 000000016c1d572c RSI: 0000000000000020 RDI: 00000000000156c0
<4>[7359073.002133] RBP: ffff88c07fc63948 R08: ffff88c07fc756c0 R09: ffffffff815b672a
<4>[7359073.002211] R10: ffff88bc97207000 R11: 00000000a2d52a83 R12: ffff885eff803800
<4>[7359073.002289] R13: 0000000100000000 R14: 00000000ffffffff R15: 0000000000000000
<4>[7359073.002367] FS: 00007f0d36755700(0000) GS:ffff88c07fc60000(0000) knlGS:0000000000000000
<4>[7359073.002447] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[7359073.002508] CR2: 0000000100000000 CR3: 000000bc22187000 CR4: 00000000000407e0
<4>[7359073.002586] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[7359073.002664] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[7359073.002741] Stack:
<4>[7359073.002796] ffff885e6e67ee40 ffff88c07fc63ac8 ffff88c07fc63968 00000020815c9145
<4>[7359073.003020] c71b4c1400000001 ffffffff81c8c1c0 ffff885e6c890000 0000000000000001
<4>[7359073.003243] 00000000ffffffff 0000000000000000 ffff88c07fc63998 ffffffff815b672a
<4>[7359073.003466] Call Trace:
<4>[7359073.003522] <IRQ>
<4>[7359073.003563] [<ffffffff815b672a>] dst_alloc+0x5a/0x180
<4>[7359073.003720] [<ffffffff815f78bc>] rt_dst_alloc+0x4c/0x50
<4>[7359073.003783] [<ffffffff815f8861>] __ip_route_output_key+0x281/0x860
<4>[7359073.003846] [<ffffffff815f8e67>] ip_route_output_flow+0x27/0x70
<4>[7359073.003910] [<ffffffff81606fee>] inet_csk_route_req+0xce/0x130
<4>[7359073.003974] [<ffffffff8161fda3>] tcp_v4_conn_request+0x463/0xb10
<4>[7359073.004038] [<ffffffff81616144>] tcp_rcv_state_process+0x1c4/0xd10
<4>[7359073.004101] [<ffffffff8161f457>] tcp_v4_do_rcv+0x257/0x4a0
<4>[7359073.004163] [<ffffffff816215d6>] tcp_v4_rcv+0x6f6/0x870
<4>[7359073.004226] [<ffffffff815fbff0>] ? ip_rcv_finish+0x360/0x360
<4>[7359073.004289] [<ffffffff815fc0be>] ip_local_deliver_finish+0xce/0x250
<4>[7359073.004352] [<ffffffff815fc3ca>] ip_local_deliver+0x4a/0x90
<4>[7359073.004415] [<ffffffff815fbda9>] ip_rcv_finish+0x119/0x360
<4>[7359073.004477] [<ffffffff815fc63b>] ip_rcv+0x22b/0x340
<4>[7359073.004539] [<ffffffff815af002>] __netif_receive_skb_core+0x512/0x640
<4>[7359073.004603] [<ffffffff815af151>] __netif_receive_skb+0x21/0x70
<4>[7359073.004666] [<ffffffff815af23b>] process_backlog+0x9b/0x170
<4>[7359073.004729] [<ffffffff815afa49>] net_rx_action+0x119/0x220
<4>[7359073.004794] [<ffffffff81080f0b>] ? check_preempt_wakeup+0x14b/0x230
<4>[7359073.004860] [<ffffffff81051970>] __do_softirq+0xd0/0x270
<4>[7359073.004921] [<ffffffff81051c25>] irq_exit+0x55/0x60
<4>[7359073.004983] [<ffffffff8107a5b5>] scheduler_ipi+0x35/0x40
<4>[7359073.005049] [<ffffffff81023bda>] smp_reschedule_interrupt+0x2a/0x30
<4>[7359073.005115] [<ffffffff816cd5da>] reschedule_interrupt+0x6a/0x70
<4>[7359073.005176] <EOI>
<4>[7359073.005217] [<ffffffff816c41f5>] ? _raw_spin_lock+0x25/0x30
<4>[7359073.005370] [<ffffffff81098629>] futex_wait_setup+0x69/0xf0
<4>[7359073.005433] [<ffffffff81098836>] futex_wait+0x186/0x2c0
<4>[7359073.005495] [<ffffffff810508c6>] ? current_fs_time+0x16/0x60
<4>[7359073.005559] [<ffffffff81159123>] ? pipe_write+0x2f3/0x590
<4>[7359073.005625] [<ffffffff8118e8c2>] ? fsnotify+0x1d2/0x2b0
<4>[7359073.005687] [<ffffffff81099e04>] do_futex+0x334/0xb20
<4>[7359073.005751] [<ffffffff8115021a>] ? do_sync_write+0x7a/0xb0
<4>[7359073.005813] [<ffffffff8118e8c2>] ? fsnotify+0x1d2/0x2b0
<4>[7359073.005875] [<ffffffff8109a732>] SyS_futex+0x142/0x1a0
<4>[7359073.005939] [<ffffffff8115148b>] ? SyS_write+0x6b/0xa0
<4>[7359073.006001] [<ffffffff816cc702>] system_call_fastpath+0x16/0x1b
<4>[7359073.006063] Code: 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 e7 00 00 00 48 85 c0 0f 84 de 00 00 00 49 63 44 24 20 48 8d 4a 01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b5 49
<1>[7359073.008543] RIP [<ffffffff811421e7>] kmem_cache_alloc+0x57/0x150
<4>[7359073.008642] RSP <ffff88c07fc638f8>
<4>[7359073.008700] CR2: 0000000100000000
<4>[7359073.008767] ---[ end trace 83220393c4cb24ad ]---
<0>[7359073.072455] Kernel panic - not syncing: Fatal exception in interrupt
We hit the routing code fairly hard. Any hints for what to look at or how
to instrument it? Or if it's fixed already? It's a real pain to iterate
since it takes ~30 days to crash, usually. Sometimes.
Thanks!
^ permalink raw reply
* Re: [Patch resend nf] ipvs: fix AF assignment in ip_vs_conn_new()
From: Michal Kubecek @ 2014-01-30 7:39 UTC (permalink / raw)
To: Julian Anastasov
Cc: netfilter-devel, netdev, lvs-devel, Wensong Zhang, Simon Horman,
Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller
In-Reply-To: <alpine.LFD.2.11.1401292319030.1844@ja.home.ssi.bg>
On Wed, Jan 29, 2014 at 11:24:17PM +0200, Julian Anastasov wrote:
> > diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
> > index 59a1a85..282b39b 100644
> > --- a/net/netfilter/ipvs/ip_vs_conn.c
> > +++ b/net/netfilter/ipvs/ip_vs_conn.c
> > @@ -871,11 +871,11 @@ ip_vs_conn_new(const struct ip_vs_conn_param *p,
> > cp->protocol = p->protocol;
> > ip_vs_addr_set(p->af, &cp->caddr, p->caddr);
> > cp->cport = p->cport;
> > - ip_vs_addr_set(p->af, &cp->vaddr, p->vaddr);
> > - cp->vport = p->vport;
> > - /* proto should only be IPPROTO_IP if d_addr is a fwmark */
> > + /* proto should only be IPPROTO_IP if p->vaddr is a fwmark */
> > ip_vs_addr_set(p->protocol == IPPROTO_IP ? AF_UNSPEC : p->af,
> > - &cp->daddr, daddr);
> > + &cp->vaddr, vaddr);
>
> Patch does not compile due to vaddr and p->daddr
> usage but you are in the right direction. Such change should
> fix a problem where connection templates don't get full
> IPv6 address for the real server, only the first 4 bytes
> are copied and as result it works only for IPv4.
Sorry for that, looks like I ran the test build after adapting to
current code with a config which didn't actually compile this file.
I'll send a v2 after testing a fixed version and I'll also extend the
commit message to describe the outcome.
Michal Kubecek
^ permalink raw reply
* [PATCH nf v2] ipvs: fix AF assignment in ip_vs_conn_new()
From: Michal Kubecek @ 2014-01-30 7:50 UTC (permalink / raw)
To: netfilter-devel
Cc: netdev, lvs-devel, Wensong Zhang, Simon Horman, Julian Anastasov,
Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller
In-Reply-To: <alpine.LFD.2.11.1401292319030.1844@ja.home.ssi.bg>
If a fwmark is passed to ip_vs_conn_new(), it is passed in
vaddr, not daddr. Therefore we should set AF to AF_UNSPEC in
vaddr assignment (like we do in ip_vs_ct_in_get()), otherwise we
may copy only first 4 bytes of an IPv6 address into cp->daddr.
v2: fix messed up {d,v}addr and p->{d,v}addr, add info about the
outcome (thanks to Julian Anastasov)
Signed-off-by: Bogdano Arendartchuk <barendartchuk@suse.com>
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
net/netfilter/ipvs/ip_vs_conn.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index 59a1a85..a8eb0a8 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -871,11 +871,11 @@ ip_vs_conn_new(const struct ip_vs_conn_param *p,
cp->protocol = p->protocol;
ip_vs_addr_set(p->af, &cp->caddr, p->caddr);
cp->cport = p->cport;
- ip_vs_addr_set(p->af, &cp->vaddr, p->vaddr);
- cp->vport = p->vport;
- /* proto should only be IPPROTO_IP if d_addr is a fwmark */
+ /* proto should only be IPPROTO_IP if p->vaddr is a fwmark */
ip_vs_addr_set(p->protocol == IPPROTO_IP ? AF_UNSPEC : p->af,
- &cp->daddr, daddr);
+ &cp->vaddr, p->vaddr);
+ cp->vport = p->vport;
+ ip_vs_addr_set(p->af, &cp->daddr, daddr);
cp->dport = dport;
cp->flags = flags;
cp->fwmark = fwmark;
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH nf v2] ipvs: fix AF assignment in ip_vs_conn_new()
From: Julian Anastasov @ 2014-01-30 8:29 UTC (permalink / raw)
To: Michal Kubecek
Cc: netfilter-devel, netdev, lvs-devel, Wensong Zhang, Simon Horman,
Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller
In-Reply-To: <20140130075020.7A903E916F@unicorn.suse.cz>
Hello,
On Thu, 30 Jan 2014, Michal Kubecek wrote:
> If a fwmark is passed to ip_vs_conn_new(), it is passed in
> vaddr, not daddr. Therefore we should set AF to AF_UNSPEC in
> vaddr assignment (like we do in ip_vs_ct_in_get()), otherwise we
> may copy only first 4 bytes of an IPv6 address into cp->daddr.
>
> v2: fix messed up {d,v}addr and p->{d,v}addr, add info about the
> outcome (thanks to Julian Anastasov)
>
> Signed-off-by: Bogdano Arendartchuk <barendartchuk@suse.com>
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Acked-by: Julian Anastasov <ja@ssi.bg>
Looks like problem comes from
commit be8be9eccbf2d908a7e56b3f7a71105cd88da06b
"ipvs: Fix IPv4 FWMARK virtual services" (2.6.30).
> ---
> net/netfilter/ipvs/ip_vs_conn.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
> index 59a1a85..a8eb0a8 100644
> --- a/net/netfilter/ipvs/ip_vs_conn.c
> +++ b/net/netfilter/ipvs/ip_vs_conn.c
> @@ -871,11 +871,11 @@ ip_vs_conn_new(const struct ip_vs_conn_param *p,
> cp->protocol = p->protocol;
> ip_vs_addr_set(p->af, &cp->caddr, p->caddr);
> cp->cport = p->cport;
> - ip_vs_addr_set(p->af, &cp->vaddr, p->vaddr);
> - cp->vport = p->vport;
> - /* proto should only be IPPROTO_IP if d_addr is a fwmark */
> + /* proto should only be IPPROTO_IP if p->vaddr is a fwmark */
> ip_vs_addr_set(p->protocol == IPPROTO_IP ? AF_UNSPEC : p->af,
> - &cp->daddr, daddr);
> + &cp->vaddr, p->vaddr);
> + cp->vport = p->vport;
> + ip_vs_addr_set(p->af, &cp->daddr, daddr);
> cp->dport = dport;
> cp->flags = flags;
> cp->fwmark = fwmark;
> --
> 1.8.1.4
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH stable 3.11+] can: use private sk reference to detect originating socket
From: Andre Naujoks @ 2014-01-30 8:32 UTC (permalink / raw)
To: Oliver Hartkopp, Eric Dumazet
Cc: David Miller, Linux Netdev List, linux-can@vger.kernel.org
In-Reply-To: <52E96BDC.9070209@hartkopp.net>
On 29.01.2014 22:00, schrieb Oliver Hartkopp:
> So here we are:
>
> Introduced can_create_echo_skb() which creates a skb which is properly
> owned to be send back (echo'ed) into the network stack.
I see no crashes with this and it works as expected.
You can add my:
Tested-by: Andre Naujoks <nautsch2@gmail.com>
Regards
Andre
>
> Regards,
> Oliver
>
^ permalink raw reply
* [PATCH stable 3.9+] can: add destructor for self generated skbs
From: Oliver Hartkopp @ 2014-01-30 9:11 UTC (permalink / raw)
To: Eric Dumazet, David Miller
Cc: Andre Naujoks, Linux Netdev List, linux-can@vger.kernel.org
Self generated skbuffs in net/can/bcm.c are setting a skb->sk reference but
no explicit destructor which is enforced since Linux 3.11 with commit
376c7311bdb6 (net: add a temporary sanity check in skb_orphan()).
This patch adds some helper functions to make sure that a destructor is
properly defined when a sock reference is assigned to a CAN related skb.
To create an unshared skb owned by the original sock a common helper function
has been introduced to replace open coded functions to create CAN echo skbs.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Andre Naujoks <nautsch2@gmail.com>
---
The patch applies properly down to Linux 3.9. For older kernels the include
file include/linux/can/skb.h would need to be created.
Don't know if it's worth the effort to be ported back to Linux < v3.9 as we
never had any issues in real world with this skb concept for the last eight
years.
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 13a9098..fc59bc6 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -323,19 +323,10 @@ void can_put_echo_skb(struct sk_buff *skb, struct net_device *dev,
}
if (!priv->echo_skb[idx]) {
- struct sock *srcsk = skb->sk;
- if (atomic_read(&skb->users) != 1) {
- struct sk_buff *old_skb = skb;
-
- skb = skb_clone(old_skb, GFP_ATOMIC);
- kfree_skb(old_skb);
- if (!skb)
- return;
- } else
- skb_orphan(skb);
-
- skb->sk = srcsk;
+ skb = can_create_echo_skb(skb);
+ if (!skb)
+ return;
/* make settings for echo to reduce code in irq context */
skb->protocol = htons(ETH_P_CAN);
diff --git a/drivers/net/can/janz-ican3.c b/drivers/net/can/janz-ican3.c
index e24e669..2124c679 100644
--- a/drivers/net/can/janz-ican3.c
+++ b/drivers/net/can/janz-ican3.c
@@ -18,6 +18,7 @@
#include <linux/netdevice.h>
#include <linux/can.h>
#include <linux/can/dev.h>
+#include <linux/can/skb.h>
#include <linux/can/error.h>
#include <linux/mfd/janz.h>
@@ -1133,20 +1134,9 @@ static void ican3_handle_message(struct ican3_dev *mod, struct ican3_msg *msg)
*/
static void ican3_put_echo_skb(struct ican3_dev *mod, struct sk_buff *skb)
{
- struct sock *srcsk = skb->sk;
-
- if (atomic_read(&skb->users) != 1) {
- struct sk_buff *old_skb = skb;
-
- skb = skb_clone(old_skb, GFP_ATOMIC);
- kfree_skb(old_skb);
- if (!skb)
- return;
- } else {
- skb_orphan(skb);
- }
-
- skb->sk = srcsk;
+ skb = can_create_echo_skb(skb);
+ if (!skb)
+ return;
/* save this skb for tx interrupt echo handling */
skb_queue_tail(&mod->echoq, skb);
diff --git a/drivers/net/can/vcan.c b/drivers/net/can/vcan.c
index 0a2a5ee..4e94057 100644
--- a/drivers/net/can/vcan.c
+++ b/drivers/net/can/vcan.c
@@ -46,6 +46,7 @@
#include <linux/if_ether.h>
#include <linux/can.h>
#include <linux/can/dev.h>
+#include <linux/can/skb.h>
#include <linux/slab.h>
#include <net/rtnetlink.h>
@@ -109,25 +110,23 @@ static netdev_tx_t vcan_tx(struct sk_buff *skb, struct net_device *dev)
stats->rx_packets++;
stats->rx_bytes += cfd->len;
}
- kfree_skb(skb);
+ consume_skb(skb);
return NETDEV_TX_OK;
}
/* perform standard echo handling for CAN network interfaces */
if (loop) {
- struct sock *srcsk = skb->sk;
- skb = skb_share_check(skb, GFP_ATOMIC);
+ skb = can_create_echo_skb(skb);
if (!skb)
return NETDEV_TX_OK;
/* receive with packet counting */
- skb->sk = srcsk;
vcan_rx(skb, dev);
} else {
/* no looped packets => no counting */
- kfree_skb(skb);
+ consume_skb(skb);
}
return NETDEV_TX_OK;
}
diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h
index 2f0543f..f9bbbb4 100644
--- a/include/linux/can/skb.h
+++ b/include/linux/can/skb.h
@@ -11,7 +11,9 @@
#define CAN_SKB_H
#include <linux/types.h>
+#include <linux/skbuff.h>
#include <linux/can.h>
+#include <net/sock.h>
/*
* The struct can_skb_priv is used to transport additional information along
@@ -42,4 +44,40 @@ static inline void can_skb_reserve(struct sk_buff *skb)
skb_reserve(skb, sizeof(struct can_skb_priv));
}
+static inline void can_skb_destructor(struct sk_buff *skb)
+{
+ sock_put(skb->sk);
+}
+
+static inline void can_skb_set_owner(struct sk_buff *skb, struct sock *sk)
+{
+ if (sk) {
+ sock_hold(sk);
+ skb->destructor = can_skb_destructor;
+ skb->sk = sk;
+ }
+}
+
+/*
+ * returns an unshared skb owned by the original sock to be echo'ed back
+ */
+static inline struct sk_buff *can_create_echo_skb(struct sk_buff *skb)
+{
+ if (skb_shared(skb)) {
+ struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
+
+ if (likely(nskb)) {
+ can_skb_set_owner(nskb, skb->sk);
+ consume_skb(skb);
+ return nskb;
+ } else {
+ kfree_skb(skb);
+ return NULL;
+ }
+ }
+
+ /* we can assume to have an unshared skb with proper owner */
+ return skb;
+}
+
#endif /* CAN_SKB_H */
diff --git a/net/can/af_can.c b/net/can/af_can.c
index d249874..a27f8aa 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -57,6 +57,7 @@
#include <linux/skbuff.h>
#include <linux/can.h>
#include <linux/can/core.h>
+#include <linux/can/skb.h>
#include <linux/ratelimit.h>
#include <net/net_namespace.h>
#include <net/sock.h>
@@ -290,7 +291,7 @@ int can_send(struct sk_buff *skb, int loop)
return -ENOMEM;
}
- newskb->sk = skb->sk;
+ can_skb_set_owner(newskb, skb->sk);
newskb->ip_summed = CHECKSUM_UNNECESSARY;
newskb->pkt_type = PACKET_BROADCAST;
}
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 3fc737b..dcb75c0 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -268,7 +268,7 @@ static void bcm_can_tx(struct bcm_op *op)
/* send with loopback */
skb->dev = dev;
- skb->sk = op->sk;
+ can_skb_set_owner(skb, op->sk);
can_send(skb, 1);
/* update statistics */
@@ -1223,7 +1223,7 @@ static int bcm_tx_send(struct msghdr *msg, int ifindex, struct sock *sk)
can_skb_prv(skb)->ifindex = dev->ifindex;
skb->dev = dev;
- skb->sk = sk;
+ can_skb_set_owner(skb, sk);
err = can_send(skb, 1); /* send with loopback */
dev_put(dev);
^ permalink raw reply related
* Re: [PATCH stable 3.9+] can: add destructor for self generated skbs
From: Marc Kleine-Budde @ 2014-01-30 9:24 UTC (permalink / raw)
To: Oliver Hartkopp, Eric Dumazet, David Miller
Cc: Andre Naujoks, Linux Netdev List, linux-can@vger.kernel.org
In-Reply-To: <52EA1740.2010108@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]
On 01/30/2014 10:11 AM, Oliver Hartkopp wrote:
> Self generated skbuffs in net/can/bcm.c are setting a skb->sk reference but
> no explicit destructor which is enforced since Linux 3.11 with commit
> 376c7311bdb6 (net: add a temporary sanity check in skb_orphan()).
>
> This patch adds some helper functions to make sure that a destructor is
> properly defined when a sock reference is assigned to a CAN related skb.
> To create an unshared skb owned by the original sock a common helper function
> has been introduced to replace open coded functions to create CAN echo skbs.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> Tested-by: Andre Naujoks <nautsch2@gmail.com>
>
> ---
>
> The patch applies properly down to Linux 3.9. For older kernels the include
> file include/linux/can/skb.h would need to be created.
Should I add stable on Cc when applying this patch?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] [BUG FIXES - 3.10.27] sit: More backports
From: Nicolas Dichtel @ 2014-01-30 9:28 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, netdev, stable, Clark Williams,
Luis Claudio R. Goncalves, John Kacur, Willem de Bruijn
In-Reply-To: <20140129154811.27fbaf13@gandalf.local.home>
Le 29/01/2014 21:48, Steven Rostedt a écrit :
> On Wed, 29 Jan 2014 17:04:12 +0100
> Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>
>> Your patch serie seems to be the good way to go (note that patch 1/2 does not
>> compile) but I think the fix is smaller because we don't have x-netns.
>>
>> Here is my proposal, if you agree, I will send the same patch for ip6_tunnnel,
>> which have the netns leak.
>>
>
> Hold on. Seems that the kernels that were being tested in QA had more
> code than what I was testing. Clark had backported "sit: fix use after
> free of fb_tunnel_dev" and that was what was causing the
> unlist_netdevice() to be missed.
>
> When I started working on vanilla 3.10.27 as well, I first did my
> original patch (which just removes the call to
> unregister_netdevice_queue() from sit_exit_net()). I asked to have that
> added to our kernel for testing, and they told me it was already there
> via Clark's backport. Then I did the full backport as well and looked
> for the leak. I'm now thinking that the full backport is not needed as
> that was what caused the leak.
>
> According to commit 9434266f2c645d4fcf62a03a8e36ad8075e37943 "sit: fix
> use after free of fb_tunnel_dev", it states:
>
> Bug: The fallback device is created in sit_init_net and assumed to
> be freed in sit_exit_net. First, it is dereferenced in that
> function, in sit_destroy_tunnels:
>
> struct net *net = dev_net(sitn->fb_tunnel_dev);
>
> Prior to this, rtnl_unlink_register has removed all devices that
> match rtnl_link_ops == sit_link_ops.
>
> Commit 205983c43700 added the line
>
> + sitn->fb_tunnel_dev->rtnl_link_ops = &sit_link_ops;
>
> which cases the fallback device to match here and be freed before it
> is last dereferenced.
>
> Commit 205983c43700 was backported to 3.10, but without commit
> 5e6700b3bf98 "sit: add support of x-netns" which was what added the
>
> net = dev_net(sitn->fb_tunnel_dev);
>
> Which looks to me that the only reason I need to port back commit
> 5e6700b3bf98 is if I add the full backport of 9434266f2c645d4f.
>
> Seems to me that my original patch may be good enough. The one that I
> said this series obsoletes.
>
> Note, I've talked with the people that are doing the testing, and I'm
> having them revert all changes except for that one fix and rerun the
> tests again. I should know the results by tomorrow.
>
> Let me know if "sit: fix use after free of fb_tunnel_dev" still needs
> to be backported due to some other way that the fallback device can be
> dereferenced after being freed.
Steve, I think the patch I sent yesterday is the good fix. At the end, it's
a backport of Willem's patch. Note that he also ack that patch.
The first version you sent (which removes
unregister_netdevice_queue(sitn->fb_tunnel_dev, &list)) will introduce a
memory leak when the user destroy a netns.
^ permalink raw reply
* RE: Help testing for USB ethernet/xHCI regression
From: David Laight @ 2014-01-30 9:44 UTC (permalink / raw)
To: 'Sarah Sharp', renevant@internode.on.net
Cc: linux-usb@vger.kernel.org, Mark Lord, Greg Kroah-Hartman,
netdev@vger.kernel.org
In-Reply-To: <20140129215408.GC5991@xanatos>
From: Sarah Sharp
> > Current issue is when plugging in the ax88179 there is lag when bringing the
> > interface up and a bunch of kernel messages:
>
> With which kernel?
I saw similar issues testing some patches yesterday.
Both with the ax179_178a and smsx95xx cards (connected to xhci).
My kernel claims to be 3.13.0-dsl+ but it is lying since it was
updated from linus's tree earlier this week.
I'd not seen any similar delays until the last week or so.
The xhci controller I'm using is the Intel 'Panther Point' 8086:1e31
rev 4 (also says 8086:1e2d and 8086:1e26).
David
^ permalink raw reply
* Re: [PATCH RFC v3 0/12] vti4: prepare namespace and interfamily support.
From: Steffen Klassert @ 2014-01-30 9:56 UTC (permalink / raw)
To: Christophe Gouault; +Cc: netdev, Saurabh Mohan
In-Reply-To: <52E8DE2C.7060706@6wind.com>
On Wed, Jan 29, 2014 at 11:55:40AM +0100, Christophe Gouault wrote:
>
> Hi Steffen,
>
> I did some tests, and it seems there is no inbound policy check against
> a vti SP after the ipsec decryption:
Thanks for testing!
>
> To confirm the problem, I added some logs in the kernel to track the
> outbound SPD lookup and inbound policy check.
>
> I tested a ping from HostL(10.22.1.1) to HostR(10.24.1.201), that must
> be encapsulated via a vti interface (vti1, mark 1, ifindex 8) between
> IPsecVTI(10.23.1.101) and HostR(10.23.1.201).
>
> . 10.22.1.0/24 10.23.1.0/24 10.24.1.0/24
> . (HostL) ------------(IPsecVTI)============(HostR)------------
> . .1 .101 .201
>
> Here is the trace:
>
> (1) xfrm_lookup: oif=8 mark=0 saddr=10.22.1.1 daddr=10.24.1.201
> (2) xfrm_lookup: oif=8 mark=1 saddr=10.22.1.1 daddr=10.24.1.201
> (3) vti_rcv: found tunnel vti1
> (4) __xfrm_policy_check: dir=0 iif=0 mark=0 saddr=10.23.1.201
> daddr=10.23.1.101 skb->sp->len=0
> (5) __xfrm_policy_check: dir=2 iif=0 mark=0 saddr=10.24.1.201
> daddr=10.22.1.1 skb->sp->len=0
>
> And the analysis:
>
> - A first SPD lookup is done before entering vti1 in (1), seeking for
> a "global SP".
> - A second SPD lookup is done after entering vti1 in (2), with mark 1,
> seeking for a "vti SP"
> - the icmp request is encapsulated and sent to HostR
> - the esp-encrypted icmp reply is received, the packet enters vti1
> and an inbound policy check is performed on the ESP packet itself in
> (4), with mark 0, seeking for a "global SP".
> - the packet is decrypted and its mark set to 1, but no vti inbound
> policy check is done. Then the skb mark and secpath are reset by
> skb_scrub_params (called by vti_rcv_cb).
> - Then only an inbound policy check is performed on the icmp
> reply in (5), seeking for a "global SP". It is considered a plaintext
> packet, with no mark or secpath.
>
> => there is no check that the forward vti security policy was
> enforced.
>
Yes, that's true and this is a real problem. If we want to support
namespace transitions with vti, we can't know if a packet is going
to be forwarded or locally received in the other namespace. This means
that we don't know if we should enforce a input or a forward policy.
All we can do here, is to enforce a input policy before we do the
namespace transition in the receive path. The patch below (on top
of the vti patchset) should do this.
But this has the implication that forward policies do not make
much sense in combination with vti. This is a bit contrary to
traditional xfrm processing. But on the other hand, we receive
plaintext packets from the vti device so we should not check
for any IPsec processing that happened before we received the
packets via the vti device.
---
include/net/xfrm.h | 10 +++++-----
net/ipv4/ip_vti.c | 5 ++++-
net/ipv4/xfrm4_protocol.c | 9 ++++++---
net/xfrm/xfrm_input.c | 4 +++-
4 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index b7740ce..cac9c46 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1519,7 +1519,7 @@ int xfrm4_extract_output(struct xfrm_state *x, struct sk_buff *skb);
int xfrm4_prepare_output(struct xfrm_state *x, struct sk_buff *skb);
int xfrm4_output(struct sk_buff *skb);
int xfrm4_output_finish(struct sk_buff *skb);
-void xfrm4_rcv_cb(struct sk_buff *skb, u8 protocol, int err);
+int xfrm4_rcv_cb(struct sk_buff *skb, u8 protocol, int err);
int xfrm4_protocol_register(struct xfrm4_protocol *handler, unsigned char protocol);
int xfrm4_protocol_deregister(struct xfrm4_protocol *handler, unsigned char protocol);
int xfrm4_tunnel_register(struct xfrm_tunnel *handler, unsigned short family);
@@ -1753,14 +1753,14 @@ static inline int xfrm_mark_put(struct sk_buff *skb, const struct xfrm_mark *m)
return ret;
}
-static inline void xfrm_rcv_cb(struct sk_buff *skb, unsigned int family,
- u8 protocol, int err)
+static inline int xfrm_rcv_cb(struct sk_buff *skb, unsigned int family,
+ u8 protocol, int err)
{
switch(family) {
case AF_INET:
- xfrm4_rcv_cb(skb, protocol, err);
- break;
+ return xfrm4_rcv_cb(skb, protocol, err);
}
+ return 0;
}
#endif /* _NET_XFRM_H */
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 7b1542c..5beb260 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -82,7 +82,7 @@ static int vti_rcv_cb(struct sk_buff *skb, int err)
struct ip_tunnel *tunnel = XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip4;
if (!tunnel)
- return -1;
+ return 1;
dev = tunnel->dev;
@@ -93,6 +93,9 @@ static int vti_rcv_cb(struct sk_buff *skb, int err)
return 0;
}
+ if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb))
+ return -EPERM;
+
skb_scrub_packet(skb, !net_eq(tunnel->net, dev_net(skb->dev)));
skb->dev = dev;
diff --git a/net/ipv4/xfrm4_protocol.c b/net/ipv4/xfrm4_protocol.c
index 993ab39..5ab5527 100644
--- a/net/ipv4/xfrm4_protocol.c
+++ b/net/ipv4/xfrm4_protocol.c
@@ -46,13 +46,16 @@ static inline struct xfrm4_protocol __rcu **proto_handlers(u8 protocol)
handler != NULL; \
handler = rcu_dereference(handler->next)) \
-void xfrm4_rcv_cb(struct sk_buff *skb, u8 protocol, int err)
+int xfrm4_rcv_cb(struct sk_buff *skb, u8 protocol, int err)
{
+ int ret;
struct xfrm4_protocol *handler;
for_each_protocol_rcu(*proto_handlers(protocol), handler)
- if (!handler->cb_handler(skb, err))
- return;
+ if ((ret = handler->cb_handler(skb, err)) <= 0)
+ return ret;
+
+ return 0;
}
EXPORT_SYMBOL(xfrm4_rcv_cb);
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index fb64b4a..99e3a9e 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -263,7 +263,9 @@ resume:
}
} while (!err);
- xfrm_rcv_cb(skb, family, x->type->proto, 0);
+ err = xfrm_rcv_cb(skb, family, x->type->proto, 0);
+ if (err)
+ goto drop;
nf_reset(skb);
--
1.7.9.5
^ permalink raw reply related
* RE: Help testing for USB ethernet/xHCI regression
From: David Laight @ 2014-01-30 10:03 UTC (permalink / raw)
To: 'Sarah Sharp', Mark Lord
Cc: Greg Kroah-Hartman, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20140129211817.GA5991@xanatos>
From: Sarah Sharp
> On Tue, Jan 28, 2014 at 11:30:51PM -0500, Mark Lord wrote:
> > On 14-01-28 03:30 PM, Sarah Sharp wrote:
> > ..
> > > Can you please pull this branch, which contains a 3.13 kernel with
> > > David's patch reverted, and test whether your USB ethernet device works
> > > or fails?
> >
> > Fails. dmesg log attached.
>
> It's funny, because there's certainly data transferred over endpoint
> 0x82, even though there were link TRBs in the middle of transfers. Did
> the "untransferred" messages stop when the device stopped working, or
> did they continue?
What I saw was that the USB transfers continued, but the ethernet
transmits stopped.
This rather changes the packets generated by TCP at both ends.
The effect can be seen in the timestamps (etc) in the USB trace.
There are still tx and rx packets, after a while they'll only
happen on ever-increasing timeouts.
That was the point where I wrote the NOP patch just to see if
it made a difference. I didn't really expect one!
I think that the LINK trb splits a 1k usb message in two.
This well and truly confuses the ethernet part of the ax88179_178a
hardware to the point where it doesn't even reset itself on the
next sub 1k message.
It might be that other targets (eg the smsx95xx) is more resilient
and only loses the single packet - which won't be immediately obvious.
David
^ permalink raw reply
* [PATCH linux-3.10.y 1/3] sit: fix double free of fb_tunnel_dev on exit
From: Nicolas Dichtel @ 2014-01-30 10:09 UTC (permalink / raw)
To: rostedt
Cc: linux-kernel, netdev, stable, williams, lclaudio, jkacur, willemb,
Nicolas Dichtel
In-Reply-To: <52EA1B4B.5080403@6wind.com>
This problem was fixed upstream by commit 9434266f2c64 ("sit: fix use after free
of fb_tunnel_dev").
The upstream patch depends on upstream commit 5e6700b3bf98 ("sit: add support of
x-netns"), which was not backported into 3.10 branch.
First, explain the problem: when the sit module is unloaded, sit_cleanup() is
called.
rmmod sit
=> sit_cleanup()
=> rtnl_link_unregister()
=> __rtnl_kill_links()
=> for_each_netdev(net, dev) {
if (dev->rtnl_link_ops == ops)
ops->dellink(dev, &list_kill);
}
At this point, the FB device is deleted (and all sit tunnels).
=> unregister_pernet_device()
=> unregister_pernet_operations()
=> ops_exit_list()
=> sit_exit_net()
=> sit_destroy_tunnels()
In this function, no tunnel is found.
=> unregister_netdevice_queue(sitn->fb_tunnel_dev, &list);
We delete the FB device a second time here!
Because we cannot simply remove the second deletion (sit_exit_net() must remove
the FB device when a netns is deleted), we add an rtnl ops which delete all sit
device excepting the FB device and thus we can keep the explicit deletion in
sit_exit_net().
CC: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Willem de Bruijn <willemb@google.com>
---
net/ipv6/sit.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 0491264b8bfc..620d326e8fdd 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1507,6 +1507,15 @@ static const struct nla_policy ipip6_policy[IFLA_IPTUN_MAX + 1] = {
#endif
};
+static void ipip6_dellink(struct net_device *dev, struct list_head *head)
+{
+ struct net *net = dev_net(dev);
+ struct sit_net *sitn = net_generic(net, sit_net_id);
+
+ if (dev != sitn->fb_tunnel_dev)
+ unregister_netdevice_queue(dev, head);
+}
+
static struct rtnl_link_ops sit_link_ops __read_mostly = {
.kind = "sit",
.maxtype = IFLA_IPTUN_MAX,
@@ -1517,6 +1526,7 @@ static struct rtnl_link_ops sit_link_ops __read_mostly = {
.changelink = ipip6_changelink,
.get_size = ipip6_get_size,
.fill_info = ipip6_fill_info,
+ .dellink = ipip6_dellink,
};
static struct xfrm_tunnel sit_handler __read_mostly = {
--
1.8.4.1
^ permalink raw reply related
* [PATCH linux-3.10.y 2/3] Revert "ip6tnl: fix use after free of fb_tnl_dev"
From: Nicolas Dichtel @ 2014-01-30 10:09 UTC (permalink / raw)
To: rostedt
Cc: linux-kernel, netdev, stable, williams, lclaudio, jkacur, willemb,
Nicolas Dichtel
In-Reply-To: <1391076563-10798-1-git-send-email-nicolas.dichtel@6wind.com>
This reverts commit 22c3ec552c29cf4bd4a75566088950fe57d860c4.
This patch is not the right fix, it introduces a memory leak when a netns is
destroyed (the FB device is never deleted).
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/ip6_tunnel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 209bb4d6e188..0516ebbea80b 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1711,6 +1711,8 @@ static void __net_exit ip6_tnl_destroy_tunnels(struct ip6_tnl_net *ip6n)
}
}
+ t = rtnl_dereference(ip6n->tnls_wc[0]);
+ unregister_netdevice_queue(t->dev, &list);
unregister_netdevice_many(&list);
}
--
1.8.4.1
^ permalink raw reply related
* [PATCH linux-3.10.y 3/3] ip6tnl: fix double free of fb_tnl_dev on exit
From: Nicolas Dichtel @ 2014-01-30 10:09 UTC (permalink / raw)
To: rostedt
Cc: linux-kernel, netdev, stable, williams, lclaudio, jkacur, willemb,
Nicolas Dichtel
In-Reply-To: <1391076563-10798-1-git-send-email-nicolas.dichtel@6wind.com>
This problem was fixed upstream by commit 1e9f3d6f1c40 ("ip6tnl: fix use after
free of fb_tnl_dev").
The upstream patch depends on upstream commit 0bd8762824e7 ("ip6tnl: add x-netns
support"), which was not backported into 3.10 branch.
First, explain the problem: when the ip6_tunnel module is unloaded,
ip6_tunnel_cleanup() is called.
rmmod ip6_tunnel
=> ip6_tunnel_cleanup()
=> rtnl_link_unregister()
=> __rtnl_kill_links()
=> for_each_netdev(net, dev) {
if (dev->rtnl_link_ops == ops)
ops->dellink(dev, &list_kill);
}
At this point, the FB device is deleted (and all ip6tnl tunnels).
=> unregister_pernet_device()
=> unregister_pernet_operations()
=> ops_exit_list()
=> ip6_tnl_exit_net()
=> ip6_tnl_destroy_tunnels()
=> t = rtnl_dereference(ip6n->tnls_wc[0]);
unregister_netdevice_queue(t->dev, &list);
We delete the FB device a second time here!
The previous fix removes these lines, which fix this double free. But the patch
introduces a memory leak when a netns is destroyed, because the FB device is
never deleted. By adding an rtnl ops which delete all ip6tnl device excepting
the FB device, we can keep this exlicit removal in ip6_tnl_destroy_tunnels().
CC: Steven Rostedt <rostedt@goodmis.org>
CC: Willem de Bruijn <willemb@google.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/ip6_tunnel.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 0516ebbea80b..f21cf476b00c 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1617,6 +1617,15 @@ static int ip6_tnl_changelink(struct net_device *dev, struct nlattr *tb[],
return ip6_tnl_update(t, &p);
}
+static void ip6_tnl_dellink(struct net_device *dev, struct list_head *head)
+{
+ struct net *net = dev_net(dev);
+ struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id);
+
+ if (dev != ip6n->fb_tnl_dev)
+ unregister_netdevice_queue(dev, head);
+}
+
static size_t ip6_tnl_get_size(const struct net_device *dev)
{
return
@@ -1681,6 +1690,7 @@ static struct rtnl_link_ops ip6_link_ops __read_mostly = {
.validate = ip6_tnl_validate,
.newlink = ip6_tnl_newlink,
.changelink = ip6_tnl_changelink,
+ .dellink = ip6_tnl_dellink,
.get_size = ip6_tnl_get_size,
.fill_info = ip6_tnl_fill_info,
};
--
1.8.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox