1. 04 Apr, 2019 3 commits
  2. 03 Apr, 2019 2 commits
  3. 02 Apr, 2019 2 commits
  4. 01 Apr, 2019 1 commit
  5. 26 Mar, 2019 1 commit
  6. 25 Mar, 2019 2 commits
    • Pankaj Bharadiya's avatar
      ASoC: dapm: Fix NULL pointer dereference in snd_soc_dapm_free_kcontrol · cacea3a9
      Pankaj Bharadiya authored
      w_text_param can be NULL and it is being dereferenced without checking.
      Add the missing sanity check to prevent  NULL pointer dereference.
      Signed-off-by: default avatarPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
      Acked-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      cacea3a9
    • Guenter Roeck's avatar
      ASoC: intel: Fix crash at suspend/resume after failed codec registration · 8f71370f
      Guenter Roeck authored
      If codec registration fails after the ASoC Intel SST driver has been probed,
      the kernel will Oops and crash at suspend/resume.
      
      general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
      CPU: 1 PID: 2811 Comm: cat Tainted: G        W         4.19.30 #15
      Hardware name: GOOGLE Clapper, BIOS Google_Clapper.5216.199.7 08/22/2014
      RIP: 0010:snd_soc_suspend+0x5a/0xd21
      Code: 03 80 3c 10 00 49 89 d7 74 0b 48 89 df e8 71 72 c4 fe 4c 89
      fa 48 8b 03 48 89 45 d0 48 8d 98 a0 01 00 00 48 89 d8 48 c1 e8 03
      <8a> 04 10 84 c0 0f 85 85 0c 00 00 80 3b 00 0f 84 6b 0c 00 00 48 8b
      RSP: 0018:ffff888035407750 EFLAGS: 00010202
      RAX: 0000000000000034 RBX: 00000000000001a0 RCX: 0000000000000000
      RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88805c417098
      RBP: ffff8880354077b0 R08: dffffc0000000000 R09: ffffed100b975718
      R10: 0000000000000001 R11: ffffffff949ea4a3 R12: 1ffff1100b975746
      R13: dffffc0000000000 R14: ffff88805cba4588 R15: dffffc0000000000
      FS:  0000794a78e91b80(0000) GS:ffff888068d00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007bd5283ccf58 CR3: 000000004b7aa000 CR4: 00000000001006e0
      Call Trace:
      ? dpm_complete+0x67b/0x67b
      ? i915_gem_suspend+0x14d/0x1ad
      sst_soc_prepare+0x91/0x1dd
      ? sst_be_hw_params+0x7e/0x7e
      dpm_prepare+0x39a/0x88b
      dpm_suspend_start+0x13/0x9d
      suspend_devices_and_enter+0x18f/0xbd7
      ? arch_suspend_enable_irqs+0x11/0x11
      ? printk+0xd9/0x12d
      ? lock_release+0x95f/0x95f
      ? log_buf_vmcoreinfo_setup+0x131/0x131
      ? rcu_read_lock_sched_held+0x140/0x22a
      ? __bpf_trace_rcu_utilization+0xa/0xa
      ? __pm_pr_dbg+0x186/0x190
      ? pm_notifier_call_chain+0x39/0x39
      ? suspend_test+0x9d/0x9d
      pm_suspend+0x2f4/0x728
      ? trace_suspend_resume+0x3da/0x3da
      ? lock_release+0x95f/0x95f
      ? kernfs_fop_write+0x19f/0x32d
      state_store+0xd8/0x147
      ? sysfs_kf_read+0x155/0x155
      kernfs_fop_write+0x23e/0x32d
      __vfs_write+0x108/0x608
      ? vfs_read+0x2e9/0x2e9
      ? rcu_read_lock_sched_held+0x140/0x22a
      ? __bpf_trace_rcu_utilization+0xa/0xa
      ? debug_smp_processor_id+0x10/0x10
      ? selinux_file_permission+0x1c5/0x3c8
      ? rcu_sync_lockdep_assert+0x6a/0xad
      ? __sb_start_write+0x129/0x2ac
      vfs_write+0x1aa/0x434
      ksys_write+0xfe/0x1be
      ? __ia32_sys_read+0x82/0x82
      do_syscall_64+0xcd/0x120
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      In the observed situation, the problem is seen because the codec driver
      failed to probe due to a hardware problem.
      
      max98090 i2c-193C9890:00: Failed to read device revision: -1
      max98090 i2c-193C9890:00: ASoC: failed to probe component -1
      cht-bsw-max98090 cht-bsw-max98090: ASoC: failed to instantiate card -1
      cht-bsw-max98090 cht-bsw-max98090: snd_soc_register_card failed -1
      cht-bsw-max98090: probe of cht-bsw-max98090 failed with error -1
      
      The problem is similar to the problem solved with commit 2fc995a8
      ("ASoC: intel: Fix crash at suspend/resume without card registration"),
      but codec registration fails at a later point. At that time, the pointer
      checked with the above mentioned commit is already set, but it is not
      cleared if the device is subsequently removed. Adding a remove function
      to clear the pointer fixes the problem.
      
      Cc: stable@vger.kernel.org
      Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
      Cc: Curtis Malainey <cujomalainey@chromium.org>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Acked-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      8f71370f
  7. 21 Mar, 2019 3 commits
  8. 20 Mar, 2019 2 commits
  9. 19 Mar, 2019 4 commits
  10. 18 Mar, 2019 5 commits
  11. 17 Mar, 2019 14 commits
  12. 16 Mar, 2019 1 commit
    • Linus Torvalds's avatar
      Merge tag 'pidfd-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux · a9dce667
      Linus Torvalds authored
      Pull pidfd system call from Christian Brauner:
       "This introduces the ability to use file descriptors from /proc/<pid>/
        as stable handles on struct pid. Even if a pid is recycled the handle
        will not change. For a start these fds can be used to send signals to
        the processes they refer to.
      
        With the ability to use /proc/<pid> fds as stable handles on struct
        pid we can fix a long-standing issue where after a process has exited
        its pid can be reused by another process. If a caller sends a signal
        to a reused pid it will end up signaling the wrong process.
      
        With this patchset we enable a variety of use cases. One obvious
        example is that we can now safely delegate an important part of
        process management - sending signals - to processes other than the
        parent of a given process by sending file descriptors around via scm
        rights and not fearing that the given process will have been recycled
        in the meantime. It also allows for easy testing whether a given
        process is still alive or not by sending signal 0 to a pidfd which is
        quite handy.
      
        There has been some interest in this feature e.g. from systems
        management (systemd, glibc) and container managers. I have requested
        and gotten comments from glibc to make sure that this syscall is
        suitable for their needs as well. In the future I expect it to take on
        most other pid-based signal syscalls. But such features are left for
        the future once they are needed.
      
        This has been sitting in linux-next for quite a while and has not
        caused any issues. It comes with selftests which verify basic
        functionality and also test that a recycled pid cannot be signaled via
        a pidfd.
      
        Jon has written about a prior version of this patchset. It should
        cover the basic functionality since not a lot has changed since then:
      
            https://lwn.net/Articles/773459/
      
        The commit message for the syscall itself is extensively documenting
        the syscall, including it's functionality and extensibility"
      
      * tag 'pidfd-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
        selftests: add tests for pidfd_send_signal()
        signal: add pidfd_send_signal() syscall
      a9dce667