1. 29 Jul, 2014 8 commits
    • Oliver Neukum's avatar
      cdc-ether: clean packet filter upon probe · c472ab68
      Oliver Neukum authored
      There are devices that don't do reset all the way. So the packet filter should
      be set to a sane initial value. Failure to do so leads to intermittent failures
      of DHCP on some systems under some conditions.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c472ab68
    • Oliver Neukum's avatar
      cdc_subset: deal with a device that needs reset for timeout · 20fbe3ae
      Oliver Neukum authored
      This device needs to be reset to recover from a timeout.
      Unfortunately this can be handled only at the level of
      the subdrivers.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20fbe3ae
    • Andrey Ryabinin's avatar
      net: sendmsg: fix NULL pointer dereference · 40eea803
      Andrey Ryabinin authored
      Sasha's report:
      	> While fuzzing with trinity inside a KVM tools guest running the latest -next
      	> kernel with the KASAN patchset, I've stumbled on the following spew:
      	>
      	> [ 4448.949424] ==================================================================
      	> [ 4448.951737] AddressSanitizer: user-memory-access on address 0
      	> [ 4448.952988] Read of size 2 by thread T19638:
      	> [ 4448.954510] CPU: 28 PID: 19638 Comm: trinity-c76 Not tainted 3.16.0-rc4-next-20140711-sasha-00046-g07d3099-dirty #813
      	> [ 4448.956823]  ffff88046d86ca40 0000000000000000 ffff880082f37e78 ffff880082f37a40
      	> [ 4448.958233]  ffffffffb6e47068 ffff880082f37a68 ffff880082f37a58 ffffffffb242708d
      	> [ 4448.959552]  0000000000000000 ffff880082f37a88 ffffffffb24255b1 0000000000000000
      	> [ 4448.961266] Call Trace:
      	> [ 4448.963158] dump_stack (lib/dump_stack.c:52)
      	> [ 4448.964244] kasan_report_user_access (mm/kasan/report.c:184)
      	> [ 4448.965507] __asan_load2 (mm/kasan/kasan.c:352)
      	> [ 4448.966482] ? netlink_sendmsg (net/netlink/af_netlink.c:2339)
      	> [ 4448.967541] netlink_sendmsg (net/netlink/af_netlink.c:2339)
      	> [ 4448.968537] ? get_parent_ip (kernel/sched/core.c:2555)
      	> [ 4448.970103] sock_sendmsg (net/socket.c:654)
      	> [ 4448.971584] ? might_fault (mm/memory.c:3741)
      	> [ 4448.972526] ? might_fault (./arch/x86/include/asm/current.h:14 mm/memory.c:3740)
      	> [ 4448.973596] ? verify_iovec (net/core/iovec.c:64)
      	> [ 4448.974522] ___sys_sendmsg (net/socket.c:2096)
      	> [ 4448.975797] ? put_lock_stats.isra.13 (./arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
      	> [ 4448.977030] ? lock_release_holdtime (kernel/locking/lockdep.c:273)
      	> [ 4448.978197] ? lock_release_non_nested (kernel/locking/lockdep.c:3434 (discriminator 1))
      	> [ 4448.979346] ? check_chain_key (kernel/locking/lockdep.c:2188)
      	> [ 4448.980535] __sys_sendmmsg (net/socket.c:2181)
      	> [ 4448.981592] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2600)
      	> [ 4448.982773] ? trace_hardirqs_on (kernel/locking/lockdep.c:2607)
      	> [ 4448.984458] ? syscall_trace_enter (arch/x86/kernel/ptrace.c:1500 (discriminator 2))
      	> [ 4448.985621] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2600)
      	> [ 4448.986754] SyS_sendmmsg (net/socket.c:2201)
      	> [ 4448.987708] tracesys (arch/x86/kernel/entry_64.S:542)
      	> [ 4448.988929] ==================================================================
      
      This reports means that we've come to netlink_sendmsg() with msg->msg_name == NULL and msg->msg_namelen > 0.
      
      After this report there was no usual "Unable to handle kernel NULL pointer dereference"
      and this gave me a clue that address 0 is mapped and contains valid socket address structure in it.
      
      This bug was introduced in f3d33426
      (net: rework recvmsg handler msg_name and msg_namelen logic).
      Commit message states that:
      	"Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
      	 non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
      	 affect sendto as it would bail out earlier while trying to copy-in the
      	 address."
      But in fact this affects sendto when address 0 is mapped and contains
      socket address structure in it. In such case copy-in address will succeed,
      verify_iovec() function will successfully exit with msg->msg_namelen > 0
      and msg->msg_name == NULL.
      
      This patch fixes it by setting msg_namelen to 0 if msg_name == NULL.
      
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarAndrey Ryabinin <a.ryabinin@samsung.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40eea803
    • Alexey Khoroshilov's avatar
      isdn/bas_gigaset: fix a leak on failure path in gigaset_probe() · 86b7987d
      Alexey Khoroshilov authored
      There is a lack of usb_put_dev(udev) on failure path in gigaset_probe().
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Acked-by: default avatarTilman Schmidt <tilman@imap.cc>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      86b7987d
    • Eric Dumazet's avatar
      ip: make IP identifiers less predictable · 04ca6973
      Eric Dumazet authored
      In "Counting Packets Sent Between Arbitrary Internet Hosts", Jeffrey and
      Jedidiah describe ways exploiting linux IP identifier generation to
      infer whether two machines are exchanging packets.
      
      With commit 73f156a6 ("inetpeer: get rid of ip_id_count"), we
      changed IP id generation, but this does not really prevent this
      side-channel technique.
      
      This patch adds a random amount of perturbation so that IP identifiers
      for a given destination [1] are no longer monotonically increasing after
      an idle period.
      
      Note that prandom_u32_max(1) returns 0, so if generator is used at most
      once per jiffy, this patch inserts no hole in the ID suite and do not
      increase collision probability.
      
      This is jiffies based, so in the worst case (HZ=1000), the id can
      rollover after ~65 seconds of idle time, which should be fine.
      
      We also change the hash used in __ip_select_ident() to not only hash
      on daddr, but also saddr and protocol, so that ICMP probes can not be
      used to infer information for other protocols.
      
      For IPv6, adds saddr into the hash as well, but not nexthdr.
      
      If I ping the patched target, we can see ID are now hard to predict.
      
      21:57:11.008086 IP (...)
          A > target: ICMP echo request, seq 1, length 64
      21:57:11.010752 IP (... id 2081 ...)
          target > A: ICMP echo reply, seq 1, length 64
      
      21:57:12.013133 IP (...)
          A > target: ICMP echo request, seq 2, length 64
      21:57:12.015737 IP (... id 3039 ...)
          target > A: ICMP echo reply, seq 2, length 64
      
      21:57:13.016580 IP (...)
          A > target: ICMP echo request, seq 3, length 64
      21:57:13.019251 IP (... id 3437 ...)
          target > A: ICMP echo reply, seq 3, length 64
      
      [1] TCP sessions uses a per flow ID generator not changed by this patch.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarJeffrey Knockel <jeffk@cs.unm.edu>
      Reported-by: default avatarJedidiah R. Crandall <crandall@cs.unm.edu>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Hannes Frederic Sowa <hannes@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04ca6973
    • Jun Zhao's avatar
      neighbour : fix ndm_type type error issue · 545469f7
      Jun Zhao authored
      ndm_type means L3 address type, in neighbour proxy and vxlan, it's RTN_UNICAST.
      NDA_DST is for netlink TLV type, hence it's not right value in this context.
      Signed-off-by: default avatarJun Zhao <mypopydev@gmail.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      545469f7
    • David L Stevens's avatar
      sunvnet: only use connected ports when sending · 8266f5fc
      David L Stevens authored
      The sunvnet driver doesn't check whether or not a port is connected when
      transmitting packets, which results in failures if a port fails to connect
      (e.g., due to a version mismatch). The original code also assumes
      unnecessarily that the first port is up and a switch, even though there is
      a flag for switch ports.
      
      This patch only matches a port if it is connected, and otherwise uses the
      switch_port flag to send the packet to a switch port that is up.
      Signed-off-by: default avatarDavid L Stevens <david.stevens@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8266f5fc
    • David S. Miller's avatar
      Merge tag 'linux-can-fixes-for-3.16-20140725' of git://gitorious.org/linux-can/linux-can · 8356f976
      David S. Miller authored
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2014-07-25
      
      this is a pull request of one patch for the net tree, hoping to get into the
      3.16 release.
      
      The patch by George Cherian fixes a regression in the c_can platform driver.
      When using two interfaces the regression leads to a non function second
      interface.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8356f976
  2. 25 Jul, 2014 9 commits
    • George Cherian's avatar
      can: c_can_platform: Fix raminit, use devm_ioremap() instead of devm_ioremap_resource() · 33cf7565
      George Cherian authored
      The raminit register is shared register for both can0 and can1. Since commit:
      
          32766fff net: can: Convert to use devm_ioremap_resource
      
      devm_ioremap_resource() is used to map raminit register. When using both
      interfaces the mapping for the can1 interface fails, leading to a non
      functional can interface.
      Signed-off-by: default avatarGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      Cc: linux-stable <stable@vger.kernel.org> # >= v3.11
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      33cf7565
    • Dmitry Kravkov's avatar
      bnx2x: fix crash during TSO tunneling · fe26566d
      Dmitry Kravkov authored
      When TSO packet is transmitted additional BD w/o mapping is used
      to describe the packed. The BD needs special handling in tx
      completion.
      
      kernel: Call Trace:
      kernel: <IRQ>  [<ffffffff815e19ba>] dump_stack+0x19/0x1b
      kernel: [<ffffffff8105dee1>] warn_slowpath_common+0x61/0x80
      kernel: [<ffffffff8105df5c>] warn_slowpath_fmt+0x5c/0x80
      kernel: [<ffffffff814a8c0d>] ? find_iova+0x4d/0x90
      kernel: [<ffffffff814ab0e2>] intel_unmap_page.part.36+0x142/0x160
      kernel: [<ffffffff814ad0e6>] intel_unmap_page+0x26/0x30
      kernel: [<ffffffffa01f55d7>] bnx2x_free_tx_pkt+0x157/0x2b0 [bnx2x]
      kernel: [<ffffffffa01f8dac>] bnx2x_tx_int+0xac/0x220 [bnx2x]
      kernel: [<ffffffff8101a0d9>] ? read_tsc+0x9/0x20
      kernel: [<ffffffffa01f8fdb>] bnx2x_poll+0xbb/0x3c0 [bnx2x]
      kernel: [<ffffffff814d041a>] net_rx_action+0x15a/0x250
      kernel: [<ffffffff81067047>] __do_softirq+0xf7/0x290
      kernel: [<ffffffff815f3a5c>] call_softirq+0x1c/0x30
      kernel: [<ffffffff81014d25>] do_softirq+0x55/0x90
      kernel: [<ffffffff810673e5>] irq_exit+0x115/0x120
      kernel: [<ffffffff815f4358>] do_IRQ+0x58/0xf0
      kernel: [<ffffffff815e94ad>] common_interrupt+0x6d/0x6d
      kernel: <EOI>  [<ffffffff810bbff7>] ? clockevents_notify+0x127/0x140
      kernel: [<ffffffff814834df>] ? cpuidle_enter_state+0x4f/0xc0
      kernel: [<ffffffff81483615>] cpuidle_idle_call+0xc5/0x200
      kernel: [<ffffffff8101bc7e>] arch_cpu_idle+0xe/0x30
      kernel: [<ffffffff810b4725>] cpu_startup_entry+0xf5/0x290
      kernel: [<ffffffff815cfee1>] start_secondary+0x265/0x27b
      kernel: ---[ end trace 11aa7726f18d7e80 ]---
      
      Fixes: a848ade4 ("bnx2x: add CSUM and TSO support for encapsulation protocols")
      Reported-by: default avatarYulong Pei <ypei@redhat.com>
      Cc: Michal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarDmitry Kravkov <Dmitry.Kravkov@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe26566d
    • hayeswang's avatar
      r8152: fix the checking of the usb speed · a3cc465d
      hayeswang authored
      When the usb speed of the RTL8152 is not high speed, the USB_DEV_STAT[2:1]
      should be equal to [0 1]. That is, the STAT_SPEED_FULL should be equal
      to 2.
      
      There is a easy way to check the usb speed by the speed field of the
      struct usb_device. Use it to replace the original metheod.
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Spotted-by: default avatarAndrey Utkin <andrey.krieger.utkin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a3cc465d
    • David S. Miller's avatar
      Merge tag 'master-2014-07-23' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · e62f7757
      David S. Miller authored
      John W. Linville says:
      
      ====================
      pull request: wireless 2014-07-24
      
      Please pull this batch of fixes intended for the 3.16 stream...
      
      For the mac80211 fixes, Johannes says:
      
      "I have two fixes: one for tracing that fixes a long-standing NULL
      pointer dereference, and one for a mac80211 issue that causes iwlmvm to
      send invalid frames during authentication/association."
      
      and,
      
      "One more fix - for a bug in the newly introduced code that obtains rate
      control information for stations."
      
      For the iwlwifi fixes, Emmanuel says:
      
      "It includes a merge damage fix. This region has been changed in -next
      and -fixes quite a few times and apparently, I failed to handle it
      properly, so here the fix.  Along with that I have a fix from Eliad
      to properly handle overlapping BSS in AP mode."
      
      On top of that, Felix provides and ath9k fix for Tx stalls that happen
      after an aggregation session failure.
      
      Please let me know if there are problems!  There are some changes
      here that will cause merge conflicts in -next.  Once you merge this
      I can pull it into wireless-next and resolve those issues.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e62f7757
    • David S. Miller's avatar
      Merge branch 'mdio_module_unload' · a88a7be6
      David S. Miller authored
      Ezequiel Garcia says:
      
      ====================
      net: phy: Prevent an MDIO bus from being unloaded while in use
      
      Changes from v1:
        * Dropped the unneeded module_put() on phy_attach_direct().
      
      The motivation of this small series is to fix the current lack of relationship
      between an ethernet driver and the MDIO bus behind the PHY device. In such
      cases, we would find no visible link between the drivers:
      
        $ lsmod
        Module                  Size  Used by    Not tainted
        mvmdio                  2941  0
        mvneta                 22069  0
      
      Which means nothing prevents the MDIO driver from being removed:
      
        $ modprobe -r mvmdio
      
        # Unable to handle kernel NULL pointer dereference at virtual address 00000060
        pgd = c0004000
        [00000060] *pgd=00000000
        Internal error: Oops: 17 [#1] SMP ARM
        Modules linked in: mvneta [last unloaded: mvmdio]
        CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 3.16.0-rc5-01127-g62c0816-dirty #608
        Workqueue: events_power_efficient phy_state_machine
        task: df5ec840 ti: df67a000 task.ti: df67a000
        PC is at phy_state_machine+0x1c/0x468
        LR is at phy_state_machine+0x18/0x468
        [snip]
      
      This patchset fixes this problem by adding a pair of module_{get,put},
      so the module reference count is increased when the PHY device is attached
      and is decreased when the PHY is detached.
      
      Tested with mvneta and mv643xx_eth drivers, which depend on the mvmdio
      driver to handle MDIO. This series applies on both net and net-next branches.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a88a7be6
    • Ezequiel Garcia's avatar
      net: phy: Ensure the MDIO bus module is held · b3565f27
      Ezequiel Garcia authored
      This commit adds proper module_{get,put} to prevent the MDIO bus module
      from being unloaded while the phydev is connected. By doing so, we fix
      a kernel panic produced when a MDIO driver is removed, but the phydev
      that relies on it is attached and running.
      Signed-off-by: default avatarEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3565f27
    • Ezequiel Garcia's avatar
      net: phy: Set the driver when registering an MDIO bus device · a71e3c37
      Ezequiel Garcia authored
      mdiobus_register() registers a device which is already bound to a driver.
      Hence, the driver pointer should be set properly in order to track down
      the driver associated to the MDIO bus.
      
      This will be used to allow ethernet driver to pin down a MDIO bus driver,
      preventing it from being unloaded while the PHY device is running.
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a71e3c37
    • Yaniv Rosner's avatar
      bnx2x: fix set_setting for some PHYs · 042d7654
      Yaniv Rosner authored
      Allow set_settings() to complete succesfully even if link is
      not estabilished and port type isn't known yet.
      Signed-off-by: default avatarYaniv Rosner <Yaniv.Rosner@qlogic.com>
      Signed-off-by: default avatarDmitry Kravkov <Dmitry.Kravkov@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      042d7654
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 29be6180
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Via Simon Horman, I received the following one-liner for your net tree:
      
      1) Fix crash when exiting from netns that uses IPVS and conntrack,
         from Julian Anastasov via Simon Horman.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29be6180
  3. 24 Jul, 2014 1 commit
  4. 23 Jul, 2014 6 commits
    • Wei Yongjun's avatar
      hyperv: Fix error return code in netvsc_init_buf() · dd1d3f8f
      Wei Yongjun authored
      Fix to return -ENOMEM from the kalloc error handling
      case instead of 0.
      Signed-off-by: default avatarWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Reviewed-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dd1d3f8f
    • Wei Yongjun's avatar
      amd-xgbe: Fix error return code in xgbe_probe() · 332cfc82
      Wei Yongjun authored
      Fix to return a negative error code from the setting real tx queue
      count error handling case instead of 0.
      Signed-off-by: default avatarWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Acked-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      332cfc82
    • Felix Fietkau's avatar
      ath9k: fix aggregation session lockup · c01fac1c
      Felix Fietkau authored
      If an aggregation session fails, frames still end up in the driver queue
      with IEEE80211_TX_CTL_AMPDU set.
      This causes tx for the affected station/tid to stall, since
      ath_tx_get_tid_subframe returning packets to send.
      
      Fix this by clearing IEEE80211_TX_CTL_AMPDU as long as no aggregation
      session is running.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c01fac1c
    • John W. Linville's avatar
    • Florian Fainelli's avatar
      net: bcmgenet: correctly pad short packets · 474ea9ca
      Florian Fainelli authored
      Packets shorter than ETH_ZLEN were not padded with zeroes, hence leaking
      potentially sensitive information. This bug has been present since the
      driver got accepted in commit 1c1008c7
      ("net: bcmgenet: add main driver file").
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      474ea9ca
    • Daniel Borkmann's avatar
      net: sctp: inherit auth_capable on INIT collisions · 1be9a950
      Daniel Borkmann authored
      Jason reported an oops caused by SCTP on his ARM machine with
      SCTP authentication enabled:
      
      Internal error: Oops: 17 [#1] ARM
      CPU: 0 PID: 104 Comm: sctp-test Not tainted 3.13.0-68744-g3632f30c9b20-dirty #1
      task: c6eefa40 ti: c6f52000 task.ti: c6f52000
      PC is at sctp_auth_calculate_hmac+0xc4/0x10c
      LR is at sg_init_table+0x20/0x38
      pc : [<c024bb80>]    lr : [<c00f32dc>]    psr: 40000013
      sp : c6f538e8  ip : 00000000  fp : c6f53924
      r10: c6f50d80  r9 : 00000000  r8 : 00010000
      r7 : 00000000  r6 : c7be4000  r5 : 00000000  r4 : c6f56254
      r3 : c00c8170  r2 : 00000001  r1 : 00000008  r0 : c6f1e660
      Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 0005397f  Table: 06f28000  DAC: 00000015
      Process sctp-test (pid: 104, stack limit = 0xc6f521c0)
      Stack: (0xc6f538e8 to 0xc6f54000)
      [...]
      Backtrace:
      [<c024babc>] (sctp_auth_calculate_hmac+0x0/0x10c) from [<c0249af8>] (sctp_packet_transmit+0x33c/0x5c8)
      [<c02497bc>] (sctp_packet_transmit+0x0/0x5c8) from [<c023e96c>] (sctp_outq_flush+0x7fc/0x844)
      [<c023e170>] (sctp_outq_flush+0x0/0x844) from [<c023ef78>] (sctp_outq_uncork+0x24/0x28)
      [<c023ef54>] (sctp_outq_uncork+0x0/0x28) from [<c0234364>] (sctp_side_effects+0x1134/0x1220)
      [<c0233230>] (sctp_side_effects+0x0/0x1220) from [<c02330b0>] (sctp_do_sm+0xac/0xd4)
      [<c0233004>] (sctp_do_sm+0x0/0xd4) from [<c023675c>] (sctp_assoc_bh_rcv+0x118/0x160)
      [<c0236644>] (sctp_assoc_bh_rcv+0x0/0x160) from [<c023d5bc>] (sctp_inq_push+0x6c/0x74)
      [<c023d550>] (sctp_inq_push+0x0/0x74) from [<c024a6b0>] (sctp_rcv+0x7d8/0x888)
      
      While we already had various kind of bugs in that area
      ec0223ec ("net: sctp: fix sctp_sf_do_5_1D_ce to verify if
      we/peer is AUTH capable") and b14878cc ("net: sctp: cache
      auth_enable per endpoint"), this one is a bit of a different
      kind.
      
      Giving a bit more background on why SCTP authentication is
      needed can be found in RFC4895:
      
        SCTP uses 32-bit verification tags to protect itself against
        blind attackers. These values are not changed during the
        lifetime of an SCTP association.
      
        Looking at new SCTP extensions, there is the need to have a
        method of proving that an SCTP chunk(s) was really sent by
        the original peer that started the association and not by a
        malicious attacker.
      
      To cause this bug, we're triggering an INIT collision between
      peers; normal SCTP handshake where both sides intent to
      authenticate packets contains RANDOM; CHUNKS; HMAC-ALGO
      parameters that are being negotiated among peers:
      
        ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
        <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
        -------------------- COOKIE-ECHO -------------------->
        <-------------------- COOKIE-ACK ---------------------
      
      RFC4895 says that each endpoint therefore knows its own random
      number and the peer's random number *after* the association
      has been established. The local and peer's random number along
      with the shared key are then part of the secret used for
      calculating the HMAC in the AUTH chunk.
      
      Now, in our scenario, we have 2 threads with 1 non-blocking
      SEQ_PACKET socket each, setting up common shared SCTP_AUTH_KEY
      and SCTP_AUTH_ACTIVE_KEY properly, and each of them calling
      sctp_bindx(3), listen(2) and connect(2) against each other,
      thus the handshake looks similar to this, e.g.:
      
        ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
        <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
        <--------- INIT[RANDOM; CHUNKS; HMAC-ALGO] -----------
        -------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] -------->
        ...
      
      Since such collisions can also happen with verification tags,
      the RFC4895 for AUTH rather vaguely says under section 6.1:
      
        In case of INIT collision, the rules governing the handling
        of this Random Number follow the same pattern as those for
        the Verification Tag, as explained in Section 5.2.4 of
        RFC 2960 [5]. Therefore, each endpoint knows its own Random
        Number and the peer's Random Number after the association
        has been established.
      
      In RFC2960, section 5.2.4, we're eventually hitting Action B:
      
        B) In this case, both sides may be attempting to start an
           association at about the same time but the peer endpoint
           started its INIT after responding to the local endpoint's
           INIT. Thus it may have picked a new Verification Tag not
           being aware of the previous Tag it had sent this endpoint.
           The endpoint should stay in or enter the ESTABLISHED
           state but it MUST update its peer's Verification Tag from
           the State Cookie, stop any init or cookie timers that may
           running and send a COOKIE ACK.
      
      In other words, the handling of the Random parameter is the
      same as behavior for the Verification Tag as described in
      Action B of section 5.2.4.
      
      Looking at the code, we exactly hit the sctp_sf_do_dupcook_b()
      case which triggers an SCTP_CMD_UPDATE_ASSOC command to the
      side effect interpreter, and in fact it properly copies over
      peer_{random, hmacs, chunks} parameters from the newly created
      association to update the existing one.
      
      Also, the old asoc_shared_key is being released and based on
      the new params, sctp_auth_asoc_init_active_key() updated.
      However, the issue observed in this case is that the previous
      asoc->peer.auth_capable was 0, and has *not* been updated, so
      that instead of creating a new secret, we're doing an early
      return from the function sctp_auth_asoc_init_active_key()
      leaving asoc->asoc_shared_key as NULL. However, we now have to
      authenticate chunks from the updated chunk list (e.g. COOKIE-ACK).
      
      That in fact causes the server side when responding with ...
      
        <------------------ AUTH; COOKIE-ACK -----------------
      
      ... to trigger a NULL pointer dereference, since in
      sctp_packet_transmit(), it discovers that an AUTH chunk is
      being queued for xmit, and thus it calls sctp_auth_calculate_hmac().
      
      Since the asoc->active_key_id is still inherited from the
      endpoint, and the same as encoded into the chunk, it uses
      asoc->asoc_shared_key, which is still NULL, as an asoc_key
      and dereferences it in ...
      
        crypto_hash_setkey(desc.tfm, &asoc_key->data[0], asoc_key->len)
      
      ... causing an oops. All this happens because sctp_make_cookie_ack()
      called with the *new* association has the peer.auth_capable=1
      and therefore marks the chunk with auth=1 after checking
      sctp_auth_send_cid(), but it is *actually* sent later on over
      the then *updated* association's transport that didn't initialize
      its shared key due to peer.auth_capable=0. Since control chunks
      in that case are not sent by the temporary association which
      are scheduled for deletion, they are issued for xmit via
      SCTP_CMD_REPLY in the interpreter with the context of the
      *updated* association. peer.auth_capable was 0 in the updated
      association (which went from COOKIE_WAIT into ESTABLISHED state),
      since all previous processing that performed sctp_process_init()
      was being done on temporary associations, that we eventually
      throw away each time.
      
      The correct fix is to update to the new peer.auth_capable
      value as well in the collision case via sctp_assoc_update(),
      so that in case the collision migrated from 0 -> 1,
      sctp_auth_asoc_init_active_key() can properly recalculate
      the secret. This therefore fixes the observed server panic.
      
      Fixes: 730fc3d0 ("[SCTP]: Implete SCTP-AUTH parameter processing")
      Reported-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Tested-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1be9a950
  5. 22 Jul, 2014 9 commits
    • Felix Fietkau's avatar
      mac80211: fix crash on getting sta info with uninitialized rate control · fa8f136f
      Felix Fietkau authored
      If the expected throughput is queried before rate control has been
      initialized, the minstrel op for it will crash while trying to access
      the rate table.
      Check for WLAN_STA_RATE_CONTROL before attempting to use the rate
      control op.
      Reported-by: default avatarJean-Pierre Tosoni <jp.tosoni@acksys.fr>
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fa8f136f
    • John W. Linville's avatar
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 15ba2236
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Null termination fix in dns_resolver got the pointer dereferncing
          wrong, fix from Ben Hutchings.
      
       2) ip_options_compile() has a benign but real buffer overflow when
          parsing options.  From Eric Dumazet.
      
       3) Table updates can crash in netfilter's nftables if none of the state
          flags indicate an actual change, from Pablo Neira Ayuso.
      
       4) Fix race in nf_tables dumping, also from Pablo.
      
       5) GRE-GRO support broke the forwarding path because the segmentation
          state was not fully initialized in these paths, from Jerry Chu.
      
       6) sunvnet driver leaks objects and potentially crashes on module
          unload, from Sowmini Varadhan.
      
       7) We can accidently generate the same handle for several u32
          classifier filters, fix from Cong Wang.
      
       8) Several edge case bug fixes in fragment handling in xen-netback,
          from Zoltan Kiss.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (21 commits)
        ipv4: fix buffer overflow in ip_options_compile()
        batman-adv: fix TT VLAN inconsistency on VLAN re-add
        batman-adv: drop QinQ claim frames in bridge loop avoidance
        dns_resolver: Null-terminate the right string
        xen-netback: Fix pointer incrementation to avoid incorrect logging
        xen-netback: Fix releasing header slot on error path
        xen-netback: Fix releasing frag_list skbs in error path
        xen-netback: Fix handling frag_list on grant op error path
        net_sched: avoid generating same handle for u32 filters
        net: huawei_cdc_ncm: add "subclass 3" devices
        net: qmi_wwan: add two Sierra Wireless/Netgear devices
        wan/x25_asy: integer overflow in x25_asy_change_mtu()
        net: ppp: fix creating PPP pass and active filters
        net/mlx4_en: cq->irq_desc wasn't set in legacy EQ's
        sunvnet: clean up objects created in vnet_new() on vnet_exit()
        r8169: Enable RX_MULTI_EN for RTL_GIGA_MAC_VER_40
        net-gre-gro: Fix a bug that breaks the forwarding path
        netfilter: nf_tables: 64bit stats need some extra synchronization
        netfilter: nf_tables: set NLM_F_DUMP_INTR if netlink dumping is stale
        netfilter: nf_tables: safe RCU iteration on list when dumping
        ...
      15ba2236
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc · 89faa06e
      Linus Torvalds authored
      Pull sparc fix from David Miller:
       "Need to hook up the new renameat2 system call"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
        sparc: Hook up renameat2 syscall.
      89faa06e
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide · 14867719
      Linus Torvalds authored
      Pull IDE fixes from David Miller:
       - fix interrupt registry for some Atari IDE chipsets.
       - adjust Kconfig dependencies for x86_32 specific chips.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide:
        ide: Fix SC1200 dependencies
        ide: Fix CS5520 and CS5530 dependencies
        m68k/atari - ide: do not register interrupt if host->get_lock is set
      14867719
    • Linus Torvalds's avatar
      Merge tag 'trace-fixes-v3.16-rc6' of... · 8dcc3be2
      Linus Torvalds authored
      Merge tag 'trace-fixes-v3.16-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
      
      Pull trace fix from Steven Rostedt:
       "Tony Luck found that using the "uptime" trace clock that uses jiffies
        as a counter was converted to nanoseconds (silly), and after 1 hour 11
        minutes and 34 seconds, this monotonic clock would wrap, causing havoc
        with the tracing system and making the clock useless.
      
        He converted that clock to use jiffies_64 and made it into a counter
        instead of nanosecond conversions, and displayed the clock with the
        straight jiffy count, which works much better than it did in the past"
      
      * tag 'trace-fixes-v3.16-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Fix wraparound problems in "uptime" trace clock
      8dcc3be2
    • David S. Miller's avatar
      sparc: Hook up renameat2 syscall. · 26053926
      David S. Miller authored
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26053926
    • David S. Miller's avatar
      Merge tag 'batman-adv-fix-for-davem' of git://git.open-mesh.org/linux-merge · 850717ef
      David S. Miller authored
      Antonio Quartulli says:
      
      ====================
      pull request [net]: batman-adv 20140721
      
      here you have two fixes that we have been testing for quite some time
      (this is why they arrived a bit late in the rc cycle).
      
      Patch 1) ensures that BLA packets get dropped and not forwarded to the
      mesh even if they reach batman-adv within QinQ frames. Forwarding them
      into the mesh means messing up with the TT database of other nodes which
      can generate all kind of unexpected behaviours during route computation.
      
      Patch 2) avoids a couple of race conditions triggered upon fast VLAN
      deletion-addition. Such race conditions are pretty dangerous because
      they not only create inconsistencies in the TT database of the nodes
      in the network, but such scenario is also unrecoverable (unless
      nodes are rebooted).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      850717ef
    • Eric Dumazet's avatar
      ipv4: fix buffer overflow in ip_options_compile() · 10ec9472
      Eric Dumazet authored
      There is a benign buffer overflow in ip_options_compile spotted by
      AddressSanitizer[1] :
      
      Its benign because we always can access one extra byte in skb->head
      (because header is followed by struct skb_shared_info), and in this case
      this byte is not even used.
      
      [28504.910798] ==================================================================
      [28504.912046] AddressSanitizer: heap-buffer-overflow in ip_options_compile
      [28504.913170] Read of size 1 by thread T15843:
      [28504.914026]  [<ffffffff81802f91>] ip_options_compile+0x121/0x9c0
      [28504.915394]  [<ffffffff81804a0d>] ip_options_get_from_user+0xad/0x120
      [28504.916843]  [<ffffffff8180dedf>] do_ip_setsockopt.isra.15+0x8df/0x1630
      [28504.918175]  [<ffffffff8180ec60>] ip_setsockopt+0x30/0xa0
      [28504.919490]  [<ffffffff8181e59b>] tcp_setsockopt+0x5b/0x90
      [28504.920835]  [<ffffffff8177462f>] sock_common_setsockopt+0x5f/0x70
      [28504.922208]  [<ffffffff817729c2>] SyS_setsockopt+0xa2/0x140
      [28504.923459]  [<ffffffff818cfb69>] system_call_fastpath+0x16/0x1b
      [28504.924722]
      [28504.925106] Allocated by thread T15843:
      [28504.925815]  [<ffffffff81804995>] ip_options_get_from_user+0x35/0x120
      [28504.926884]  [<ffffffff8180dedf>] do_ip_setsockopt.isra.15+0x8df/0x1630
      [28504.927975]  [<ffffffff8180ec60>] ip_setsockopt+0x30/0xa0
      [28504.929175]  [<ffffffff8181e59b>] tcp_setsockopt+0x5b/0x90
      [28504.930400]  [<ffffffff8177462f>] sock_common_setsockopt+0x5f/0x70
      [28504.931677]  [<ffffffff817729c2>] SyS_setsockopt+0xa2/0x140
      [28504.932851]  [<ffffffff818cfb69>] system_call_fastpath+0x16/0x1b
      [28504.934018]
      [28504.934377] The buggy address ffff880026382828 is located 0 bytes to the right
      [28504.934377]  of 40-byte region [ffff880026382800, ffff880026382828)
      [28504.937144]
      [28504.937474] Memory state around the buggy address:
      [28504.938430]  ffff880026382300: ........ rrrrrrrr rrrrrrrr rrrrrrrr
      [28504.939884]  ffff880026382400: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
      [28504.941294]  ffff880026382500: .....rrr rrrrrrrr rrrrrrrr rrrrrrrr
      [28504.942504]  ffff880026382600: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
      [28504.943483]  ffff880026382700: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
      [28504.944511] >ffff880026382800: .....rrr rrrrrrrr rrrrrrrr rrrrrrrr
      [28504.945573]                         ^
      [28504.946277]  ffff880026382900: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
      [28505.094949]  ffff880026382a00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
      [28505.096114]  ffff880026382b00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
      [28505.097116]  ffff880026382c00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
      [28505.098472]  ffff880026382d00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
      [28505.099804] Legend:
      [28505.100269]  f - 8 freed bytes
      [28505.100884]  r - 8 redzone bytes
      [28505.101649]  . - 8 allocated bytes
      [28505.102406]  x=1..7 - x allocated bytes + (8-x) redzone bytes
      [28505.103637] ==================================================================
      
      [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernelSigned-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      10ec9472
  6. 21 Jul, 2014 7 commits
    • Linus Torvalds's avatar
      Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media · 67dd8f35
      Linus Torvalds authored
      Pull media fixes from Mauro Carvalho Chehab:
       "A series of driver fixes:
         - fix DVB-S tuning with tda1071
         - fix tuner probe on af9035 when the device has a bad eeprom
         - some fixes for the new si2168/2157 drivers
         - one Kconfig build fix (for omap4iss)
         - fixes at vpif error path
         - don't lock saa7134 ioctl at driver's base core level, as it now
           uses V4L2 and VB2 locking schema
         - fix audio at hdpvr driver
         - fix the aspect ratio at the digital timings table
         - one new USB ID (at gspca_pac7302): Genius i-Look 317 webcam"
      
      * 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
        [media] gspca_pac7302: Add new usb-id for Genius i-Look 317
        [media] tda10071: fix returned symbol rate calculation
        [media] tda10071: fix spec inversion reporting
        [media] tda10071: add missing DVB-S2/PSK-8 FEC AUTO
        [media] tda10071: force modulation to QPSK on DVB-S
        [media] hdpvr: fix two audio bugs
        [media] davinci: vpif: missing unlocks on error
        [media] af9035: override tuner id when bad value set into eeprom
        [media] saa7134: use unlocked_ioctl instead of ioctl
        [media] media: v4l2-core: v4l2-dv-timings.c: Cleaning up code wrong value used in aspect ratio
        [media] si2168: firmware download fix
        [media] si2157: add one missing parenthesis
        [media] si2168: add one missing parenthesis
        [media] staging: tighten omap4iss dependencies
      67dd8f35
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 6890ad4b
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
       "Final block fixes for 3.16
      
        Four small fixes that should go into 3.16, have been queued up for a
        bit and delayed due to vacation and other euro duties.  But here they
        are.  The pull request contains:
      
         - Fix for a reported crash with shared tagging on SCSI from Christoph
      
         - A regression fix for drbd.  From Lars Ellenberg.
      
         - Hooking up the compat ioctl for BLKZEROOUT, which requires no
           translation.  From Mikulas.
      
      - A fix for a regression where we woud crash on queue exit if the
        root_blkg is gone/not there. From Tejun"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        block: provide compat ioctl for BLKZEROOUT
        blkcg: don't call into policy draining if root_blkg is already gone
        drbd: fix regression 'out of mem, failed to invoke fence-peer helper'
        block: don't assume last put of shared tags is for the host
      6890ad4b
    • Linus Torvalds's avatar
      Merge branch 'for-3.16-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata · d6e6c48e
      Linus Torvalds authored
      Pull libata fixes from Tejun Heo:
       "Late libata fixes.
      
        The most important one is from Kevin Hao which makes sure that libata
        only allocates tags inside the max tag number the controller supports.
        libata always had this problem but the recent tag allocation change
        and addition of support for sata_fsl which only supports queue depth
        of 16 exposed the issue.
      
        Hans de Goede agreed to become the maintainer of libahci_platform
        which is under higher than usual development pressure from all the new
        controllers popping up from the ARM world"
      
      * 'for-3.16-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
        ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode)
        drivers/ata/pata_ep93xx.c: use signed int type for result of platform_get_irq()
        libata: EH should handle AMNF error condition as a media error
        libata: support the ata host which implements a queue depth less than 32
        MAINTAINERS: Add Hans de Goede as ahci-platform maintainer
      d6e6c48e
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 5b2b9d77
      Linus Torvalds authored
      Pull kvm fixes from Paolo Bonzini:
       "These are mostly PPC changes for 3.16-new things.  However, there is
        an x86 change too and it is a regression from 3.14.  As it only
        affects nested virtualization and there were other changes in this
        area in 3.16, I am not nominating it for 3.15-stable"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: x86: Check for nested events if there is an injectable interrupt
        KVM: PPC: RTAS: Do byte swaps explicitly
        KVM: PPC: Book3S PR: Fix ABIv2 on LE
        KVM: PPC: Assembly functions exported to modules need _GLOBAL_TOC()
        PPC: Add _GLOBAL_TOC for 32bit
        KVM: PPC: BOOK3S: HV: Use base page size when comparing against slb value
        KVM: PPC: Book3E: Unlock mmu_lock when setting caching atttribute
      5b2b9d77
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 80d6191e
      Linus Torvalds authored
      Pull s390 fixes from Martin Schwidefsky:
       "A couple of last minute bug fixes for 3.16, including a fix for ptrace
        to close a hole which allowed a user space program to write to the
        kernel address space"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390: fix restore of invalid floating-point-control
        s390/zcrypt: improve device probing for zcrypt adapter cards
        s390/ptrace: fix PSW mask check
        s390/MSI: Use standard mask and unmask funtions
        s390/3270: correct size detection with the read-partition command
        s390: require mvcos facility, not tod clock steering facility
      80d6191e
    • Tony Luck's avatar
      tracing: Fix wraparound problems in "uptime" trace clock · 58d4e21e
      Tony Luck authored
      The "uptime" trace clock added in:
      
          commit 8aacf017
          tracing: Add "uptime" trace clock that uses jiffies
      
      has wraparound problems when the system has been up more
      than 1 hour 11 minutes and 34 seconds. It converts jiffies
      to nanoseconds using:
              (u64)jiffies_to_usecs(jiffy) * 1000ULL
      but since jiffies_to_usecs() only returns a 32-bit value, it
      truncates at 2^32 microseconds.  An additional problem on 32-bit
      systems is that the argument is "unsigned long", so fixing the
      return value only helps until 2^32 jiffies (49.7 days on a HZ=1000
      system).
      
      Avoid these problems by using jiffies_64 as our basis, and
      not converting to nanoseconds (we do convert to clock_t because
      user facing API must not be dependent on internal kernel
      HZ values).
      
      Link: http://lkml.kernel.org/p/99d63c5bfe9b320a3b428d773825a37095bf6a51.1405708254.git.tony.luck@intel.com
      
      Cc: stable@vger.kernel.org # 3.10+
      Fixes: 8aacf017 "tracing: Add "uptime" trace clock that uses jiffies"
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      58d4e21e
    • Antonio Quartulli's avatar
      batman-adv: fix TT VLAN inconsistency on VLAN re-add · 35df3b29
      Antonio Quartulli authored
      When a VLAN interface (on top of batX) is removed and
      re-added within a short timeframe TT does not have enough
      time to properly cleanup. This creates an internal TT state
      mismatch as the newly created softif_vlan will be
      initialized from scratch with a TT client count of zero
      (even if TT entries for this VLAN still exist). The
      resulting TT messages are bogus due to the counter / tt
      client listing mismatch, thus creating inconsistencies on
      every node in the network
      
      To fix this issue destroy_vlan() has to not free the VLAN
      object immediately but it has to be kept alive until all the
      TT entries for this VLAN have been removed. destroy_vlan()
      still removes the sysfs folder so that the user has the
      feeling that everything went fine.
      
      If the same VLAN is re-added before the old object is free'd,
      then the latter is resurrected and re-used.
      
      Implement such behaviour by increasing the reference counter
      of a softif_vlan object every time a new local TT entry for
      such VLAN is created and remove the object from the list
      only when all the TT entries have been destroyed.
      Signed-off-by: default avatarAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      35df3b29