1. 15 Jun, 2016 40 commits
    • Mathias Krause's avatar
      proc: prevent accessing /proc/<PID>/environ until it's ready · eee69c92
      Mathias Krause authored
      commit 8148a73c upstream.
      
      If /proc/<PID>/environ gets read before the envp[] array is fully set up
      in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to
      read more bytes than are actually written, as env_start will already be
      set but env_end will still be zero, making the range calculation
      underflow, allowing to read beyond the end of what has been written.
      
      Fix this as it is done for /proc/<PID>/cmdline by testing env_end for
      zero.  It is, apparently, intentionally set last in create_*_tables().
      
      This bug was found by the PaX size_overflow plugin that detected the
      arithmetic underflow of 'this_len = env_end - (env_start + src)' when
      env_end is still zero.
      
      The expected consequence is that userland trying to access
      /proc/<PID>/environ of a not yet fully set up process may get
      inconsistent data as we're in the middle of copying in the environment
      variables.
      
      Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&t=4363
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Cc: Emese Revfy <re.emese@gmail.com>
      Cc: Pax Team <pageexec@freemail.hu>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Mateusz Guzik <mguzik@redhat.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Jarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      eee69c92
    • Lucas Stach's avatar
      drm/radeon: fix PLL sharing on DCE6.1 (v2) · a9098f8e
      Lucas Stach authored
      commit e3c00d87 upstream.
      
      On DCE6.1 PPLL2 is exclusively available to UNIPHYA, so it should not
      be taken into consideration when looking for an already enabled PLL
      to be shared with other outputs.
      
      This fixes the broken VGA port (TRAVIS DP->VGA bridge) on my Richland
      based laptop, where the internal display is connected to UNIPHYA through
      a TRAVIS DP->LVDS bridge.
      
      Bug:
      https://bugs.freedesktop.org/show_bug.cgi?id=78987
      
      v2: agd: add check in radeon_get_shared_nondp_ppll as well, drop
          extra parameter.
      Signed-off-by: default avatarLucas Stach <dev@lynxeye.de>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a9098f8e
    • Eric W. Biederman's avatar
      propogate_mnt: Handle the first propogated copy being a slave · 816d889b
      Eric W. Biederman authored
      commit 5ec0811d upstream.
      
      When the first propgated copy was a slave the following oops would result:
      > BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      > IP: [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
      > PGD bacd4067 PUD bac66067 PMD 0
      > Oops: 0000 [#1] SMP
      > Modules linked in:
      > CPU: 1 PID: 824 Comm: mount Not tainted 4.6.0-rc5userns+ #1523
      > Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      > task: ffff8800bb0a8000 ti: ffff8800bac3c000 task.ti: ffff8800bac3c000
      > RIP: 0010:[<ffffffff811fba4e>]  [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
      > RSP: 0018:ffff8800bac3fd38  EFLAGS: 00010283
      > RAX: 0000000000000000 RBX: ffff8800bb77ec00 RCX: 0000000000000010
      > RDX: 0000000000000000 RSI: ffff8800bb58c000 RDI: ffff8800bb58c480
      > RBP: ffff8800bac3fd48 R08: 0000000000000001 R09: 0000000000000000
      > R10: 0000000000001ca1 R11: 0000000000001c9d R12: 0000000000000000
      > R13: ffff8800ba713800 R14: ffff8800bac3fda0 R15: ffff8800bb77ec00
      > FS:  00007f3c0cd9b7e0(0000) GS:ffff8800bfb00000(0000) knlGS:0000000000000000
      > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > CR2: 0000000000000010 CR3: 00000000bb79d000 CR4: 00000000000006e0
      > Stack:
      >  ffff8800bb77ec00 0000000000000000 ffff8800bac3fd88 ffffffff811fbf85
      >  ffff8800bac3fd98 ffff8800bb77f080 ffff8800ba713800 ffff8800bb262b40
      >  0000000000000000 0000000000000000 ffff8800bac3fdd8 ffffffff811f1da0
      > Call Trace:
      >  [<ffffffff811fbf85>] propagate_mnt+0x105/0x140
      >  [<ffffffff811f1da0>] attach_recursive_mnt+0x120/0x1e0
      >  [<ffffffff811f1ec3>] graft_tree+0x63/0x70
      >  [<ffffffff811f1f6b>] do_add_mount+0x9b/0x100
      >  [<ffffffff811f2c1a>] do_mount+0x2aa/0xdf0
      >  [<ffffffff8117efbe>] ? strndup_user+0x4e/0x70
      >  [<ffffffff811f3a45>] SyS_mount+0x75/0xc0
      >  [<ffffffff8100242b>] do_syscall_64+0x4b/0xa0
      >  [<ffffffff81988f3c>] entry_SYSCALL64_slow_path+0x25/0x25
      > Code: 00 00 75 ec 48 89 0d 02 22 22 01 8b 89 10 01 00 00 48 89 05 fd 21 22 01 39 8e 10 01 00 00 0f 84 e0 00 00 00 48 8b 80 d8 00 00 00 <48> 8b 50 10 48 89 05 df 21 22 01 48 89 15 d0 21 22 01 8b 53 30
      > RIP  [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
      >  RSP <ffff8800bac3fd38>
      > CR2: 0000000000000010
      > ---[ end trace 2725ecd95164f217 ]---
      
      This oops happens with the namespace_sem held and can be triggered by
      non-root users.  An all around not pleasant experience.
      
      To avoid this scenario when finding the appropriate source mount to
      copy stop the walk up the mnt_master chain when the first source mount
      is encountered.
      
      Further rewrite the walk up the last_source mnt_master chain so that
      it is clear what is going on.
      
      The reason why the first source mount is special is that it it's
      mnt_parent is not a mount in the dest_mnt propagation tree, and as
      such termination conditions based up on the dest_mnt mount propgation
      tree do not make sense.
      
      To avoid other kinds of confusion last_dest is not changed when
      computing last_source.  last_dest is only used once in propagate_one
      and that is above the point of the code being modified, so changing
      the global variable is meaningless and confusing.
      
      fixes: f2ebb3a9 ("smarter propagate_mnt()")
      Reported-by: default avatarTycho Andersen <tycho.andersen@canonical.com>
      Reviewed-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Tested-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      816d889b
    • Maxim Patlasov's avatar
      fs/pnode.c: treat zero mnt_group_id-s as unequal · f4e8208d
      Maxim Patlasov authored
      commit 7ae8fd03 upstream.
      
      propagate_one(m) calculates "type" argument for copy_tree() like this:
      
      >    if (m->mnt_group_id == last_dest->mnt_group_id) {
      >        type = CL_MAKE_SHARED;
      >    } else {
      >        type = CL_SLAVE;
      >        if (IS_MNT_SHARED(m))
      >           type |= CL_MAKE_SHARED;
      >   }
      
      The "type" argument then governs clone_mnt() behavior with respect to flags
      and mnt_master of new mount. When we iterate through a slave group, it is
      possible that both current "m" and "last_dest" are not shared (although,
      both are slaves, i.e. have non-NULL mnt_master-s). Then the comparison
      above erroneously makes new mount shared and sets its mnt_master to
      last_source->mnt_master. The patch fixes the problem by handling zero
      mnt_group_id-s as though they are unequal.
      
      The similar problem exists in the implementation of "else" clause above
      when we have to ascend upward in the master/slave tree by calling:
      
      >    last_source = last_source->mnt_master;
      >    last_dest = last_source->mnt_parent;
      
      proper number of times. The last step is governed by
      "n->mnt_group_id != last_dest->mnt_group_id" condition that may lie if
      both are zero. The patch fixes this case in the same way as the former one.
      
      [AV: don't open-code an obvious helper...]
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@virtuozzo.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f4e8208d
    • Wang YanQing's avatar
      x86/sysfb_efi: Fix valid BAR address range check · c5948e3b
      Wang YanQing authored
      commit c10fcb14 upstream.
      
      The code for checking whether a BAR address range is valid will break
      out of the loop when a start address of 0x0 is encountered.
      
      This behaviour is wrong since by breaking out of the loop we may miss
      the BAR that describes the EFI frame buffer in a later iteration.
      
      Because of this bug I can't use video=efifb: boot parameter to get
      efifb on my new ThinkPad E550 for my old linux system hard disk with
      3.10 kernel. In 3.10, efifb is the only choice due to DRM/I915 not
      supporting the GPU.
      
      This patch also add a trivial optimization to break out after we find
      the frame buffer address range without testing later BARs.
      Signed-off-by: default avatarWang YanQing <udknight@gmail.com>
      [ Rewrote changelog. ]
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Reviewed-by: default avatarPeter Jones <pjones@redhat.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1462454061-21561-2-git-send-email-matt@codeblueprint.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c5948e3b
    • Herbert Xu's avatar
      crypto: hash - Fix page length clamping in hash walk · b986834b
      Herbert Xu authored
      commit 13f4bb78 upstream.
      
      The crypto hash walk code is broken when supplied with an offset
      greater than or equal to PAGE_SIZE.  This patch fixes it by adjusting
      walk->pg and walk->offset when this happens.
      Reported-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b986834b
    • Prarit Bhargava's avatar
      ACPICA: Dispatcher: Update thread ID for recursive method calls · eee71883
      Prarit Bhargava authored
      commit 93d68841 upstream.
      
      ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25
      
      Set the mutex owner thread ID.
      Original patch from: Prarit Bhargava <prarit@redhat.com>
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121
      Link: https://github.com/acpica/acpica/commit/7a3bd2d9Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Tested-by: Andy Lutomirski <luto@kernel.org> # On a Dell XPS 13 9350
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      eee71883
    • Matt Fleming's avatar
      MAINTAINERS: Remove asterisk from EFI directory names · 9d639520
      Matt Fleming authored
      commit e8dfe6d8 upstream.
      
      Mark reported that having asterisks on the end of directory names
      confuses get_maintainer.pl when it encounters subdirectories, and that
      my name does not appear when run on drivers/firmware/efi/libstub.
      Reported-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1462303781-8686-2-git-send-email-matt@codeblueprint.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9d639520
    • Alex Deucher's avatar
      drm/radeon: make sure vertical front porch is at least 1 · 8ad468c4
      Alex Deucher authored
      commit 3104b812 upstream.
      
      hw doesn't like a 0 value.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8ad468c4
    • Chunyu Hu's avatar
      tracing: Don't display trigger file for events that can't be enabled · 543320c2
      Chunyu Hu authored
      commit 854145e0 upstream.
      
      Currently register functions for events will be called
      through the 'reg' field of event class directly without
      any check when seting up triggers.
      
      Triggers for events that don't support register through
      debug fs (events under events/ftrace are for trace-cmd to
      read event format, and most of them don't have a register
      function except events/ftrace/functionx) can't be enabled
      at all, and an oops will be hit when setting up trigger
      for those events, so just not creating them is an easy way
      to avoid the oops.
      
      Link: http://lkml.kernel.org/r/1462275274-3911-1-git-send-email-chuhu@redhat.com
      
      Fixes: 85f2b082 ("tracing: Add basic event trigger framework")
      Signed-off-by: default avatarChunyu Hu <chuhu@redhat.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      543320c2
    • Linus Torvalds's avatar
      Minimal fix-up of bad hashing behavior of hash_64() · 475d831d
      Linus Torvalds authored
      commit 689de1d6 upstream.
      
      This is a fairly minimal fixup to the horribly bad behavior of hash_64()
      with certain input patterns.
      
      In particular, because the multiplicative value used for the 64-bit hash
      was intentionally bit-sparse (so that the multiply could be done with
      shifts and adds on architectures without hardware multipliers), some
      bits did not get spread out very much.  In particular, certain fairly
      common bit ranges in the input (roughly bits 12-20: commonly with the
      most information in them when you hash things like byte offsets in files
      or memory that have block factors that mean that the low bits are often
      zero) would not necessarily show up much in the result.
      
      There's a bigger patch-series brewing to fix up things more completely,
      but this is the fairly minimal fix for the 64-bit hashing problem.  It
      simply picks a much better constant multiplier, spreading the bits out a
      lot better.
      
      NOTE! For 32-bit architectures, the bad old hash_64() remains the same
      for now, since 64-bit multiplies are expensive.  The bigger hashing
      cleanup will replace the 32-bit case with something better.
      
      The new constants were picked by George Spelvin who wrote that bigger
      cleanup series.  I just picked out the constants and part of the comment
      from that series.
      
      Cc: George Spelvin <linux@horizon.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      475d831d
    • Linus Torvalds's avatar
      Make hash_64() use a 64-bit multiply when appropriate · 4fc1eb4f
      Linus Torvalds authored
      commit 23d0db76 upstream.
      
      The hash_64() function historically does the multiply by the
      GOLDEN_RATIO_PRIME_64 number with explicit shifts and adds, because
      unlike the 32-bit case, gcc seems unable to turn the constant multiply
      into the more appropriate shift and adds when required.
      
      However, that means that we generate those shifts and adds even when the
      architecture has a fast multiplier, and could just do it better in
      hardware.
      
      Use the now-cleaned-up CONFIG_ARCH_HAS_FAST_MULTIPLIER (together with
      "is it a 64-bit architecture") to decide whether to use an integer
      multiply or the explicit sequence of shift/add instructions.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      [bwh: This has no immediate effect in 3.16 because nothing defines
       CONFIG_ARCH_HAS_FAST_MULTIPLIER. However the following fix removes
       that condition.]
      4fc1eb4f
    • Anton Blanchard's avatar
      powerpc: Fix bad inline asm constraint in create_zero_mask() · 17cabcb4
      Anton Blanchard authored
      commit b4c11211 upstream.
      
      In create_zero_mask() we have:
      
      	addi	%1,%2,-1
      	andc	%1,%1,%2
      	popcntd	%0,%1
      
      using the "r" constraint for %2. r0 is a valid register in the "r" set,
      but addi X,r0,X turns it into an li:
      
      	li	r7,-1
      	andc	r7,r7,r0
      	popcntd	r4,r7
      
      Fix this by using the "b" constraint, for which r0 is not a valid
      register.
      
      This was found with a kernel build using gcc trunk, narrowed down to
      when -frename-registers was enabled at -O2. It is just luck however
      that we aren't seeing this on older toolchains.
      
      Thanks to Segher for working with me to find this issue.
      
      Fixes: d0cebfa6 ("powerpc: word-at-a-time optimization for 64-bit Little Endian")
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      [bwh: Backported to 3.16: same issue exists with a different variable in
       find_zero()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      17cabcb4
    • K. Y. Srinivasan's avatar
      Drivers: hv: vmbus: Fix signaling logic in hv_need_to_signal_on_read() · dfc39542
      K. Y. Srinivasan authored
      commit 1db488d1 upstream.
      
      On the consumer side, we have interrupt driven flow management of the
      producer. It is sufficient to base the signaling decision on the
      amount of space that is available to write after the read is complete.
      The current code samples the previous available space and uses this
      in making the signaling decision. This state can be stale and is
      unnecessary. Since the state can be stale, we end up not signaling
      the host (when we should) and this can result in a hang. Fix this
      problem by removing the unnecessary check. I would like to thank
      Arseney Romanenko <arseneyr@microsoft.com> for pointing out this issue.
      
      Also, issue a full memory barrier before making the signaling descision
      to correctly deal with potential reordering of the write (read index)
      followed by the read of pending_sz.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Tested-by: default avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      dfc39542
    • Christopher Oo's avatar
      Drivers: hv_vmbus: Fix signal to host condition · c84f51d7
      Christopher Oo authored
      commit a5cca686 upstream.
      
      Fixes a bug where previously hv_ringbuffer_read would pass in the old
      number of bytes available to read instead of the expected old read index
      when calculating when to signal to the host that the ringbuffer is empty.
      Since the previous write size is already saved, also changes the
      hv_need_to_signal_on_read to use the previously read value rather than
      recalculating it.
      Signed-off-by: default avatarChristopher Oo <t-chriso@microsoft.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c84f51d7
    • Al Viro's avatar
      atomic_open(): fix the handling of create_error · 6f8d26fd
      Al Viro authored
      commit 10c64cea upstream.
      
      * if we have a hashed negative dentry and either CREAT|EXCL on
      r/o filesystem, or CREAT|TRUNC on r/o filesystem, or CREAT|EXCL
      with failing may_o_create(), we should fail with EROFS or the
      error may_o_create() has returned, but not ENOENT.  Which is what
      the current code ends up returning.
      
      * if we have CREAT|TRUNC hitting a regular file on a read-only
      filesystem, we can't fail with EROFS here.  At the very least,
      not until we'd done follow_managed() - we might have a writable
      file (or a device, for that matter) bound on top of that one.
      Moreover, the code downstream will see that O_TRUNC and attempt
      to grab the write access (*after* following possible mount), so
      if we really should fail with EROFS, it will happen.  No need
      to do that inside atomic_open().
      
      The real logics is much simpler than what the current code is
      trying to do - if we decided to go for simple lookup, ended
      up with a negative dentry *and* had create_error set, fail with
      create_error.  No matter whether we'd got that negative dentry
      from lookup_real() or had found it in dcache.
      Acked-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      [bwh: Backported to 3.16: deleted code was slightly different]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6f8d26fd
    • Tony Luck's avatar
      EDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback · ff6845cf
      Tony Luck authored
      commit c4fc1956 upstream.
      
      Both of these drivers can return NOTIFY_BAD, but this terminates
      processing other callbacks that were registered later on the chain.
      Since the driver did nothing to log the error it seems wrong to prevent
      other interested parties from seeing it. E.g. neither of them had even
      bothered to check the type of the error to see if it was a memory error
      before the return NOTIFY_BAD.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Acked-by: default avatarAristeu Rozanski <aris@redhat.com>
      Acked-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Link: http://lkml.kernel.org/r/72937355dd92318d2630979666063f8a2853495b.1461864507.git.tony.luck@intel.comSigned-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ff6845cf
    • Sven Eckelmann's avatar
      batman-adv: Fix reference counting of vlan object for tt_local_entry · 40575df7
      Sven Eckelmann authored
      commit a33d970d upstream.
      
      The batadv_tt_local_entry was specific to a batadv_softif_vlan and held an
      implicit reference to it. But this reference was never stored in form of a
      pointer in the tt_local_entry itself. Instead batadv_tt_local_remove,
      batadv_tt_local_table_free and batadv_tt_local_purge_pending_clients depend
      on a consistent state of bat_priv->softif_vlan_list and that
      batadv_softif_vlan_get always returns the batadv_softif_vlan object which
      it has a reference for. But batadv_softif_vlan_get cannot guarantee that
      because it is working only with rcu_read_lock on this list. It can
      therefore happen that an vid is in this list twice or that
      batadv_softif_vlan_get cannot find the batadv_softif_vlan for an vid due to
      some other list operations taking place at the same time.
      
      Instead add a batadv_softif_vlan pointer directly in batadv_tt_local_entry
      which will be used for the reference counter decremented on release of
      batadv_tt_local_entry.
      
      Fixes: 35df3b29 ("batman-adv: fix TT VLAN inconsistency on VLAN re-add")
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Acked-by: default avatarAntonio Quartulli <a@unstable.cc>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <a@unstable.cc>
      [bwh: Backported to 3.16:
       - s/_put/_free_ref/ in various function names
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      40575df7
    • Antonio Quartulli's avatar
      batman-adv: fix DAT candidate selection (must use vid) · 29a56550
      Antonio Quartulli authored
      commit 2871734e upstream.
      
      Now that DAT is VLAN aware, it must use the VID when
      computing the DHT address of the candidate nodes where
      an entry is going to be stored/retrieved.
      
      Fixes: be1db4f6 ("batman-adv: make the Distributed ARP Table vlan aware")
      Signed-off-by: default avatarAntonio Quartulli <a@unstable.cc>
      [sven@narfation.org: fix conflicts with current version]
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      29a56550
    • Sven Eckelmann's avatar
      batman-adv: Fix invalid stack access in batadv_dat_select_candidates · 19d8176d
      Sven Eckelmann authored
      commit b7fe3d4f upstream.
      
      batadv_dat_select_candidates provides an u32 to batadv_hash_dat but it
      needs a batadv_dat_entry with at least ip and vid filled in.
      
      Fixes: 3e26722bc9f2 ("batman-adv: make the Distributed ARP Table vlan aware")
      Signed-off-by: default avatarSven Eckelmann <sven@open-mesh.com>
      Acked-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      19d8176d
    • Konstantin Khlebnikov's avatar
      mm/huge_memory: replace VM_NO_THP VM_BUG_ON with actual VMA check · 1ec1d746
      Konstantin Khlebnikov authored
      commit 3486b85a upstream.
      
      Khugepaged detects own VMAs by checking vm_file and vm_ops but this way
      it cannot distinguish private /dev/zero mappings from other special
      mappings like /dev/hpet which has no vm_ops and popultes PTEs in mmap.
      
      This fixes false-positive VM_BUG_ON and prevents installing THP where
      they are not expected.
      
      Link: http://lkml.kernel.org/r/CACT4Y+ZmuZMV5CjSFOeXviwQdABAgT7T+StKfTqan9YDtgEi5g@mail.gmail.com
      Fixes: 78f11a25 ("mm: thp: fix /dev/zero MAP_PRIVATE and vm_flags cleanups")
      Signed-off-by: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16: deleted assertions used VM_BUG_ON()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1ec1d746
    • Jason Gunthorpe's avatar
      IB/security: Restrict use of the write() interface · f4b592cb
      Jason Gunthorpe authored
      commit e6bd18f5 upstream.
      
      The drivers/infiniband stack uses write() as a replacement for
      bi-directional ioctl().  This is not safe. There are ways to
      trigger write calls that result in the return structure that
      is normally written to user space being shunted off to user
      specified kernel memory instead.
      
      For the immediate repair, detect and deny suspicious accesses to
      the write API.
      
      For long term, update the user space libraries and the kernel API
      to something that doesn't present the same security vulnerabilities
      (likely a structured ioctl() interface).
      
      The impacted uAPI interfaces are generally only available if
      hardware from drivers/infiniband is installed in the system.
      Reported-by: default avatarJann Horn <jann@thejh.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      [ Expanded check to all known write() entry points ]
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      [bwh: Backported to 3.2:
       - Drop changes to hfi1
       - ipath_write() has the same problem, so add the same restriction there]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f4b592cb
    • Ilya Dryomov's avatar
      rbd: fix rbd map vs notify races · 80e4da25
      Ilya Dryomov authored
      commit 811c6688 upstream.
      
      A while ago, commit 9875201e ("rbd: fix use-after free of
      rbd_dev->disk") fixed rbd unmap vs notify race by introducing
      an exported wrapper for flushing notifies and sticking it into
      do_rbd_remove().
      
      A similar problem exists on the rbd map path, though: the watch is
      registered in rbd_dev_image_probe(), while the disk is set up quite
      a few steps later, in rbd_dev_device_setup().  Nothing prevents
      a notify from coming in and crashing on a NULL rbd_dev->disk:
      
          BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
          Call Trace:
           [<ffffffffa0508344>] rbd_watch_cb+0x34/0x180 [rbd]
           [<ffffffffa04bd290>] do_event_work+0x40/0xb0 [libceph]
           [<ffffffff8109d5db>] process_one_work+0x17b/0x470
           [<ffffffff8109e3ab>] worker_thread+0x11b/0x400
           [<ffffffff8109e290>] ? rescuer_thread+0x400/0x400
           [<ffffffff810a5acf>] kthread+0xcf/0xe0
           [<ffffffff810b41b3>] ? finish_task_switch+0x53/0x170
           [<ffffffff810a5a00>] ? kthread_create_on_node+0x140/0x140
           [<ffffffff81645dd8>] ret_from_fork+0x58/0x90
           [<ffffffff810a5a00>] ? kthread_create_on_node+0x140/0x140
          RIP  [<ffffffffa050828a>] rbd_dev_refresh+0xfa/0x180 [rbd]
      
      If an error occurs during rbd map, we have to error out, potentially
      tearing down a watch.  Just like on rbd unmap, notifies have to be
      flushed, otherwise rbd_watch_cb() may end up trying to read in the
      image header after rbd_dev_image_release() has run:
      
          Assertion failure in rbd_dev_header_info() at line 4722:
      
           rbd_assert(rbd_image_format_valid(rbd_dev->image_format));
      
          Call Trace:
           [<ffffffff81cccee0>] ? rbd_parent_request_create+0x150/0x150
           [<ffffffff81cd4e59>] rbd_dev_refresh+0x59/0x390
           [<ffffffff81cd5229>] rbd_watch_cb+0x69/0x290
           [<ffffffff81fde9bf>] do_event_work+0x10f/0x1c0
           [<ffffffff81107799>] process_one_work+0x689/0x1a80
           [<ffffffff811076f7>] ? process_one_work+0x5e7/0x1a80
           [<ffffffff81132065>] ? finish_task_switch+0x225/0x640
           [<ffffffff81107110>] ? pwq_dec_nr_in_flight+0x2b0/0x2b0
           [<ffffffff81108c69>] worker_thread+0xd9/0x1320
           [<ffffffff81108b90>] ? process_one_work+0x1a80/0x1a80
           [<ffffffff8111b02d>] kthread+0x21d/0x2e0
           [<ffffffff8111ae10>] ? kthread_stop+0x550/0x550
           [<ffffffff82022802>] ret_from_fork+0x22/0x40
           [<ffffffff8111ae10>] ? kthread_stop+0x550/0x550
          RIP  [<ffffffff81ccd8f9>] rbd_dev_header_info+0xa19/0x1e30
      
      To fix this, a) check if RBD_DEV_FLAG_EXISTS is set before calling
      revalidate_disk(), b) move ceph_osdc_flush_notifies() call into
      rbd_dev_header_unwatch_sync() to cover rbd map error paths and c) turn
      header read-in into a critical section.  The latter also happens to
      take care of rbd map foo@bar vs rbd snap rm foo@bar race.
      
      Fixes: http://tracker.ceph.com/issues/15490Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarJosh Durgin <jdurgin@redhat.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      80e4da25
    • Sascha Hauer's avatar
      ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel · b5752ee2
      Sascha Hauer authored
      commit 5616f367 upstream.
      
      The secondary CPU starts up in ARM mode. When the kernel is compiled in
      thumb2 mode we have to explicitly compile the secondary startup
      trampoline in ARM mode, otherwise the CPU will go to Nirvana.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Reported-by: default avatarSteffen Trumtrar <s.trumtrar@pengutronix.de>
      Suggested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarDinh Nguyen <dinguyen@opensource.altera.com>
      Signed-off-by: default avatarKevin Hilman <khilman@baylibre.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b5752ee2
    • Imre Deak's avatar
      drm/i915: Fix system resume if PCI device remained enabled · 94488e8c
      Imre Deak authored
      commit dab9a266 upstream.
      
      During system resume we depended on pci_enable_device() also putting the
      device into PCI D0 state. This won't work if the PCI device was already
      enabled but still in D3 state. This is because pci_enable_device() is
      refcounted and will not change the HW state if called with a non-zero
      refcount. Leaving the device in D3 will make all subsequent device
      accesses fail.
      
      This didn't cause a problem most of the time, since we resumed with an
      enable refcount of 0. But it fails at least after module reload because
      after that we also happen to leak a PCI device enable reference: During
      probing we call drm_get_pci_dev() which will enable the PCI device, but
      during device removal drm_put_dev() won't disable it. This is a bug of
      its own in DRM core, but without much harm as it only leaves the PCI
      device enabled. Fixing it is also a bit more involved, due to DRM
      mid-layering and because it affects non-i915 drivers too. The fix in
      this patch is valid regardless of the problem in DRM core.
      
      v2:
      - Add a code comment about the relation of this fix to the freeze/thaw
        vs. the suspend/resume phases. (Ville)
      - Add a code comment about the inconsistent ordering of set power state
        and device enable calls. (Chris)
      
      CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460979954-14503-1-git-send-email-imre.deak@intel.com
      (cherry picked from commit 44410cd0)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      [bwh: Backported to 3.16:
       - Return error code directly
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      94488e8c
    • Roman Pen's avatar
      workqueue: fix ghost PENDING flag while doing MQ IO · 69717777
      Roman Pen authored
      commit 346c09f8 upstream.
      
      The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
      with the following backtrace:
      
      [  601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds.
      [  601.347574]       Tainted: G           O    4.4.5-1-storage+ #6
      [  601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  601.348142] kworker/u129:5  D ffff880803077988     0  1636      2 0x00000000
      [  601.348519] Workqueue: ibnbd_server_fileio_wq ibnbd_dev_file_submit_io_worker [ibnbd_server]
      [  601.348999]  ffff880803077988 ffff88080466b900 ffff8808033f9c80 ffff880803078000
      [  601.349662]  ffff880807c95000 7fffffffffffffff ffffffff815b0920 ffff880803077ad0
      [  601.350333]  ffff8808030779a0 ffffffff815b01d5 0000000000000000 ffff880803077a38
      [  601.350965] Call Trace:
      [  601.351203]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
      [  601.351444]  [<ffffffff815b01d5>] schedule+0x35/0x80
      [  601.351709]  [<ffffffff815b2dd2>] schedule_timeout+0x192/0x230
      [  601.351958]  [<ffffffff812d43f7>] ? blk_flush_plug_list+0xc7/0x220
      [  601.352208]  [<ffffffff810bd737>] ? ktime_get+0x37/0xa0
      [  601.352446]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
      [  601.352688]  [<ffffffff815af784>] io_schedule_timeout+0xa4/0x110
      [  601.352951]  [<ffffffff815b3a4e>] ? _raw_spin_unlock_irqrestore+0xe/0x10
      [  601.353196]  [<ffffffff815b093b>] bit_wait_io+0x1b/0x70
      [  601.353440]  [<ffffffff815b056d>] __wait_on_bit+0x5d/0x90
      [  601.353689]  [<ffffffff81127bd0>] wait_on_page_bit+0xc0/0xd0
      [  601.353958]  [<ffffffff81096db0>] ? autoremove_wake_function+0x40/0x40
      [  601.354200]  [<ffffffff81127cc4>] __filemap_fdatawait_range+0xe4/0x140
      [  601.354441]  [<ffffffff81127d34>] filemap_fdatawait_range+0x14/0x30
      [  601.354688]  [<ffffffff81129a9f>] filemap_write_and_wait_range+0x3f/0x70
      [  601.354932]  [<ffffffff811ced3b>] blkdev_fsync+0x1b/0x50
      [  601.355193]  [<ffffffff811c82d9>] vfs_fsync_range+0x49/0xa0
      [  601.355432]  [<ffffffff811cf45a>] blkdev_write_iter+0xca/0x100
      [  601.355679]  [<ffffffff81197b1a>] __vfs_write+0xaa/0xe0
      [  601.355925]  [<ffffffff81198379>] vfs_write+0xa9/0x1a0
      [  601.356164]  [<ffffffff811c59d8>] kernel_write+0x38/0x50
      
      The underlying device is a null_blk, with default parameters:
      
        queue_mode    = MQ
        submit_queues = 1
      
      Verification that nullb0 has something inflight:
      
      root@pserver8:~# cat /sys/block/nullb0/inflight
             0        1
      root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec cat {} \;
      ...
      /sys/block/nullb0/mq/0/cpu2/rq_list
      CTX pending:
              ffff8838038e2400
      ...
      
      During debug it became clear that stalled request is always inserted in
      the rq_list from the following path:
      
         save_stack_trace_tsk + 34
         blk_mq_insert_requests + 231
         blk_mq_flush_plug_list + 281
         blk_flush_plug_list + 199
         wait_on_page_bit + 192
         __filemap_fdatawait_range + 228
         filemap_fdatawait_range + 20
         filemap_write_and_wait_range + 63
         blkdev_fsync + 27
         vfs_fsync_range + 73
         blkdev_write_iter + 202
         __vfs_write + 170
         vfs_write + 169
         kernel_write + 56
      
      So blk_flush_plug_list() was called with from_schedule == true.
      
      If from_schedule is true, that means that finally blk_mq_insert_requests()
      offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue,
      i.e. it calls kblockd_schedule_delayed_work_on().
      
      That means, that we race with another CPU, which is about to execute
      __blk_mq_run_hw_queue() work.
      
      Further debugging shows the following traces from different CPUs:
      
        CPU#0                                  CPU#1
        ----------------------------------     -------------------------------
        reqeust A inserted
        STORE hctx->ctx_map[0] bit marked
        kblockd_schedule...() returns 1
        <schedule to kblockd workqueue>
                                               request B inserted
                                               STORE hctx->ctx_map[1] bit marked
                                               kblockd_schedule...() returns 0
        *** WORK PENDING bit is cleared ***
        flush_busy_ctxs() is executed, but
        bit 1, set by CPU#1, is not observed
      
      As a result request B pended forever.
      
      This behaviour can be explained by speculative LOAD of hctx->ctx_map on
      CPU#0, which is reordered with clear of PENDING bit and executed _before_
      actual STORE of bit 1 on CPU#1.
      
      The proper fix is an explicit full barrier <mfence>, which guarantees
      that clear of PENDING bit is to be executed before all possible
      speculative LOADS or STORES inside actual work function.
      Signed-off-by: default avatarRoman Pen <roman.penyaev@profitbricks.com>
      Cc: Gioh Kim <gi-oh.kim@profitbricks.com>
      Cc: Michael Wang <yun.wang@profitbricks.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: linux-block@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      69717777
    • Conrad Kostecki's avatar
      ALSA: hda - Add dock support for ThinkPad X260 · ea229bed
      Conrad Kostecki authored
      commit 037e1197 upstream.
      
      Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013
      docking station series (basic, pro, ultra).
      Signed-off-by: default avatarConrad Kostecki <ck+linuxkernel@bl4ckb0x.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ea229bed
    • Eric Dumazet's avatar
      net/mlx4_en: fix spurious timestamping callbacks · 8e0c1edd
      Eric Dumazet authored
      commit fc96256c upstream.
      
      When multiple skb are TX-completed in a row, we might incorrectly keep
      a timestamp of a prior skb and cause extra work.
      
      Fixes: ec693d47 ("net/mlx4_en: Add HW timestamping (TS) support")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Reviewed-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8e0c1edd
    • Ilya Dryomov's avatar
      libceph: make authorizer destruction independent of ceph_auth_client · 5d740c28
      Ilya Dryomov authored
      commit 6c1ea260 upstream.
      
      Starting the kernel client with cephx disabled and then enabling cephx
      and restarting userspace daemons can result in a crash:
      
          [262671.478162] BUG: unable to handle kernel paging request at ffffebe000000000
          [262671.531460] IP: [<ffffffff811cd04a>] kfree+0x5a/0x130
          [262671.584334] PGD 0
          [262671.635847] Oops: 0000 [#1] SMP
          [262672.055841] CPU: 22 PID: 2961272 Comm: kworker/22:2 Not tainted 4.2.0-34-generic #39~14.04.1-Ubuntu
          [262672.162338] Hardware name: Dell Inc. PowerEdge R720/068CDY, BIOS 2.4.3 07/09/2014
          [262672.268937] Workqueue: ceph-msgr con_work [libceph]
          [262672.322290] task: ffff88081c2d0dc0 ti: ffff880149ae8000 task.ti: ffff880149ae8000
          [262672.428330] RIP: 0010:[<ffffffff811cd04a>]  [<ffffffff811cd04a>] kfree+0x5a/0x130
          [262672.535880] RSP: 0018:ffff880149aeba58  EFLAGS: 00010286
          [262672.589486] RAX: 000001e000000000 RBX: 0000000000000012 RCX: ffff8807e7461018
          [262672.695980] RDX: 000077ff80000000 RSI: ffff88081af2be04 RDI: 0000000000000012
          [262672.803668] RBP: ffff880149aeba78 R08: 0000000000000000 R09: 0000000000000000
          [262672.912299] R10: ffffebe000000000 R11: ffff880819a60e78 R12: ffff8800aec8df40
          [262673.021769] R13: ffffffffc035f70f R14: ffff8807e5b138e0 R15: ffff880da9785840
          [262673.131722] FS:  0000000000000000(0000) GS:ffff88081fac0000(0000) knlGS:0000000000000000
          [262673.245377] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          [262673.303281] CR2: ffffebe000000000 CR3: 0000000001c0d000 CR4: 00000000001406e0
          [262673.417556] Stack:
          [262673.472943]  ffff880149aeba88 ffff88081af2be04 ffff8800aec8df40 ffff88081af2be04
          [262673.583767]  ffff880149aeba98 ffffffffc035f70f ffff880149aebac8 ffff8800aec8df00
          [262673.694546]  ffff880149aebac8 ffffffffc035c89e ffff8807e5b138e0 ffff8805b047f800
          [262673.805230] Call Trace:
          [262673.859116]  [<ffffffffc035f70f>] ceph_x_destroy_authorizer+0x1f/0x50 [libceph]
          [262673.968705]  [<ffffffffc035c89e>] ceph_auth_destroy_authorizer+0x3e/0x60 [libceph]
          [262674.078852]  [<ffffffffc0352805>] put_osd+0x45/0x80 [libceph]
          [262674.134249]  [<ffffffffc035290e>] remove_osd+0xae/0x140 [libceph]
          [262674.189124]  [<ffffffffc0352aa3>] __reset_osd+0x103/0x150 [libceph]
          [262674.243749]  [<ffffffffc0354703>] kick_requests+0x223/0x460 [libceph]
          [262674.297485]  [<ffffffffc03559e2>] ceph_osdc_handle_map+0x282/0x5e0 [libceph]
          [262674.350813]  [<ffffffffc035022e>] dispatch+0x4e/0x720 [libceph]
          [262674.403312]  [<ffffffffc034bd91>] try_read+0x3d1/0x1090 [libceph]
          [262674.454712]  [<ffffffff810ab7c2>] ? dequeue_entity+0x152/0x690
          [262674.505096]  [<ffffffffc034cb1b>] con_work+0xcb/0x1300 [libceph]
          [262674.555104]  [<ffffffff8108fb3e>] process_one_work+0x14e/0x3d0
          [262674.604072]  [<ffffffff810901ea>] worker_thread+0x11a/0x470
          [262674.652187]  [<ffffffff810900d0>] ? rescuer_thread+0x310/0x310
          [262674.699022]  [<ffffffff810957a2>] kthread+0xd2/0xf0
          [262674.744494]  [<ffffffff810956d0>] ? kthread_create_on_node+0x1c0/0x1c0
          [262674.789543]  [<ffffffff817bd81f>] ret_from_fork+0x3f/0x70
          [262674.834094]  [<ffffffff810956d0>] ? kthread_create_on_node+0x1c0/0x1c0
      
      What happens is the following:
      
          (1) new MON session is established
          (2) old "none" ac is destroyed
          (3) new "cephx" ac is constructed
          ...
          (4) old OSD session (w/ "none" authorizer) is put
                ceph_auth_destroy_authorizer(ac, osd->o_auth.authorizer)
      
      osd->o_auth.authorizer in the "none" case is just a bare pointer into
      ac, which contains a single static copy for all services.  By the time
      we get to (4), "none" ac, freed in (2), is long gone.  On top of that,
      a new vtable installed in (3) points us at ceph_x_destroy_authorizer(),
      so we end up trying to destroy a "none" authorizer with a "cephx"
      destructor operating on invalid memory!
      
      To fix this, decouple authorizer destruction from ac and do away with
      a single static "none" authorizer by making a copy for each OSD or MDS
      session.  Authorizers themselves are independent of ac and so there is
      no reason for destroy_authorizer() to be an ac op.  Make it an op on
      the authorizer itself by turning ceph_authorizer into a real struct.
      
      Fixes: http://tracker.ceph.com/issues/15447Reported-by: default avatarAlan Zhang <alan.zhang@linux.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      [bwh: Backported to 3.16:
       - Implementation of ceph_x_destroy_authorizer() is different
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5d740c28
    • Ilya Dryomov's avatar
      libceph: kfree() in put_osd() shouldn't depend on authorizer · 20b81291
      Ilya Dryomov authored
      commit b28ec2f3 upstream.
      
      a255651d ("ceph: ensure auth ops are defined before use") made
      kfree() in put_osd() conditional on the authorizer.  A mechanical
      mistake most likely - fix it.
      
      Cc: Alex Elder <elder@linaro.org>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      20b81291
    • Jasem Mutlaq's avatar
      USB: serial: cp210x: add Straizona Focusers device ids · 9e395dbd
      Jasem Mutlaq authored
      commit 613ac23a upstream.
      
      Adding VID:PID for Straizona Focusers to cp210x driver.
      Signed-off-by: default avatarJasem Mutlaq <mutlaqja@ikarustech.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9e395dbd
    • Mike Manning's avatar
      USB: serial: cp210x: add ID for Link ECU · 414ccda0
      Mike Manning authored
      commit 1d377f4d upstream.
      
      The Link ECU is an aftermarket ECU computer for vehicles that provides
      full tuning abilities as well as datalogging and displaying capabilities
      via the USB to Serial adapter built into the device.
      Signed-off-by: default avatarMike Manning <michael@bsch.com.au>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      414ccda0
    • Linus Lüssing's avatar
      batman-adv: Fix broadcast/ogm queue limit on a removed interface · e93055ed
      Linus Lüssing authored
      commit c4fdb6cf upstream.
      
      When removing a single interface while a broadcast or ogm packet is
      still pending then we will free the forward packet without releasing the
      queue slots again.
      
      This patch is supposed to fix this issue.
      
      Fixes: 6d5808d4 ("batman-adv: Add missing hardif_free_ref in forw_packet_free")
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      [sven@narfation.org: fix conflicts with current version]
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <a@unstable.cc>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e93055ed
    • Sven Eckelmann's avatar
      batman-adv: Reduce refcnt of removed router when updating route · c8238563
      Sven Eckelmann authored
      commit d1a65f17 upstream.
      
      _batadv_update_route rcu_derefences orig_ifinfo->router outside of a
      spinlock protected region to print some information messages to the debug
      log. But this pointer is not checked again when the new pointer is assigned
      in the spinlock protected region. Thus is can happen that the value of
      orig_ifinfo->router changed in the meantime and thus the reference counter
      of the wrong router gets reduced after the spinlock protected region.
      
      Just rcu_dereferencing the value of orig_ifinfo->router inside the spinlock
      protected region (which also set the new pointer) is enough to get the
      correct old router object.
      
      Fixes: e1a5382f ("batman-adv: Make orig_node->router an rcu protected pointer")
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <a@unstable.cc>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c8238563
    • Sven Eckelmann's avatar
      batman-adv: Check skb size before using encapsulated ETH+VLAN header · e7ad6820
      Sven Eckelmann authored
      commit c7829666 upstream.
      
      The encapsulated ethernet and VLAN header may be outside the received
      ethernet frame. Thus the skb buffer size has to be checked before it can be
      parsed to find out if it encapsulates another batman-adv packet.
      
      Fixes: 42019357 ("batman-adv: softif bridge loop avoidance")
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <a@unstable.cc>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e7ad6820
    • Laszlo Ersek's avatar
      efi: Fix out-of-bounds read in variable_matches() · 87f1822d
      Laszlo Ersek authored
      commit 630ba0cc upstream.
      
      The variable_matches() function can currently read "var_name[len]", for
      example when:
      
       - var_name[0] == 'a',
       - len == 1
       - match_name points to the NUL-terminated string "ab".
      
      This function is supposed to accept "var_name" inputs that are not
      NUL-terminated (hence the "len" parameter"). Document the function, and
      access "var_name[*match]" only if "*match" is smaller than "len".
      Reported-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Matthew Garrett <mjg59@coreos.com>
      Cc: Jason Andryuk <jandryuk@gmail.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Link: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/86906Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      87f1822d
    • Javier Martinez Canillas's avatar
      i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared · a3db726d
      Javier Martinez Canillas authored
      commit 10ff4c52 upstream.
      
      The exynos5 I2C controller driver always prepares and enables a clock
      before using it and then disables unprepares it when the clock is not
      used anymore.
      
      But this can cause a possible ABBA deadlock in some scenarios since a
      driver that uses regmap to access its I2C registers, will first grab
      the regmap lock and then the I2C xfer function will grab the prepare
      lock when preparing the I2C clock. But since the clock driver also
      uses regmap for I2C accesses, preparing a clock will first grab the
      prepare lock and then the regmap lock when using the regmap API.
      
      An example of this happens on the Exynos5422 Odroid XU4 board where a
      s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
      share the same I2C regmap.
      
      The possible deadlock is reported by the kernel lockdep:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(sec_core:428:(regmap)->lock);
                                      lock(prepare_lock);
                                      lock(sec_core:428:(regmap)->lock);
         lock(prepare_lock);
      
        *** DEADLOCK ***
      
      Fix it by leaving the code prepared on probe and use {en,dis}able in
      the I2C transfer function.
      
      This patch is similar to commit 34e81ad5 ("i2c: s3c2410: fix ABBA
      deadlock by keeping clock prepared") that fixes the same bug in other
      driver for an I2C controller found in Samsung SoCs.
      Reported-by: default avatarAnand Moon <linux.amoon@gmail.com>
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Reviewed-by: default avatarAnand Moon <linux.amoon@gmail.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a3db726d
    • Jan Beulich's avatar
      x86/mm/xen: Suppress hugetlbfs in PV guests · 27c03f88
      Jan Beulich authored
      commit 103f6112 upstream.
      
      Huge pages are not normally available to PV guests. Not suppressing
      hugetlbfs use results in an endless loop of page faults when user mode
      code tries to access a hugetlbfs mapped area (since the hypervisor
      denies such PTEs to be created, but error indications can't be
      propagated out of xen_set_pte_at(), just like for various of its
      siblings), and - once killed in an oops like this:
      
        kernel BUG at .../fs/hugetlbfs/inode.c:428!
        invalid opcode: 0000 [#1] SMP
        ...
        RIP: e030:[<ffffffff811c333b>]  [<ffffffff811c333b>] remove_inode_hugepages+0x25b/0x320
        ...
        Call Trace:
         [<ffffffff811c3415>] hugetlbfs_evict_inode+0x15/0x40
         [<ffffffff81167b3d>] evict+0xbd/0x1b0
         [<ffffffff8116514a>] __dentry_kill+0x19a/0x1f0
         [<ffffffff81165b0e>] dput+0x1fe/0x220
         [<ffffffff81150535>] __fput+0x155/0x200
         [<ffffffff81079fc0>] task_work_run+0x60/0xa0
         [<ffffffff81063510>] do_exit+0x160/0x400
         [<ffffffff810637eb>] do_group_exit+0x3b/0xa0
         [<ffffffff8106e8bd>] get_signal+0x1ed/0x470
         [<ffffffff8100f854>] do_signal+0x14/0x110
         [<ffffffff810030e9>] prepare_exit_to_usermode+0xe9/0xf0
         [<ffffffff814178a5>] retint_user+0x8/0x13
      
      This is CVE-2016-3961 / XSA-174.
      Reported-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Juergen Gross <JGross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: xen-devel <xen-devel@lists.xenproject.org>
      Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      27c03f88
    • Dominik Dingel's avatar
      s390/hugetlb: add hugepages_supported define · 732ca998
      Dominik Dingel authored
      commit 7f9be775 upstream.
      
      On s390 we only can enable hugepages if the underlying hardware/hypervisor
      also does support this.  Common code now would assume this to be
      signaled by setting HPAGE_SHIFT to 0.  But on s390, where we only
      support one hugepage size, there is a link between HPAGE_SHIFT and
      pageblock_order.
      
      So instead of setting HPAGE_SHIFT to 0, we will implement the check for
      the hardware capability.
      Signed-off-by: default avatarDominik Dingel <dingel@linux.vnet.ibm.com>
      Acked-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      732ca998
    • Dominik Dingel's avatar
      mm: hugetlb: allow hugepages_supported to be architecture specific · 609aa408
      Dominik Dingel authored
      commit 2531c8cf upstream.
      
      s390 has a constant hugepage size, by setting HPAGE_SHIFT we also change
      e.g. the pageblock_order, which should be independent in respect to
      hugepage support.
      
      With this patch every architecture is free to define how to check
      for hugepage support.
      Signed-off-by: default avatarDominik Dingel <dingel@linux.vnet.ibm.com>
      Acked-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      609aa408