Skip to content

L
linux
Switch branch/tag
  1. 29 Jan, 2016 19 commits
  3. 28 Jan, 2016 21 commits
    • Josh Boyer's avatar
      ideapad-laptop: Add Lenovo Yoga 700 to no_hw_rfkill dmi list · e90344af
      Josh Boyer authored 
      commit 6b31de3e upstream.

Like the Yoga 900 models the Lenovo Yoga 700 does not have a
hw rfkill switch, and trying to read the hw rfkill switch through the
ideapad module causes it to always reported blocking breaking wifi.

This commit adds the Lenovo Yoga 700 to the no_hw_rfkill dmi list, fixing
the wifi breakage.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1295272
Tested-by: <dinyar.rabady+spam@gmail.com>
Signed-off-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e90344af
    • Rich Felker's avatar
      MAINTAINERS: return arch/sh to maintained state, with new maintainers · b3d6f289
      Rich Felker authored 
      commit 114bf37e upstream.

Add Yoshinori Sato and Rich Felker as maintainers for arch/sh
(SUPERH).
Signed-off-by: default avatarRich Felker <dalias@libc.org>
Signed-off-by: default avatarYoshinori Sato <ysato@users.sourceforge.jp>
Acked-by: default avatarD. Jeff Dionne <jeff@uClinux.org>
Acked-by: default avatarRob Landley <rob@landley.net>
Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: default avatarSimon Horman <horms+renesas@verge.net.au>
Acked-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b3d6f289
    • Tariq Saeed's avatar
      ocfs2: NFS hangs in __ocfs2_cluster_lock due to race with ocfs2_unblock_lock · 87f4697b
      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 avatarKamal Mostafa <kamal@canonical.com>
      87f4697b
    • Takashi Iwai's avatar
      ALSA: timer: Handle disconnection more safely · d758ee58
      Takashi Iwai authored 
      commit 230323da upstream.

Currently ALSA timer device doesn't take the disconnection into
account very well; it merely unlinks the timer device at disconnection
callback but does nothing else.  Because of this, when an application
accessing the timer device is disconnected, it may release the
resource before actually closed.  In most cases, it results in a
warning message indicating a leftover timer instance like:
   ALSA: timer xxxx is busy?
But basically this is an open race.

This patch tries to address it.  The strategy is like other ALSA
devices: namely,
- Manage card's refcount at each open/close
- Wake up the pending tasks at disconnection
- Check the shutdown flag appropriately at each possible call

Note that this patch has one ugly hack to handle the wakeup of pending
tasks.  It'd be cleaner to introduce a new disconnect op to
snd_timer_instance ops.  But since it would lead to internal ABI
breakage and it eventually increase my own work when backporting to
stable kernels, I took a different path to implement locally in
timer.c.  A cleanup patch will follow at next for 4.5 kernel.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109431Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      d758ee58
    • Takashi Iwai's avatar
      ALSA: hda - Flush the pending probe work at remove · 0a1d2dc5
      Takashi Iwai authored 
      commit 991f86d7 upstream.

As HD-audio driver does deferred probe internally via workqueue, the
driver might go into the mixed state doing both probe and remove when
the module gets unloaded during the probe work.  This eventually
triggers an Oops, unsurprisingly.

For avoiding this race, we just need to flush the pending probe work
explicitly before actually starting the resource release.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=960710Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0a1d2dc5
    • Nicholas Bellinger's avatar
      iscsi-target: Fix potential dead-lock during node acl delete · 1c035f6b
      Nicholas Bellinger authored 
      commit 26a99c19 upstream.

This patch is a iscsi-target specific bug-fix for a dead-lock
that can occur during explicit struct se_node_acl->acl_group
se_session deletion via configfs rmdir(2), when iscsi-target
time2retain timer is still active.

It changes iscsi-target to obtain se_portal_group->session_lock
internally using spin_in_locked() to check for the specific
se_node_acl configfs shutdown rmdir(2) case.

