1. 13 Jun, 2017 40 commits
    • Liam Breck's avatar
      power: supply: bq24190_charger: Fix irq trigger to IRQF_TRIGGER_FALLING · 0ba15a28
      Liam Breck authored
      [ Upstream commit 767eee36 ]
      
      The interrupt signal is TRIGGER_FALLING. This is is specified in the
      data sheet PIN FUNCTIONS: "The INT pin sends active low, 256us
      pulse to host to report charger device status and fault."
      
      Also the direction can be seen in the data sheet Figure 37 "BQ24190
      with D+/D- Detection and USB On-The-Go (OTG)" which shows a 10k
      pull-up resistor installed for the sample configurations.
      
      Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
      Signed-off-by: default avatarLiam Breck <kernel@networkimprov.net>
      Acked-by: default avatarMark Greer <mgreer@animalcreek.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0ba15a28
    • Michael Ellerman's avatar
      powerpc/powernv: Fix opal_exit tracepoint opcode · ab1b6423
      Michael Ellerman authored
      [ Upstream commit a7e0fb6c ]
      
      Currently the opal_exit tracepoint usually shows the opcode as 0:
      
        <idle>-0     [047] d.h.   635.654292: opal_entry: opcode=63
        <idle>-0     [047] d.h.   635.654296: opal_exit: opcode=0 retval=0
        kopald-1209  [019] d...   636.420943: opal_entry: opcode=10
        kopald-1209  [019] d...   636.420959: opal_exit: opcode=0 retval=0
      
      This is because we incorrectly load the opcode into r0 before calling
      __trace_opal_exit(), whereas it expects the opcode in r3 (first function
      parameter). In fact we are leaving the retval in r3, so opcode and
      retval will always show the same value.
      
      Instead load the opcode into r3, resulting in:
      
        <idle>-0     [040] d.h.   636.618625: opal_entry: opcode=63
        <idle>-0     [040] d.h.   636.618627: opal_exit: opcode=63 retval=0
      
      Fixes: c49f6353 ("powernv: Add OPAL tracepoints")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ab1b6423
    • Ben Hutchings's avatar
      cpupower: Fix turbo frequency reporting for pre-Sandy Bridge cores · 5d1767ce
      Ben Hutchings authored
      [ Upstream commit 4cca0457 ]
      
      The switch that conditionally sets CPUPOWER_CAP_HAS_TURBO_RATIO and
      CPUPOWER_CAP_IS_SNB flags is missing a break, so all cores get both
      flags set and an assumed base clock of 100 MHz for turbo values.
      Reported-by: default avatarGSR <gsr.bugs@infernal-iceberg.com>
      Tested-by: default avatarGSR <gsr.bugs@infernal-iceberg.com>
      References: https://bugs.debian.org/859978
      Fixes: 8fb2e440 (cpupower: Show Intel turbo ratio support via ...)
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5d1767ce
    • Cong Wang's avatar
      9p: fix a potential acl leak · 16968228
      Cong Wang authored
      [ Upstream commit b5c66bab ]
      
      posix_acl_update_mode() could possibly clear 'acl', if so we leak the
      memory pointed by 'acl'.  Save this pointer before calling
      posix_acl_update_mode() and release the memory if 'acl' really gets
      cleared.
      
      Link: http://lkml.kernel.org/r/1486678332-2430-1-git-send-email-xiyou.wangcong@gmail.comSigned-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reported-by: default avatarMark Salyzyn <salyzyn@android.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarGreg Kurz <groug@kaod.org>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Ron Minnich <rminnich@sandia.gov>
      Cc: Latchesar Ionkov <lucho@ionkov.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      16968228
    • Arnd Bergmann's avatar
      net: tg3: avoid uninitialized variable warning · c41e1ba8
      Arnd Bergmann authored
      [ Upstream commit e434e041 ]
      
      The tg3_set_eeprom() function correctly initializes the 'start' variable,
      but gcc generates a false warning:
      
      drivers/net/ethernet/broadcom/tg3.c: In function 'tg3_set_eeprom':
      drivers/net/ethernet/broadcom/tg3.c:12057:4: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      I have not come up with a way to restructure the code in a way that
      avoids the warning without making it less readable, so this adds an
      initialization for the declaration to shut up that warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c41e1ba8
    • Arnd Bergmann's avatar
      mtd: avoid stack overflow in MTD CFI code · 95660aa2
      Arnd Bergmann authored
      [ Upstream commit fddcca51 ]
      
      When map_word gets too large, we use a lot of kernel stack, and for
      MTD_MAP_BANK_WIDTH_32, this means we use more than the recommended
      1024 bytes in a number of functions:
      
      drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers':
      drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1336 bytes is larger than 1024 bytes [-Wframe-larger-than=]
      drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_erase_varsize':
      drivers/mtd/chips/cfi_cmdset_0020.c:972:1: warning: the frame size of 1208 bytes is larger than 1024 bytes [-Wframe-larger-than=]
      drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer':
      drivers/mtd/chips/cfi_cmdset_0001.c:1835:1: warning: the frame size of 1240 bytes is larger than 1024 bytes [-Wframe-larger-than=]
      
      This can be avoided if all operations on the map word are done
      indirectly and the stack gets reused between the calls. We can
      mostly achieve this by selecting MTD_COMPLEX_MAPPINGS whenever
      MTD_MAP_BANK_WIDTH_32 is set, but for the case that no other
      bank width is enabled, we also need to use a non-constant
      map_bankwidth() to convince the compiler to use less stack.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      [Brian: this patch mostly achieves its goal by forcing
          MTD_COMPLEX_MAPPINGS (and the accompanying indirection) for 256-bit
          mappings; the rest of the change is mostly a wash, though it helps
          reduce stack size slightly. If we really care about supporting
          256-bit mappings though, we should consider rewriting some of this
          code to avoid keeping and assigning so many 256-bit objects on the
          stack.]
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      95660aa2
    • Lars Ellenberg's avatar
      drbd: avoid redefinition of BITS_PER_PAGE · b9e4b97e
      Lars Ellenberg authored
      [ Upstream commit 2630628b ]
      
      Apparently we now implicitly get definitions for BITS_PER_PAGE and
      BITS_PER_PAGE_MASK from the pid_namespace.h
      
      Instead of renaming our defines, I chose to define only if not yet
      defined, but to double check the value if already defined.
      Signed-off-by: default avatarPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: default avatarLars Ellenberg <lars.ellenberg@linbit.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b9e4b97e
    • Arnd Bergmann's avatar
      ALSA: ppc/awacs: shut up maybe-uninitialized warning · 1de253cb
      Arnd Bergmann authored
      [ Upstream commit b268c34e ]
      
      The awacs sound driver produces a false-positive warning in ppc64_defconfig:
      
      sound/ppc/awacs.c: In function 'snd_pmac_awacs_init':
      include/sound/control.h:219:9: warning: 'master_vol' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      I haven't come up with a good way to rewrite the code to avoid the
      warning, so here is a bad one: I initialize the variable before
      the conditionall initialization so gcc no longer has to worry about
      it.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1de253cb
    • Thomas Gleixner's avatar
      timerfd: Protect the might cancel mechanism proper · db144641
      Thomas Gleixner authored
      [ Upstream commit 1e38da30 ]
      
      The handling of the might_cancel queueing is not properly protected, so
      parallel operations on the file descriptor can race with each other and
      lead to list corruptions or use after free.
      
      Protect the context for these operations with a seperate lock.
      
      The wait queue lock cannot be reused for this because that would create a
      lock inversion scenario vs. the cancel lock. Replacing might_cancel with an
      atomic (atomic_t or atomic bit) does not help either because it still can
      race vs. the actual list operation.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: "linux-fsdevel@vger.kernel.org"
      Cc: syzkaller <syzkaller@googlegroups.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311521430.3457@nanosSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      db144641
    • Josh Poimboeuf's avatar
      ftrace/x86: Fix triple fault with graph tracing and suspend-to-ram · 11d54db4
      Josh Poimboeuf authored
      [ Upstream commit 34a477e5 ]
      
      On x86-32, with CONFIG_FIRMWARE and multiple CPUs, if you enable function
      graph tracing and then suspend to RAM, it will triple fault and reboot when
      it resumes.
      
      The first fault happens when booting a secondary CPU:
      
      startup_32_smp()
        load_ucode_ap()
          prepare_ftrace_return()
            ftrace_graph_is_dead()
              (accesses 'kill_ftrace_graph')
      
      The early head_32.S code calls into load_ucode_ap(), which has an an
      ftrace hook, so it calls prepare_ftrace_return(), which calls
      ftrace_graph_is_dead(), which tries to access the global
      'kill_ftrace_graph' variable with a virtual address, causing a fault
      because the CPU is still in real mode.
      
      The fix is to add a check in prepare_ftrace_return() to make sure it's
      running in protected mode before continuing.  The check makes sure the
      stack pointer is a virtual kernel address.  It's a bit of a hack, but
      it's not very intrusive and it works well enough.
      
      For reference, here are a few other (more difficult) ways this could
      have potentially been fixed:
      
      - Move startup_32_smp()'s call to load_ucode_ap() down to *after* paging
        is enabled.  (No idea what that would break.)
      
      - Track down load_ucode_ap()'s entire callee tree and mark all the
        functions 'notrace'.  (Probably not realistic.)
      
      - Pause graph tracing in ftrace_suspend_notifier_call() or bringup_cpu()
        or __cpu_up(), and ensure that the pause facility can be queried from
        real mode.
      Reported-by: default avatarPaul Menzel <pmenzel@molgen.mpg.de>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Tested-by: default avatarPaul Menzel <pmenzel@molgen.mpg.de>
      Reviewed-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>
      Cc: linux-acpi@vger.kernel.org
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: stable@kernel.org
      Cc: Len Brown <lenb@kernel.org>
      Link: http://lkml.kernel.org/r/5c1272269a580660703ed2eccf44308e790c7a98.1492123841.git.jpoimboe@redhat.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      11d54db4
    • Jamie Bainbridge's avatar
      ipv6: check raw payload size correctly in ioctl · 77ded373
      Jamie Bainbridge authored
      [ Upstream commit 105f5528 ]
      
      In situations where an skb is paged, the transport header pointer and
      tail pointer can be the same because the skb contents are in frags.
      
      This results in ioctl(SIOCINQ/FIONREAD) incorrectly returning a
      length of 0 when the length to receive is actually greater than zero.
      
      skb->len is already correctly set in ip6_input_finish() with
      pskb_pull(), so use skb->len as it always returns the correct result
      for both linear and paged data.
      Signed-off-by: default avatarJamie Bainbridge <jbainbri@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      77ded373
    • Nikolay Aleksandrov's avatar
      ip6mr: fix notification device destruction · 0c8f1722
      Nikolay Aleksandrov authored
      [ Upstream commit 723b929c ]
      
      Andrey Konovalov reported a BUG caused by the ip6mr code which is caused
      because we call unregister_netdevice_many for a device that is already
      being destroyed. In IPv4's ipmr that has been resolved by two commits
      long time ago by introducing the "notify" parameter to the delete
      function and avoiding the unregister when called from a notifier, so
      let's do the same for ip6mr.
      
      The trace from Andrey:
      ------------[ cut here ]------------
      kernel BUG at net/core/dev.c:6813!
      invalid opcode: 0000 [#1] SMP KASAN
      Modules linked in:
      CPU: 1 PID: 1165 Comm: kworker/u4:3 Not tainted 4.11.0-rc7+ #251
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
      01/01/2011
      Workqueue: netns cleanup_net
      task: ffff880069208000 task.stack: ffff8800692d8000
      RIP: 0010:rollback_registered_many+0x348/0xeb0 net/core/dev.c:6813
      RSP: 0018:ffff8800692de7f0 EFLAGS: 00010297
      RAX: ffff880069208000 RBX: 0000000000000002 RCX: 0000000000000001
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88006af90569
      RBP: ffff8800692de9f0 R08: ffff8800692dec60 R09: 0000000000000000
      R10: 0000000000000006 R11: 0000000000000000 R12: ffff88006af90070
      R13: ffff8800692debf0 R14: dffffc0000000000 R15: ffff88006af90000
      FS:  0000000000000000(0000) GS:ffff88006cb00000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fe7e897d870 CR3: 00000000657e7000 CR4: 00000000000006e0
      Call Trace:
       unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
       unregister_netdevice_many+0xc8/0x120 net/core/dev.c:7880
       ip6mr_device_event+0x362/0x3f0 net/ipv6/ip6mr.c:1346
       notifier_call_chain+0x145/0x2f0 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394
       raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1647
       call_netdevice_notifiers net/core/dev.c:1663
       rollback_registered_many+0x919/0xeb0 net/core/dev.c:6841
       unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
       unregister_netdevice_many net/core/dev.c:7880
       default_device_exit_batch+0x4fa/0x640 net/core/dev.c:8333
       ops_exit_list.isra.4+0x100/0x150 net/core/net_namespace.c:144
       cleanup_net+0x5a8/0xb40 net/core/net_namespace.c:463
       process_one_work+0xc04/0x1c10 kernel/workqueue.c:2097
       worker_thread+0x223/0x19c0 kernel/workqueue.c:2231
       kthread+0x35e/0x430 kernel/kthread.c:231
       ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
      Code: 3c 32 00 0f 85 70 0b 00 00 48 b8 00 02 00 00 00 00 ad de 49 89
      47 78 e9 93 fe ff ff 49 8d 57 70 49 8d 5f 78 eb 9e e8 88 7a 14 fe <0f>
      0b 48 8b 9d 28 fe ff ff e8 7a 7a 14 fe 48 b8 00 00 00 00 00
      RIP: rollback_registered_many+0x348/0xeb0 RSP: ffff8800692de7f0
      ---[ end trace e0b29c57e9b3292c ]---
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0c8f1722
    • Tushar Dave's avatar
      netpoll: Check for skb->queue_mapping · 7f4ab2ce
      Tushar Dave authored
      [ Upstream commit c70b17b7 ]
      
      Reducing real_num_tx_queues needs to be in sync with skb queue_mapping
      otherwise skbs with queue_mapping greater than real_num_tx_queues
      can be sent to the underlying driver and can result in kernel panic.
      
      One such event is running netconsole and enabling VF on the same
      device. Or running netconsole and changing number of tx queues via
      ethtool on same device.
      
      e.g.
      Unable to handle kernel NULL pointer dereference
      tsk->{mm,active_mm}->context = 0000000000001525
      tsk->{mm,active_mm}->pgd = fff800130ff9a000
                    \|/ ____ \|/
                    "@'/ .. \`@"
                    /_| \__/ |_\
                       \__U_/
      kworker/48:1(475): Oops [#1]
      CPU: 48 PID: 475 Comm: kworker/48:1 Tainted: G           OE
      4.11.0-rc3-davem-net+ #7
      Workqueue: events queue_process
      task: fff80013113299c0 task.stack: fff800131132c000
      TSTATE: 0000004480e01600 TPC: 00000000103f9e3c TNPC: 00000000103f9e40 Y:
      00000000    Tainted: G           OE
      TPC: <ixgbe_xmit_frame_ring+0x7c/0x6c0 [ixgbe]>
      g0: 0000000000000000 g1: 0000000000003fff g2: 0000000000000000 g3:
      0000000000000001
      g4: fff80013113299c0 g5: fff8001fa6808000 g6: fff800131132c000 g7:
      00000000000000c0
      o0: fff8001fa760c460 o1: fff8001311329a50 o2: fff8001fa7607504 o3:
      0000000000000003
      o4: fff8001f96e63a40 o5: fff8001311d77ec0 sp: fff800131132f0e1 ret_pc:
      000000000049ed94
      RPC: <set_next_entity+0x34/0xb80>
      l0: 0000000000000000 l1: 0000000000000800 l2: 0000000000000000 l3:
      0000000000000000
      l4: 000b2aa30e34b10d l5: 0000000000000000 l6: 0000000000000000 l7:
      fff8001fa7605028
      i0: fff80013111a8a00 i1: fff80013155a0780 i2: 0000000000000000 i3:
      0000000000000000
      i4: 0000000000000000 i5: 0000000000100000 i6: fff800131132f1a1 i7:
      00000000103fa4b0
      I7: <ixgbe_xmit_frame+0x30/0xa0 [ixgbe]>
      Call Trace:
       [00000000103fa4b0] ixgbe_xmit_frame+0x30/0xa0 [ixgbe]
       [0000000000998c74] netpoll_start_xmit+0xf4/0x200
       [0000000000998e10] queue_process+0x90/0x160
       [0000000000485fa8] process_one_work+0x188/0x480
       [0000000000486410] worker_thread+0x170/0x4c0
       [000000000048c6b8] kthread+0xd8/0x120
       [0000000000406064] ret_from_fork+0x1c/0x2c
       [0000000000000000]           (null)
      Disabling lock debugging due to kernel taint
      Caller[00000000103fa4b0]: ixgbe_xmit_frame+0x30/0xa0 [ixgbe]
      Caller[0000000000998c74]: netpoll_start_xmit+0xf4/0x200
      Caller[0000000000998e10]: queue_process+0x90/0x160
      Caller[0000000000485fa8]: process_one_work+0x188/0x480
      Caller[0000000000486410]: worker_thread+0x170/0x4c0
      Caller[000000000048c6b8]: kthread+0xd8/0x120
      Caller[0000000000406064]: ret_from_fork+0x1c/0x2c
      Caller[0000000000000000]:           (null)
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7f4ab2ce
    • Xin Long's avatar
      sctp: listen on the sock only when it's state is listening or closed · 74c4460b
      Xin Long authored
      [ Upstream commit 34b2789f ]
      
      Now sctp doesn't check sock's state before listening on it. It could
      even cause changing a sock with any state to become a listening sock
      when doing sctp_listen.
      
      This patch is to fix it by checking sock's state in sctp_listen, so
      that it will listen on the sock with right state.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      74c4460b
    • Florian Larysch's avatar
      net: ipv4: fix multipath RTM_GETROUTE behavior when iif is given · 7d1a0fdd
      Florian Larysch authored
      [ Upstream commit a8801799 ]
      
      inet_rtm_getroute synthesizes a skeletal ICMP skb, which is passed to
      ip_route_input when iif is given. If a multipath route is present for
      the designated destination, ip_multipath_icmp_hash ends up being called,
      which uses the source/destination addresses within the skb to calculate
      a hash. However, those are not set in the synthetic skb, causing it to
      return an arbitrary and incorrect result.
      
      Instead, use UDP, which gets no such special treatment.
      Signed-off-by: default avatarFlorian Larysch <fl@n621.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7d1a0fdd
    • Guillaume Nault's avatar
      l2tp: take reference on sessions being dumped · 6824dcd3
      Guillaume Nault authored
      [ Upstream commit e08293a4 ]
      
      Take a reference on the sessions returned by l2tp_session_find_nth()
      (and rename it l2tp_session_get_nth() to reflect this change), so that
      caller is assured that the session isn't going to disappear while
      processing it.
      
      For procfs and debugfs handlers, the session is held in the .start()
      callback and dropped in .show(). Given that pppol2tp_seq_session_show()
      dereferences the associated PPPoL2TP socket and that
      l2tp_dfs_seq_session_show() might call pppol2tp_show(), we also need to
      call the session's .ref() callback to prevent the socket from going
      away from under us.
      
      Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
      Fixes: 0ad66140 ("l2tp: Add debugfs files for dumping l2tp debug info")
      Fixes: 309795f4 ("l2tp: Add netlink control API for L2TP")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6824dcd3
    • Andrey Konovalov's avatar
      net/packet: fix overflow in check for tp_reserve · cc09115f
      Andrey Konovalov authored
      [ Upstream commit bcc5364b ]
      
      When calculating po->tp_hdrlen + po->tp_reserve the result can overflow.
      
      Fix by checking that tp_reserve <= INT_MAX on assign.
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      cc09115f
    • Andrey Konovalov's avatar
      net/packet: fix overflow in check for tp_frame_nr · fed85340
      Andrey Konovalov authored
      [ Upstream commit 8f8d28e4 ]
      
      When calculating rb->frames_per_block * req->tp_block_nr the result
      can overflow.
      
      Add a check that tp_block_size * tp_block_nr <= UINT_MAX.
      
      Since frames_per_block <= tp_block_size, the expression would
      never overflow.
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      fed85340
    • Guillaume Nault's avatar
      l2tp: purge socket queues in the .destruct() callback · 9ba24021
      Guillaume Nault authored
      [ Upstream commit e91793bb ]
      
      The Rx path may grab the socket right before pppol2tp_release(), but
      nothing guarantees that it will enqueue packets before
      skb_queue_purge(). Therefore, the socket can be destroyed without its
      queues fully purged.
      
      Fix this by purging queues in pppol2tp_session_destruct() where we're
      guaranteed nothing is still referencing the socket.
      
      Fixes: 9e9cb622 ("l2tp: fix userspace reception on plain L2TP sockets")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9ba24021
    • Nathan Sullivan's avatar
      net: phy: handle state correctly in phy_stop_machine · 28bad8a6
      Nathan Sullivan authored
      [ Upstream commit 49d52e81 ]
      
      If the PHY is halted on stop, then do not set the state to PHY_UP.  This
      ensures the phy will be restarted later in phy_start when the machine is
      started again.
      
      Fixes: 00db8189 ("This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling ethernet drivers to remain as ignorant as is reasonable of the connected PHY's design and operation details.")
      Signed-off-by: default avatarNathan Sullivan <nathan.sullivan@ni.com>
      Signed-off-by: default avatarBrad Mouring <brad.mouring@ni.com>
      Acked-by: default avatarXander Huff <xander.huff@ni.com>
      Acked-by: default avatarKyle Roeschley <kyle.roeschley@ni.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      28bad8a6
    • Eric Dumazet's avatar
      net: neigh: guard against NULL solicit() method · b39245e3
      Eric Dumazet authored
      [ Upstream commit 48481c8f ]
      
      Dmitry posted a nice reproducer of a bug triggering in neigh_probe()
      when dereferencing a NULL neigh->ops->solicit method.
      
      This can happen for arp_direct_ops/ndisc_direct_ops and similar,
      which can be used for NUD_NOARP neighbours (created when dev->header_ops
      is NULL). Admin can then force changing nud_state to some other state
      that would fire neigh timer.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b39245e3
    • Tom Hromatka's avatar
      sparc64: Fix kernel panic due to erroneous #ifdef surrounding pmd_write() · 9ffb20a6
      Tom Hromatka authored
      [ Upstream commit 9ae34dbd ]
      
      This commit moves sparc64's prototype of pmd_write() outside
      of the CONFIG_TRANSPARENT_HUGEPAGE ifdef.
      
      In 2013, commit a7b9403f ("sparc64: Encode huge PMDs using PTE
      encoding.") exposed a path where pmd_write() could be called without
      CONFIG_TRANSPARENT_HUGEPAGE defined.  This can result in the panic below.
      
      The diff is awkward to read, but the changes are straightforward.
      pmd_write() was moved outside of #ifdef CONFIG_TRANSPARENT_HUGEPAGE.
      Also, __HAVE_ARCH_PMD_WRITE was defined.
      
      kernel BUG at include/asm-generic/pgtable.h:576!
                    \|/ ____ \|/
                    "@'/ .. \`@"
                    /_| \__/ |_\
                       \__U_/
      oracle_8114_cdb(8114): Kernel bad sw trap 5 [#1]
      CPU: 120 PID: 8114 Comm: oracle_8114_cdb Not tainted
      4.1.12-61.7.1.el6uek.rc1.sparc64 #1
      task: fff8400700a24d60 ti: fff8400700bc4000 task.ti: fff8400700bc4000
      TSTATE: 0000004411e01607 TPC: 00000000004609f8 TNPC: 00000000004609fc Y:
      00000005    Not tainted
      TPC: <gup_huge_pmd+0x198/0x1e0>
      g0: 000000000001c000 g1: 0000000000ef3954 g2: 0000000000000000 g3: 0000000000000001
      g4: fff8400700a24d60 g5: fff8001fa5c10000 g6: fff8400700bc4000 g7: 0000000000000720
      o0: 0000000000bc5058 o1: 0000000000000240 o2: 0000000000006000 o3: 0000000000001c00
      o4: 0000000000000000 o5: 0000048000080000 sp: fff8400700bc6ab1 ret_pc: 00000000004609f0
      RPC: <gup_huge_pmd+0x190/0x1e0>
      l0: fff8400700bc74fc l1: 0000000000020000 l2: 0000000000002000 l3: 0000000000000000
      l4: fff8001f93250950 l5: 000000000113f800 l6: 0000000000000004 l7: 0000000000000000
      i0: fff8400700ca46a0 i1: bd0000085e800453 i2: 000000026a0c4000 i3: 000000026a0c6000
      i4: 0000000000000001 i5: fff800070c958de8 i6: fff8400700bc6b61 i7: 0000000000460dd0
      I7: <gup_pud_range+0x170/0x1a0>
      Call Trace:
       [0000000000460dd0] gup_pud_range+0x170/0x1a0
       [0000000000460e84] get_user_pages_fast+0x84/0x120
       [00000000006f5a18] iov_iter_get_pages+0x98/0x240
       [00000000005fa744] do_direct_IO+0xf64/0x1e00
       [00000000005fbbc0] __blockdev_direct_IO+0x360/0x15a0
       [00000000101f74fc] ext4_ind_direct_IO+0xdc/0x400 [ext4]
       [00000000101af690] ext4_ext_direct_IO+0x1d0/0x2c0 [ext4]
       [00000000101af86c] ext4_direct_IO+0xec/0x220 [ext4]
       [0000000000553bd4] generic_file_read_iter+0x114/0x140
       [00000000005bdc2c] __vfs_read+0xac/0x100
       [00000000005bf254] vfs_read+0x54/0x100
       [00000000005bf368] SyS_pread64+0x68/0x80
      Signed-off-by: default avatarTom Hromatka <tom.hromatka@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9ffb20a6
    • bob picco's avatar
      sparc64: kern_addr_valid regression · 1acc886c
      bob picco authored
      [ Upstream commit adfae8a5 ]
      
      I encountered this bug when using /proc/kcore to examine the kernel. Plus a
      coworker inquired about debugging tools. We computed pa but did
      not use it during the maximum physical address bits test. Instead we used
      the identity mapped virtual address which will always fail this test.
      
      I believe the defect came in here:
      [bpicco@zareason linus.git]$ git describe --contains bb4e6e85
      v3.18-rc1~87^2~4
      .
      Signed-off-by: default avatarBob Picco <bob.picco@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1acc886c
    • Stefano Stabellini's avatar
      xen/x86: don't lose event interrupts · 5023f121
      Stefano Stabellini authored
      [ Upstream commit c06b6d70 ]
      
      On slow platforms with unreliable TSC, such as QEMU emulated machines,
      it is possible for the kernel to request the next event in the past. In
      that case, in the current implementation of xen_vcpuop_clockevent, we
      simply return -ETIME. To be precise the Xen returns -ETIME and we pass
      it on. However the result of this is a missed event, which simply causes
      the kernel to hang.
      
      Instead it is better to always ask the hypervisor for a timer event,
      even if the timeout is in the past. That way there are no lost
      interrupts and the kernel survives. To do that, remove the
      VCPU_SSHOTTMR_future flag.
      Signed-off-by: default avatarStefano Stabellini <sstabellini@kernel.org>
      Acked-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5023f121
    • Felipe F. Tonello's avatar
      usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize · b64d0823
      Felipe F. Tonello authored
      [ Upstream commit 03d27ade ]
      
      buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
      devices.
      
      That caused the OUT endpoint to freeze if the host send any data packet of
      length greater than 256 bytes.
      
      This is an example dump of what happended on that enpoint:
      HOST:   [DATA][Length=260][...]
      DEVICE: [NAK]
      HOST:   [PING]
      DEVICE: [NAK]
      HOST:   [PING]
      DEVICE: [NAK]
      ...
      HOST:   [PING]
      DEVICE: [NAK]
      
      This patch fixes this problem by setting the minimum usb_request's buffer size
      for the OUT endpoint as its wMaxPacketSize.
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarFelipe F. Tonello <eu@felipetonello.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b64d0823
    • santosh.shilimkar@oracle.com's avatar
      RDS: Fix the atomicity for congestion map update · e7211d1f
      santosh.shilimkar@oracle.com authored
      [ Upstream commit e47db94e ]
      
      Two different threads with different rds sockets may be in
      rds_recv_rcvbuf_delta() via receive path. If their ports
      both map to the same word in the congestion map, then
      using non-atomic ops to update it could cause the map to
      be incorrect. Lets use atomics to avoid such an issue.
      
      Full credit to Wengang <wen.gang.wang@oracle.com> for
      finding the issue, analysing it and also pointing out
      to offending code with spin lock based fix.
      Reviewed-by: default avatarLeon Romanovsky <leon@leon.nu>
      Signed-off-by: default avatarWengang Wang <wen.gang.wang@oracle.com>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e7211d1f
    • Corey Minyard's avatar
      MIPS: Fix crash registers on non-crashing CPUs · 92bf6b46
      Corey Minyard authored
      [ Upstream commit c80e1b62 ]
      
      As part of handling a crash on an SMP system, an IPI is send to
      all other CPUs to save their current registers and stop.  It was
      using task_pt_regs(current) to get the registers, but that will
      only be accurate if the CPU was interrupted running in userland.
      Instead allow the architecture to pass in the registers (all
      pass NULL now, but allow for the future) and then use get_irq_regs()
      which should be accurate as we are in an interrupt.  Fall back to
      task_pt_regs(current) if nothing else is available.
      Signed-off-by: default avatarCorey Minyard <cminyard@mvista.com>
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13050/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      92bf6b46
    • Wei Fang's avatar
      md:raid1: fix a dead loop when read from a WriteMostly disk · d0388c0e
      Wei Fang authored
      [ Upstream commit 816b0acf ]
      
      If first_bad == this_sector when we get the WriteMostly disk
      in read_balance(), valid disk will be returned with zero
      max_sectors. It'll lead to a dead loop in make_request(), and
      OOM will happen because of endless allocation of struct bio.
      
      Since we can't get data from this disk in this case, so
      continue for another disk.
      Signed-off-by: default avatarWei Fang <fangwei1@huawei.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d0388c0e
    • Jerome Marchand's avatar
      crypto: testmgr - fix out of bound read in __test_aead() · f364181f
      Jerome Marchand authored
      [ Upstream commit abfa7f43 ]
      
      __test_aead() reads MAX_IVLEN bytes from template[i].iv, but the
      actual length of the initialisation vector can be shorter.
      The length of the IV is already calculated earlier in the
      function. Let's just reuses that. Also the IV length is currently
      calculated several time for no reason. Let's fix that too.
      This fix an out-of-bound error detected by KASan.
      Signed-off-by: default avatarJerome Marchand <jmarchan@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f364181f
    • Dan Carpenter's avatar
      [media] xc2028: unlock on error in xc2028_set_config() · 9800a9a4
      Dan Carpenter authored
      [ Upstream commit 210bd104 ]
      
      We have to unlock before returning -ENOMEM.
      
      Fixes: 8dfbcc43 ('[media] xc2028: avoid use after free')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9800a9a4
    • Chao Yu's avatar
      f2fs: do more integrity verification for superblock · c5ef0e9f
      Chao Yu authored
      [ Upstream commit 9a59b62f ]
      
      Do more sanity check for superblock during ->mount.
      Signed-off-by: default avatarChao Yu <chao2.yu@samsung.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c5ef0e9f
    • Eric Dumazet's avatar
      ping: implement proper locking · 5f1cef9e
      Eric Dumazet authored
      [ Upstream commit 43a66845 ]
      
      We got a report of yet another bug in ping
      
      http://www.openwall.com/lists/oss-security/2017/03/24/6
      
      ->disconnect() is not called with socket lock held.
      
      Fix this by acquiring ping rwlock earlier.
      
      Thanks to Daniel, Alexander and Andrey for letting us know this problem.
      
      Fixes: c319b4d7 ("net: ipv4: add IPPROTO_ICMP socket kind")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDaniel Jiang <danieljiang0415@gmail.com>
      Reported-by: default avatarSolar Designer <solar@openwall.com>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5f1cef9e
    • EunTaik Lee's avatar
      staging/android/ion : fix a race condition in the ion driver · 9c90c093
      EunTaik Lee authored
      [ Upstream commit 9590232b ]
      
      There is a use-after-free problem in the ion driver.
      This is caused by a race condition in the ion_ioctl()
      function.
      
      A handle has ref count of 1 and two tasks on different
      cpus calls ION_IOC_FREE simultaneously.
      
      cpu 0                                   cpu 1
      -------------------------------------------------------
      ion_handle_get_by_id()
      (ref == 2)
                                  ion_handle_get_by_id()
                                  (ref == 3)
      
      ion_free()
      (ref == 2)
      
      ion_handle_put()
      (ref == 1)
      
                                  ion_free()
                                  (ref == 0 so ion_handle_destroy() is
                                  called
                                  and the handle is freed.)
      
                                  ion_handle_put() is called and it
                                  decreases the slub's next free pointer
      
      The problem is detected as an unaligned access in the
      spin lock functions since it uses load exclusive
       instruction. In some cases it corrupts the slub's
      free pointer which causes a mis-aligned access to the
      next free pointer.(kmalloc returns a pointer like
      ffffc0745b4580aa). And it causes lots of other
      hard-to-debug problems.
      
      This symptom is caused since the first member in the
      ion_handle structure is the reference count and the
      ion driver decrements the reference after it has been
      freed.
      
      To fix this problem client->lock mutex is extended
      to protect all the codes that uses the handle.
      Signed-off-by: default avatarEun Taik Lee <eun.taik.lee@samsung.com>
      Reviewed-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9c90c093
    • Vlad Tsyrklevich's avatar
      vfio/pci: Fix integer overflows, bitmask check · 073e9973
      Vlad Tsyrklevich authored
      [ Upstream commit 05692d70 ]
      
      The VFIO_DEVICE_SET_IRQS ioctl did not sufficiently sanitize
      user-supplied integers, potentially allowing memory corruption. This
      patch adds appropriate integer overflow checks, checks the range bounds
      for VFIO_IRQ_SET_DATA_NONE, and also verifies that only single element
      in the VFIO_IRQ_SET_DATA_TYPE_MASK bitmask is set.
      VFIO_IRQ_SET_ACTION_TYPE_MASK is already correctly checked later in
      vfio_pci_set_irqs_ioctl().
      
      Furthermore, a kzalloc is changed to a kcalloc because the use of a
      kzalloc with an integer multiplication allowed an integer overflow
      condition to be reached without this patch. kcalloc checks for overflow
      and should prevent a similar occurrence.
      Signed-off-by: default avatarVlad Tsyrklevich <vlad@tsyrklevich.net>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      073e9973
    • Mauro Carvalho Chehab's avatar
      [media] xc2028: avoid use after free · e21b00fe
      Mauro Carvalho Chehab authored
      [ Upstream commit 8dfbcc43 ]
      
      If struct xc2028_config is passed without a firmware name,
      the following trouble may happen:
      
      [11009.907205] xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner
      [11009.907491] ==================================================================
      [11009.907750] BUG: KASAN: use-after-free in strcmp+0x96/0xb0 at addr ffff8803bd78ab40
      [11009.907992] Read of size 1 by task modprobe/28992
      [11009.907994] =============================================================================
      [11009.907997] BUG kmalloc-16 (Tainted: G        W      ): kasan: bad access detected
      [11009.907999] -----------------------------------------------------------------------------
      
      [11009.908008] INFO: Allocated in xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd] age=0 cpu=3 pid=28992
      [11009.908012] 	___slab_alloc+0x581/0x5b0
      [11009.908014] 	__slab_alloc+0x51/0x90
      [11009.908017] 	__kmalloc+0x27b/0x350
      [11009.908022] 	xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd]
      [11009.908026] 	usb_hcd_submit_urb+0x1e8/0x1c60
      [11009.908029] 	usb_submit_urb+0xb0e/0x1200
      [11009.908032] 	usb_serial_generic_write_start+0xb6/0x4c0
      [11009.908035] 	usb_serial_generic_write+0x92/0xc0
      [11009.908039] 	usb_console_write+0x38a/0x560
      [11009.908045] 	call_console_drivers.constprop.14+0x1ee/0x2c0
      [11009.908051] 	console_unlock+0x40d/0x900
      [11009.908056] 	vprintk_emit+0x4b4/0x830
      [11009.908061] 	vprintk_default+0x1f/0x30
      [11009.908064] 	printk+0x99/0xb5
      [11009.908067] 	kasan_report_error+0x10a/0x550
      [11009.908070] 	__asan_report_load1_noabort+0x43/0x50
      [11009.908074] INFO: Freed in xc2028_set_config+0x90/0x630 [tuner_xc2028] age=1 cpu=3 pid=28992
      [11009.908077] 	__slab_free+0x2ec/0x460
      [11009.908080] 	kfree+0x266/0x280
      [11009.908083] 	xc2028_set_config+0x90/0x630 [tuner_xc2028]
      [11009.908086] 	xc2028_attach+0x310/0x8a0 [tuner_xc2028]
      [11009.908090] 	em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
      [11009.908094] 	em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
      [11009.908098] 	em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
      [11009.908101] 	em28xx_register_extension+0xd9/0x190 [em28xx]
      [11009.908105] 	em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
      [11009.908108] 	do_one_initcall+0x141/0x300
      [11009.908111] 	do_init_module+0x1d0/0x5ad
      [11009.908114] 	load_module+0x6666/0x9ba0
      [11009.908117] 	SyS_finit_module+0x108/0x130
      [11009.908120] 	entry_SYSCALL_64_fastpath+0x16/0x76
      [11009.908123] INFO: Slab 0xffffea000ef5e280 objects=25 used=25 fp=0x          (null) flags=0x2ffff8000004080
      [11009.908126] INFO: Object 0xffff8803bd78ab40 @offset=2880 fp=0x0000000000000001
      
      [11009.908130] Bytes b4 ffff8803bd78ab30: 01 00 00 00 2a 07 00 00 9d 28 00 00 01 00 00 00  ....*....(......
      [11009.908133] Object ffff8803bd78ab40: 01 00 00 00 00 00 00 00 b0 1d c3 6a 00 88 ff ff  ...........j....
      [11009.908137] CPU: 3 PID: 28992 Comm: modprobe Tainted: G    B   W       4.5.0-rc1+ #43
      [11009.908140] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
      [11009.908142]  ffff8803bd78a000 ffff8802c273f1b8 ffffffff81932007 ffff8803c6407a80
      [11009.908148]  ffff8802c273f1e8 ffffffff81556759 ffff8803c6407a80 ffffea000ef5e280
      [11009.908153]  ffff8803bd78ab40 dffffc0000000000 ffff8802c273f210 ffffffff8155ccb4
      [11009.908158] Call Trace:
      [11009.908162]  [<ffffffff81932007>] dump_stack+0x4b/0x64
      [11009.908165]  [<ffffffff81556759>] print_trailer+0xf9/0x150
      [11009.908168]  [<ffffffff8155ccb4>] object_err+0x34/0x40
      [11009.908171]  [<ffffffff8155f260>] kasan_report_error+0x230/0x550
      [11009.908175]  [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290
      [11009.908179]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908182]  [<ffffffff8155f5c3>] __asan_report_load1_noabort+0x43/0x50
      [11009.908185]  [<ffffffff8155ea00>] ? __asan_register_globals+0x50/0xa0
      [11009.908189]  [<ffffffff8194cea6>] ? strcmp+0x96/0xb0
      [11009.908192]  [<ffffffff8194cea6>] strcmp+0x96/0xb0
      [11009.908196]  [<ffffffffa13ba4ac>] xc2028_set_config+0x15c/0x630 [tuner_xc2028]
      [11009.908200]  [<ffffffffa13bac90>] xc2028_attach+0x310/0x8a0 [tuner_xc2028]
      [11009.908203]  [<ffffffff8155ea78>] ? memset+0x28/0x30
      [11009.908206]  [<ffffffffa13ba980>] ? xc2028_set_config+0x630/0x630 [tuner_xc2028]
      [11009.908211]  [<ffffffffa157a59a>] em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
      [11009.908215]  [<ffffffffa157aa2a>] ? em28xx_dvb_init.part.3+0x37c/0x5cf4 [em28xx_dvb]
      [11009.908219]  [<ffffffffa157a3a1>] ? hauppauge_hvr930c_init+0x487/0x487 [em28xx_dvb]
      [11009.908222]  [<ffffffffa01795ac>] ? lgdt330x_attach+0x1cc/0x370 [lgdt330x]
      [11009.908226]  [<ffffffffa01793e0>] ? i2c_read_demod_bytes.isra.2+0x210/0x210 [lgdt330x]
      [11009.908230]  [<ffffffff812e87d0>] ? ref_module.part.15+0x10/0x10
      [11009.908233]  [<ffffffff812e56e0>] ? module_assert_mutex_or_preempt+0x80/0x80
      [11009.908238]  [<ffffffffa157af92>] em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
      [11009.908242]  [<ffffffffa157a6ae>] ? em28xx_attach_xc3028.constprop.7+0x30d/0x30d [em28xx_dvb]
      [11009.908245]  [<ffffffff8195222d>] ? string+0x14d/0x1f0
      [11009.908249]  [<ffffffff8195381f>] ? symbol_string+0xff/0x1a0
      [11009.908253]  [<ffffffff81953720>] ? uuid_string+0x6f0/0x6f0
      [11009.908257]  [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0
      [11009.908260]  [<ffffffff8104b02f>] ? print_context_stack+0x7f/0xf0
      [11009.908264]  [<ffffffff812e9846>] ? __module_address+0xb6/0x360
      [11009.908268]  [<ffffffff8137fdc9>] ? is_ftrace_trampoline+0x99/0xe0
      [11009.908271]  [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0
      [11009.908275]  [<ffffffff81240a70>] ? debug_check_no_locks_freed+0x290/0x290
      [11009.908278]  [<ffffffff8104a24b>] ? dump_trace+0x11b/0x300
      [11009.908282]  [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx]
      [11009.908285]  [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290
      [11009.908289]  [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590
      [11009.908292]  [<ffffffff812404dd>] ? trace_hardirqs_on+0xd/0x10
      [11009.908296]  [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx]
      [11009.908299]  [<ffffffff822dcbb0>] ? mutex_trylock+0x400/0x400
      [11009.908302]  [<ffffffff810021a1>] ? do_one_initcall+0x131/0x300
      [11009.908306]  [<ffffffff81296dc7>] ? call_rcu_sched+0x17/0x20
      [11009.908309]  [<ffffffff8159e708>] ? put_object+0x48/0x70
      [11009.908314]  [<ffffffffa1579f11>] em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
      [11009.908317]  [<ffffffffa13e81f9>] em28xx_register_extension+0xd9/0x190 [em28xx]
      [11009.908320]  [<ffffffffa0150000>] ? 0xffffffffa0150000
      [11009.908324]  [<ffffffffa0150010>] em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
      [11009.908327]  [<ffffffff810021b1>] do_one_initcall+0x141/0x300
      [11009.908330]  [<ffffffff81002070>] ? try_to_run_init_process+0x40/0x40
      [11009.908333]  [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590
      [11009.908337]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908340]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908343]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
      [11009.908346]  [<ffffffff8155ea37>] ? __asan_register_globals+0x87/0xa0
      [11009.908350]  [<ffffffff8144da7b>] do_init_module+0x1d0/0x5ad
      [11009.908353]  [<ffffffff812f2626>] load_module+0x6666/0x9ba0
      [11009.908356]  [<ffffffff812e9c90>] ? symbol_put_addr+0x50/0x50
      [11009.908361]  [<ffffffffa1580037>] ? em28xx_dvb_init.part.3+0x5989/0x5cf4 [em28xx_dvb]
      [11009.908366]  [<ffffffff812ebfc0>] ? module_frob_arch_sections+0x20/0x20
      [11009.908369]  [<ffffffff815bc940>] ? open_exec+0x50/0x50
      [11009.908374]  [<ffffffff811671bb>] ? ns_capable+0x5b/0xd0
      [11009.908377]  [<ffffffff812f5e58>] SyS_finit_module+0x108/0x130
      [11009.908379]  [<ffffffff812f5d50>] ? SyS_init_module+0x1f0/0x1f0
      [11009.908383]  [<ffffffff81004044>] ? lockdep_sys_exit_thunk+0x12/0x14
      [11009.908394]  [<ffffffff822e6936>] entry_SYSCALL_64_fastpath+0x16/0x76
      [11009.908396] Memory state around the buggy address:
      [11009.908398]  ffff8803bd78aa00: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908401]  ffff8803bd78aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908403] >ffff8803bd78ab00: fc fc fc fc fc fc fc fc 00 00 fc fc fc fc fc fc
      [11009.908405]                                            ^
      [11009.908407]  ffff8803bd78ab80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908409]  ffff8803bd78ac00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [11009.908411] ==================================================================
      
      In order to avoid it, let's set the cached value of the firmware
      name to NULL after freeing it. While here, return an error if
      the memory allocation fails.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e21b00fe
    • Parthasarathy Bhuvaragan's avatar
      tipc: fix random link resets while adding a second bearer · c8580e3d
      Parthasarathy Bhuvaragan authored
      [ Upstream commit d2f394dc ]
      
      In a dual bearer configuration, if the second tipc link becomes
      active while the first link still has pending nametable "bulk"
      updates, it randomly leads to reset of the second link.
      
      When a link is established, the function named_distribute(),
      fills the skb based on node mtu (allows room for TUNNEL_PROTOCOL)
      with NAME_DISTRIBUTOR message for each PUBLICATION.
      However, the function named_distribute() allocates the buffer by
      increasing the node mtu by INT_H_SIZE (to insert NAME_DISTRIBUTOR).
      This consumes the space allocated for TUNNEL_PROTOCOL.
      
      When establishing the second link, the link shall tunnel all the
      messages in the first link queue including the "bulk" update.
      As size of the NAME_DISTRIBUTOR messages while tunnelling, exceeds
      the link mtu the transmission fails (-EMSGSIZE).
      
      Thus, the synch point based on the message count of the tunnel
      packets is never reached leading to link timeout.
      
      In this commit, we adjust the size of name distributor message so that
      they can be tunnelled.
      Reviewed-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarParthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c8580e3d
    • Arnd Bergmann's avatar
      gfs2: avoid uninitialized variable warning · 5eb668f8
      Arnd Bergmann authored
      [ Upstream commit 67893f12 ]
      
      We get a bogus warning about a potential uninitialized variable
      use in gfs2, because the compiler does not figure out that we
      never use the leaf number if get_leaf_nr() returns an error:
      
      fs/gfs2/dir.c: In function 'get_first_leaf':
      fs/gfs2/dir.c:802:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
      fs/gfs2/dir.c: In function 'dir_split_leaf':
      fs/gfs2/dir.c:1021:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      Changing the 'if (!error)' to 'if (!IS_ERR_VALUE(error))' is
      sufficient to let gcc understand that this is exactly the same
      condition as in IS_ERR() so it can optimize the code path enough
      to understand it.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5eb668f8
    • Arnd Bergmann's avatar
      hostap: avoid uninitialized variable use in hfa384x_get_rid · 6013c31f
      Arnd Bergmann authored
      [ Upstream commit 48dc5fb3 ]
      
      The driver reads a value from hfa384x_from_bap(), which may fail,
      and then assigns the value to a local variable. gcc detects that
      in in the failure case, the 'rlen' variable now contains
      uninitialized data:
      
      In file included from ../drivers/net/wireless/intersil/hostap/hostap_pci.c:220:0:
      drivers/net/wireless/intersil/hostap/hostap_hw.c: In function 'hfa384x_get_rid':
      drivers/net/wireless/intersil/hostap/hostap_hw.c:842:5: warning: 'rec' may be used uninitialized in this function [-Wmaybe-uninitialized]
        if (le16_to_cpu(rec.len) == 0) {
      
      This restructures the function as suggested by Russell King, to
      make it more readable and get more reliable error handling, by
      handling each failure mode using a goto.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6013c31f
    • Arnd Bergmann's avatar
      tty: nozomi: avoid a harmless gcc warning · 56c3cd09
      Arnd Bergmann authored
      [ Upstream commit a4f642a8 ]
      
      The nozomi wireless data driver has its own helper function to
      transfer data from a FIFO, doing an extra byte swap on big-endian
      architectures, presumably to bring the data back into byte-serial
      order after readw() or readl() perform their implicit byteswap.
      
      This helper function is used in the receive_data() function to
      first read the length into a 32-bit variable, which causes
      a compile-time warning:
      
      drivers/tty/nozomi.c: In function 'receive_data':
      drivers/tty/nozomi.c:857:9: warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      The problem is that gcc is unsure whether the data was actually
      read or not. We know that it is at this point, so we can replace
      it with a single readl() to shut up that warning.
      
      I am leaving the byteswap in there, to preserve the existing
      behavior, even though this seems fishy: Reading the length of
      the data into a cpu-endian variable should normally not use
      a second byteswap on big-endian systems, unless the hardware
      is aware of the CPU endianess.
      
      There appears to be a lot more confusion about endianess in this
      driver, so it probably has not worked on big-endian systems in
      a long time, if ever, and I have no way to test it. It's well
      possible that this driver has not been used by anyone in a while,
      the last patch that looks like it was tested on the hardware is
      from 2008.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      56c3cd09
    • Jon Paul Maloy's avatar
      tipc: re-enable compensation for socket receive buffer double counting · 39a978c3
      Jon Paul Maloy authored
      [ Upstream commit 7c8bcfb1 ]
      
      In the refactoring commit d570d864 ("tipc: enqueue arrived buffers
      in socket in separate function") we did by accident replace the test
      
      if (sk->sk_backlog.len == 0)
           atomic_set(&tsk->dupl_rcvcnt, 0);
      
      with
      
      if (sk->sk_backlog.len)
           atomic_set(&tsk->dupl_rcvcnt, 0);
      
      This effectively disables the compensation we have for the double
      receive buffer accounting that occurs temporarily when buffers are
      moved from the backlog to the socket receive queue. Until now, this
      has gone unnoticed because of the large receive buffer limits we are
      applying, but becomes indispensable when we reduce this buffer limit
      later in this series.
      
      We now fix this by inverting the mentioned condition.
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      39a978c3