1. 30 Apr, 2016 40 commits
    • Filipe Manana's avatar
      Btrfs: fix file/data loss caused by fsync after rename and new inode · bb91d38d
      Filipe Manana authored
      commit 56f23fdb upstream.
      
      If we rename an inode A (be it a file or a directory), create a new
      inode B with the old name of inode A and under the same parent directory,
      fsync inode B and then power fail, at log tree replay time we end up
      removing inode A completely. If inode A is a directory then all its files
      are gone too.
      
      Example scenarios where this happens:
      This is reproducible with the following steps, taken from a couple of
      test cases written for fstests which are going to be submitted upstream
      soon:
      
         # Scenario 1
      
         mkfs.btrfs -f /dev/sdc
         mount /dev/sdc /mnt
         mkdir -p /mnt/a/x
         echo "hello" > /mnt/a/x/foo
         echo "world" > /mnt/a/x/bar
         sync
         mv /mnt/a/x /mnt/a/y
         mkdir /mnt/a/x
         xfs_io -c fsync /mnt/a/x
         <power failure happens>
      
         The next time the fs is mounted, log tree replay happens and
         the directory "y" does not exist nor do the files "foo" and
         "bar" exist anywhere (neither in "y" nor in "x", nor the root
         nor anywhere).
      
         # Scenario 2
      
         mkfs.btrfs -f /dev/sdc
         mount /dev/sdc /mnt
         mkdir /mnt/a
         echo "hello" > /mnt/a/foo
         sync
         mv /mnt/a/foo /mnt/a/bar
         echo "world" > /mnt/a/foo
         xfs_io -c fsync /mnt/a/foo
         <power failure happens>
      
         The next time the fs is mounted, log tree replay happens and the
         file "bar" does not exists anymore. A file with the name "foo"
         exists and it matches the second file we created.
      
      Another related problem that does not involve file/data loss is when a
      new inode is created with the name of a deleted snapshot and we fsync it:
      
         mkfs.btrfs -f /dev/sdc
         mount /dev/sdc /mnt
         mkdir /mnt/testdir
         btrfs subvolume snapshot /mnt /mnt/testdir/snap
         btrfs subvolume delete /mnt/testdir/snap
         rmdir /mnt/testdir
         mkdir /mnt/testdir
         xfs_io -c fsync /mnt/testdir # or fsync some file inside /mnt/testdir
         <power failure>
      
         The next time the fs is mounted the log replay procedure fails because
         it attempts to delete the snapshot entry (which has dir item key type
         of BTRFS_ROOT_ITEM_KEY) as if it were a regular (non-root) entry,
         resulting in the following error that causes mount to fail:
      
         [52174.510532] BTRFS info (device dm-0): failed to delete reference to snap, inode 257 parent 257
         [52174.512570] ------------[ cut here ]------------
         [52174.513278] WARNING: CPU: 12 PID: 28024 at fs/btrfs/inode.c:3986 __btrfs_unlink_inode+0x178/0x351 [btrfs]()
         [52174.514681] BTRFS: Transaction aborted (error -2)
         [52174.515630] Modules linked in: btrfs dm_flakey dm_mod overlay crc32c_generic ppdev xor raid6_pq acpi_cpufreq parport_pc tpm_tis sg parport tpm evdev i2c_piix4 proc
         [52174.521568] CPU: 12 PID: 28024 Comm: mount Tainted: G        W       4.5.0-rc6-btrfs-next-27+ #1
         [52174.522805] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
         [52174.524053]  0000000000000000 ffff8801df2a7710 ffffffff81264e93 ffff8801df2a7758
         [52174.524053]  0000000000000009 ffff8801df2a7748 ffffffff81051618 ffffffffa03591cd
         [52174.524053]  00000000fffffffe ffff88015e6e5000 ffff88016dbc3c88 ffff88016dbc3c88
         [52174.524053] Call Trace:
         [52174.524053]  [<ffffffff81264e93>] dump_stack+0x67/0x90
         [52174.524053]  [<ffffffff81051618>] warn_slowpath_common+0x99/0xb2
         [52174.524053]  [<ffffffffa03591cd>] ? __btrfs_unlink_inode+0x178/0x351 [btrfs]
         [52174.524053]  [<ffffffff81051679>] warn_slowpath_fmt+0x48/0x50
         [52174.524053]  [<ffffffffa03591cd>] __btrfs_unlink_inode+0x178/0x351 [btrfs]
         [52174.524053]  [<ffffffff8118f5e9>] ? iput+0xb0/0x284
         [52174.524053]  [<ffffffffa0359fe8>] btrfs_unlink_inode+0x1c/0x3d [btrfs]
         [52174.524053]  [<ffffffffa038631e>] check_item_in_log+0x1fe/0x29b [btrfs]
         [52174.524053]  [<ffffffffa0386522>] replay_dir_deletes+0x167/0x1cf [btrfs]
         [52174.524053]  [<ffffffffa038739e>] fixup_inode_link_count+0x289/0x2aa [btrfs]
         [52174.524053]  [<ffffffffa038748a>] fixup_inode_link_counts+0xcb/0x105 [btrfs]
         [52174.524053]  [<ffffffffa038a5ec>] btrfs_recover_log_trees+0x258/0x32c [btrfs]
         [52174.524053]  [<ffffffffa03885b2>] ? replay_one_extent+0x511/0x511 [btrfs]
         [52174.524053]  [<ffffffffa034f288>] open_ctree+0x1dd4/0x21b9 [btrfs]
         [52174.524053]  [<ffffffffa032b753>] btrfs_mount+0x97e/0xaed [btrfs]
         [52174.524053]  [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
         [52174.524053]  [<ffffffff8117bafa>] mount_fs+0x67/0x131
         [52174.524053]  [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
         [52174.524053]  [<ffffffffa032af81>] btrfs_mount+0x1ac/0xaed [btrfs]
         [52174.524053]  [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
         [52174.524053]  [<ffffffff8108c262>] ? lockdep_init_map+0xb9/0x1b3
         [52174.524053]  [<ffffffff8117bafa>] mount_fs+0x67/0x131
         [52174.524053]  [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
         [52174.524053]  [<ffffffff8119590f>] do_mount+0x8a6/0x9e8
         [52174.524053]  [<ffffffff811358dd>] ? strndup_user+0x3f/0x59
         [52174.524053]  [<ffffffff81195c65>] SyS_mount+0x77/0x9f
         [52174.524053]  [<ffffffff814935d7>] entry_SYSCALL_64_fastpath+0x12/0x6b
         [52174.561288] ---[ end trace 6b53049efb1a3ea6 ]---
      
      Fix this by forcing a transaction commit when such cases happen.
      This means we check in the commit root of the subvolume tree if there
      was any other inode with the same reference when the inode we are
      fsync'ing is a new inode (created in the current transaction).
      
      Test cases for fstests, covering all the scenarios given above, were
      submitted upstream for fstests:
      
        * fstests: generic test for fsync after renaming directory
          https://patchwork.kernel.org/patch/8694281/
      
        * fstests: generic test for fsync after renaming file
          https://patchwork.kernel.org/patch/8694301/
      
        * fstests: add btrfs test for fsync after snapshot deletion
          https://patchwork.kernel.org/patch/8670671/Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      bb91d38d
    • Thadeu Lima de Souza Cascardo's avatar
      ip6_tunnel: set rtnl_link_ops before calling register_netdevice · 9d37d0bd
      Thadeu Lima de Souza Cascardo authored
      commit b6ee376c upstream.
      
      When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set
      before ip6_tnl_create2 is called. When register_netdevice is called, there
      is no linkinfo attribute in the NEWLINK message because of that.
      
      Setting rtnl_link_ops before calling register_netdevice fixes that.
      
      Fixes: 0b112457 ("ip6tnl: add support of link creation via rtnl")
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@redhat.com>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9d37d0bd
    • Paolo Bonzini's avatar
      compiler-gcc: disable -ftracer for __noclone functions · 9f9aecbf
      Paolo Bonzini authored
      commit 95272c29 upstream.
      
      -ftracer can duplicate asm blocks causing compilation to fail in
      noclone functions.  For example, KVM declares a global variable
      in an asm like
      
          asm("2: ... \n
               .pushsection data \n
               .global vmx_return \n
               vmx_return: .long 2b");
      
      and -ftracer causes a double declaration.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: kvm@vger.kernel.org
      Reported-by: default avatarLinda Walsh <lkml@tlinx.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [bwh: Backported to 3.16: apply to compiler-gcc{4,5}.h]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9f9aecbf
    • Boris Ostrovsky's avatar
      xen/events: Mask a moving irq · 8be84a48
      Boris Ostrovsky authored
      commit ff1e22e7 upstream.
      
      Moving an unmasked irq may result in irq handler being invoked on both
      source and target CPUs.
      
      With 2-level this can happen as follows:
      
      On source CPU:
              evtchn_2l_handle_events() ->
                  generic_handle_irq() ->
                      handle_edge_irq() ->
                         eoi_pirq():
                             irq_move_irq(data);
      
                             /***** WE ARE HERE *****/
      
                             if (VALID_EVTCHN(evtchn))
                                 clear_evtchn(evtchn);
      
      If at this moment target processor is handling an unrelated event in
      evtchn_2l_handle_events()'s loop it may pick up our event since target's
      cpu_evtchn_mask claims that this event belongs to it *and* the event is
      unmasked and still pending. At the same time, source CPU will continue
      executing its own handle_edge_irq().
      
      With FIFO interrupt the scenario is similar: irq_move_irq() may result
      in a EVTCHNOP_unmask hypercall which, in turn, may make the event
      pending on the target CPU.
      
      We can avoid this situation by moving and clearing the event while
      keeping event masked.
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8be84a48
    • Xishi Qiu's avatar
      mm: fix invalid node in alloc_migrate_target() · 6aab15b4
      Xishi Qiu authored
      commit 6f25a14a upstream.
      
      It is incorrect to use next_node to find a target node, it will return
      MAX_NUMNODES or invalid node.  This will lead to crash in buddy system
      allocation.
      
      Fixes: c8721bbb ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
      Signed-off-by: default avatarXishi Qiu <qiuxishi@huawei.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Acked-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Joonsoo Kim <js1304@gmail.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: "Laura Abbott" <lauraa@codeaurora.org>
      Cc: Hui Zhu <zhuhui@xiaomi.com>
      Cc: Wang Xiaoqiang <wangxq10@lzu.edu.cn>
      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>
      6aab15b4
    • Takashi Iwai's avatar
      ALSA: timer: Use mod_timer() for rearming the system timer · 59f6922e
      Takashi Iwai authored
      commit 4a07083e upstream.
      
      ALSA system timer backend stops the timer via del_timer() without sync
      and leaves del_timer_sync() at the close instead.  This is because of
      the restriction by the design of ALSA timer: namely, the stop callback
      may be called from the timer handler, and calling the sync shall lead
      to a hangup.  However, this also triggers a kernel BUG() when the
      timer is rearmed immediately after stopping without sync:
       kernel BUG at kernel/time/timer.c:966!
       Call Trace:
        <IRQ>
        [<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0
        [<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0
        [<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290
        [<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120
        [<ffffffff81296b72>] call_timer_fn+0x162/0x520
        [<ffffffff81296add>] ? call_timer_fn+0xcd/0x520
        [<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0
        ....
      
      It's the place where add_timer() checks the pending timer.  It's clear
      that this may happen after the immediate restart without sync in our
      cases.
      
      So, the workaround here is just to use mod_timer() instead of
      add_timer().  This looks like a band-aid fix, but it's a right move,
      as snd_timer_interrupt() takes care of the continuous rearm of timer.
      Reported-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      59f6922e
    • Yuki Shibuya's avatar
      KVM: x86: Inject pending interrupt even if pending nmi exist · 916d888c
      Yuki Shibuya authored
      commit 321c5658 upstream.
      
      Non maskable interrupts (NMI) are preferred to interrupts in current
      implementation. If a NMI is pending and NMI is blocked by the result
      of nmi_allowed(), pending interrupt is not injected and
      enable_irq_window() is not executed, even if interrupts injection is
      allowed.
      
      In old kernel (e.g. 2.6.32), schedule() is often called in NMI context.
      In this case, interrupts are needed to execute iret that intends end
      of NMI. The flag of blocking new NMI is not cleared until the guest
      execute the iret, and interrupts are blocked by pending NMI. Due to
      this, iret can't be invoked in the guest, and the guest is starved
      until block is cleared by some events (e.g. canceling injection).
      
      This patch injects pending interrupts, when it's allowed, even if NMI
      is blocked. And, If an interrupts is pending after executing
      inject_pending_event(), enable_irq_window() is executed regardless of
      NMI pending counter.
      Signed-off-by: default avatarYuki Shibuya <shibuya.yk@ncos.nec.co.jp>
      Suggested-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      916d888c
    • Hui Wang's avatar
      ALSA: hda - fix front mic problem for a HP desktop · d235bb2b
      Hui Wang authored
      commit e549d190 upstream.
      
      The front mic jack (pink color) can't detect any plug or unplug. After
      applying this fix, both detecting function and recording function
      work well.
      
      BugLink: https://bugs.launchpad.net/bugs/1564712Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d235bb2b
    • Theodore Ts'o's avatar
      ext4: add lockdep annotations for i_data_sem · f08b6c73
      Theodore Ts'o authored
      commit daf647d2 upstream.
      
      With the internal Quota feature, mke2fs creates empty quota inodes and
      quota usage tracking is enabled as soon as the file system is mounted.
      Since quotacheck is no longer preallocating all of the blocks in the
      quota inode that are likely needed to be written to, we are now seeing
      a lockdep false positive caused by needing to allocate a quota block
      from inside ext4_map_blocks(), while holding i_data_sem for a data
      inode.  This results in this complaint:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&ei->i_data_sem);
                                      lock(&s->s_dquot.dqio_mutex);
                                      lock(&ei->i_data_sem);
         lock(&s->s_dquot.dqio_mutex);
      
      Google-Bug-Id: 27907753
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f08b6c73
    • Daniel Vetter's avatar
      drm/udl: Use unlocked gem unreferencing · 057358a0
      Daniel Vetter authored
      commit 72b9ff06 upstream.
      
      For drm_gem_object_unreference callers are required to hold
      dev->struct_mutex, which these paths don't. Enforcing this requirement
      has become a bit more strict with
      
      commit ef4c6270
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Oct 15 09:36:25 2015 +0200
      
          drm/gem: Check locking in drm_gem_object_unreference
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      057358a0
    • Rob Clark's avatar
      drm/dp: move hw_mutex up the call stack · 58f64e3e
      Rob Clark authored
      commit 7779c5e2 upstream.
      
      1) don't let other threads trying to bang on aux channel interrupt the
      defer timeout/logic
      2) don't let other threads interrupt the i2c over aux logic
      
      Technically, according to people who actually have the DP spec, this
      should not be required.  In practice, it makes some troublesome Dell
      monitor (and perhaps others) work, so probably a case of "It's compliant
      if it works with windows" on the hw vendor's part..
      
      v2: rebased to come before DPCD/AUX logging patch for easier backport
      to stable branches.
      Reported-by: default avatarDave Wysochanski <dwysocha@redhat.com>
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1274157Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      58f64e3e
    • Martin K. Petersen's avatar
      sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes · 5b08968c
      Martin K. Petersen authored
      commit f08bb1e0 upstream.
      
      During revalidate we check whether device capacity has changed before we
      decide whether to output disk information or not.
      
      The check for old capacity failed to take into account that we scaled
      sdkp->capacity based on the reported logical block size. And therefore
      the capacity test would always fail for devices with sectors bigger than
      512 bytes and we would print several copies of the same discovery
      information.
      
      Avoid scaling sdkp->capacity and instead adjust the value on the fly
      when setting the block device capacity and generating fake C/H/S
      geometry.
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Reported-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarHannes Reinicke <hare@suse.de>
      Reviewed-by: default avatarEwan Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      [bwh: Backported to 3.16:
       - logical_to_sectors() is a new function
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5b08968c
    • Oliver Neukum's avatar
      USB: digi_acceleport: do sanity checking for the number of ports · 68833f49
      Oliver Neukum authored
      commit 5a07975a upstream.
      
      The driver can be crashed with devices that expose crafted descriptors
      with too few endpoints.
      
      See: http://seclists.org/bugtraq/2016/Mar/61Signed-off-by: default avatarOliver Neukum <ONeukum@suse.com>
      [johan: fix OOB endpoint check and add error messages ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      68833f49
    • Oliver Neukum's avatar
      USB: cypress_m8: add endpoint sanity check · 768c09c4
      Oliver Neukum authored
      commit c55aee1b upstream.
      
      An attack using missing endpoints exists.
      
      CVE-2016-3137
      Signed-off-by: default avatarOliver Neukum <ONeukum@suse.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      768c09c4
    • Oliver Neukum's avatar
      USB: mct_u232: add sanity checking in probe · f3b7e0bf
      Oliver Neukum authored
      commit 4e9a0b05 upstream.
      
      An attack using the lack of sanity checking in probe is known. This
      patch checks for the existence of a second port.
      
      CVE-2016-3136
      Signed-off-by: default avatarOliver Neukum <ONeukum@suse.com>
      [johan: add error message ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f3b7e0bf
    • Vladis Dronov's avatar
      ALSA: usb-audio: Fix double-free in error paths after snd_usb_add_audio_stream() call · 4420afcc
      Vladis Dronov authored
      commit 836b34a9 upstream.
      
      create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and
      create_uaxx_quirk() functions allocate the audioformat object by themselves
      and free it upon error before returning. However, once the object is linked
      to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be
      double-freed, eventually resulting in a memory corruption.
      
      This patch fixes these failures in the error paths by unlinking the audioformat
      object before freeing it.
      
      Based on a patch by Takashi Iwai <tiwai@suse.de>
      
      [Note for stable backports:
       this patch requires the commit 902eb7fd ('ALSA: usb-audio: Minor
       code cleanup in create_fixed_stream_quirk()')]
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283358Reported-by: default avatarRalf Spenneberg <ralf@spenneberg.net>
      Signed-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4420afcc
    • Takashi Iwai's avatar
      ALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk() · 1bf88e4f
      Takashi Iwai authored
      commit 902eb7fd upstream.
      
      Just a minor code cleanup: unify the error paths.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1bf88e4f
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer · 288349b2
      Yoshihiro Shimoda authored
      commit 6490865c upstream.
      
      This patch adds a code to surely disable TX IRQ of the pipe before
      starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs
      may happen in rare cases when DMAC is used.
      
      Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      288349b2
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler() · 0a76bf60
      Yoshihiro Shimoda authored
      commit 894f2fc4 upstream.
      
      When unexpected situation happened (e.g. tx/rx irq happened while
      DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
      pointer dereference like the followings:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 80000007 [#1] SMP ARM
      Modules linked in: usb_f_acm u_serial g_serial libcomposite
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63
      Hardware name: Generic R8A7790 (Flattened Device Tree)
      task: c0729c00 ti: c0724000 task.ti: c0724000
      PC is at 0x0
      LR is at usbhsf_pkt_handler+0xac/0x118
      pc : [<00000000>]    lr : [<c03257e0>]    psr: 60000193
      sp : c0725db8  ip : 00000000  fp : c0725df4
      r10: 00000001  r9 : 00000193  r8 : ef3ccab4
      r7 : ef3cca10  r6 : eea4586c  r5 : 00000000  r4 : ef19ceb4
      r3 : 00000000  r2 : 0000009c  r1 : c0725dc4  r0 : ef19ceb4
      
      This patch adds a condition to avoid the dereference.
      
      Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0a76bf60
    • Alex Deucher's avatar
      drm/radeon: add a dpm quirk for all R7 370 parts · 374ab4ba
      Alex Deucher authored
      commit 0e5585dc upstream.
      
      Higher mclk values are not stable due to a bug somewhere.
      Limit them for now.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      374ab4ba
    • Alex Deucher's avatar
    • Guenter Roeck's avatar
      hwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated · 57dbfea6
      Guenter Roeck authored
      commit 3c2e2266 upstream.
      
      arm:pxa_defconfig can result in the following crash if the max1111 driver
      is not instantiated.
      
      Unhandled fault: page domain fault (0x01b) at 0x00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: : 1b [#1] PREEMPT ARM
      Modules linked in:
      CPU: 0 PID: 300 Comm: kworker/0:1 Not tainted 4.5.0-01301-g1701f680 #10
      Hardware name: SHARP Akita
      Workqueue: events sharpsl_charge_toggle
      task: c390a000 ti: c391e000 task.ti: c391e000
      PC is at max1111_read_channel+0x20/0x30
      LR is at sharpsl_pm_pxa_read_max1111+0x2c/0x3c
      pc : [<c03aaab0>]    lr : [<c0024b50>]    psr: 20000013
      ...
      [<c03aaab0>] (max1111_read_channel) from [<c0024b50>]
      					(sharpsl_pm_pxa_read_max1111+0x2c/0x3c)
      [<c0024b50>] (sharpsl_pm_pxa_read_max1111) from [<c00262e0>]
      					(spitzpm_read_devdata+0x5c/0xc4)
      [<c00262e0>] (spitzpm_read_devdata) from [<c0024094>]
      					(sharpsl_check_battery_temp+0x78/0x110)
      [<c0024094>] (sharpsl_check_battery_temp) from [<c0024f9c>]
      					(sharpsl_charge_toggle+0x48/0x110)
      [<c0024f9c>] (sharpsl_charge_toggle) from [<c004429c>]
      					(process_one_work+0x14c/0x48c)
      [<c004429c>] (process_one_work) from [<c0044618>] (worker_thread+0x3c/0x5d4)
      [<c0044618>] (worker_thread) from [<c004a238>] (kthread+0xd0/0xec)
      [<c004a238>] (kthread) from [<c000a670>] (ret_from_fork+0x14/0x24)
      
      This can occur because the SPI controller driver (SPI_PXA2XX) is built as
      module and thus not necessarily loaded. While building SPI_PXA2XX into the
      kernel would make the problem disappear, it appears prudent to ensure that
      the driver is instantiated before accessing its data structures.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      57dbfea6
    • Joseph Qi's avatar
      ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list · cea90036
      Joseph Qi authored
      commit be12b299 upstream.
      
      When master handles convert request, it queues ast first and then
      returns status.  This may happen that the ast is sent before the request
      status because the above two messages are sent by two threads.  And
      right after the ast is sent, if master down, it may trigger BUG in
      dlm_move_lockres_to_recovery_list in the requested node because ast
      handler moves it to grant list without clear lock->convert_pending.  So
      remove BUG_ON statement and check if the ast is processed in
      dlmconvert_remote.
      Signed-off-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Reported-by: default avatarYiwen Jiang <jiangyiwen@huawei.com>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Tariq Saeed <tariq.x.saeed@oracle.com>
      Cc: Junxiao Bi <junxiao.bi@oracle.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>
      cea90036
    • Joseph Qi's avatar
      ocfs2/dlm: fix race between convert and recovery · 6af67aba
      Joseph Qi authored
      commit ac7cf246 upstream.
      
      There is a race window between dlmconvert_remote and
      dlm_move_lockres_to_recovery_list, which will cause a lock with
      OCFS2_LOCK_BUSY in grant list, thus system hangs.
      
      dlmconvert_remote
      {
              spin_lock(&res->spinlock);
              list_move_tail(&lock->list, &res->converting);
              lock->convert_pending = 1;
              spin_unlock(&res->spinlock);
      
              status = dlm_send_remote_convert_request();
              >>>>>> race window, master has queued ast and return DLM_NORMAL,
                     and then down before sending ast.
                     this node detects master down and calls
                     dlm_move_lockres_to_recovery_list, which will revert the
                     lock to grant list.
                     Then OCFS2_LOCK_BUSY won't be cleared as new master won't
                     send ast any more because it thinks already be authorized.
      
              spin_lock(&res->spinlock);
              lock->convert_pending = 0;
              if (status != DLM_NORMAL)
                      dlm_revert_pending_convert(res, lock);
              spin_unlock(&res->spinlock);
      }
      
      In this case, check if res->state has DLM_LOCK_RES_RECOVERING bit set
      (res is still in recovering) or res master changed (new master has
      finished recovery), reset the status to DLM_RECOVERING, then it will
      retry convert.
      Signed-off-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Reported-by: default avatarYiwen Jiang <jiangyiwen@huawei.com>
      Reviewed-by: default avatarJunxiao Bi <junxiao.bi@oracle.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Tariq Saeed <tariq.x.saeed@oracle.com>
      Cc: Junxiao Bi <junxiao.bi@oracle.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>
      6af67aba
    • Alex Deucher's avatar
    • Guenter Roeck's avatar
      MAINTAINERS: Update mailing list and web page for hwmon subsystem · a067190d
      Guenter Roeck authored
      commit 968ce1b1 upstream.
      
      The old web page for the hwmon subsystem is no longer operational,
      and the mailing list has become unreliable. Move both to kernel.org.
      Reviewed-by: default avatarJean Delvare <jdelvare@suse.de>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      [bwh: Backported to 3.16: the set of hwmon drivers is different, so do a
       search-and-replace for the same addresses]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a067190d
    • Petri Gynther's avatar
      net: bcmgenet: fix skb_len in bcmgenet_xmit_single() · ab020c41
      Petri Gynther authored
      commit 7dd39913 upstream.
      
      skb_len needs to be skb_headlen(skb) in bcmgenet_xmit_single().
      
      Fragmented skbs can have only Ethernet + IP + TCP headers (14+20+20=54 bytes)
      in the linear buffer, followed by the rest in fragments. Bumping skb_len to
      ETH_ZLEN would be incorrect for this case, as it would introduce garbage
      between TCP header and the fragment data.
      
      This also works with regular/non-fragmented small packets < ETH_ZLEN bytes.
      Successfully tested this on GENETv3 with 42-byte ARP frames.
      
      For testing, I used:
      ethtool -K eth0 tx-checksum-ipv4 off
      ethtool -K eth0 tx-checksum-ipv6 off
      echo 0 > /proc/sys/net/ipv4/tcp_timestamps
      
      Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
      Signed-off-by: default avatarPetri Gynther <pgynther@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ab020c41
    • Guillaume Nault's avatar
      ppp: take reference on channels netns · 6ab3a433
      Guillaume Nault authored
      commit 1f461dcd upstream.
      
      Let channels hold a reference on their network namespace.
      Some channel types, like ppp_async and ppp_synctty, can have their
      userspace controller running in a different namespace. Therefore they
      can't rely on them to preclude their netns from being removed from
      under them.
      
      ==================================================================
      BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at
      addr ffff880064e217e0
      Read of size 8 by task syz-executor/11581
      =============================================================================
      BUG net_namespace (Not tainted): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906
      [<      none      >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
      [<      none      >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
      [<     inline     >] slab_alloc_node kernel/mm/slub.c:2532
      [<     inline     >] slab_alloc kernel/mm/slub.c:2574
      [<      none      >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579
      [<     inline     >] kmem_cache_zalloc kernel/include/linux/slab.h:597
      [<     inline     >] net_alloc kernel/net/core/net_namespace.c:325
      [<      none      >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360
      [<      none      >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95
      [<      none      >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150
      [<      none      >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451
      [<     inline     >] copy_process kernel/kernel/fork.c:1274
      [<      none      >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723
      [<     inline     >] SYSC_clone kernel/kernel/fork.c:1832
      [<      none      >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826
      [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185
      
      INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631
      [<      none      >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
      [<     inline     >] slab_free kernel/mm/slub.c:2805
      [<      none      >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814
      [<     inline     >] net_free kernel/net/core/net_namespace.c:341
      [<      none      >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348
      [<      none      >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448
      [<      none      >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
      [<      none      >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
      [<      none      >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
      [<      none      >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
      INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000
      flags=0x5fffc0000004080
      INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200
      
      CPU: 1 PID: 11581 Comm: syz-executor Tainted: G    B           4.4.0+
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
       00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300
       ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054
       ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000
      Call Trace:
       [<     inline     >] __dump_stack kernel/lib/dump_stack.c:15
       [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
       [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
       [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
       [<     inline     >] print_address_description kernel/mm/kasan/report.c:138
       [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
       [<     inline     >] kasan_report kernel/mm/kasan/report.c:259
       [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280
       [<     inline     >] ? ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293
       [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241
       [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000
       [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478
       [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744
       [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772
       [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901
       [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688
       [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208
       [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244
       [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115
       [<     inline     >] exit_task_work kernel/include/linux/task_work.h:21
       [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750
       [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
       [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357
       [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550
       [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145
       [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880
       [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307
       [<     inline     >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113
       [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158
       [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712
       [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655
       [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165
       [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692
       [<     inline     >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099
       [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678
       [<     inline     >] ? context_switch kernel/kernel/sched/core.c:2807
       [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
       [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247
       [<     inline     >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282
       [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344
       [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281
      Memory state around the buggy address:
       ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Fixes: 273ec51d ("net: ppp_generic - introduce net-namespace functionality v2")
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Reviewed-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6ab3a433
    • John Dahlstrom's avatar
      ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list · cc9a6f5b
      John Dahlstrom authored
      commit 4db9675d upstream.
      
      Some Lenovo ideapad models lack a physical rfkill switch.
      On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK,
      ideapad-laptop would wrongly report all radios as blocked by
      hardware which caused wireless network connections to fail.
      
      Add these models without an rfkill switch to the no_hw_rfkill list.
      Signed-off-by: default avatarJohn Dahlstrom <jodarom@sdf.org>
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cc9a6f5b
    • Bobi Mihalca's avatar
      ALSA: hda - Apply fix for white noise on Asus N550JV, too · de1872f4
      Bobi Mihalca authored
      commit 83a9efb5 upstream.
      
      Apply the new fixup that is used for ASUS N750JV to another similar
      model, N500JV, too, for reducing the headphone noise.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181Signed-off-by: default avatarBobi Mihalca <bobbymihalca@touchtech.ro>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      de1872f4
    • Bobi Mihalca's avatar
      ALSA: hda - Fix white noise on Asus N750JV headphone · ce72835b
      Bobi Mihalca authored
      commit 9d4dc584 upstream.
      
      For reducing the noise from the headphone output on ASUS N750JV,
      call the existing fixup, alc_fixup_auto_mute_via_amp(), additionally.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181Signed-off-by: default avatarBobi Mihalca <bobbymihalca@touchtech.ro>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ce72835b
    • Bobi Mihalca's avatar
      ALSA: hda - Asus N750JV external subwoofer fixup · 932f7bd3
      Bobi Mihalca authored
      commit 70cf2cbd upstream.
      
      ASUS N750JV needs the same fixup as N550 for enabling its subwoofer.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181Signed-off-by: default avatarBobi Mihalca <bobbymihalca@touchtech.ro>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      932f7bd3
    • Aurelien Jacquiot's avatar
      rapidio/rionet: fix deadlock on SMP · 4fedde54
      Aurelien Jacquiot authored
      commit 36915976 upstream.
      
      Fix deadlocking during concurrent receive and transmit operations on SMP
      platforms caused by the use of incorrect lock: on transmit 'tx_lock'
      spinlock should be used instead of 'lock' which is used for receive
      operation.
      
      This fix is applicable to kernel versions starting from v2.15.
      Signed-off-by: default avatarAurelien Jacquiot <a-jacquiot@ti.com>
      Signed-off-by: default avatarAlexandre Bounine <alexandre.bounine@idt.com>
      Cc: Matt Porter <mporter@kernel.crashing.org>
      Cc: Andre van Herk <andre.van.herk@prodrive-technologies.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>
      4fedde54
    • Jann Horn's avatar
      fs/coredump: prevent fsuid=0 dumps into user-controlled directories · b80e0e86
      Jann Horn authored
      commit 378c6520 upstream.
      
      This commit fixes the following security hole affecting systems where
      all of the following conditions are fulfilled:
      
       - The fs.suid_dumpable sysctl is set to 2.
       - The kernel.core_pattern sysctl's value starts with "/". (Systems
         where kernel.core_pattern starts with "|/" are not affected.)
       - Unprivileged user namespace creation is permitted. (This is
         true on Linux >=3.8, but some distributions disallow it by
         default using a distro patch.)
      
      Under these conditions, if a program executes under secure exec rules,
      causing it to run with the SUID_DUMP_ROOT flag, then unshares its user
      namespace, changes its root directory and crashes, the coredump will be
      written using fsuid=0 and a path derived from kernel.core_pattern - but
      this path is interpreted relative to the root directory of the process,
      allowing the attacker to control where a coredump will be written with
      root privileges.
      
      To fix the security issue, always interpret core_pattern for dumps that
      are written under SUID_DUMP_ROOT relative to the root directory of init.
      Signed-off-by: default avatarJann Horn <jann@thejh.net>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Oleg Nesterov <oleg@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: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b80e0e86
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Fix trace_printk() to print when not using bprintk() · fcb91695
      Steven Rostedt (Red Hat) authored
      commit 3debb0a9 upstream.
      
      The trace_printk() code will allocate extra buffers if the compile detects
      that a trace_printk() is used. To do this, the format of the trace_printk()
      is saved to the __trace_printk_fmt section, and if that section is bigger
      than zero, the buffers are allocated (along with a message that this has
      happened).
      
      If trace_printk() uses a format that is not a constant, and thus something
      not guaranteed to be around when the print happens, the compiler optimizes
      the fmt out, as it is not used, and the __trace_printk_fmt section is not
      filled. This means the kernel will not allocate the special buffers needed
      for the trace_printk() and the trace_printk() will not write anything to the
      tracing buffer.
      
      Adding a "__used" to the variable in the __trace_printk_fmt section will
      keep it around, even though it is set to NULL. This will keep the string
      from being printed in the debugfs/tracing/printk_formats section as it is
      not needed.
      Reported-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Fixes: 07d777fe "tracing: Add percpu buffers for trace_printk()"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      fcb91695
    • Paolo Bonzini's avatar
      KVM: fix spin_lock_init order on x86 · 89c23ae1
      Paolo Bonzini authored
      commit e9ad4ec8 upstream.
      
      Moving the initialization earlier is needed in 4.6 because
      kvm_arch_init_vm is now using mmu_lock, causing lockdep to
      complain:
      
      [  284.440294] INFO: trying to register non-static key.
      [  284.445259] the code is fine but needs lockdep annotation.
      [  284.450736] turning off the locking correctness validator.
      ...
      [  284.528318]  [<ffffffff810aecc3>] lock_acquire+0xd3/0x240
      [  284.533733]  [<ffffffffa0305aa0>] ? kvm_page_track_register_notifier+0x20/0x60 [kvm]
      [  284.541467]  [<ffffffff81715581>] _raw_spin_lock+0x41/0x80
      [  284.546960]  [<ffffffffa0305aa0>] ? kvm_page_track_register_notifier+0x20/0x60 [kvm]
      [  284.554707]  [<ffffffffa0305aa0>] kvm_page_track_register_notifier+0x20/0x60 [kvm]
      [  284.562281]  [<ffffffffa02ece70>] kvm_mmu_init_vm+0x20/0x30 [kvm]
      [  284.568381]  [<ffffffffa02dbf7a>] kvm_arch_init_vm+0x1ea/0x200 [kvm]
      [  284.574740]  [<ffffffffa02bff3f>] kvm_dev_ioctl+0xbf/0x4d0 [kvm]
      
      However, it also helps fixing a preexisting problem, which is why this
      patch is also good for stable kernels: kvm_create_vm was incrementing
      current->mm->mm_count but not decrementing it at the out_err label (in
      case kvm_init_mmu_notifier failed).  The new initialization order makes
      it possible to add the required mmdrop without adding a new error label.
      Reported-by: default avatarBorislav Petkov <bp@alien8.de>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      89c23ae1
    • Paolo Bonzini's avatar
      KVM: VMX: avoid guest hang on invalid invept instruction · 0b5b0458
      Paolo Bonzini authored
      commit 2849eb4f upstream.
      
      A guest executing an invalid invept instruction would hang
      because the instruction pointer was not updated.
      
      Fixes: bfd0a56bReviewed-by: default avatarDavid Matlack <dmatlack@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0b5b0458
    • Himanshu Madhani's avatar
      target: Fix target_release_cmd_kref shutdown comp leak · 34a20235
      Himanshu Madhani authored
      commit 5e47f198 upstream.
      
      This patch fixes an active I/O shutdown bug for fabric
      drivers using target_wait_for_sess_cmds(), where se_cmd
      descriptor shutdown would result in hung tasks waiting
      indefinitely for se_cmd->cmd_wait_comp to complete().
      
      To address this bug, drop the incorrect list_del_init()
      usage in target_wait_for_sess_cmds() and always complete()
      during se_cmd target_release_cmd_kref() put, in order to
      let caller invoke the final fabric release callback
      into se_cmd->se_tfo->release_cmd() code.
      Reported-by: default avatarHimanshu Madhani <himanshu.madhani@qlogic.com>
      Tested-by: default avatarHimanshu Madhani <himanshu.madhani@qlogic.com>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@qlogic.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      34a20235
    • Dan Carpenter's avatar
      mdio-sun4i: oops in error handling in probe · 1d5dd57e
      Dan Carpenter authored
      commit 227f33be upstream.
      
      We could end up dereferencing an error pointer when we call
      regulator_disable().
      
      Fixes: 4bdcb1dd ('net: Add MDIO bus driver for the Allwinner EMAC')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1d5dd57e
    • Peter Zijlstra's avatar
      bitops: Do not default to __clear_bit() for __clear_bit_unlock() · 75033f02
      Peter Zijlstra authored
      commit f75d4864 upstream.
      
      __clear_bit_unlock() is a special little snowflake. While it carries the
      non-atomic '__' prefix, it is specifically documented to pair with
      test_and_set_bit() and therefore should be 'somewhat' atomic.
      
      Therefore the generic implementation of __clear_bit_unlock() cannot use
      the fully non-atomic __clear_bit() as a default.
      
      If an arch is able to do better; is must provide an implementation of
      __clear_bit_unlock() itself.
      
      Specifically, this came up as a result of hackbench livelock'ing in
      slab_lock() on ARC with SMP + SLUB + !LLSC.
      
      The issue was incorrect pairing of atomic ops.
      
       slab_lock() -> bit_spin_lock() -> test_and_set_bit()
       slab_unlock() -> __bit_spin_unlock() -> __clear_bit()
      
      The non serializing __clear_bit() was getting "lost"
      
       80543b8e:	ld_s       r2,[r13,0] <--- (A) Finds PG_locked is set
       80543b90:	or         r3,r2,1    <--- (B) other core unlocks right here
       80543b94:	st_s       r3,[r13,0] <--- (C) sets PG_locked (overwrites unlock)
      
      Fixes ARC STAR 9000817404 (and probably more).
      Reported-by: default avatarVineet Gupta <Vineet.Gupta1@synopsys.com>
      Tested-by: default avatarVineet Gupta <Vineet.Gupta1@synopsys.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: James E.J. Bottomley <jejb@parisc-linux.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160309114054.GJ6356@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      75033f02