Note this patch is intended for stable, and the subsequent
v4.5-rc patch converts target_core_tpg.c to use proper
se_sess->sess_kref reference counting for both se_node_acl
deletion + se_node_acl->queue_depth se_session restart.
Reported-by: default avatar: Sagi Grimberg <sagig@mellanox.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Andy Grover <agrover@redhat.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1c035f6b
    • Josh Boyer's avatar
      ideapad-laptop: Add Lenovo ideapad Y700-17ISK to no_hw_rfkill dmi list · ae82f303
      Josh Boyer authored 
      commit edde316a upstream.

One of the newest ideapad models also lacks a physical hw rfkill switch,
and trying to read the hw rfkill switch through the ideapad module
causes it to always reported blocking breaking wifi.

Fix it by adding this model to the DMI list.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1286293Signed-off-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ae82f303
    • Vinit Agnihotri's avatar
      IB/qib: Support creating qps with GFP_NOIO flag · 5e1cc3a2
      Vinit Agnihotri authored 
      commit fbbeb863 upstream.

The current code is problematic when the QP creation and ipoib is used to
support NFS and NFS desires to do IO for paging purposes. In that case, the
GFP_KERNEL allocation in qib_qp.c causes a deadlock in tight memory
situations.

This fix adds support to create queue pair with GFP_NOIO flag for connected
mode only to cleanly fail the create queue pair in those situations.
Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: default avatarVinit Agnihotri <vinit.abhay.agnihotri@intel.com>
Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5e1cc3a2
    • Mike Marciniszyn's avatar
      IB/qib: fix mcast detach when qp not attached · b2a2d140
      Mike Marciniszyn authored 
      commit 09dc9cd6 upstream.

The code produces the following trace:

[1750924.419007] general protection fault: 0000 [#3] SMP
[1750924.420364] Modules linked in: nfnetlink autofs4 rpcsec_gss_krb5 nfsv4
dcdbas rfcomm bnep bluetooth nfsd auth_rpcgss nfs_acl dm_multipath nfs lockd
scsi_dh sunrpc fscache radeon ttm drm_kms_helper drm serio_raw parport_pc
ppdev i2c_algo_bit lpc_ich ipmi_si ib_mthca ib_qib dca lp parport ib_ipoib
mac_hid ib_cm i3000_edac ib_sa ib_uverbs edac_core ib_umad ib_mad ib_core
ib_addr tg3 ptp dm_mirror dm_region_hash dm_log psmouse pps_core
[1750924.420364] CPU: 1 PID: 8401 Comm: python Tainted: G D
3.13.0-39-generic #66-Ubuntu
[1750924.420364] Hardware name: Dell Computer Corporation PowerEdge
860/0XM089, BIOS A04 07/24/2007
[1750924.420364] task: ffff8800366a9800 ti: ffff88007af1c000 task.ti:
ffff88007af1c000
[1750924.420364] RIP: 0010:[<ffffffffa0131d51>] [<ffffffffa0131d51>]
qib_mcast_qp_free+0x11/0x50 [ib_qib]
[1750924.420364] RSP: 0018:ffff88007af1dd70  EFLAGS: 00010246
[1750924.420364] RAX: 0000000000000001 RBX: ffff88007b822688 RCX:
000000000000000f
[1750924.420364] RDX: ffff88007b822688 RSI: ffff8800366c15a0 RDI:
6764697200000000
[1750924.420364] RBP: ffff88007af1dd78 R08: 0000000000000001 R09:
0000000000000000
[1750924.420364] R10: 0000000000000011 R11: 0000000000000246 R12:
ffff88007baa1d98
[1750924.420364] R13: ffff88003ecab000 R14: ffff88007b822660 R15:
0000000000000000
[1750924.420364] FS:  00007ffff7fd8740(0000) GS:ffff88007fc80000(0000)
knlGS:0000000000000000
[1750924.420364] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1750924.420364] CR2: 00007ffff597c750 CR3: 000000006860b000 CR4:
00000000000007e0
[1750924.420364] Stack:
[1750924.420364]  ffff88007b822688 ffff88007af1ddf0 ffffffffa0132429
000000007af1de20
[1750924.420364]  ffff88007baa1dc8 ffff88007baa0000 ffff88007af1de70
ffffffffa00cb313
[1750924.420364]  00007fffffffde88 0000000000000000 0000000000000008
ffff88003ecab000
[1750924.420364] Call Trace:
[1750924.420364]  [<ffffffffa0132429>] qib_multicast_detach+0x1e9/0x350
[ib_qib]
[1750924.568035]  [<ffffffffa00cb313>] ? ib_uverbs_modify_qp+0x323/0x3d0
[ib_uverbs]
[1750924.568035]  [<ffffffffa0092d61>] ib_detach_mcast+0x31/0x50 [ib_core]
[1750924.568035]  [<ffffffffa00cc213>] ib_uverbs_detach_mcast+0x93/0x170
[ib_uverbs]
[1750924.568035]  [<ffffffffa00c61f6>] ib_uverbs_write+0xc6/0x2c0 [ib_uverbs]
[1750924.568035]  [<ffffffff81312e68>] ? apparmor_file_permission+0x18/0x20
[1750924.568035]  [<ffffffff812d4cd3>] ? security_file_permission+0x23/0xa0
[1750924.568035]  [<ffffffff811bd214>] vfs_write+0xb4/0x1f0
[1750924.568035]  [<ffffffff811bdc49>] SyS_write+0x49/0xa0
[1750924.568035]  [<ffffffff8172f7ed>] system_call_fastpath+0x1a/0x1f
[1750924.568035] Code: 66 2e 0f 1f 84 00 00 00 00 00 31 c0 5d c3 66 2e 0f 1f
84 00 00 00 00 00 66 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 8b 7f 10
<f0> ff 8f 40 01 00 00 74 0e 48 89 df e8 8e f8 06 e1 5b 5d c3 0f
[1750924.568035] RIP  [<ffffffffa0131d51>] qib_mcast_qp_free+0x11/0x50
[ib_qib]
[1750924.568035]  RSP <ffff88007af1dd70>
[1750924.650439] ---[ end trace 73d5d4b3f8ad4851 ]

