1. 17 Feb, 2016 39 commits
    • Kailang Yang's avatar
      ALSA: hda/realtek - New codec support of ALC225 · 1732e586
      Kailang Yang authored
      commit 4231430d upstream.
      
      Add new support for ALC225, yet another variant of ALC298 codec.
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1732e586
    • Takashi Iwai's avatar
      ALSA: rawmidi: Fix race at copying & updating the position · 49ba9e22
      Takashi Iwai authored
      commit 81f57754 upstream.
      
      The rawmidi read and write functions manage runtime stream status
      such as runtime->appl_ptr and runtime->avail.  These point where to
      copy the new data and how many bytes have been copied (or to be
      read).  The problem is that rawmidi read/write call copy_from_user()
      or copy_to_user(), and the runtime spinlock is temporarily unlocked
      and relocked while copying user-space.  Since the current code
      advances and updates the runtime status after the spin unlock/relock,
      the copy and the update may be asynchronous, and eventually
      runtime->avail might go to a negative value when many concurrent
      accesses are done.  This may lead to memory corruption in the end.
      
      For fixing this race, in this patch, the status update code is
      performed in the same lock before the temporary unlock.  Also, the
      spinlock is now taken more widely in snd_rawmidi_kernel_read1() for
      protecting more properly during the whole operation.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+b-dCmNf1GpgPKfDO0ih+uZCL2JV4__j-r1kdhPLSgQCQ@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49ba9e22
    • Takashi Iwai's avatar
      ALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check · 8af97f7c
      Takashi Iwai authored
      commit cc85f7a6 upstream.
      
      NULL user-space buffer can be passed even in a normal path, thus it's
      not good to spew a kernel warning with stack trace at each time.
      Just drop snd_BUG_ON() macro usage there.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+YfVJ3L+q0i-4vyQVyyPD7V=OMX0PWPi29x9Bo3QaBLdw@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8af97f7c
    • Takashi Iwai's avatar
      ALSA: rawmidi: Make snd_rawmidi_transmit() race-free · c3f8a500
      Takashi Iwai authored
      commit 06ab3003 upstream.
      
      A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by
      syzkaller fuzzer:
        WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
       [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
       [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
       [<ffffffff84f80bd5>] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136
       [<ffffffff84fdb3c1>] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163
       [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
       [<ffffffff84f87ed9>] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223
       [<ffffffff84f89fd3>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273
       [<ffffffff817b0323>] __vfs_write+0x113/0x480 fs/read_write.c:528
       [<ffffffff817b1db7>] vfs_write+0x167/0x4a0 fs/read_write.c:577
       [<     inline     >] SYSC_write fs/read_write.c:624
       [<ffffffff817b50a1>] SyS_write+0x111/0x220 fs/read_write.c:616
       [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185
      
      Also a similar warning is found but in another path:
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff82be2c0d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
       [<ffffffff81355139>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
       [<ffffffff81355369>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
       [<ffffffff8527e69a>] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133
       [<ffffffff8527e851>] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163
       [<ffffffff852d9046>] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185
       [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
       [<ffffffff85285a0b>] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252
       [<ffffffff85287b73>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302
       [<ffffffff817ba5f3>] __vfs_write+0x113/0x480 fs/read_write.c:528
       [<ffffffff817bc087>] vfs_write+0x167/0x4a0 fs/read_write.c:577
       [<     inline     >] SYSC_write fs/read_write.c:624
       [<ffffffff817bf371>] SyS_write+0x111/0x220 fs/read_write.c:616
       [<ffffffff86660276>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185
      
      In the former case, the reason is that virmidi has an open code
      calling snd_rawmidi_transmit_ack() with the value calculated outside
      the spinlock.   We may use snd_rawmidi_transmit() in a loop just for
      consuming the input data, but even there, there is a race between
      snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack().
      
      Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and
      snd_rawmidi_tranmit_ack() separately without protection, so they are
      racy as well.
      
      The patch tries to address these issues by the following ways:
      - Introduce the unlocked versions of snd_rawmidi_transmit_peek() and
        snd_rawmidi_transmit_ack() to be called inside the explicit lock.
      - Rewrite snd_rawmidi_transmit() to be race-free (the former case).
      - Make the split calls (the latter case) protected in the rawmidi spin
        lock.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+YPq1+cYLkadwjWa5XjzF1_Vki1eHnVn-Lm0hzhSpu5PA@mail.gmail.com
      BugLink: http://lkml.kernel.org/r/CACT4Y+acG4iyphdOZx47Nyq_VHGbpJQK-6xNpiqUjaZYqsXOGw@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3f8a500
    • Takashi Iwai's avatar
      ALSA: seq: Degrade the error message for too many opens · aef1181d
      Takashi Iwai authored
      commit da10816e upstream.
      
      ALSA OSS sequencer spews a kernel error message ("ALSA: seq_oss: too
      many applications") when user-space tries to open more than the
      limit.  This means that it can easily fill the log buffer.
      
      Since it's merely a normal error, it's safe to suppress it via
      pr_debug() instead.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aef1181d
    • Takashi Iwai's avatar
      ALSA: seq: Fix incorrect sanity check at snd_seq_oss_synth_cleanup() · fa8fcbe3
      Takashi Iwai authored
      commit 59915133 upstream.
      
      ALSA sequencer OSS emulation code has a sanity check for currently
      opened devices, but there is a thinko there, eventually it spews
      warnings and skips the operation wrongly like:
        WARNING: CPU: 1 PID: 7573 at sound/core/seq/oss/seq_oss_synth.c:311
      
      Fix this off-by-one error.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa8fcbe3
    • Takashi Iwai's avatar
      ALSA: dummy: Disable switching timer backend via sysfs · d0cc6515
      Takashi Iwai authored
      commit 7ee96216 upstream.
      
      ALSA dummy driver can switch the timer backend between system timer
      and hrtimer via its hrtimer module option.  This can be also switched
      dynamically via sysfs, but it may lead to a memory corruption when
      switching is done while a PCM stream is running; the stream instance
      for the newly switched timer method tries to access the memory that
      was allocated by another timer method although the sizes differ.
      
      As the simplest fix, this patch just disables the switch via sysfs by
      dropping the writable bit.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+ZGEeEBntHW5WHn2GoeE0G_kRrCmUh6=dWyy-wfzvuJLg@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0cc6515
    • Takashi Iwai's avatar
      ALSA: compress: Disable GET_CODEC_CAPS ioctl for some architectures · 1963ffef
      Takashi Iwai authored
      commit 462b3f16 upstream.
      
      Some architectures like PowerPC can handle the maximum struct size in
      an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by
      SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit.  This
      problem was revealed recently by a powerpc change, as it's now treated
      as a fatal build error.
      
      This patch is a stop-gap for that: for architectures with less than 14
      bit ioctl struct size, get rid of the handling of the relevant ioctl.
      We should provide an alternative equivalent ioctl code later, but for
      now just paper over it.  Luckily, the compress API hasn't been used on
      such architectures, so the impact must be effectively zero.
      Reviewed-by: default avatarMark Brown <broonie@kernel.org>
      Acked-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1963ffef
    • Libin Yang's avatar
      ALSA: hda - disable dynamic clock gating on Broxton before reset · fc3e5563
      Libin Yang authored
      commit 6639484d upstream.
      
      On Broxton, to make sure the reset controller works properly,
      MISCBDCGE bit (bit 6) in CGCTL (0x48) of PCI configuration space
      need be cleared before reset and set back to 1 after reset.
      Otherwise, it may prevent the CORB/RIRB logic from being reset.
      Signed-off-by: default avatarLibin Yang <libin.yang@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fc3e5563
    • Takashi Iwai's avatar
      ALSA: Add missing dependency on CONFIG_SND_TIMER · 9f080d37
      Takashi Iwai authored
      commit 61595dca upstream.
      
      Since the build of PCM timer may be disabled via Kconfig now, each
      driver that provides a timer interface needs to set CONFIG_SND_TIMER
      explicitly.  Otherwise it may get a build error due to missing
      symbol.
      
      Fixes: 90bbaf66 ('ALSA: timer: add config item to export PCM timer disabling for expert')
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f080d37
    • Lucas Tanure's avatar
      ALSA: bebob: Use a signed return type for get_formation_index · 2f32c8c0
      Lucas Tanure authored
      commit 07905298 upstream.
      
      The return type "unsigned int" was used by the get_formation_index function
      despite of the aspect that it will eventually return a negative	error code.
      So, change to signed int and get index by reference in the parameters.
      
      Done with the help of Coccinelle.
      
      [Fix the missing braces suggested by Julia Lawall -- tiwai]
      Signed-off-by: default avatarLucas Tanure <tanure@linux.com>
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Tested-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f32c8c0
    • Andrey Konovalov's avatar
      ALSA: usb-audio: avoid freeing umidi object twice · fbb430c5
      Andrey Konovalov authored
      commit 07d86ca9 upstream.
      
      The 'umidi' object will be free'd on the error path by snd_usbmidi_free()
      when tearing down the rawmidi interface. So we shouldn't try to free it
      in snd_usbmidi_create() after having registered the rawmidi interface.
      
      Found by KASAN.
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@gmail.com>
      Acked-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fbb430c5
    • Jurgen Kramer's avatar
      ALSA: usb-audio: Add native DSD support for PS Audio NuWave DAC · bb1066e6
      Jurgen Kramer authored
      commit ad678b4c upstream.
      
      This patch adds native DSD support for the PS Audio NuWave DAC.
      Signed-off-by: default avatarJurgen Kramer <gtmkramer@xs4all.nl>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb1066e6
    • Jurgen Kramer's avatar
      ALSA: usb-audio: Fix OPPO HA-1 vendor ID · 29a928ff
      Jurgen Kramer authored
      commit 5327d6ba upstream.
      
      In my patch adding native DSD support for the Oppo HA-1, the wrong vendor ID got
      through. This patch fixes the vendor ID and aligns the comment.
      
      Fixes: a4eae3a5 ('ALSA: usb: Add native DSD support for Oppo HA-1')
      Signed-off-by: default avatarJurgen Kramer <gtmkramer@xs4all.nl>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29a928ff
    • Lev Lybin's avatar
      ALSA: usb-audio: Add quirk for Microsoft LifeCam HD-6000 · 11e7913d
      Lev Lybin authored
      commit 1b3c993a upstream.
      
      Microsoft LifeCam HD-6000 (045e:076f) requires the similar quirk for
      avoiding the stall due to the invalid sample rate reads.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111491Signed-off-by: default avatarLev Lybin <lev.lybin@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11e7913d
    • Guillaume Fougnies's avatar
      ALSA: usb-audio: Fix TEAC UD-501/UD-503/NT-503 usb delay · 1eb90d90
      Guillaume Fougnies authored
      commit 5a4ff9ec upstream.
      
      TEAC UD-501/UD-503/NT-503 fail to switch properly between different
      rate/format. Similar to 'Playback Design', this patch corrects the
      invalid clock source error for TEAC products and avoids complete
      freeze of the usb interface of 503 series.
      Signed-off-by: default avatarGuillaume Fougnies <guillaume@eulerian.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1eb90d90
    • Thomas Gleixner's avatar
      hrtimer: Handle remaining time proper for TIME_LOW_RES · dd0d5115
      Thomas Gleixner authored
      commit 203cbf77 upstream.
      
      If CONFIG_TIME_LOW_RES is enabled we add a jiffie to the relative timeout to
      prevent short sleeps, but we do not account for that in interfaces which
      retrieve the remaining time.
      
      Helge observed that timerfd can return a remaining time larger than the
      relative timeout. That's not expected and breaks userland test programs.
      
      Store the information that the timer was armed relative and provide functions
      to adjust the remaining time. To avoid bloating the hrtimer struct make state
      a u8, which as a bonus results in better code on x86 at least.
      Reported-and-tested-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: linux-m68k@lists.linux-m68k.org
      Cc: dhowells@redhat.com
      Link: http://lkml.kernel.org/r/20160114164159.273328486@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd0d5115
    • Dan Williams's avatar
      md/raid: only permit hot-add of compatible integrity profiles · 2c4b95da
      Dan Williams authored
      commit 1501efad upstream.
      
      It is not safe for an integrity profile to be changed while i/o is
      in-flight in the queue.  Prevent adding new disks or otherwise online
      spares to an array if the device has an incompatible integrity profile.
      
      The original change to the blk_integrity_unregister implementation in
      md, commmit c7bfced9 "md: suspend i/o during runtime
      blk_integrity_unregister" introduced an immediate hang regression.
      
      This policy of disallowing changes the integrity profile once one has
      been established is shared with DM.
      
      Here is an abbreviated log from a test run that:
      1/ Creates a degraded raid1 with an integrity-enabled device (pmem0s) [   59.076127]
      2/ Tries to add an integrity-disabled device (pmem1m) [   90.489209]
      3/ Retries with an integrity-enabled device (pmem1s) [  205.671277]
      
      [   59.076127] md/raid1:md0: active with 1 out of 2 mirrors
      [   59.078302] md: data integrity enabled on md0
      [..]
      [   90.489209] md0: incompatible integrity profile for pmem1m
      [..]
      [  205.671277] md: super_written gets error=-5
      [  205.677386] md/raid1:md0: Disk failure on pmem1m, disabling device.
      [  205.677386] md/raid1:md0: Operation continuing on 1 devices.
      [  205.683037] RAID1 conf printout:
      [  205.684699]  --- wd:1 rd:2
      [  205.685972]  disk 0, wo:0, o:1, dev:pmem0s
      [  205.687562]  disk 1, wo:1, o:1, dev:pmem1s
      [  205.691717] md: recovery of RAID array md0
      
      Fixes: c7bfced9 ("md: suspend i/o during runtime blk_integrity_unregister")
      Cc: Mike Snitzer <snitzer@redhat.com>
      Reported-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2c4b95da
    • Javier Martinez Canillas's avatar
      media: i2c: Don't export ir-kbd-i2c module alias · 3809abba
      Javier Martinez Canillas authored
      commit 329d88da upstream.
      
      This is a partial revert of commit ed8d1cf0 ("[media] Export I2C
      module alias information in missing drivers") that exported the module
      aliases for the I2C drivers that were missing to make autoload to work.
      
      But there is a bug report [0] that auto load of the ir-kbd-i2c driver
      cause the Hauppauge HD-PVR driver to not behave correctly.
      
      This is a hdpvr latent bug that was just exposed by ir-kbd-i2c module
      autoloading working and will also happen if the I2C driver is built-in
      or a user calls modprobe to load the module and register the driver.
      
      But there is a regression experimented by users so until the real bug
      is fixed, let's not export the module alias for the ir-kbd-i2c driver
      even when this just masks the actual issue.
      
      [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810726
      
      Fixes: ed8d1cf0 ("[media] Export I2C module alias information in missing drivers")
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3809abba
    • Helge Deller's avatar
      parisc: Fix __ARCH_SI_PREAMBLE_SIZE · 702ea6de
      Helge Deller authored
      commit e60fc5aa upstream.
      
      On a 64bit kernel build the compiler aligns the _sifields union in the
      struct siginfo_t on a 64bit address. The __ARCH_SI_PREAMBLE_SIZE define
      compensates for this alignment and thus fixes the wait testcase of the
      strace package.
      
      The symptoms of a wrong __ARCH_SI_PREAMBLE_SIZE value is that
      _sigchld.si_stime variable is missed to be copied and thus after a
      copy_siginfo() will have uninitialized values.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      702ea6de
    • Helge Deller's avatar
      parisc: Protect huge page pte changes with spinlocks · 583097a3
      Helge Deller authored
      commit b0e55131 upstream.
      
      PA-RISC doesn't have atomic instructions to modify page table entries, so it
      takes spinlock in the TLB handler and modifies the page table entry
      non-atomically. If you modify the page table entry without the spinlock, you
      may race with TLB handler on another CPU and your modification may be lost.
      Protect against that with usage of purge_tlb_start() and purge_tlb_end() which
      handles the TLB spinlock.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      583097a3
    • Tejun Heo's avatar
      printk: do cond_resched() between lines while outputting to consoles · a623f87a
      Tejun Heo authored
      commit 8d91f8b1 upstream.
      
      @console_may_schedule tracks whether console_sem was acquired through
      lock or trylock.  If the former, we're inside a sleepable context and
      console_conditional_schedule() performs cond_resched().  This allows
      console drivers which use console_lock for synchronization to yield
      while performing time-consuming operations such as scrolling.
      
      However, the actual console outputting is performed while holding
      irq-safe logbuf_lock, so console_unlock() clears @console_may_schedule
      before starting outputting lines.  Also, only a few drivers call
      console_conditional_schedule() to begin with.  This means that when a
      lot of lines need to be output by console_unlock(), for example on a
      console registration, the task doing console_unlock() may not yield for
      a long time on a non-preemptible kernel.
      
      If this happens with a slow console devices, for example a serial
      console, the outputting task may occupy the cpu for a very long time.
      Long enough to trigger softlockup and/or RCU stall warnings, which in
      turn pile more messages, sometimes enough to trigger the next cycle of
      warnings incapacitating the system.
      
      Fix it by making console_unlock() insert cond_resched() between lines if
      @console_may_schedule.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarCalvin Owens <calvinowens@fb.com>
      Acked-by: default avatarJan Kara <jack@suse.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Cc: Kyle McMartin <kyle@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a623f87a
    • Steven Rostedt's avatar
      tracing/stacktrace: Show entire trace if passed in function not found · bf46aa7e
      Steven Rostedt authored
      commit 6ccd8371 upstream.
      
      When a max stack trace is discovered, the stack dump is saved. In order to
      not record the overhead of the stack tracer, the ip of the traced function
      is looked for within the dump. The trace is started from the location of
      that function. But if for some reason the ip is not found, the entire stack
      trace is then truncated. That's not very useful. Instead, print everything
      if the ip of the traced function is not found within the trace.
      
      This issue showed up on s390.
      
      Link: http://lkml.kernel.org/r/20160129102241.1b3c9c04@gandalf.local.home
      
      Fixes: 72ac426a ("tracing: Clean up stack tracing and fix fentry updates")
      Reported-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Tested-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf46aa7e
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Fix stacktrace skip depth in trace_buffer_unlock_commit_regs() · cc6d9800
      Steven Rostedt (Red Hat) authored
      commit 7717c6be upstream.
      
      While cleaning the stacktrace code I unintentially changed the skip depth of
      trace_buffer_unlock_commit_regs() from 0 to 6. kprobes uses this function,
      and with skipping 6 call backs, it can easily produce no stack.
      
      Here's how I tested it:
      
       # echo 'p:ext4_sync_fs ext4_sync_fs ' > /sys/kernel/debug/tracing/kprobe_events
       # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
       # cat /sys/kernel/debug/trace
                  sync-2394  [005]   502.457060: ext4_sync_fs: (ffffffff81317650)
                  sync-2394  [005]   502.457063: kernel_stack:         <stack trace>
                  sync-2394  [005]   502.457086: ext4_sync_fs: (ffffffff81317650)
                  sync-2394  [005]   502.457087: kernel_stack:         <stack trace>
                  sync-2394  [005]   502.457091: ext4_sync_fs: (ffffffff81317650)
      
      After putting back the skip stack to zero, we have:
      
                  sync-2270  [000]   748.052693: ext4_sync_fs: (ffffffff81317650)
                  sync-2270  [000]   748.052695: kernel_stack:         <stack trace>
       => iterate_supers (ffffffff8126412e)
       => sys_sync (ffffffff8129c4b6)
       => entry_SYSCALL_64_fastpath (ffffffff8181f0b2)
                  sync-2270  [000]   748.053017: ext4_sync_fs: (ffffffff81317650)
                  sync-2270  [000]   748.053019: kernel_stack:         <stack trace>
       => iterate_supers (ffffffff8126412e)
       => sys_sync (ffffffff8129c4b6)
       => entry_SYSCALL_64_fastpath (ffffffff8181f0b2)
                  sync-2270  [000]   748.053381: ext4_sync_fs: (ffffffff81317650)
                  sync-2270  [000]   748.053383: kernel_stack:         <stack trace>
       => iterate_supers (ffffffff8126412e)
       => sys_sync (ffffffff8129c4b6)
       => entry_SYSCALL_64_fastpath (ffffffff8181f0b2)
      
      Fixes: 73dddbb5 "tracing: Only create stacktrace option when STACKTRACE is configured"
      Reported-by: default avatarBrendan Gregg <brendan.d.gregg@gmail.com>
      Tested-by: default avatarBrendan Gregg <brendan.d.gregg@gmail.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc6d9800
    • Christoph Biedl's avatar
      PCI: Fix minimum allocation address overwrite · 695f6c87
      Christoph Biedl authored
      commit 3460baa6 upstream.
      
      Commit 36e097a8 ("PCI: Split out bridge window override of minimum
      allocation address") claimed to do no functional changes but unfortunately
      did: The "min" variable is altered.  At least the AVM A1 PCMCIA adapter was
      no longer detected, breaking ISDN operation.
      
      Use a local copy of "min" to restore the previous behaviour.
      
      [bhelgaas: avoid gcc "?:" extension for portability and readability]
      Fixes: 36e097a8 ("PCI: Split out bridge window override of minimum allocation address")
      Signed-off-by: default avatarChristoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      695f6c87
    • Grygorii Strashko's avatar
      PCI: host: Mark PCIe/PCI (MSI) IRQ cascade handlers as IRQF_NO_THREAD · ad53ae59
      Grygorii Strashko authored
      commit 8ff0ef99 upstream.
      
      On -RT and if kernel is booting with "threadirqs" cmd line parameter,
      PCIe/PCI (MSI) IRQ cascade handlers (like dra7xx_pcie_msi_irq_handler())
      will be forced threaded and, as result, will generate warnings like this:
      
        WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 handle_irq_event_percpu+0x14c/0x174()
        irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts
        Backtrace:
         (warn_slowpath_common) from (warn_slowpath_fmt+0x38/0x40)
         (warn_slowpath_fmt) from (handle_irq_event_percpu+0x14c/0x174)
         (handle_irq_event_percpu) from (handle_irq_event+0x84/0xb8)
         (handle_irq_event) from (handle_simple_irq+0x90/0x118)
         (handle_simple_irq) from (generic_handle_irq+0x30/0x44)
         (generic_handle_irq) from (dra7xx_pcie_msi_irq_handler+0x7c/0x8c)
         (dra7xx_pcie_msi_irq_handler) from (irq_forced_thread_fn+0x28/0x5c)
         (irq_forced_thread_fn) from (irq_thread+0x128/0x204)
      
      This happens because all of them invoke generic_handle_irq() from the
      requested handler.  generic_handle_irq() grabs raw_locks and thus needs to
      run in raw-IRQ context.
      
      This issue was originally reproduced on TI dra7-evem, but, as was
      identified during discussion [1], other hosts can also suffer from this
      issue.  Fix all them at once by marking PCIe/PCI (MSI) IRQ cascade handlers
      IRQF_NO_THREAD explicitly.
      
      [1] http://lkml.kernel.org/r/1448027966-21610-1-git-send-email-grygorii.strashko@ti.com
      
      [bhelgaas: add stable tag, fix typos]
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarLucas Stach <l.stach@pengutronix.de>
      CC: Kishon Vijay Abraham I <kishon@ti.com>
      CC: Jingoo Han <jingoohan1@gmail.com>
      CC: Kukjin Kim <kgene@kernel.org>
      CC: Krzysztof Kozlowski <k.kozlowski@samsung.com>
      CC: Richard Zhu <Richard.Zhu@freescale.com>
      CC: Thierry Reding <thierry.reding@gmail.com>
      CC: Stephen Warren <swarren@wwwdotorg.org>
      CC: Alexandre Courbot <gnurou@gmail.com>
      CC: Simon Horman <horms@verge.net.au>
      CC: Pratyush Anand <pratyush.anand@gmail.com>
      CC: Michal Simek <michal.simek@xilinx.com>
      CC: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
      CC: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ad53ae59
    • Brian Norris's avatar
      mtd: nand: assign reasonable default name for NAND drivers · e18da11f
      Brian Norris authored
      commit f7a8e38f upstream.
      
      Commits such as commit 853f1c58 ("mtd: nand: omap2: show parent
      device structure in sysfs") attempt to rely on the core MTD code to set
      the MTD name based on the parent device. However, nand_base tries to set
      a different default name according to the flash name (e.g., extracted
      from the ONFI parameter page), which means NAND drivers will never make
      use of the MTD defaults. This is not the intention of commit
      853f1c58.
      
      This results in problems when trying to use the cmdline partition
      parser, since the MTD name is different than expected. Let's fix this by
      providing a default NAND name, where possible.
      
      Note that this is not really a great default name in the long run, since
      this means that if there are multiple MTDs attached to the same
      controller device, they will have the same name. But that is an existing
      issue and requires future work on a better controller vs. flash chip
      abstraction to fix properly.
      
      Fixes: 853f1c58 ("mtd: nand: omap2: show parent device structure in sysfs")
      Reported-by: default avatarHeiko Schocher <hs@denx.de>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Reviewed-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Tested-by: default avatarHeiko Schocher <hs@denx.de>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Frans Klaver <fransklaver@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e18da11f
    • Uri Mashiach's avatar
      wlcore/wl12xx: spi: fix NULL pointer dereference (Oops) · c13c92ac
      Uri Mashiach authored
      commit e47301b0 upstream.
      
      Fix the below Oops when trying to modprobe wlcore_spi.
      The oops occurs because the wl1271_power_{off,on}()
      function doesn't check the power() function pointer.
      
      [   23.401447] Unable to handle kernel NULL pointer dereference at
      virtual address 00000000
      [   23.409954] pgd = c0004000
      [   23.412922] [00000000] *pgd=00000000
      [   23.416693] Internal error: Oops: 80000007 [#1] SMP ARM
      [   23.422168] Modules linked in: wl12xx wlcore mac80211 cfg80211
      musb_dsps musb_hdrc usbcore usb_common snd_soc_simple_card evdev joydev
      omap_rng wlcore_spi snd_soc_tlv320aic23_i2c rng_core snd_soc_tlv320aic23
      c_can_platform c_can can_dev snd_soc_davinci_mcasp snd_soc_edma
      snd_soc_omap omap_wdt musb_am335x cpufreq_dt thermal_sys hwmon
      [   23.453253] CPU: 0 PID: 36 Comm: kworker/0:2 Not tainted
      4.2.0-00002-g951efee-dirty #233
      [   23.461720] Hardware name: Generic AM33XX (Flattened Device Tree)
      [   23.468123] Workqueue: events request_firmware_work_func
      [   23.473690] task: de32efc0 ti: de4ee000 task.ti: de4ee000
      [   23.479341] PC is at 0x0
      [   23.482112] LR is at wl12xx_set_power_on+0x28/0x124 [wlcore]
      [   23.488074] pc : [<00000000>]    lr : [<bf2581f0>]    psr: 60000013
      [   23.488074] sp : de4efe50  ip : 00000002  fp : 00000000
      [   23.500162] r10: de7cdd00  r9 : dc848800  r8 : bf27af00
      [   23.505663] r7 : bf27a1a8  r6 : dcbd8a80  r5 : dce0e2e0  r4 :
      dce0d2e0
      [   23.512536] r3 : 00000000  r2 : 00000000  r1 : 00000001  r0 :
      dc848810
      [   23.519412] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
      Segment kernel
      [   23.527109] Control: 10c5387d  Table: 9cb78019  DAC: 00000015
      [   23.533160] Process kworker/0:2 (pid: 36, stack limit = 0xde4ee218)
      [   23.539760] Stack: (0xde4efe50 to 0xde4f0000)
      
      [...]
      
      [   23.665030] [<bf2581f0>] (wl12xx_set_power_on [wlcore]) from
      [<bf25f7ac>] (wlcore_nvs_cb+0x118/0xa4c [wlcore])
      [   23.675604] [<bf25f7ac>] (wlcore_nvs_cb [wlcore]) from [<c04387ec>]
      (request_firmware_work_func+0x30/0x58)
      [   23.685784] [<c04387ec>] (request_firmware_work_func) from
      [<c0058e2c>] (process_one_work+0x1b4/0x4b4)
      [   23.695591] [<c0058e2c>] (process_one_work) from [<c0059168>]
      (worker_thread+0x3c/0x4a4)
      [   23.704124] [<c0059168>] (worker_thread) from [<c005ee68>]
      (kthread+0xd4/0xf0)
      [   23.711747] [<c005ee68>] (kthread) from [<c000f598>]
      (ret_from_fork+0x14/0x3c)
      [   23.719357] Code: bad PC value
      [   23.722760] ---[ end trace 981be8510db9b3a9 ]---
      
      Prevent oops by validationg power() pointer value before
      calling the function.
      Signed-off-by: default avatarUri Mashiach <uri.mashiach@compulab.co.il>
      Acked-by: default avatarIgor Grinberg <grinberg@compulab.co.il>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c13c92ac
    • Uri Mashiach's avatar
      wlcore/wl12xx: spi: fix oops on firmware load · 1463df0f
      Uri Mashiach authored
      commit 9b2761cb upstream.
      
      The maximum chunks used by the function is
      (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE + 1).
      The original commands array had space for
      (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) commands.
      When the last chunk is used (len > 4 * WSPI_MAX_CHUNK_SIZE), the last
      command is stored outside the bounds of the commands array.
      
      Oops 5 (page fault) is generated during current wl1271 firmware load
      attempt:
      
      root@debian-armhf:~# ifconfig wlan0 up
      [  294.312399] Unable to handle kernel paging request at virtual address
      00203fc4
      [  294.320173] pgd = de528000
      [  294.323028] [00203fc4] *pgd=00000000
      [  294.326916] Internal error: Oops: 5 [#1] SMP ARM
      [  294.331789] Modules linked in: bnep rfcomm bluetooth ipv6 arc4 wl12xx
      wlcore mac80211 musb_dsps cfg80211 musb_hdrc usbcore usb_common
      wlcore_spi omap_rng rng_core musb_am335x omap_wdt cpufreq_dt thermal_sys
      hwmon
      [  294.351838] CPU: 0 PID: 1827 Comm: ifconfig Not tainted
      4.2.0-00002-g3e9ad27-dirty #78
      [  294.360154] Hardware name: Generic AM33XX (Flattened Device Tree)
      [  294.366557] task: dc9d6d40 ti: de550000 task.ti: de550000
      [  294.372236] PC is at __spi_validate+0xa8/0x2ac
      [  294.376902] LR is at __spi_sync+0x78/0x210
      [  294.381200] pc : [<c049c760>]    lr : [<c049ebe0>]    psr: 60000013
      [  294.381200] sp : de551998  ip : de5519d8  fp : 00200000
      [  294.393242] r10: de551c8c  r9 : de5519d8  r8 : de3a9000
      [  294.398730] r7 : de3a9258  r6 : de3a9400  r5 : de551a48  r4 :
      00203fbc
      [  294.405577] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 :
      de3a9000
      [  294.412420] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
      Segment user
      [  294.419918] Control: 10c5387d  Table: 9e528019  DAC: 00000015
      [  294.425954] Process ifconfig (pid: 1827, stack limit = 0xde550218)
      [  294.432437] Stack: (0xde551998 to 0xde552000)
      
      ...
      
      [  294.883613] [<c049c760>] (__spi_validate) from [<c049ebe0>]
      (__spi_sync+0x78/0x210)
      [  294.891670] [<c049ebe0>] (__spi_sync) from [<bf036598>]
      (wl12xx_spi_raw_write+0xfc/0x148 [wlcore_spi])
      [  294.901661] [<bf036598>] (wl12xx_spi_raw_write [wlcore_spi]) from
      [<bf21c694>] (wlcore_boot_upload_firmware+0x1ec/0x458 [wlcore])
      [  294.914038] [<bf21c694>] (wlcore_boot_upload_firmware [wlcore]) from
      [<bf24532c>] (wl12xx_boot+0xc10/0xfac [wl12xx])
      [  294.925161] [<bf24532c>] (wl12xx_boot [wl12xx]) from [<bf20d5cc>]
      (wl1271_op_add_interface+0x5b0/0x910 [wlcore])
      [  294.936364] [<bf20d5cc>] (wl1271_op_add_interface [wlcore]) from
      [<bf15c4ac>] (ieee80211_do_open+0x44c/0xf7c [mac80211])
      [  294.947963] [<bf15c4ac>] (ieee80211_do_open [mac80211]) from
      [<c0537978>] (__dev_open+0xa8/0x110)
      [  294.957307] [<c0537978>] (__dev_open) from [<c0537bf8>]
      (__dev_change_flags+0x88/0x148)
      [  294.965713] [<c0537bf8>] (__dev_change_flags) from [<c0537cd0>]
      (dev_change_flags+0x18/0x48)
      [  294.974576] [<c0537cd0>] (dev_change_flags) from [<c05a55a0>]
      (devinet_ioctl+0x6b4/0x7d0)
      [  294.983191] [<c05a55a0>] (devinet_ioctl) from [<c0517040>]
      (sock_ioctl+0x1e4/0x2bc)
      [  294.991244] [<c0517040>] (sock_ioctl) from [<c017d378>]
      (do_vfs_ioctl+0x420/0x6b0)
      [  294.999208] [<c017d378>] (do_vfs_ioctl) from [<c017d674>]
      (SyS_ioctl+0x6c/0x7c)
      [  295.006880] [<c017d674>] (SyS_ioctl) from [<c000f4c0>]
      (ret_fast_syscall+0x0/0x54)
      [  295.014835] Code: e1550004 e2444034 0a00007d e5953018 (e5942008)
      [  295.021544] ---[ end trace 66ed188198f4e24e ]---
      Signed-off-by: default avatarUri Mashiach <uri.mashiach@compulab.co.il>
      Acked-by: default avatarIgor Grinberg <grinberg@compulab.co.il>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1463df0f
    • xuejiufei's avatar
      ocfs2/dlm: clear refmap bit of recovery lock while doing local recovery cleanup · e6fe2687
      xuejiufei authored
      commit c95a5180 upstream.
      
      When recovery master down, dlm_do_local_recovery_cleanup() only remove
      the $RECOVERY lock owned by dead node, but do not clear the refmap bit.
      Which will make umount thread falling in dead loop migrating $RECOVERY
      to the dead node.
      Signed-off-by: default avatarxuejiufei <xuejiufei@huawei.com>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6fe2687
    • xuejiufei's avatar
      ocfs2/dlm: ignore cleaning the migration mle that is inuse · 7889b844
      xuejiufei authored
      commit bef5502d upstream.
      
      We have found that migration source will trigger a BUG that the refcount
      of mle is already zero before put when the target is down during
      migration.  The situation is as follows:
      
      dlm_migrate_lockres
        dlm_add_migration_mle
        dlm_mark_lockres_migrating
        dlm_get_mle_inuse
        <<<<<< Now the refcount of the mle is 2.
        dlm_send_one_lockres and wait for the target to become the
        new master.
        <<<<<< o2hb detect the target down and clean the migration
        mle. Now the refcount is 1.
      
      dlm_migrate_lockres woken, and put the mle twice when found the target
      goes down which trigger the BUG with the following message:
      
        "ERROR: bad mle: ".
      Signed-off-by: default avatarJiufei Xue <xuejiufei@huawei.com>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7889b844
    • Takashi Iwai's avatar
      ALSA: hda - Implement loopback control switch for Realtek and other codecs · 5feecbf0
      Takashi Iwai authored
      commit e7fdd527 upstream.
      
      Many codecs, typically found on Realtek codecs, have the analog
      loopback path merged to the secondary input of the middle of the
      output paths.  Currently, we don't offer the dynamic switching in such
      configuration but let each loopback path mute by itself.
      
      This should work well in theory, but in reality, we often see that
      such a dead loopback path causes some background noises even if all
      the elements get muted.  Such a problem has been fixed by adding the
      quirk accordingly to disable aamix, and it's the right fix, per se.
      The only problem is that it's not so trivial to achieve it; user needs
      to pass a hint string via patch module option or sysfs.
      
      This patch gives a bit improvement on the situation: it adds "Loopback
      Mixing" control element for such codecs like other codecs (e.g. IDT or
      VIA codecs) with the individual loopback paths.  User can turn on/off
      the loopback path simply via a mixer app.
      
      For keeping the compatibility, the loopback is still enabled on these
      codecs.  But user can try to turn it off if experiencing a suspicious
      background or click noise on the fly, then build a static fixup later
      once after the problem is addressed.
      
      Other than the addition of the loopback enable/disablement control,
      there should be no changes.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5feecbf0
    • Ming Lei's avatar
      block: fix bio splitting on max sectors · bfc5caf7
      Ming Lei authored
      commit d0e5fbb0 upstream.
      
      After commit e36f6204(block: split bios to maxpossible length),
      bio can be splitted in the middle of a vector entry, then it
      is easy to split out one bio which size isn't aligned with block
      size, especially when the block size is bigger than 512.
      
      This patch fixes the issue by making the max io size aligned
      to logical block size.
      
      Fixes: e36f6204(block: split bios to maxpossible length)
      Reported-by: default avatarStefan Haberland <sth@linux.vnet.ibm.com>
      Cc: Keith Busch <keith.busch@intel.com>
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bfc5caf7
    • Martin Wilck's avatar
      base/platform: Fix platform drivers with no probe callback · 9e5d4a6c
      Martin Wilck authored
      commit 25cad69f upstream.
      
      Since b8b2c7d8, platform_drv_probe() is called for all platform
      devices. If drv->probe is NULL, and dev_pm_domain_attach() fails,
      platform_drv_probe() will return the error code from dev_pm_domain_attach().
      
      This causes real_probe() to enter the "probe_failed" path and set
      dev->driver to NULL. Before b8b2c7d8, real_probe() would assume
      success if both dev->bus->probe and drv->probe were missing. As a result,
      a device and driver could be "bound" together just by matching their names;
      this doesn't work any more after b8b2c7d8.
      
      This may cause problems later for certain usage of platform_driver_register()
      and platform_device_register_simple(). I observed a panic while loading
      the tpm_tis driver with parameter "force=1" (i.e. registering tpm_tis as
      a platform driver), because tpm_tis_init's assumption that the device
      returned by platform_device_register_simple() was bound didn't hold any more
      (tpmm_chip_alloc() dereferences chip->pdev->driver, causing panic).
      
      This patch restores the previous (4.3.0 and earlier) behavior of
      platform_drv_probe() in the case when the associated platform driver has
      no "probe" function.
      
      Fixes: b8b2c7d8 ("base/platform: assert that dev_pm_domain callbacks are called unconditionally")
      Signed-off-by: default avatarMartin Wilck <Martin.Wilck@ts.fujitsu.com>
      Cc: Martin Fuzzey <mfuzzey@parkeon.com>
      Acked-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e5d4a6c
    • Ioan-Adrian Ratiu's avatar
      HID: usbhid: fix recursive deadlock · 0fc93ba9
      Ioan-Adrian Ratiu authored
      commit e470127e upstream.
      
      The critical section protected by usbhid->lock in hid_ctrl() is too
      big and because of this it causes a recursive deadlock. "Too big" means
      the case statement and the call to hid_input_report() do not need to be
      protected by the spinlock (no URB operations are done inside them).
      
      The deadlock happens because in certain rare cases drivers try to grab
      the lock while handling the ctrl irq which grabs the lock before them
      as described above. For example newer wacom tablets like 056a:033c try
      to reschedule proximity reads from wacom_intuos_schedule_prox_event()
      calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()
      which tries to grab the usbhid lock already held by hid_ctrl().
      
      There are two ways to get out of this deadlock:
          1. Make the drivers work "around" the ctrl critical region, in the
          wacom case for ex. by delaying the scheduling of the proximity read
          request itself to a workqueue.
          2. Shrink the critical region so the usbhid lock protects only the
          instructions which modify usbhid state, calling hid_input_report()
          with the spinlock unlocked, allowing the device driver to grab the
          lock first, finish and then grab the lock afterwards in hid_ctrl().
      
      This patch implements the 2nd solution.
      Signed-off-by: default avatarIoan-Adrian Ratiu <adi@adirat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0fc93ba9
    • Tariq Saeed's avatar
      ocfs2: NFS hangs in __ocfs2_cluster_lock due to race with ocfs2_unblock_lock · 00191545
      Tariq Saeed authored
      commit b1b1e15e upstream.
      
      NFS on a 2 node ocfs2 cluster each node exporting dir.  The lock causing
      the hang is the global bit map inode lock.  Node 1 is master, has the
      lock granted in PR mode; Node 2 is in the converting list (PR -> EX).
      There are no holders of the lock on the master node so it should
      downconvert to NL and grant EX to node 2 but that does not happen.
      BLOCKED + QUEUED in lock res are set and it is on osb blocked list.
      Threads are waiting in __ocfs2_cluster_lock on BLOCKED.  One thread
      wants EX, rest want PR.  So it is as though the downconvert thread needs
      to be kicked to complete the conv.
      
      The hang is caused by an EX req coming into __ocfs2_cluster_lock on the
      heels of a PR req after it sets BUSY (drops l_lock, releasing EX
      thread), forcing the incoming EX to wait on BUSY without doing anything.
      PR has called ocfs2_dlm_lock, which sets the node 1 lock from NL -> PR,
      queues ast.
      
      At this time, upconvert (PR ->EX) arrives from node 2, finds conflict
      with node 1 lock in PR, so the lock res is put on dlm thread's dirty
      listt.
      
      After ret from ocf2_dlm_lock, PR thread now waits behind EX on BUSY till
      awoken by ast.
      
      Now it is dlm_thread that serially runs dlm_shuffle_lists, ast, bast, in
      that order.  dlm_shuffle_lists ques a bast on behalf of node 2 (which
      will be run by dlm_thread right after the ast).  ast does its part, sets
      UPCONVERT_FINISHING, clears BUSY and wakes its waiters.  Next,
      dlm_thread runs bast.  It sets BLOCKED and kicks dc thread.  dc thread
      runs ocfs2_unblock_lock, but since UPCONVERT_FINISHING set, skips doing
      anything and reques.
      
      Inside of __ocfs2_cluster_lock, since EX has been waiting on BUSY ahead
      of PR, it wakes up first, finds BLOCKED set and skips doing anything but
      clearing UPCONVERT_FINISHING (which was actually "meant" for the PR
      thread), and this time waits on BLOCKED.  Next, the PR thread comes out
      of wait but since UPCONVERT_FINISHING is not set, it skips updating the
      l_ro_holders and goes straight to wait on BLOCKED.  So there, we have a
      hang! Threads in __ocfs2_cluster_lock wait on BLOCKED, lock res in osb
      blocked list.  Only when dc thread is awoken, it will run
      ocfs2_unblock_lock and things will unhang.
      
      One way to fix this is to wake the dc thread on the flag after clearing
      UPCONVERT_FINISHING
      
      Orabug: 20933419
      Signed-off-by: default avatarTariq Saeed <tariq.x.saeed@oracle.com>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Reviewed-by: default avatarWengang Wang <wen.gang.wang@oracle.com>
      Reviewed-by: default avatarMark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Cc: Eric Ren <zren@suse.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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      00191545
    • Keith Busch's avatar
      block: split bios to max possible length · d2081cfe
      Keith Busch authored
      commit e36f6204 upstream.
      
      This splits bio in the middle of a vector to form the largest possible
      bio at the h/w's desired alignment, and guarantees the bio being split
      will have some data.
      
      The criteria for splitting is changed from the max sectors to the h/w's
      optimal sector alignment if it is provided. For h/w that advertise their
      block storage's underlying chunk size, it's a big performance win to not
      submit commands that cross them. If sector alignment is not provided,
      this patch uses the max sectors as before.
      
      This addresses the performance issue commit d3805611 attempted to
      fix, but was reverted due to splitting logic error.
      Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Ming Lei <tom.leiming@gmail.com>
      Cc: Kent Overstreet <kent.overstreet@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2081cfe
    • Trond Myklebust's avatar
      NFSv4.1/pnfs: Fixup an lo->plh_block_lgets imbalance in layoutreturn · 1f1c9c9b
      Trond Myklebust authored
      commit 1a093ceb upstream.
      
      Since commit 2d8ae84f, nothing is bumping lo->plh_block_lgets in the
      layoutreturn path, so it should not be touched in nfs4_layoutreturn_release
      either.
      
      Fixes: 2d8ae84f ("NFSv4.1/pnfs: Remove redundant lo->plh_block_lgets...")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f1c9c9b
    • LABBE Corentin's avatar
      crypto: sun4i-ss - add missing statesize · 6abc6562
      LABBE Corentin authored
      commit 4f9ea866 upstream.
      
      sun4i-ss implementaton of md5/sha1 is via ahash algorithms.
      Commit 8996eafd ("crypto: ahash - ensure statesize is non-zero")
      made impossible to load them without giving statesize. This patch
      specifiy statesize for sha1 and md5.
      
      Fixes: 6298e948 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
      Tested-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarLABBE Corentin <clabbe.montjoie@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6abc6562
  2. 31 Jan, 2016 1 commit