1. 02 Jul, 2017 1 commit
  2. 01 Jul, 2017 5 commits
  3. 30 Jun, 2017 10 commits
  4. 29 Jun, 2017 22 commits
    • Doug Berger's avatar
      ARM: 8685/1: ensure memblock-limit is pmd-aligned · 9e25ebfe
      Doug Berger authored
      The pmd containing memblock_limit is cleared by prepare_page_table()
      which creates the opportunity for early_alloc() to allocate unmapped
      memory if memblock_limit is not pmd aligned causing a boot-time hang.
      
      Commit 965278dc ("ARM: 8356/1: mm: handle non-pmd-aligned end of RAM")
      attempted to resolve this problem, but there is a path through the
      adjust_lowmem_bounds() routine where if all memory regions start and
      end on pmd-aligned addresses the memblock_limit will be set to
      arm_lowmem_limit.
      
      Since arm_lowmem_limit can be affected by the vmalloc early parameter,
      the value of arm_lowmem_limit may not be pmd-aligned. This commit
      corrects this oversight such that memblock_limit is always rounded
      down to pmd-alignment.
      
      Fixes: 965278dc ("ARM: 8356/1: mm: handle non-pmd-aligned end of RAM")
      Signed-off-by: default avatarDoug Berger <opendmb@gmail.com>
      Suggested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      9e25ebfe
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 4d8a991d
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Need to access netdev->num_rx_queues behind an accessor in netvsc
          driver otherwise the build breaks with some configs, from Arnd
          Bergmann.
      
       2) Add dummy xfrm_dev_event() so that build doesn't fail when
          CONFIG_XFRM_OFFLOAD is not set. From Hangbin Liu.
      
       3) Don't OOPS when pfkey_msg2xfrm_state() signals an erros, from Dan
          Carpenter.
      
       4) Fix MCDI command size for filter operations in sfc driver, from
          Martin Habets.
      
       5) Fix UFO segmenting so that we don't calculate incorrect checksums,
          from Michal Kubecek.
      
       6) When ipv6 datagram connects fail, reset destination address and
          port. From Wei Wang.
      
       7) TCP disconnect must reset the cached receive DST, from WANG Cong.
      
       8) Fix sign extension bug on 32-bit in dev_get_stats(), from Eric
          Dumazet.
      
       9) fman driver has to depend on HAS_DMA, from Madalin Bucur.
      
      10) Fix bpf pointer leak with xadd in verifier, from Daniel Borkmann.
      
      11) Fix negative page counts with GFO, from Michal Kubecek.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (41 commits)
        sfc: fix attempt to translate invalid filter ID
        net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()
        bpf: prevent leaking pointer via xadd on unpriviledged
        arcnet: com20020-pci: add missing pdev setup in netdev structure
        arcnet: com20020-pci: fix dev_id calculation
        arcnet: com20020: remove needless base_addr assignment
        Trivial fix to spelling mistake in arc_printk message
        arcnet: change irq handler to lock irqsave
        rocker: move dereference before free
        mlxsw: spectrum_router: Fix NULL pointer dereference
        net: sched: Fix one possible panic when no destroy callback
        virtio-net: serialize tx routine during reset
        net: usb: asix88179_178a: Add support for the Belkin B2B128
        fsl/fman: add dependency on HAS_DMA
        net: prevent sign extension in dev_get_stats()
        tcp: reset sk_rx_dst in tcp_disconnect()
        net: ipv6: reset daddr and dport in sk if connect() fails
        bnx2x: Don't log mc removal needlessly
        bnxt_en: Fix netpoll handling.
        bnxt_en: Add missing logic to handle TPA end error conditions.
        ...
      4d8a991d
    • Linus Torvalds's avatar
      Merge tag 'for-4.12/dm-fixes-5' of... · 27bc3440
      Linus Torvalds authored
      Merge tag 'for-4.12/dm-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
      
      Pull device mapper fixes from Mike Snitzer:
      
       - dm thinp fix for crash that will occur when metadata device failure
         races with discard passdown to the underlying data device.
      
       - dm raid fix to not access the superblock's >= 1.9.0 'sectors' member
         unconditionally.
      
      * tag 'for-4.12/dm-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm thin: do not queue freed thin mapping for next stage processing
        dm raid: fix oops on upgrading to extended superblock format
      27bc3440
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 374bf883
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
       "Two fixes that should go into this release.
      
        One is an nvme regression fix from Keith, fixing a missing queue
        freeze if the controller is being reset. This causes the reset to
        hang.
      
        The other is a fix for a leak of the bio protection info, if smaller
        sized O_DIRECT is used. This fix should be more involved as we have
        other problematic paths in the kernel, but given as this isn't a
        regression in this series, we'll tackle those for 4.13"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        block: provide bio_uninit() free freeing integrity/task associations
        nvme/pci: Fix stuck nvme reset
      374bf883
    • Edward Cree's avatar
      sfc: fix attempt to translate invalid filter ID · d58299a4
      Edward Cree authored
      When filter insertion fails with no rollback, we were trying to convert
       EFX_EF10_FILTER_ID_INVALID to an id to store in 'ids' (which is either
       vlan->uc or vlan->mc).  This would WARN_ON_ONCE and then record a bogus
       filter ID of 0x1fff, neither of which is a good thing.
      
      Fixes: 0ccb998b ("sfc: fix filter_id misinterpretation in edge case")
      Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d58299a4
    • Michal Kubeček's avatar
      net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish() · e44699d2
      Michal Kubeček authored
      Recently I started seeing warnings about pages with refcount -1. The
      problem was traced to packets being reused after their head was merged into
      a GRO packet by skb_gro_receive(). While bisecting the issue pointed to
      commit c21b48cc ("net: adjust skb->truesize in ___pskb_trim()") and
      I have never seen it on a kernel with it reverted, I believe the real
      problem appeared earlier when the option to merge head frag in GRO was
      implemented.
      
      Handling NAPI_GRO_FREE_STOLEN_HEAD state was only added to GRO_MERGED_FREE
      branch of napi_skb_finish() so that if the driver uses napi_gro_frags()
      and head is merged (which in my case happens after the skb_condense()
      call added by the commit mentioned above), the skb is reused including the
      head that has been merged. As a result, we release the page reference
      twice and eventually end up with negative page refcount.
      
      To fix the problem, handle NAPI_GRO_FREE_STOLEN_HEAD in napi_frags_finish()
      the same way it's done in napi_skb_finish().
      
      Fixes: d7e8883c ("net: make GRO aware of skb->head_frag")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e44699d2
    • Daniel Borkmann's avatar
      bpf: prevent leaking pointer via xadd on unpriviledged · 6bdf6abc
      Daniel Borkmann authored
      Leaking kernel addresses on unpriviledged is generally disallowed,
      for example, verifier rejects the following:
      
        0: (b7) r0 = 0
        1: (18) r2 = 0xffff897e82304400
        3: (7b) *(u64 *)(r1 +48) = r2
        R2 leaks addr into ctx
      
      Doing pointer arithmetic on them is also forbidden, so that they
      don't turn into unknown value and then get leaked out. However,
      there's xadd as a special case, where we don't check the src reg
      for being a pointer register, e.g. the following will pass:
      
        0: (b7) r0 = 0
        1: (7b) *(u64 *)(r1 +48) = r0
        2: (18) r2 = 0xffff897e82304400 ; map
        4: (db) lock *(u64 *)(r1 +48) += r2
        5: (95) exit
      
      We could store the pointer into skb->cb, loose the type context,
      and then read it out from there again to leak it eventually out
      of a map value. Or more easily in a different variant, too:
      
         0: (bf) r6 = r1
         1: (7a) *(u64 *)(r10 -8) = 0
         2: (bf) r2 = r10
         3: (07) r2 += -8
         4: (18) r1 = 0x0
         6: (85) call bpf_map_lookup_elem#1
         7: (15) if r0 == 0x0 goto pc+3
         R0=map_value(ks=8,vs=8,id=0),min_value=0,max_value=0 R6=ctx R10=fp
         8: (b7) r3 = 0
         9: (7b) *(u64 *)(r0 +0) = r3
        10: (db) lock *(u64 *)(r0 +0) += r6
        11: (b7) r0 = 0
        12: (95) exit
      
        from 7 to 11: R0=inv,min_value=0,max_value=0 R6=ctx R10=fp
        11: (b7) r0 = 0
        12: (95) exit
      
      Prevent this by checking xadd src reg for pointer types. Also
      add a couple of test cases related to this.
      
      Fixes: 1be7f75d ("bpf: enable non-root eBPF programs")
      Fixes: 17a52670 ("bpf: verifier (add verifier core)")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Acked-by: default avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6bdf6abc
    • Kan Liang's avatar
      perf/x86/intel/uncore: Fix wrong box pointer check · 80c65fdb
      Kan Liang authored
      Should not init a NULL box. It will cause system crash.
      The issue looks like caused by a typo.
      
      This was not noticed because there is no NULL box. Also, for most
      boxes, they are enabled by default. The init code is not critical.
      
      Fixes: fff4b87e ("perf/x86/intel/uncore: Make package handling more robust")
      Signed-off-by: default avatarKan Liang <kan.liang@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20170629190926.2456-1-kan.liang@intel.com
      80c65fdb
    • David S. Miller's avatar
      Merge branch 'arcnet-fixes' · 00778f7c
      David S. Miller authored
      Michael Grzeschik says:
      
      ====================
      arcnet: Collection of latest fixes
      
      Here we sum up the recent fixes I collected on the way to use and
      stabilise the framework. Part of it is an possible deadlock that we
      prevent as well to fix the calculation of the dev_id that can be setup
      by an rotary encoder. Beside that we added an trivial spelling patch and
      fix some wrong and missing assignments that improves the code footprint.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      00778f7c
    • Michael Grzeschik's avatar
      arcnet: com20020-pci: add missing pdev setup in netdev structure · 2a0ea04c
      Michael Grzeschik authored
      We add the pdev data to the pci devices netdev structure. This way
      the interface get consistent device names in the userspace (udev).
      Signed-off-by: default avatarMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a0ea04c
    • Michael Grzeschik's avatar
      arcnet: com20020-pci: fix dev_id calculation · cb108619
      Michael Grzeschik authored
      The dev_id was miscalculated. Only the two bits 4-5 are relevant for the
      MA1 card. PCIARC1 and PCIFB2 use the four bits 4-7 for id selection.
      Signed-off-by: default avatarMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb108619
    • Michael Grzeschik's avatar
      arcnet: com20020: remove needless base_addr assignment · 0d494fcf
      Michael Grzeschik authored
      The assignment is superfluous.
      Signed-off-by: default avatarMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d494fcf
    • Colin Ian King's avatar
    • Michael Grzeschik's avatar
      arcnet: change irq handler to lock irqsave · 5b858403
      Michael Grzeschik authored
      This patch prevents the arcnet driver from the following deadlock.
      
      [   41.273910] ======================================================
      [   41.280397] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
      [   41.287433] 4.4.0-00034-gc0ae784 #536 Not tainted
      [   41.292366] ------------------------------------------------------
      [   41.298863] arcecho/233 [HC0[0]:SC0[2]:HE0:SE0] is trying to acquire:
      [   41.305628]  (&(&lp->lock)->rlock){+.+...}, at: [<bf083bc8>] arcnet_send_packet+0x60/0x1c0 [arcnet]
      [   41.315199]
      [   41.315199] and this task is already holding:
      [   41.321324]  (_xmit_ARCNET#2){+.-...}, at: [<c06b934c>] packet_direct_xmit+0xfc/0x1c8
      [   41.329593] which would create a new lock dependency:
      [   41.334893]  (_xmit_ARCNET#2){+.-...} -> (&(&lp->lock)->rlock){+.+...}
      [   41.341801]
      [   41.341801] but this new dependency connects a SOFTIRQ-irq-safe lock:
      [   41.350108]  (_xmit_ARCNET#2){+.-...}
      ... which became SOFTIRQ-irq-safe at:
      [   41.357539]   [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.362677]   [<c063ab8c>] dev_watchdog+0x5c/0x264
      [   41.367723]   [<c0094edc>] call_timer_fn+0x6c/0xf4
      [   41.372759]   [<c00950b8>] run_timer_softirq+0x154/0x210
      [   41.378340]   [<c0036b30>] __do_softirq+0x144/0x298
      [   41.383469]   [<c0036fb4>] irq_exit+0xcc/0x130
      [   41.388138]   [<c0085c50>] __handle_domain_irq+0x60/0xb4
      [   41.393728]   [<c0014578>] __irq_svc+0x58/0x78
      [   41.398402]   [<c0010274>] arch_cpu_idle+0x24/0x3c
      [   41.403443]   [<c007127c>] cpu_startup_entry+0x1f8/0x25c
      [   41.409029]   [<c09adc90>] start_kernel+0x3c0/0x3cc
      [   41.414170]
      [   41.414170] to a SOFTIRQ-irq-unsafe lock:
      [   41.419931]  (&(&lp->lock)->rlock){+.+...}
      ... which became SOFTIRQ-irq-unsafe at:
      [   41.427996] ...  [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.433409]   [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
      [   41.439646]   [<c0089120>] handle_nested_irq+0x8c/0xec
      [   41.445063]   [<c03c1170>] regmap_irq_thread+0x190/0x314
      [   41.450661]   [<c0087244>] irq_thread_fn+0x1c/0x34
      [   41.455700]   [<c0087548>] irq_thread+0x13c/0x1dc
      [   41.460649]   [<c0050f10>] kthread+0xe4/0xf8
      [   41.465158]   [<c000f810>] ret_from_fork+0x14/0x24
      [   41.470207]
      [   41.470207] other info that might help us debug this:
      [   41.470207]
      [   41.478627]  Possible interrupt unsafe locking scenario:
      [   41.478627]
      [   41.485763]        CPU0                    CPU1
      [   41.490521]        ----                    ----
      [   41.495279]   lock(&(&lp->lock)->rlock);
      [   41.499414]                                local_irq_disable();
      [   41.505636]                                lock(_xmit_ARCNET#2);
      [   41.511967]                                lock(&(&lp->lock)->rlock);
      [   41.518741]   <Interrupt>
      [   41.521490]     lock(_xmit_ARCNET#2);
      [   41.525356]
      [   41.525356]  *** DEADLOCK ***
      [   41.525356]
      [   41.531587] 1 lock held by arcecho/233:
      [   41.535617]  #0:  (_xmit_ARCNET#2){+.-...}, at: [<c06b934c>] packet_direct_xmit+0xfc/0x1c8
      [   41.544355]
      the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
      [   41.552362] -> (_xmit_ARCNET#2){+.-...} ops: 27 {
      [   41.557357]    HARDIRQ-ON-W at:
      [   41.560664]                     [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.567445]                     [<c063ba28>] dev_deactivate_many+0x114/0x304
      [   41.574866]                     [<c063bc3c>] dev_deactivate+0x24/0x38
      [   41.581646]                     [<c0630374>] linkwatch_do_dev+0x40/0x74
      [   41.588613]                     [<c06305d8>] __linkwatch_run_queue+0xec/0x140
      [   41.596120]                     [<c0630658>] linkwatch_event+0x2c/0x34
      [   41.602991]                     [<c004af30>] process_one_work+0x188/0x40c
      [   41.610131]                     [<c004b200>] worker_thread+0x4c/0x480
      [   41.616912]                     [<c0050f10>] kthread+0xe4/0xf8
      [   41.623048]                     [<c000f810>] ret_from_fork+0x14/0x24
      [   41.629735]    IN-SOFTIRQ-W at:
      [   41.633039]                     [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.639820]                     [<c063ab8c>] dev_watchdog+0x5c/0x264
      [   41.646508]                     [<c0094edc>] call_timer_fn+0x6c/0xf4
      [   41.653190]                     [<c00950b8>] run_timer_softirq+0x154/0x210
      [   41.660425]                     [<c0036b30>] __do_softirq+0x144/0x298
      [   41.667201]                     [<c0036fb4>] irq_exit+0xcc/0x130
      [   41.673518]                     [<c0085c50>] __handle_domain_irq+0x60/0xb4
      [   41.680754]                     [<c0014578>] __irq_svc+0x58/0x78
      [   41.687077]                     [<c0010274>] arch_cpu_idle+0x24/0x3c
      [   41.693769]                     [<c007127c>] cpu_startup_entry+0x1f8/0x25c
      [   41.701006]                     [<c09adc90>] start_kernel+0x3c0/0x3cc
      [   41.707791]    INITIAL USE at:
      [   41.711003]                    [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.717696]                    [<c063ba28>] dev_deactivate_many+0x114/0x304
      [   41.725026]                    [<c063bc3c>] dev_deactivate+0x24/0x38
      [   41.731718]                    [<c0630374>] linkwatch_do_dev+0x40/0x74
      [   41.738593]                    [<c06305d8>] __linkwatch_run_queue+0xec/0x140
      [   41.746011]                    [<c0630658>] linkwatch_event+0x2c/0x34
      [   41.752789]                    [<c004af30>] process_one_work+0x188/0x40c
      [   41.759847]                    [<c004b200>] worker_thread+0x4c/0x480
      [   41.766541]                    [<c0050f10>] kthread+0xe4/0xf8
      [   41.772596]                    [<c000f810>] ret_from_fork+0x14/0x24
      [   41.779198]  }
      [   41.780945]  ... key      at: [<c124d620>] netdev_xmit_lock_key+0x38/0x1c8
      [   41.788192]  ... acquired at:
      [   41.791309]    [<c007bed8>] lock_acquire+0x70/0x90
      [   41.796361]    [<c06f9140>] _raw_spin_lock_irqsave+0x40/0x54
      [   41.802324]    [<bf083bc8>] arcnet_send_packet+0x60/0x1c0 [arcnet]
      [   41.808844]    [<c06b9380>] packet_direct_xmit+0x130/0x1c8
      [   41.814622]    [<c06bc7e4>] packet_sendmsg+0x3b8/0x680
      [   41.820034]    [<c05fe8b0>] sock_sendmsg+0x14/0x24
      [   41.825091]    [<c05ffd68>] SyS_sendto+0xb8/0xe0
      [   41.829956]    [<c05ffda8>] SyS_send+0x18/0x20
      [   41.834638]    [<c000f780>] ret_fast_syscall+0x0/0x1c
      [   41.839954]
      [   41.841514]
      the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock:
      [   41.850302] -> (&(&lp->lock)->rlock){+.+...} ops: 5 {
      [   41.855644]    HARDIRQ-ON-W at:
      [   41.858945]                     [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.865726]                     [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
      [   41.873607]                     [<c0089120>] handle_nested_irq+0x8c/0xec
      [   41.880666]                     [<c03c1170>] regmap_irq_thread+0x190/0x314
      [   41.887901]                     [<c0087244>] irq_thread_fn+0x1c/0x34
      [   41.894593]                     [<c0087548>] irq_thread+0x13c/0x1dc
      [   41.901195]                     [<c0050f10>] kthread+0xe4/0xf8
      [   41.907338]                     [<c000f810>] ret_from_fork+0x14/0x24
      [   41.914025]    SOFTIRQ-ON-W at:
      [   41.917328]                     [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.924106]                     [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
      [   41.931981]                     [<c0089120>] handle_nested_irq+0x8c/0xec
      [   41.939028]                     [<c03c1170>] regmap_irq_thread+0x190/0x314
      [   41.946264]                     [<c0087244>] irq_thread_fn+0x1c/0x34
      [   41.952954]                     [<c0087548>] irq_thread+0x13c/0x1dc
      [   41.959548]                     [<c0050f10>] kthread+0xe4/0xf8
      [   41.965689]                     [<c000f810>] ret_from_fork+0x14/0x24
      [   41.972379]    INITIAL USE at:
      [   41.975595]                    [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.982283]                    [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
      [   41.990063]                    [<c0089120>] handle_nested_irq+0x8c/0xec
      [   41.997027]                    [<c03c1170>] regmap_irq_thread+0x190/0x314
      [   42.004172]                    [<c0087244>] irq_thread_fn+0x1c/0x34
      [   42.010766]                    [<c0087548>] irq_thread+0x13c/0x1dc
      [   42.017267]                    [<c0050f10>] kthread+0xe4/0xf8
      [   42.023314]                    [<c000f810>] ret_from_fork+0x14/0x24
      [   42.029903]  }
      [   42.031648]  ... key      at: [<bf0854cc>] __key.42091+0x0/0xfffff0f8 [arcnet]
      [   42.039255]  ... acquired at:
      [   42.042372]    [<c007bed8>] lock_acquire+0x70/0x90
      [   42.047413]    [<c06f9140>] _raw_spin_lock_irqsave+0x40/0x54
      [   42.053364]    [<bf083bc8>] arcnet_send_packet+0x60/0x1c0 [arcnet]
      [   42.059872]    [<c06b9380>] packet_direct_xmit+0x130/0x1c8
      [   42.065634]    [<c06bc7e4>] packet_sendmsg+0x3b8/0x680
      [   42.071030]    [<c05fe8b0>] sock_sendmsg+0x14/0x24
      [   42.076069]    [<c05ffd68>] SyS_sendto+0xb8/0xe0
      [   42.080926]    [<c05ffda8>] SyS_send+0x18/0x20
      [   42.085601]    [<c000f780>] ret_fast_syscall+0x0/0x1c
      [   42.090918]
      [   42.092481]
      [   42.092481] stack backtrace:
      [   42.097065] CPU: 0 PID: 233 Comm: arcecho Not tainted 4.4.0-00034-gc0ae784 #536
      [   42.104751] Hardware name: Generic AM33XX (Flattened Device Tree)
      [   42.111183] [<c0017ec8>] (unwind_backtrace) from [<c00139d0>] (show_stack+0x10/0x14)
      [   42.119337] [<c00139d0>] (show_stack) from [<c02a82c4>] (dump_stack+0x8c/0x9c)
      [   42.126937] [<c02a82c4>] (dump_stack) from [<c0078260>] (check_usage+0x4bc/0x63c)
      [   42.134815] [<c0078260>] (check_usage) from [<c0078438>] (check_irq_usage+0x58/0xb0)
      [   42.142964] [<c0078438>] (check_irq_usage) from [<c007aaa0>] (__lock_acquire+0x1524/0x20b0)
      [   42.151740] [<c007aaa0>] (__lock_acquire) from [<c007bed8>] (lock_acquire+0x70/0x90)
      [   42.159886] [<c007bed8>] (lock_acquire) from [<c06f9140>] (_raw_spin_lock_irqsave+0x40/0x54)
      [   42.168768] [<c06f9140>] (_raw_spin_lock_irqsave) from [<bf083bc8>] (arcnet_send_packet+0x60/0x1c0 [arcnet])
      [   42.179115] [<bf083bc8>] (arcnet_send_packet [arcnet]) from [<c06b9380>] (packet_direct_xmit+0x130/0x1c8)
      [   42.189182] [<c06b9380>] (packet_direct_xmit) from [<c06bc7e4>] (packet_sendmsg+0x3b8/0x680)
      [   42.198059] [<c06bc7e4>] (packet_sendmsg) from [<c05fe8b0>] (sock_sendmsg+0x14/0x24)
      [   42.206199] [<c05fe8b0>] (sock_sendmsg) from [<c05ffd68>] (SyS_sendto+0xb8/0xe0)
      [   42.213978] [<c05ffd68>] (SyS_sendto) from [<c05ffda8>] (SyS_send+0x18/0x20)
      [   42.221388] [<c05ffda8>] (SyS_send) from [<c000f780>] (ret_fast_syscall+0x0/0x1c)
      Signed-off-by: default avatarMichael Grzeschik <m.grzeschik@pengutronix.de>
      
         ---
         v1 -> v2: removed unneeded zero assignment of flags
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b858403
    • Dan Carpenter's avatar
      rocker: move dereference before free · acb4b7df
      Dan Carpenter authored
      My static checker complains that ofdpa_neigh_del() can sometimes free
      "found".   It just makes sense to use it first before deleting it.
      
      Fixes: ecf244f7 ("rocker: fix maybe-uninitialized warning")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      acb4b7df
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Fix NULL pointer dereference · 6b27c8ad
      Ido Schimmel authored
      In case a VLAN device is enslaved to a bridge we shouldn't create a
      router interface (RIF) for it when it's configured with an IP address.
      This is already handled by the driver for other types of netdevs, such
      as physical ports and LAG devices.
      
      If this IP address is then removed and the interface is subsequently
      unlinked from the bridge, a NULL pointer dereference can happen, as the
      original 802.1d FID was replaced with an rFID which was then deleted.
      
      To reproduce:
      $ ip link set dev enp3s0np9 up
      $ ip link add name enp3s0np9.111 link enp3s0np9 type vlan id 111
      $ ip link set dev enp3s0np9.111 up
      $ ip link add name br0 type bridge
      $ ip link set dev br0 up
      $ ip link set enp3s0np9.111 master br0
      $ ip address add dev enp3s0np9.111 192.168.0.1/24
      $ ip address del dev enp3s0np9.111 192.168.0.1/24
      $ ip link set dev enp3s0np9.111 nomaster
      
      Fixes: 99724c18 ("mlxsw: spectrum: Introduce support for router interfaces")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-by: default avatarPetr Machata <petrm@mellanox.com>
      Tested-by: default avatarPetr Machata <petrm@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b27c8ad
    • Gao Feng's avatar
      net: sched: Fix one possible panic when no destroy callback · c1a4872e
      Gao Feng authored
      When qdisc fail to init, qdisc_create would invoke the destroy callback
      to cleanup. But there is no check if the callback exists really. So it
      would cause the panic if there is no real destroy callback like the qdisc
      codel, fq, and so on.
      
      Take codel as an example following:
      When a malicious user constructs one invalid netlink msg, it would cause
      codel_init->codel_change->nla_parse_nested failed.
      Then kernel would invoke the destroy callback directly but qdisc codel
      doesn't define one. It causes one panic as a result.
      
      Now add one the check for destroy to avoid the possible panic.
      
      Fixes: 87b60cfa ("net_sched: fix error recovery at qdisc creation")
      Signed-off-by: default avatarGao Feng <gfree.wind@vip.163.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c1a4872e
    • Jason Wang's avatar
      virtio-net: serialize tx routine during reset · 713a98d9
      Jason Wang authored
      We don't hold any tx lock when trying to disable TX during reset, this
      would lead a use after free since ndo_start_xmit() tries to access
      the virtqueue which has already been freed. Fix this by using
      netif_tx_disable() before freeing the vqs, this could make sure no tx
      after vq freeing.
      Reported-by: default avatarJean-Philippe Menil <jpmenil@gmail.com>
      Tested-by: default avatarJean-Philippe Menil <jpmenil@gmail.com>
      Fixes commit f600b690 ("virtio_net: Add XDP support")
      Cc: John Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarRobert McCabe <robert.mccabe@rockwellcollins.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      713a98d9
    • Steven Rostedt (VMware)'s avatar
      ftrace: Fix regression with module command in stack_trace_filter · 0f179765
      Steven Rostedt (VMware) authored
      When doing the following command:
      
       # echo ":mod:kvm_intel" > /sys/kernel/tracing/stack_trace_filter
      
      it triggered a crash.
      
      This happened with the clean up of probes. It required all callers to the
      regex function (doing ftrace filtering) to have ops->private be a pointer to
      a trace_array. But for the stack tracer, that is not the case.
      
      Allow for the ops->private to be NULL, and change the function command
      callbacks to handle the trace_array pointer being NULL as well.
      
      Fixes: d2afd57a ("tracing/ftrace: Allow instances to have their own function probes")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      0f179765
    • Brian Norris's avatar
      Revert "pinctrl: rockchip: avoid hardirq-unsafe functions in irq_chip" · 1d80df93
      Brian Norris authored
      This reverts commit 88bb9421.
      
      It introduced a new CONFIG_DEBUG_ATOMIC_SLEEP warning in v4.12-rc1:
      
      [ 7226.716713] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
      [ 7226.716716] in_atomic(): 0, irqs_disabled(): 0, pid: 1708, name: bash
      [ 7226.716722] CPU: 1 PID: 1708 Comm: bash Not tainted 4.12.0-rc6+ #1213
      [ 7226.716724] Hardware name: Google Kevin (DT)
      [ 7226.716726] Call trace:
      [ 7226.716738] [<ffffff8008089928>] dump_backtrace+0x0/0x24c
      [ 7226.716743] [<ffffff8008089b94>] show_stack+0x20/0x28
      [ 7226.716749] [<ffffff8008371370>] dump_stack+0x90/0xb0
      [ 7226.716755] [<ffffff80080cd2a0>] ___might_sleep+0x10c/0x124
      [ 7226.716760] [<ffffff80080cd330>] __might_sleep+0x78/0x88
      [ 7226.716765] [<ffffff800879e210>] mutex_lock+0x2c/0x64
      [ 7226.716771] [<ffffff80083ad678>] rockchip_irq_bus_lock+0x30/0x3c
      [ 7226.716777] [<ffffff80080f6d40>] __irq_get_desc_lock+0x78/0x98
      [ 7226.716782] [<ffffff80080f7e6c>] irq_set_irq_wake+0x44/0x12c
      [ 7226.716787] [<ffffff8008486e18>] dev_pm_arm_wake_irq+0x4c/0x58
      [ 7226.716792] [<ffffff800848b80c>] device_wakeup_arm_wake_irqs+0x3c/0x58
      [ 7226.716796] [<ffffff80084896fc>] dpm_suspend_noirq+0xf8/0x3a0
      [ 7226.716800] [<ffffff80080f1384>] suspend_devices_and_enter+0x1a4/0x9a8
      [ 7226.716803] [<ffffff80080f21ec>] pm_suspend+0x664/0x6a4
      [ 7226.716807] [<ffffff80080f04d8>] state_store+0xd4/0xf8
      ...
      
      It was reported on -rc1, and it's still not fixed in -rc6, so it should
      just be reverted.
      
      Cc: John Keeping <john@metanate.com>
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Reviewed-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      1d80df93
    • Hans de Goede's avatar
      gpio: acpi: Skip _AEI entries without a handler rather then aborting the scan · c06632ea
      Hans de Goede authored
      acpi_walk_resources will stop as soon as the callback passed in returns
      an error status. On a x86 tablet I have the first GpioInt in the _AEI
      resource list has no handler defined in the DSDT, causing
      acpi_walk_resources to abort scanning the rest of the resource list,
      which does define valid ACPI GPIO events.
      
      This commit changes the return for not finding a handler from
      AE_BAD_PARAMETER to AE_OK so that the rest of the resource list will
      get scanned normally in case of missing event handlers.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      c06632ea
    • Bartosz Golaszewski's avatar
      gpiolib: fix filtering out unwanted events · ad537b82
      Bartosz Golaszewski authored
      GPIOEVENT_REQUEST_BOTH_EDGES is not a single flag, but a binary OR of
      GPIOEVENT_REQUEST_RISING_EDGE and GPIOEVENT_REQUEST_FALLING_EDGE.
      
      The expression 'le->eflags & GPIOEVENT_REQUEST_BOTH_EDGES' we'll get
      evaluated to true even if only one event type was requested.
      
      Fix it by checking both RISING & FALLING flags explicitly.
      
      Cc: stable@vger.kernel.org
      Fixes: 61f922db ("gpio: userspace ABI for reading GPIO line events")
      Signed-off-by: default avatarBartosz Golaszewski <brgl@bgdev.pl>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      ad537b82
  5. 28 Jun, 2017 2 commits
    • Tobias Klauser's avatar
      arch: remove unused macro/function thread_saved_pc() · 6474924e
      Tobias Klauser authored
      The only user of thread_saved_pc() in non-arch-specific code was removed
      in commit 8243d559 ("sched/core: Remove pointless printout in
      sched_show_task()").  Remove the implementations as well.
      
      Some architectures use thread_saved_pc() in their arch-specific code.
      Leave their thread_saved_pc() intact.
      Signed-off-by: default avatarTobias Klauser <tklauser@distanz.ch>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6474924e
    • Jens Axboe's avatar
      block: provide bio_uninit() free freeing integrity/task associations · 9ae3b3f5
      Jens Axboe authored
      Wen reports significant memory leaks with DIF and O_DIRECT:
      
      "With nvme devive + T10 enabled, On a system it has 256GB and started
      logging /proc/meminfo & /proc/slabinfo for every minute and in an hour
      it increased by 15968128 kB or ~15+GB.. Approximately 256 MB / minute
      leaking.
      
      /proc/meminfo | grep SUnreclaim...
      
      SUnreclaim:      6752128 kB
      SUnreclaim:      6874880 kB
      SUnreclaim:      7238080 kB
      ....
      SUnreclaim:     22307264 kB
      SUnreclaim:     22485888 kB
      SUnreclaim:     22720256 kB
      
      When testcases with T10 enabled call into __blkdev_direct_IO_simple,
      code doesn't free memory allocated by bio_integrity_alloc. The patch
      fixes the issue. HTX has been run with +60 hours without failure."
      
      Since __blkdev_direct_IO_simple() allocates the bio on the stack, it
      doesn't go through the regular bio free. This means that any ancillary
      data allocated with the bio through the stack is not freed. Hence, we
      can leak the integrity data associated with the bio, if the device is
      using DIF/DIX.
      
      Fix this by providing a bio_uninit() and export it, so that we can use
      it to free this data. Note that this is a minimal fix for this issue.
      Any current user of bio's that are allocated outside of
      bio_alloc_bioset() suffers from this issue, most notably some drivers.
      We will fix those in a more comprehensive patch for 4.13. This also
      means that the commit marked as being fixed by this isn't the real
      culprit, it's just the most obvious one out there.
      
      Fixes: 542ff7bf ("block: new direct I/O implementation")
      Reported-by: default avatarWen Xiong <wenxiong@linux.vnet.ibm.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      9ae3b3f5