The fix is to note the qib_mcast_qp that was found.   If none is found, then
return EINVAL indicating the error.
Reviewed-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
Reported-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b2a2d140
    • Jean Delvare's avatar
      crypto: crc32c - Fix crc32c soft dependency · 80529662
      Jean Delvare authored 
      commit fd7f6727 upstream.

I don't think it makes sense for a module to have a soft dependency
on itself. This seems quite cyclic by nature and I can't see what
purpose it could serve.

OTOH libcrc32c calls crypto_alloc_shash("crc32c", 0, 0) so it pretty
much assumes that some incarnation of the "crc32c" hash algorithm has
been loaded. Therefore it makes sense to have the soft dependency
there (as crc-t10dif does.)

Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      80529662
    • Herbert Xu's avatar
      crypto: algif_skcipher - Load TX SG list after waiting · 78b0a019
      Herbert Xu authored 
      commit 4f0414e5 upstream.

We need to load the TX SG list in sendmsg(2) after waiting for
incoming data, not before.
Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
[ kamal: backport to 3.19-stable: context ]
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      78b0a019
    • Dave Chinner's avatar
      xfs: log mount failures don't wait for buffers to be released · 51006a38
      Dave Chinner authored 
      commit 85bec546 upstream.

Recently I've been seeing xfs/051 fail on 1k block size filesystems.
Trying to trace the events during the test lead to the problem going
away, indicating that it was a race condition that lead to this
ASSERT failure:

XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0, file: fs/xfs/xfs_mount.c, line: 156
.....
[<ffffffff814e1257>] xfs_free_perag+0x87/0xb0
[<ffffffff814e21b9>] xfs_mountfs+0x4d9/0x900
[<ffffffff814e5dff>] xfs_fs_fill_super+0x3bf/0x4d0
[<ffffffff811d8800>] mount_bdev+0x180/0x1b0
[<ffffffff814e3ff5>] xfs_fs_mount+0x15/0x20
[<ffffffff811d90a8>] mount_fs+0x38/0x170
[<ffffffff811f4347>] vfs_kern_mount+0x67/0x120
[<ffffffff811f7018>] do_mount+0x218/0xd60
[<ffffffff811f7e5b>] SyS_mount+0x8b/0xd0

