1. 09 1月, 2016 5 次提交
  2. 08 1月, 2016 5 次提交
  3. 07 1月, 2016 12 次提交
  4. 06 1月, 2016 14 次提交
  5. 05 1月, 2016 4 次提交
    • C
      tile: provide CONFIG_PAGE_SIZE_64KB etc for tilepro · c1b27ab5
      Chris Metcalf 提交于
      This allows the build system to know that it can't attempt to
      configure the Lustre virtual block device, for example, when tilepro
      is using 64KB pages (as it does by default).  The tilegx build
      already provided those symbols.
      
      Previously we required that the tilepro hypervisor be rebuilt with
      a different hardcoded page size in its headers, and then Linux be
      rebuilt using the updated hypervisor header.  Now we allow each of
      the hypervisor and Linux to be built independently.  We still check
      at boot time to ensure that the page size provided by the hypervisor
      matches what Linux expects.
      Signed-off-by: NChris Metcalf <cmetcalf@ezchip.com>
      Cc: stable@vger.kernel.org [3.19+]
      c1b27ab5
    • V
      ASoC: Intel: Skylake: Fix the memory leak · d8018361
      Vinod Koul 提交于
      This provide the fix for firmware memory by freeing the pointer in driver
      remove where it is safe to do so
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      d8018361
    • V
      ASoC: Intel: Skylake: Revert previous broken fix memory leak fix · fb203adc
      Vinod Koul 提交于
      This reverts commit 87b5ed8e ("ASoC: Intel:
      Skylake: fix memory leak") as it causes regression on Skylake devices
      
      The SKL drivers can be deferred probe. The topology file based widgets can
      have references to topology file so this can't be freed until card is fully
      created, so revert this patch for now
      
      [   66.682767] BUG: unable to handle kernel paging request at ffffc900001363fc
      [   66.690735] IP: [<ffffffff806c94dd>] strnlen+0xd/0x40
      [   66.696509] PGD 16e035067 PUD 16e036067 PMD 16e038067 PTE 0
      [   66.702925] Oops: 0000 [#1] PREEMPT SMP
      [   66.768390] CPU: 3 PID: 57 Comm: kworker/u16:3 Tainted: G O 4.4.0-rc7-skl #62
      [   66.778869] Hardware name: Intel Corporation Skylake Client platform
      [   66.793201] Workqueue: deferwq deferred_probe_work_func
      [   66.799173] task: ffff88008b700f40 ti: ffff88008b704000 task.ti: ffff88008b704000
      [   66.807692] RIP: 0010:[<ffffffff806c94dd>]  [<ffffffff806c94dd>] strnlen+0xd/0x40
      [   66.816243] RSP: 0018:ffff88008b707878  EFLAGS: 00010286
      [   66.822293] RAX: ffffffff80e60a82 RBX: 000000000000000e RCX: fffffffffffffffe
      [   66.830406] RDX: ffffc900001363fc RSI: ffffffffffffffff RDI: ffffc900001363fc
      [   66.838520] RBP: ffff88008b707878 R08: 000000000000ffff R09: 000000000000ffff
      [   66.846649] R10: 0000000000000001 R11: ffffffffa01c6368 R12: ffffc900001363fc
      [   66.854765] R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000
      [   66.862910] FS:  0000000000000000(0000) GS:ffff88016ecc0000(0000) knlGS:0000000000000000
      [   66.872150] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   66.878696] CR2: ffffc900001363fc CR3: 0000000002c09000 CR4: 00000000003406e0
      [   66.886820] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   66.894938] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   66.903052] Stack:
      [   66.905346]  ffff88008b7078b0 ffffffff806cb1db 000000000000000e 0000000000000000
      [   66.913854]  ffff88008b707928 ffffffffa00d1050 ffffffffa00d104e ffff88008b707918
      [   66.922353]  ffffffff806ccbd6 ffff88008b707948 0000000000000046 ffff88008b707940
      [   66.930855] Call Trace:
      [   66.933646]  [<ffffffff806cb1db>] string.isra.4+0x3b/0xd0
      [   66.939793]  [<ffffffff806ccbd6>] vsnprintf+0x116/0x540
      [   66.945742]  [<ffffffff806d02f0>] kvasprintf+0x40/0x80
      [   66.951591]  [<ffffffff806d0370>] kasprintf+0x40/0x50
      [   66.957359]  [<ffffffffa00c085f>] dapm_create_or_share_kcontrol+0x1cf/0x300 [snd_soc_core]
      [   66.966771]  [<ffffffff8057dd1e>] ? __kmalloc+0x16e/0x2a0
      [   66.972931]  [<ffffffffa00c0dab>] snd_soc_dapm_new_widgets+0x41b/0x4b0 [snd_soc_core]
      [   66.981857]  [<ffffffffa00be8c0>] ? snd_soc_dapm_add_routes+0xb0/0xd0 [snd_soc_core]
      [   67.007828]  [<ffffffffa00b92ed>] soc_probe_component+0x23d/0x360 [snd_soc_core]
      [   67.016244]  [<ffffffff80b14e69>] ? mutex_unlock+0x9/0x10
      [   67.022405]  [<ffffffffa00ba02f>] snd_soc_instantiate_card+0x47f/0xd10 [snd_soc_core]
      [   67.031329]  [<ffffffff8049eeb2>] ? debug_mutex_init+0x32/0x40
      [   67.037973]  [<ffffffffa00baa92>] snd_soc_register_card+0x1d2/0x2b0 [snd_soc_core]
      [   67.046619]  [<ffffffffa00c8b54>] devm_snd_soc_register_card+0x44/0x80 [snd_soc_core]
      [   67.055539]  [<ffffffffa01c303b>] skylake_audio_probe+0x1b/0x20 [snd_soc_skl_rt286]
      [   67.064292]  [<ffffffff808aa887>] platform_drv_probe+0x37/0x90
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      fb203adc
    • R
      af_unix: Fix splice-bind deadlock · c845acb3
      Rainer Weikusat 提交于
      On 2015/11/06, Dmitry Vyukov reported a deadlock involving the splice
      system call and AF_UNIX sockets,
      
      http://lists.openwall.net/netdev/2015/11/06/24
      
      The situation was analyzed as
      
      (a while ago) A: socketpair()
      B: splice() from a pipe to /mnt/regular_file
      	does sb_start_write() on /mnt
      C: try to freeze /mnt
      	wait for B to finish with /mnt
      A: bind() try to bind our socket to /mnt/new_socket_name
      	lock our socket, see it not bound yet
      	decide that it needs to create something in /mnt
      	try to do sb_start_write() on /mnt, block (it's
      	waiting for C).
      D: splice() from the same pipe to our socket
      	lock the pipe, see that socket is connected
      	try to lock the socket, block waiting for A
      B:	get around to actually feeding a chunk from
      	pipe to file, try to lock the pipe.  Deadlock.
      
      on 2015/11/10 by Al Viro,
      
      http://lists.openwall.net/netdev/2015/11/10/4
      
      The patch fixes this by removing the kern_path_create related code from
      unix_mknod and executing it as part of unix_bind prior acquiring the
      readlock of the socket in question. This means that A (as used above)
      will sb_start_write on /mnt before it acquires the readlock, hence, it
      won't indirectly block B which first did a sb_start_write and then
      waited for a thread trying to acquire the readlock. Consequently, A
      being blocked by C waiting for B won't cause a deadlock anymore
      (effectively, both A and B acquire two locks in opposite order in the
      situation described above).
      
      Dmitry Vyukov(<dvyukov@google.com>) tested the original patch.
      Signed-off-by: NRainer Weikusat <rweikusat@mobileactivedefense.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c845acb3