1. 18 Apr, 2014 1 commit
    • dingtianhong's avatar
      vlan: Fix lockdep warning when vlan dev handle notification · dc8eaaa0
      dingtianhong authored
      When I open the LOCKDEP config and run these steps:
      
      modprobe 8021q
      vconfig add eth2 20
      vconfig add eth2.20 30
      ifconfig eth2 xx.xx.xx.xx
      
      then the Call Trace happened:
      
      [32524.386288] =============================================
      [32524.386293] [ INFO: possible recursive locking detected ]
      [32524.386298] 3.14.0-rc2-0.7-default+ #35 Tainted: G           O
      [32524.386302] ---------------------------------------------
      [32524.386306] ifconfig/3103 is trying to acquire lock:
      [32524.386310]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff814275f4>] dev_mc_sync+0x64/0xb0
      [32524.386326]
      [32524.386326] but task is already holding lock:
      [32524.386330]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff8141af83>] dev_set_rx_mode+0x23/0x40
      [32524.386341]
      [32524.386341] other info that might help us debug this:
      [32524.386345]  Possible unsafe locking scenario:
      [32524.386345]
      [32524.386350]        CPU0
      [32524.386352]        ----
      [32524.386354]   lock(&vlan_netdev_addr_lock_key/1);
      [32524.386359]   lock(&vlan_netdev_addr_lock_key/1);
      [32524.386364]
      [32524.386364]  *** DEADLOCK ***
      [32524.386364]
      [32524.386368]  May be due to missing lock nesting notation
      [32524.386368]
      [32524.386373] 2 locks held by ifconfig/3103:
      [32524.386376]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81431d42>] rtnl_lock+0x12/0x20
      [32524.386387]  #1:  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff8141af83>] dev_set_rx_mode+0x23/0x40
      [32524.386398]
      [32524.386398] stack backtrace:
      [32524.386403] CPU: 1 PID: 3103 Comm: ifconfig Tainted: G           O 3.14.0-rc2-0.7-default+ #35
      [32524.386409] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [32524.386414]  ffffffff81ffae40 ffff8800d9625ae8 ffffffff814f68a2 ffff8800d9625bc8
      [32524.386421]  ffffffff810a35fb ffff8800d8a8d9d0 00000000d9625b28 ffff8800d8a8e5d0
      [32524.386428]  000003cc00000000 0000000000000002 ffff8800d8a8e5f8 0000000000000000
      [32524.386435] Call Trace:
      [32524.386441]  [<ffffffff814f68a2>] dump_stack+0x6a/0x78
      [32524.386448]  [<ffffffff810a35fb>] __lock_acquire+0x7ab/0x1940
      [32524.386454]  [<ffffffff810a323a>] ? __lock_acquire+0x3ea/0x1940
      [32524.386459]  [<ffffffff810a4874>] lock_acquire+0xe4/0x110
      [32524.386464]  [<ffffffff814275f4>] ? dev_mc_sync+0x64/0xb0
      [32524.386471]  [<ffffffff814fc07a>] _raw_spin_lock_nested+0x2a/0x40
      [32524.386476]  [<ffffffff814275f4>] ? dev_mc_sync+0x64/0xb0
      [32524.386481]  [<ffffffff814275f4>] dev_mc_sync+0x64/0xb0
      [32524.386489]  [<ffffffffa0500cab>] vlan_dev_set_rx_mode+0x2b/0x50 [8021q]
      [32524.386495]  [<ffffffff8141addf>] __dev_set_rx_mode+0x5f/0xb0
      [32524.386500]  [<ffffffff8141af8b>] dev_set_rx_mode+0x2b/0x40
      [32524.386506]  [<ffffffff8141b3cf>] __dev_open+0xef/0x150
      [32524.386511]  [<ffffffff8141b177>] __dev_change_flags+0xa7/0x190
      [32524.386516]  [<ffffffff8141b292>] dev_change_flags+0x32/0x80
      [32524.386524]  [<ffffffff8149ca56>] devinet_ioctl+0x7d6/0x830
      [32524.386532]  [<ffffffff81437b0b>] ? dev_ioctl+0x34b/0x660
      [32524.386540]  [<ffffffff814a05b0>] inet_ioctl+0x80/0xa0
      [32524.386550]  [<ffffffff8140199d>] sock_do_ioctl+0x2d/0x60
      [32524.386558]  [<ffffffff81401a52>] sock_ioctl+0x82/0x2a0
      [32524.386568]  [<ffffffff811a7123>] do_vfs_ioctl+0x93/0x590
      [32524.386578]  [<ffffffff811b2705>] ? rcu_read_lock_held+0x45/0x50
      [32524.386586]  [<ffffffff811b39e5>] ? __fget_light+0x105/0x110
      [32524.386594]  [<ffffffff811a76b1>] SyS_ioctl+0x91/0xb0
      [32524.386604]  [<ffffffff815057e2>] system_call_fastpath+0x16/0x1b
      
      ========================================================================
      
      The reason is that all of the addr_lock_key for vlan dev have the same class,
      so if we change the status for vlan dev, the vlan dev and its real dev will
      hold the same class of addr_lock_key together, so the warning happened.
      
      we should distinguish the lock depth for vlan dev and its real dev.
      
      v1->v2: Convert the vlan_netdev_addr_lock_key to an array of eight elements, which
      	could support to add 8 vlan id on a same vlan dev, I think it is enough for current
      	scene, because a netdev's name is limited to IFNAMSIZ which could not hold 8 vlan id,
      	and the vlan dev would not meet the same class key with its real dev.
      
      	The new function vlan_dev_get_lockdep_subkey() will return the subkey and make the vlan
      	dev could get a suitable class key.
      
      v2->v3: According David's suggestion, I use the subclass to distinguish the lock key for vlan dev
      	and its real dev, but it make no sense, because the difference for subclass in the
      	lock_class_key doesn't mean that the difference class for lock_key, so I use lock_depth
      	to distinguish the different depth for every vlan dev, the same depth of the vlan dev
      	could have the same lock_class_key, I import the MAX_LOCK_DEPTH from the include/linux/sched.h,
      	I think it is enough here, the lockdep should never exceed that value.
      
      v3->v4: Add a huge array of locking keys will waste static kernel memory and is not a appropriate method,
      	we could use _nested() variants to fix the problem, calculate the depth for every vlan dev,
      	and use the depth as the subclass for addr_lock_key.
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dc8eaaa0
  2. 16 Apr, 2014 19 commits
    • Kees Cook's avatar
      seccomp: fix memory leak on filter attach · 0acf07d2
      Kees Cook authored
      This sets the correct error code when final filter memory is unavailable,
      and frees the raw filter no matter what.
      
      unreferenced object 0xffff8800d6ea4000 (size 512):
        comm "sshd", pid 278, jiffies 4294898315 (age 46.653s)
        hex dump (first 32 bytes):
          21 00 00 00 04 00 00 00 15 00 01 00 3e 00 00 c0  !...........>...
          06 00 00 00 00 00 00 00 21 00 00 00 00 00 00 00  ........!.......
        backtrace:
          [<ffffffff8151414e>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811a3a40>] __kmalloc+0x280/0x320
          [<ffffffff8110842e>] prctl_set_seccomp+0x11e/0x3b0
          [<ffffffff8107bb6b>] SyS_prctl+0x3bb/0x4a0
          [<ffffffff8152ef2d>] system_call_fastpath+0x1a/0x1f
          [<ffffffffffffffff>] 0xffffffffffffffff
      Reported-by: default avatarMasami Ichikawa <masami256@gmail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarMasami Ichikawa <masami256@gmail.com>
      Acked-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0acf07d2
    • Dan Carpenter's avatar
      isdn: icn: buffer overflow in icn_command() · b7a31405
      Dan Carpenter authored
      This buffer over was detected using static analysis:
      
      	drivers/isdn/icn/icn.c:1325 icn_command()
      	error: format string overflow. buf_size: 60 length: 98
      
      The calculation for the length of the string is off because it assumes
      that the dial[] buffer holds a 50 character string, but actually it is
      at most 31 characters and NUL.  I have removed the dial[] buffer because
      it isn't needed.
      
      The maximum length of the string is actually 79 characters and a NUL.  I
      have made the cbuf[] array large enough to hold it and changed the
      sprintf() to an snprintf() as a further safety enhancement.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7a31405
    • Nicolas Dichtel's avatar
      ip6_tunnel: use the right netns in ioctl handler · 74462f0d
      Nicolas Dichtel authored
      Because the netdevice may be in another netns than the i/o netns, we should
      use the i/o netns instead of dev_net(dev).
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      74462f0d
    • Nicolas Dichtel's avatar
      sit: use the right netns in ioctl handler · 9aad77c3
      Nicolas Dichtel authored
      Because the netdevice may be in another netns than the i/o netns, we should
      use the i/o netns instead of dev_net(dev).
      
      Note that netdev_priv(dev) cannot bu NULL, hence we can remove these useless
      checks.
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9aad77c3
    • Nicolas Dichtel's avatar
      ip_tunnel: use the right netns in ioctl handler · 8c923ce2
      Nicolas Dichtel authored
      Because the netdevice may be in another netns than the i/o netns, we should
      use the i/o netns instead of dev_net(dev).
      
      The variable 'tunnel' was used only to get 'itn', hence to simplify code I
      remove it and use 't' instead.
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c923ce2
    • Jan Glauber's avatar
      net: use SYSCALL_DEFINEx for sys_recv · b7c0ddf5
      Jan Glauber authored
      Make sys_recv a first class citizen by using the SYSCALL_DEFINEx
      macro. Besides being cleaner this will also generate meta data
      for the system call so tracing tools like ftrace or LTTng can
      resolve this system call.
      Signed-off-by: default avatarJan Glauber <jan.glauber@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7c0ddf5
    • David S. Miller's avatar
      Merge branch 'mdio-gpio' · c3206e6f
      David S. Miller authored
      Guenter Roeck says:
      
      ====================
      net: mdio-gpio enhancements
      
      The following series of patches adds support for active-low gpio pins
      as well as for systems with separate MDI and MDO pins to the mdio-gpio
      driver.
      
      A board using those features is based on a COM Express CPU board.
      The COM Express standard supports GPIO pins on its connector,
      with one caveat: The pins on the connector have fixed direction
      and are hard configured either as input or output pins.
      The COM Express Design Guide [1] provides additional details.
      
      The hardware uses three of the GPO/GPI pins from the COM Express board
      to drive an MDIO bus. Connectivity between GPI/GPO pins and the MDIO bus
      is as follows.
      
      GPI2 --------------------+------------ MDIO
                               |
                  +--------+   |
      GPO2 ---+---G        |   |
              |   |        |   |
             4.7k | 2N7002 D---+
      	|   |        |
      	+---S        |
      	|   +--------+
             GND
      
      GPO1 --------------------------------- MDC
      
      To support this hardware, two extensions to the driver were necessary.
      
      - Due to the FET in the MDO path (GPO2), the MDO signal is inverted.
        The driver therefore has to support active-low GPIO pins.
      
      - The MDIO signal must be separated into MDI and MDO.
      
      Those changes are implemented in patch 2/3 and 3/3.
      Patch 1/3 simplifies the error path and thus the subsequent
      patches.
      
      [1] http://www.picmg.org/pdf/picmg_comdg_100.pdf
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3206e6f
    • Guenter Roeck's avatar
      net: mdio-gpio: Add support for separate MDI and MDO gpio pins · f1d54c47
      Guenter Roeck authored
      This is for a system with fixed assignments of input and output pins
      (various variants of Kontron COMe).
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1d54c47
    • Guenter Roeck's avatar
      net: mdio-gpio: Add support for active low gpio pins · 1d251481
      Guenter Roeck authored
      Some systems using mdio-gpio may use active-low gpio pins
      (eg with inverters or FETs connected to all or some of the
      gpio pins).
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d251481
    • Guenter Roeck's avatar
      net: mdio-gpio: Use devm_ functions where possible · 78cdb079
      Guenter Roeck authored
      This simplifies error path and deinit/removal functions.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Tested-by: default avatarChris Healy <cphealy@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78cdb079
    • David S. Miller's avatar
      Merge branch 'fib_validate_loopback' · bc383ea5
      David S. Miller authored
      Cong Wang says:
      
      ====================
      ipv4: fix flowi4_iif for input routing
      
      This patchset fixes ->flowi4_iif for input routing and rp filter,
      based on suggestion from Julian. See per patch for details.
      
      v1 -> v2:
      * merge the first two patches into one
      * fix fib_check_nh() too
      * add this cover letter
      ====================
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarCong Wang <cwang@twopensource.com>
      Reviewed-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc383ea5
    • Cong Wang's avatar
      ipv4, route: pass 0 instead of LOOPBACK_IFINDEX to fib_validate_source() · 0d5edc68
      Cong Wang authored
      In my special case, when a packet is redirected from veth0 to lo,
      its skb->dev->ifindex would be LOOPBACK_IFINDEX. Meanwhile we
      pass the hard-coded LOOPBACK_IFINDEX to fib_validate_source()
      in ip_route_input_slow(). This would cause the following check
      in fib_validate_source() fail:
      
                  (dev->ifindex != oif || !IN_DEV_TX_REDIRECTS(idev))
      
      when rp_filter is disabeld on loopback. As suggested by Julian,
      the caller should pass 0 here so that we will not end up by
      calling __fib_validate_source().
      
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d5edc68
    • Cong Wang's avatar
      ipv4, fib: pass LOOPBACK_IFINDEX instead of 0 to flowi4_iif · 6a662719
      Cong Wang authored
      As suggested by Julian:
      
      	Simply, flowi4_iif must not contain 0, it does not
      	look logical to ignore all ip rules with specified iif.
      
      because in fib_rule_match() we do:
      
              if (rule->iifindex && (rule->iifindex != fl->flowi_iif))
                      goto out;
      
      flowi4_iif should be LOOPBACK_IFINDEX by default.
      
      We need to move LOOPBACK_IFINDEX to include/net/flow.h:
      
      1) It is mostly used by flowi_iif
      
      2) Fix the following compile error if we use it in flow.h
      by the patches latter:
      
      In file included from include/linux/netfilter.h:277:0,
                       from include/net/netns/netfilter.h:5,
                       from include/net/net_namespace.h:21,
                       from include/linux/netdevice.h:43,
                       from include/linux/icmpv6.h:12,
                       from include/linux/ipv6.h:61,
                       from include/net/ipv6.h:16,
                       from include/linux/sunrpc/clnt.h:27,
                       from include/linux/nfs_fs.h:30,
                       from init/do_mounts.c:32:
      include/net/flow.h: In function ‘flowi4_init_output’:
      include/net/flow.h:84:32: error: ‘LOOPBACK_IFINDEX’ undeclared (first use in this function)
      
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6a662719
    • Chris Mason's avatar
      mlx4_en: don't use napi_synchronize inside mlx4_en_netpoll · c98235cb
      Chris Mason authored
      The mlx4 driver is triggering schedules while atomic inside
      mlx4_en_netpoll:
      
      	spin_lock_irqsave(&cq->lock, flags);
      	napi_synchronize(&cq->napi);
      		^^^^^ msleep here
      	mlx4_en_process_rx_cq(dev, cq, 0);
      	spin_unlock_irqrestore(&cq->lock, flags);
      
      This was part of a patch by Alexander Guller from Mellanox in 2011,
      but it still isn't upstream.
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      cc: stable@vger.kernel.org
      Acked-By: default avatarAmir Vadai <amirv@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c98235cb
    • David S. Miller's avatar
      Merge branch 'mvneta_qsgmii' · b07afe07
      David S. Miller authored
      Thomas Petazzoni says:
      
      ====================
      net: mvneta: fix usage as a module, and support QSGMII properly
      
      This set of patches is a new attempt at fixing the operation of the
      mvneta driver when built as a module. For the record, the previous
      attempt, merged in commit e3a8786c
      ('net: mvneta: fix usage as a module on RGMII configurations') caused
      problems for all RGMII configurations.
      
      In fact, it turned out that the MAC to PHY connection on the Armada XP
      GP, which was described as using RGMII-ID according to its Device
      Tree, is in fact a QSGMII connection. And the RGMII and QSGMII
      configurations have to be handled in a different way in the driver,
      because the SERDES configuration is different in those two cases.
      
      So, this patch series fixes that by:
      
       * Adding minimal handling of a "qsgmii" connection type in the PHY
         layer. Mainly to make sure that a "qsgmii" phy-mode in the Device
         Tree is recognized, and handed over to the driver as
         PHY_INTERFACE_QSGMII.
      
       * Changing the mvneta driver to properly configure the RGMIIEn and
         PCSEn bits in the GMAC_CTRL_2 register, and configure the SERDES
         register, in the three possible cases: RGMII, SGMII and QSGMII.
      
       * Updating the Device Tree of the Armada XP GP board to reflect the
         fact that it uses a QSGMII MAC/PHY connection.
      
      PATCH 1 and 2 would be merged by David Miller, through the net tree,
      while PATCH 3 would be merged by the mach-mvebu maintainers, through
      their tree and arm-soc.
      
      This set of patches has been tested on:
      
       * Armada XP GP (four QSGMII interfaces)
       * Armada XP DB (two RGMII interfaces and two SGMII interfaces)
       * Armada 370 Mirabox (two RGMII interfaces)
      
      I've tested both the driver built-in, and compiled as a module.
      
      Since the last attempt at fixing this was quite a fiasco, I'd like
      this new attempt to be tested more widely before being applied. I'll
      try to do some testing on other Armada boards I have, but independent
      testing from other persons would also be appreciated.
      
      Note that these patches apply after reverting the previous attempt,
      obviously.
      ====================
      Tested-by: default avatarArnaud Ebalard <arno@natisbad.org>
      Tested-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b07afe07
    • Thomas Petazzoni's avatar
      net: mvneta: properly configure the MAC <-> PHY connection in all situations · 3f1dd4bc
      Thomas Petazzoni authored
      Commit 5445eaf3 ('mvneta: Try to fix mvneta when compiled as
      module') fixed the mvneta driver to make it work properly when loaded
      as a module in SGMII configuration, which was tested successful by the
      author on the Armada XP OpenBlocks AX3, which uses SGMII.
      
      However, some other platforms, namely the Armada XP GP don't use
      SGMII, but a QSGMII connection between the MAC and the PHY, and this
      case was not supported by the mvneta driver, which was relying on
      configuration put in place by the bootloader. While this works when
      the mvneta driver is built-in (because clocks are not gated), it
      breaks when mvneta is built as a module, because the clock is gated
      (all configuration is lost) and then re-enabled when the mvneta driver
      is loaded.
      
      In order to support all of RGMII, SGMII and QSGMII, this commit
      reworks how the PHY interface configuration is done, and simplifies
      it: it removes the mvneta_port_sgmii_config() and
      mvneta_gmac_rgmii_set() functions, which were strange because
      mvneta_gmac_rgmii_set() was called in all cases, even for SGMII
      configurations. Also, the mvneta_gmac_rgmii_set() function was taking
      a boolean as argument, which was always true.
      
      Instead, all the PHY interface configuration logic is moved into the
      mvneta_port_power_up() function, in a much simpler 'switch' construct,
      with four cases:
      
       - QSGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
         the SERDES is configured in QSGMII. Technically speaking,
         configuring the SERDES of the first port would be sufficient, but
         it is simpler to do it on all ports.
      
       - SGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
         the SERDES is configured as SGMII.
      
       - RGMII: the RGMIIEn bit in GMAC_CTRL_2 is set. The PCSEn bit is kept
         cleared, and no SERDES configuration is done, because RGMII is not
         using SERDES lanes.
      
       - other: an error is returned. For this reason, the
         mvneta_port_power_up() now returns an int instead of nothing, and
         the return value is checked by mvneta_probe().
      
      This has been successfully tested on:
      
       * Armada XP DB, which has two RGMII and two SGMII connections
       * Armada XP GP, which uses QSGMII for its four interfaces
       * Armada 370 Mirabox, which has two RGMII connections
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f1dd4bc
    • Thomas Petazzoni's avatar
      net: phy: add minimal support for QSGMII PHY · b9d12085
      Thomas Petazzoni authored
      This commit adds the necessary definitions for the PHY layer to
      recognize "qsgmii" as a valid PHY interface. A QSMII interface, as
      defined at
      http://en.wikipedia.org/wiki/Media_Independent_Interface#Quad_Serial_Gigabit_Media_Independent_Interface,
      is "is a method of combining four SGMII lines into a 5Gbit/s
      interface. QSGMII, like SGMII, uses LVDS signalling for the TX and RX
      data and a single LVDS clock signal. QSGMII uses significantly fewer
      signal lines than four SGMII busses."
      
      This type of MAC <-> PHY connection might require special handling on
      the MAC driver side, so it should be possible to express this type of
      MAC <-> PHY connection, for example in the Device Tree.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: devicetree@vger.kernel.org
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9d12085
    • Edward Cree's avatar
      sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast) · e283546c
      Edward Cree authored
      When an MCDI command times out (whether or not we find it
      completed when we poll), call efx_mcdi_abandon(), which tells
      all subsequent MCDI calls to fail-fast, and queues up an FLR.
      
      Because an FLR doesn't lead to receiving any reboot even from
      the MC (unlike most other types of reset), we have to call
      efx_ef10_reset_mc_allocations.
      In efx_start_all(), if a reset (of any kind) is pending, we
      bail out.
      Without this, attempts to reconfigure (e.g. change mtu) can
      cause driver/mc state inconsistency if the first MCDI call
      triggers an FLR.
      
      For similar reasons, on EF10, in
      efx_reset_down(method=RESET_TYPE_MCDI_TIMEOUT), set the number
      of active queues to zero before calling efx_stop_all().
      And, on farch, in efx_reset_up(method=RESET_TYPE_MCDI_TIMEOUT),
      set active_queues and flushes pending & outstanding to zero.
      
      efx_mcdi_mode_{poll,event}() should not take us out of fail-fast
       mode. Instead, this is done by efx_mcdi_reset() after the FLR
      completes.
      
      The new FLR reset_type RESET_TYPE_MCDI_TIMEOUT doesn't really
      fit into the hierarchy of reset 'scopes' whereby efx_reset()
      decides some resets subsume others.  Thus, it uses separate logic.
      
      Also, fixed up some inconsistency around RESET_TYPE_MC_BIST,
      which was in the wrong place in that hierarchy.
      Signed-off-by: default avatarShradha Shah <sshah@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e283546c
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 10ec34fc
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Fix BPF filter validation of netlink attribute accesses, from
          Mathias Kruase.
      
       2) Netfilter conntrack generation seqcount not initialized properly,
          from Andrey Vagin.
      
       3) Fix comparison mask computation on big-endian in nft_cmp_fast(),
          from Patrick McHardy.
      
       4) Properly limit MTU over ipv6, from Eric Dumazet.
      
       5) Fix seccomp system call argument population on 32-bit, from Daniel
          Borkmann.
      
       6) skb_network_protocol() should not use hard-coded ETH_HLEN, instead
          skb->mac_len needs to be used.  From Vlad Yasevich.
      
       7) We have several cases of using socket based communications to
          implement a tunnel.  For example, some tunnels are encapsulations
          over UDP so we use an internal kernel UDP socket to do the
          transmits.
      
          These tunnels should behave just like other software devices and
          pass the packets on down to the next layer.
      
          Most importantly we want the top-level socket (eg TCP) that created
          the traffic to be charged for the SKB memory.
      
          However, once you get into the IP output path, we have code that
          assumed that whatever was attached to skb->sk is an IP socket.
      
          To keep the top-level socket being charged for the SKB memory,
          whilst satisfying the needs of the IP output path, we now pass in an
          explicit 'sk' argument.
      
          From Eric Dumazet.
      
       8) ping_init_sock() leaks group info, from Xiaoming Wang.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (33 commits)
        cxgb4: use the correct max size for firmware flash
        qlcnic: Fix MSI-X initialization code
        ip6_gre: don't allow to remove the fb_tunnel_dev
        ipv4: add a sock pointer to dst->output() path.
        ipv4: add a sock pointer to ip_queue_xmit()
        driver/net: cosa driver uses udelay incorrectly
        at86rf230: fix __at86rf230_read_subreg function
        at86rf230: remove check if AVDD settled
        net: cadence: Add architecture dependencies
        net: Start with correct mac_len in skb_network_protocol
        Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"
        cxgb4: Save the correct mac addr for hw-loopback connections in the L2T
        net: filter: seccomp: fix wrong decoding of BPF_S_ANC_SECCOMP_LD_W
        seccomp: fix populating a0-a5 syscall args in 32-bit x86 BPF
        qlcnic: Do not disable SR-IOV when VFs are assigned to VMs
        qlcnic: Fix QLogic application/driver interface for virtual NIC configuration
        qlcnic: Fix PVID configuration on eSwitch port.
        qlcnic: Fix max ring count calculation
        qlcnic: Fix to send INIT_NIC_FUNC as first mailbox.
        qlcnic: Fix panic due to uninitialzed delayed_work struct in use.
        ...
      10ec34fc
  3. 15 Apr, 2014 9 commits
  4. 14 Apr, 2014 11 commits