When I finally caught it with tracing enabled, I saw that AG 2 had
an elevated reference count and a buffer was responsible for it. I
tracked down the specific buffer, and found that it was missing the
final reference count release that would put it back on the LRU and
hence be found by xfs_wait_buftarg() calls in the log mount failure
handling.

The last four traces for the buffer before the assert were (trimmed
for relevance)

kworker/0:1-5259   xfs_buf_iodone:        hold 2  lock 0 flags ASYNC
kworker/0:1-5259   xfs_buf_ioerror:       hold 2  lock 0 error -5
mount-7163	   xfs_buf_lock_done:     hold 2  lock 0 flags ASYNC
mount-7163	   xfs_buf_unlock:        hold 2  lock 1 flags ASYNC

This is an async write that is completing, so there's nobody waiting
for it directly.  Hence we call xfs_buf_relse() once all the
processing is complete. That does:

static inline void xfs_buf_relse(xfs_buf_t *bp)
{
	xfs_buf_unlock(bp);
	xfs_buf_rele(bp);
}

Now, it's clear that mount is waiting on the buffer lock, and that
it has been released by xfs_buf_relse() and gained by mount. This is
expected, because at this point the mount process is in
xfs_buf_delwri_submit() waiting for all the IO it submitted to
complete.

The mount process, however, is waiting on the lock for the buffer
because it is in xfs_buf_delwri_submit(). This waits for IO
completion, but it doesn't wait for the buffer reference owned by
the IO to go away. The mount process collects all the completions,
fails the log recovery, and the higher level code then calls
xfs_wait_buftarg() to free all the remaining buffers in the
filesystem.

The issue is that on unlocking the buffer, the scheduler has decided
that the mount process has higher priority than the the kworker
thread that is running the IO completion, and so immediately
switched contexts to the mount process from the semaphore unlock
code, hence preventing the kworker thread from finishing the IO
completion and releasing the IO reference to the buffer.

Hence by the time that xfs_wait_buftarg() is run, the buffer still
has an active reference and so isn't on the LRU list that the
function walks to free the remaining buffers. Hence we miss that
buffer and continue onwards to tear down the mount structures,
at which time we get find a stray reference count on the perag
structure. On a non-debug kernel, this will be ignored and the
structure torn down and freed. Hence when the kworker thread is then
rescheduled and the buffer released and freed, it will access a
freed perag structure.

The problem here is that when the log mount fails, we still need to
quiesce the log to ensure that the IO workqueues have returned to
idle before we run xfs_wait_buftarg(). By synchronising the
workqueues, we ensure that all IO completions are fully processed,
not just to the point where buffers have been unlocked. This ensures
we don't end up in the situation above.
Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      51006a38
    • Arnd Bergmann's avatar
      ARM: debug-ll: fix BCM63xx entry for multiplatform · 1dda19b4
      Arnd Bergmann authored 
      commit 6c548099 upstream.

During my randconfig build testing, I found that a kernel with
DEBUG_AT91_UART and ARCH_BCM_63XX fails to build:

arch/arm/include/debug/at91.S:18:0: error: "CONFIG_DEBUG_UART_VIRT" redefined [-Werror]

It turns out that the DEBUG_UART_BCM63XX option is enabled whenever
the ARCH_BCM_63XX is, and that breaks multiplatform kernels because
we then end up using the UART address from BCM63XX rather than the
one we actually configured (if any).

This changes the BCM63XX options to only have one Kconfig option,
and only enable that if the user explicitly turns it on.
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Fixes: b51312be ("ARM: BCM63XX: add low-level UART debug support")
[ kamal: backport to 3.19-stable: context ]
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1dda19b4
    • Takashi Iwai's avatar
      ALSA: control: Avoid kernel warnings from tlv ioctl with numid 0 · 77e05fba
      Takashi Iwai authored 
      commit c0bcdbdf upstream.

When a TLV ioctl with numid zero is handled, the driver may spew a
kernel warning with a stack trace at each call.  The check was
intended obviously only for a kernel driver, but not for a user
interaction.  Let's fix it.

