1. 02 Jul, 2013 19 commits
    • Michal Schmidt's avatar
      ethtool: make .get_dump_data() harder to misuse by drivers · c590b5e2
      Michal Schmidt authored
      As the patch "bnx2x: remove zeroing of dump data buffer" showed,
      it is too easy implement .get_dump_data incorrectly in a driver.
      
      Let's make sure drivers cannot get confused by userspace requesting
      a too big dump.
      
      Also WARN if the driver sets dump->len to something weird and make
      sure the length reported to userspace is the actual length of data
      copied to userspace.
      Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Reviewed-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c590b5e2
    • Michal Schmidt's avatar
      bnx2x: fill in sane dump flag information · 8cc2d927
      Michal Schmidt authored
      bnx2x did not set dump->version in its .get_dump_flag() method.
      Let's set it to BNX2X_DUMP_VERSION. It's not a particularly nice
      number (0x50acff01 currently), but at least it's something
      deterministic.
      
      dump->flag should report the value previously set using ethtool -W.
      Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8cc2d927
    • Michal Schmidt's avatar
      bnx2x: fix dump flag handling · 5bb680d6
      Michal Schmidt authored
      bnx2x interprets the dump flag as an index of a register preset.
      It is important to validate the index to avoid out of bounds
      memory accesses.
      Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5bb680d6
    • Michal Schmidt's avatar
      bnx2x: remove zeroing of dump data buffer · 058eec41
      Michal Schmidt authored
      There is no need to initialize the dump data with zeros.
      data is allocated with vzalloc, so it's already zero-filled.
      
      More importantly, the memset is harmful, because dump->len (the length
      requested by userspace) can be bigger than the allocated buffer (whose
      size is determined by asking the driver's .get_dump_flag method).
      Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      058eec41
    • Daniel Borkmann's avatar
      net: sctp: get rid of SCTP_DBG_TSNS entirely · e02010ad
      Daniel Borkmann authored
      After having reworked the debugging framework, Neil and Vlad agreed to
      get rid of the leftover SCTP_DBG_TSNS code for a couple of reasons:
      
      We can use systemtap scripts to investigate these things, we now have
      pr_debug() helpers that make life easier, and if we really need anything
      else besides those tools, we will be forced to come up with something
      better than we have there. Therefore, get rid of this ifdef debugging
      code entirely for now.
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      CC: Vlad Yasevich <vyasevich@gmail.com>
      CC: Neil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e02010ad
    • Ben Hutchings's avatar
      cassini: Make missing firmware non-fatal · 15627e84
      Ben Hutchings authored
      The firmware patch for the Saturn PHY fixes a bug, but is not absolutely
      essential.  And its licence is unclear, so it is not included in all
      distributions.  Just log an error message and continue if it is missing
      or invalid.
      
      References: http://bugs.debian.org/712674Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Tested-by: Jose Andres Arias Velichko <Andres.Arias@PaisLinux.net> (against 3.2)
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15627e84
    • Enrico Mioso's avatar
      qmi_wwan: add ONDA MT689DC device ID (fwd) · d8eb8f99
      Enrico Mioso authored
      Another QMI-speaking device by ZTE, re-branded by ONDA!
      
      I'm connected ovr this device's QMI interface right now, so I can say I tested
      it! :)
      
      Note: a follow-up patch was posted to the linux-usb mailing list, to prevent
      the option driver from binding to the device's QMI interface, making it
      unusable.
      Signed-off-by: default avatarEnrico Mioso <mrkiko.rs@gmail.com>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d8eb8f99
    • Amerigo Wang's avatar
      ipv6,mcast: always hold idev->lock before mca_lock · 8965779d
      Amerigo Wang authored
      dingtianhong reported the following deadlock detected by lockdep:
      
       ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.4.24.05-0.1-default #1 Not tainted
       -------------------------------------------------------
       ksoftirqd/0/3 is trying to acquire lock:
        (&ndev->lock){+.+...}, at: [<ffffffff8147f804>] ipv6_get_lladdr+0x74/0x120
      
       but task is already holding lock:
        (&mc->mca_lock){+.+...}, at: [<ffffffff8149d130>] mld_send_report+0x40/0x150
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&mc->mca_lock){+.+...}:
              [<ffffffff810a8027>] validate_chain+0x637/0x730
              [<ffffffff810a8417>] __lock_acquire+0x2f7/0x500
              [<ffffffff810a8734>] lock_acquire+0x114/0x150
              [<ffffffff814f691a>] rt_spin_lock+0x4a/0x60
              [<ffffffff8149e4bb>] igmp6_group_added+0x3b/0x120
              [<ffffffff8149e5d8>] ipv6_mc_up+0x38/0x60
              [<ffffffff81480a4d>] ipv6_find_idev+0x3d/0x80
              [<ffffffff81483175>] addrconf_notify+0x3d5/0x4b0
              [<ffffffff814fae3f>] notifier_call_chain+0x3f/0x80
              [<ffffffff81073471>] raw_notifier_call_chain+0x11/0x20
              [<ffffffff813d8722>] call_netdevice_notifiers+0x32/0x60
              [<ffffffff813d92d4>] __dev_notify_flags+0x34/0x80
              [<ffffffff813d9360>] dev_change_flags+0x40/0x70
              [<ffffffff813ea627>] do_setlink+0x237/0x8a0
              [<ffffffff813ebb6c>] rtnl_newlink+0x3ec/0x600
              [<ffffffff813eb4d0>] rtnetlink_rcv_msg+0x160/0x310
              [<ffffffff814040b9>] netlink_rcv_skb+0x89/0xb0
              [<ffffffff813eb357>] rtnetlink_rcv+0x27/0x40
              [<ffffffff81403e20>] netlink_unicast+0x140/0x180
              [<ffffffff81404a9e>] netlink_sendmsg+0x33e/0x380
              [<ffffffff813c4252>] sock_sendmsg+0x112/0x130
              [<ffffffff813c537e>] __sys_sendmsg+0x44e/0x460
              [<ffffffff813c5544>] sys_sendmsg+0x44/0x70
              [<ffffffff814feab9>] system_call_fastpath+0x16/0x1b
      
       -> #0 (&ndev->lock){+.+...}:
              [<ffffffff810a798e>] check_prev_add+0x3de/0x440
              [<ffffffff810a8027>] validate_chain+0x637/0x730
              [<ffffffff810a8417>] __lock_acquire+0x2f7/0x500
              [<ffffffff810a8734>] lock_acquire+0x114/0x150
              [<ffffffff814f6c82>] rt_read_lock+0x42/0x60
              [<ffffffff8147f804>] ipv6_get_lladdr+0x74/0x120
              [<ffffffff8149b036>] mld_newpack+0xb6/0x160
              [<ffffffff8149b18b>] add_grhead+0xab/0xc0
              [<ffffffff8149d03b>] add_grec+0x3ab/0x460
              [<ffffffff8149d14a>] mld_send_report+0x5a/0x150
              [<ffffffff8149f99e>] igmp6_timer_handler+0x4e/0xb0
              [<ffffffff8105705a>] call_timer_fn+0xca/0x1d0
              [<ffffffff81057b9f>] run_timer_softirq+0x1df/0x2e0
              [<ffffffff8104e8c7>] handle_pending_softirqs+0xf7/0x1f0
              [<ffffffff8104ea3b>] __do_softirq_common+0x7b/0xf0
              [<ffffffff8104f07f>] __thread_do_softirq+0x1af/0x210
              [<ffffffff8104f1c1>] run_ksoftirqd+0xe1/0x1f0
              [<ffffffff8106c7de>] kthread+0xae/0xc0
              [<ffffffff814fff74>] kernel_thread_helper+0x4/0x10
      
      actually we can just hold idev->lock before taking pmc->mca_lock,
      and avoid taking idev->lock again when iterating idev->addr_list,
      since the upper callers of mld_newpack() already take
      read_lock_bh(&idev->lock).
      Reported-by: default avatardingtianhong <dingtianhong@huawei.com>
      Cc: dingtianhong <dingtianhong@huawei.com>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Tested-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Tested-by: default avatarChen Weilong <chenweilong@huawei.com>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8965779d
    • Cong Wang's avatar
      vti: remove duplicated code to fix a memory leak · ab6c7a0a
      Cong Wang authored
      vti module allocates dev->tstats twice: in vti_fb_tunnel_init()
      and in vti_tunnel_init(), this lead to a memory leak of
      dev->tstats.
      
      Just remove the duplicated operations in vti_fb_tunnel_init().
      
      (candidate for -stable)
      
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Saurabh Mohan <saurabh.mohan@vyatta.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Acked-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ab6c7a0a
    • Cong Wang's avatar
      gre: fix a regression in ioctl · 6c734fb8
      Cong Wang authored
      When testing GRE tunnel, I got:
      
       # ip tunnel show
       get tunnel gre0 failed: Invalid argument
       get tunnel gre1 failed: Invalid argument
      
      This is a regression introduced by commit c5441932
      ("GRE: Refactor GRE tunneling code.") because previously we
      only check the parameters for SIOCADDTUNNEL and SIOCCHGTUNNEL,
      after that commit, the check is moved for all commands.
      
      So, just check for SIOCADDTUNNEL and SIOCCHGTUNNEL.
      
      After this patch I got:
      
       # ip tunnel show
       gre0: gre/ip  remote any  local any  ttl inherit  nopmtudisc
       gre1: gre/ip  remote 192.168.122.101  local 192.168.122.45  ttl inherit
      
      Cc: Pravin B Shelar <pshelar@nicira.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c734fb8
    • Daniel Borkmann's avatar
      net: sctp: rework debugging framework to use pr_debug and friends · bb33381d
      Daniel Borkmann authored
      We should get rid of all own SCTP debug printk macros and use the ones
      that the kernel offers anyway instead. This makes the code more readable
      and conform to the kernel code, and offers all the features of dynamic
      debbuging that pr_debug() et al has, such as only turning on/off portions
      of debug messages at runtime through debugfs. The runtime cost of having
      CONFIG_DYNAMIC_DEBUG enabled, but none of the debug statements printing,
      is negligible [1]. If kernel debugging is completly turned off, then these
      statements will also compile into "empty" functions.
      
      While we're at it, we also need to change the Kconfig option as it /now/
      only refers to the ifdef'ed code portions in outqueue.c that enable further
      debugging/tracing of SCTP transaction fields. Also, since SCTP_ASSERT code
      was enabled with this Kconfig option and has now been removed, we
      transform those code parts into WARNs resp. where appropriate BUG_ONs so
      that those bugs can be more easily detected as probably not many people
      have SCTP debugging permanently turned on.
      
      To turn on all SCTP debugging, the following steps are needed:
      
       # mount -t debugfs none /sys/kernel/debug
       # echo -n 'module sctp +p' > /sys/kernel/debug/dynamic_debug/control
      
      This can be done more fine-grained on a per file, per line basis and others
      as described in [2].
      
       [1] https://www.kernel.org/doc/ols/2009/ols2009-pages-39-46.pdf
       [2] Documentation/dynamic-debug-howto.txt
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bb33381d
    • Daniel Borkmann's avatar
      lib: vsprintf: add IPv4/v6 generic %p[Ii]S[pfs] format specifier · 10679643
      Daniel Borkmann authored
      In order to avoid making code that deals with printing both, IPv4 and
      IPv6 addresses, unnecessary complicated as for example ...
      
        if (sa.sa_family == AF_INET6)
          printk("... %pI6 ...", ..sin6_addr);
        else
          printk("... %pI4 ...", ..sin_addr.s_addr);
      
      ... it would be better to introduce a format specifier that can deal
      with those kind of situations internally; just as we have a "struct
      sockaddr" for generic mapping into "struct sockaddr_in" or "struct
      sockaddr_in6" as e.g. done in "union sctp_addr". Then, we could
      reduce the above statement into something like:
      
        printk("... %pIS ..", &sockaddr);
      
      In case our pointer is NULL, pointer() then deals with that already at
      an earlier point in time internally. While we're at it, support for both
      %piS/%pIS, where 'S' stands for sockaddr, comes (almost) for free.
      
      Additionally to that, postfix specifiers 'p', 'f' and 's' are supported
      as suggested and initially implemented in 2009 by Joe Perches [1].
      Handling of those additional specifiers orientate on the initial RFC that
      was proposed. Also we support IPv6 compressed format specified by 'c' and
      various other IPv4 extensions as stated in the documentation part.
      
      Likely, there are many other areas than just SCTP in the kernel to make
      use of this extension as well.
      
       [1] http://patchwork.ozlabs.org/patch/31480/Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      CC: Joe Perches <joe@perches.com>
      CC: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      10679643
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/vxlan-next · 936faf6c
      David S. Miller authored
      Stephen Hemminger says:
      
      ====================
      Here is current updates for vxlan in net-next.  It includes Mike's changes
      to handle multiple destinations and lots of little cosmetic stuff.
      
      This is a fresh vxlan-next repository which was forked from net-next.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      936faf6c
    • Changli Gao's avatar
      net: Swap ver and type in pppoe_hdr · b1a5a34b
      Changli Gao authored
      Ver and type in pppoe_hdr should be swapped as defined by RFC2516
      section-4.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b1a5a34b
    • Dave Jones's avatar
      x25: Fix broken locking in ioctl error paths. · 4ccb93ce
      Dave Jones authored
      Two of the x25 ioctl cases have error paths that break out of the function without
      unlocking the socket, leading to this warning:
      
      ================================================
      [ BUG: lock held when returning to user space! ]
      3.10.0-rc7+ #36 Not tainted
      ------------------------------------------------
      trinity-child2/31407 is leaving the kernel with locks still held!
      1 lock held by trinity-child2/31407:
       #0:  (sk_lock-AF_X25){+.+.+.}, at: [<ffffffffa024b6da>] x25_ioctl+0x8a/0x740 [x25]
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4ccb93ce
    • Eric Dumazet's avatar
      netem: use rb tree to implement the time queue · aec0a40a
      Eric Dumazet authored
      Following typical setup to implement a ~100 ms RTT and big
      amount of reorders has very poor performance because netem
      implements the time queue using a linked list.
      -----------------------------------------------------------
      ETH=eth0
      IFB=ifb0
      modprobe ifb
      ip link set dev $IFB up
      tc qdisc add dev $ETH ingress 2>/dev/null
      tc filter add dev $ETH parent ffff: \
         protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress \
         redirect dev $IFB
      ethtool -K $ETH gro off tso off gso off
      tc qdisc add dev $IFB root netem delay 50ms 10ms limit 100000
      tc qd add dev $ETH root netem delay 50ms limit 100000
      ---------------------------------------------------------
      
      Switch netem time queue to a rb tree, so this kind of setup can work at
      high speed.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aec0a40a
    • Bjørn Mork's avatar
      net: qmi_wwan: add TP-LINK MA260 · d0b5e516
      Bjørn Mork authored
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0b5e516
    • Bjørn Mork's avatar
      net: qmi_wwan: add Option GTM681W · aa3aba1c
      Bjørn Mork authored
      A standard Gobi 3000 reference design module.
      Reported-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aa3aba1c
    • Bjørn Mork's avatar
      net: qmi_wwan: fixup Sierra Wireless MC8305 entry · 5a008ffa
      Bjørn Mork authored
      The MC8305 module got an additional entry added based solely on
      information from a Windows driver *.inf file. We now have the
      actual descriptor layout from one of these modules, and it
      consists of two alternate configurations where cfg #1 is a
      normal Gobi 2k layout and cfg #2 is MBIM only, using interface
      numbers 5 and 6 for MBIM control and data. The extra Windows
      driver entry for interface number 5 was most likely a bug.
      
      Deleting the bogus entry to avoid unnecessary qmi_wwan probe
      failures when using the MBIM configuration.
      Reported-by: default avatarLana Black <sickmind@lavabit.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a008ffa
  2. 01 Jul, 2013 21 commits