This was spotted by syzkaller fuzzer.
Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      77e05fba
    • Nicolas Boichat's avatar
      ALSA: seq: Fix snd_seq_call_port_info_ioctl in compat mode · 9f148300
      Nicolas Boichat authored 
      commit 9586495d upstream.

This reverts one hunk of
commit ef44a1ec ("ALSA: sound/core: use memdup_user()"), which
replaced a number of kmalloc followed by memcpy with memdup calls.

In this case, we are copying from a struct snd_seq_port_info32 to a
struct snd_seq_port_info, but the latter is 4 bytes longer than the
32-bit version, so we need to separate kmalloc and copy calls.

Fixes: ef44a1ec ('ALSA: sound/core: use memdup_user()')
Signed-off-by: default avatarNicolas Boichat <drinkcat@chromium.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9f148300
    • Nicolas Boichat's avatar
      ALSA: pcm: Fix snd_pcm_hw_params struct copy in compat mode · c8be7897
      Nicolas Boichat authored 
      commit 43c54b8c upstream.

This reverts one hunk of
commit ef44a1ec ("ALSA: sound/core: use memdup_user()"), which
replaced a number of kmalloc followed by memcpy with memdup calls.

In this case, we are copying from a struct snd_pcm_hw_params32 to
a struct snd_pcm_hw_params, but the latter is 4 bytes longer than
the 32-bit version, so we need to separate kmalloc and copy calls.

This actually leads to an out-of-bounds memory access later on
in sound/soc/soc-pcm.c:soc_pcm_hw_params() (detected using KASan).

Fixes: ef44a1ec ('ALSA: sound/core: use memdup_user()')
Signed-off-by: default avatarNicolas Boichat <drinkcat@chromium.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c8be7897
    • Takashi Iwai's avatar
      ALSA: hrtimer: Fix stall by hrtimer_cancel() · 3811f772
      Takashi Iwai authored 
      commit 2ba1fe7a upstream.

hrtimer_cancel() waits for the completion from the callback, thus it
must not be called inside the callback itself.  This was already a
problem in the past with ALSA hrtimer driver, and the early commit
[fcfdebe7: ALSA: hrtimer - Fix lock-up] tried to address it.

However, the previous fix is still insufficient: it may still cause a
lockup when the ALSA timer instance reprograms itself in its callback.
Then it invokes the start function even in snd_timer_interrupt() that
is called in hrtimer callback itself, results in a CPU stall.  This is
no hypothetical problem but actually triggered by syzkaller fuzzer.

This patch tries to fix the issue again.  Now we call
hrtimer_try_to_cancel() at both start and stop functions so that it
won't fall into a deadlock, yet giving some chance to cancel the queue
if the functions have been called outside the callback.  The proper
hrtimer_cancel() is called in anyway at closing, so this should be
enough.
Reported-and-tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      3811f772
    • Herbert Xu's avatar
      crypto: af_alg - Forbid bind(2) when nokey child sockets are present · 1cc38158
      Herbert Xu authored 
      commit a6a48c56 upstream.

This patch forbids the calling of bind(2) when there are child
sockets created by accept(2) in existence, even if they are created
on the nokey path.

This is needed as those child sockets have references to the tfm
object which bind(2) will destroy.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1cc38158
    • Herbert Xu's avatar
      crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path · 074bd2ed
      Herbert Xu authored 
      commit 6a935170 upstream.

This patch allows af_alg_release_parent to be called even for
nokey sockets.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      074bd2ed
    • Herbert Xu's avatar
      crypto: hash - Add crypto_ahash_has_setkey · bfde8726
      Herbert Xu authored 
      commit a5596d63 upstream.

This patch adds a way for ahash users to determine whether a key
is required by a crypto_ahash transform.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      bfde8726
    • Herbert Xu's avatar
      crypto: af_alg - Add nokey compatibility path · 3baec392
      Herbert Xu authored 
      commit 37766586 upstream.

This patch adds a compatibility path to support old applications
that do acept(2) before setkey.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      3baec392
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7