linux.git/sound/core, branch v4.5

ALSA: seq: oss: Don't drain at closing a client

2016-03-01T19:26:40+00:00

The OSS sequencer client tries to drain the pending events at
releasing.  Unfortunately, as spotted by syzkaller fuzzer, this may
lead to an unkillable process state when the event has been queued at
the far future.  Since the process being released can't be signaled
any longer, it remains and waits for the echo-back event in that far
future.

Back to history, the draining feature was implemented at the time we
misinterpreted POSIX definition for blocking file operation.
Actually, such a behavior is superfluous at release, and we should
just release the device as is instead of keeping it up forever.

This patch just removes the draining call that may block the release
for too long time unexpectedly.

BugLink: http://lkml.kernel.org/r/CACT4Y+Y4kD-aBGj37rf-xBw9bH3GMU6P+MYg4W1e-s-paVD2pg@mail.gmail.com
Reported-by: Dmitry Vyukov 
Cc: 
Signed-off-by: Takashi Iwai

ALSA: timer: Fix ioctls for X32 ABI

2016-02-28T16:49:30+00:00

X32 ABI takes the 64bit timespec, thus the timer user status ioctl becomes
incompatible with IA32.  This results in NOTTY error when the ioctl is
issued.

Meanwhile, this struct in X32 is essentially identical with the one in
X86-64, so we can just bypassing to the existing code for this
specific compat ioctl.

Cc:  # v3.4+
Signed-off-by: Takashi Iwai

ALSA: timer: Fix broken compat timer user status ioctl

2016-02-28T16:48:11+00:00

The timer user status compat ioctl returned the bogus struct used for
64bit architectures instead of the 32bit one.  This patch addresses
it to return the proper struct.

Cc: 
Signed-off-by: Takashi Iwai

ALSA: rawmidi: Fix ioctls X32 ABI

2016-02-28T16:44:51+00:00

Like the previous fixes for ctl and PCM, we need a fix for
incompatible X32 ABI regarding the rawmidi: namely, struct
snd_rawmidi_status has the timespec, and the size and the alignment on
X32 differ from IA32.

This patch fixes the incompatible ioctl for X32.

Cc:  # v3.4+
Signed-off-by: Takashi Iwai

ALSA: rawmidi: Use comapt_put_timespec()

2016-02-28T16:44:48+00:00

Instead of open-coding, use the existing helper to copy a 32bit
timespec from/to 64bit.

Signed-off-by: Takashi Iwai

ALSA: pcm: Fix ioctls for X32 ABI

2016-02-28T16:44:35+00:00

X32 ABI uses the 64bit timespec in addition to 64bit alignment of
64bit values.  This leads to incompatibilities in some PCM ioctls
involved with snd_pcm_channel_info, snd_pcm_status and
snd_pcm_sync_ptr structs.  Fix the PCM compat ABI for these ioctls
like the previous commit for ctl API.

Reported-by: Steven Newbury 
Cc:  # v3.4+
Signed-off-by: Takashi Iwai

ALSA: ctl: Fix ioctls for X32 ABI

2016-02-28T16:43:54+00:00

The X32 ABI takes the same alignment like x86-64, and this may result
in the incompatible struct size from ia32.  Unfortunately, we hit this
in some control ABI: struct snd_ctl_elem_value differs between them
due to the position of 64bit variable array.  This ends up with the
unknown ioctl (ENOTTY) error.

The fix is to add the compat entries for the new aligned struct.

Reported-and-tested-by: Steven Newbury 
Cc:  # v3.4+
Signed-off-by: Takashi Iwai

ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream

2016-02-18T10:27:52+00:00

A non-atomic PCM stream may take snd_pcm_link_rwsem rw semaphore twice
in the same code path, e.g. one in snd_pcm_action_nonatomic() and
another in snd_pcm_stream_lock().  Usually this is OK, but when a
write lock is issued between these two read locks, the problem
happens: the write lock is blocked due to the first reade lock, and
the second read lock is also blocked by the write lock.  This
eventually deadlocks.

The reason is the way rwsem manages waiters; it's queued like FIFO, so
even if the writer itself doesn't take the lock yet, it blocks all the
waiters (including reads) queued after it.

As a workaround, in this patch, we replace the standard down_write()
with an spinning loop.  This is far from optimal, but it's good
enough, as the spinning time is supposed to be relatively short for
normal PCM operations, and the code paths requiring the write lock
aren't called so often.

Reported-by: Vinod Koul 
Tested-by: Ramesh Babu 
Cc:  # v3.18+
Signed-off-by: Takashi Iwai

ALSA: seq: Fix double port list deletion

2016-02-16T13:37:19+00:00

The commit [7f0973e973cd: ALSA: seq: Fix lockdep warnings due to
double mutex locks] split the management of two linked lists (source
and destination) into two individual calls for avoiding the AB/BA
deadlock.  However, this may leave the possible double deletion of one
of two lists when the counterpart is being deleted concurrently.
It ends up with a list corruption, as revealed by syzkaller fuzzer.

This patch fixes it by checking the list emptiness and skipping the
deletion and the following process.

BugLink: http://lkml.kernel.org/r/CACT4Y+bay9qsrz6dQu31EcGaH9XwfW7o3oBzSQUG9fMszoh=Sg@mail.gmail.com
Fixes: 7f0973e973cd ('ALSA: seq: Fix lockdep warnings due to 'double mutex locks)
Reported-by: Dmitry Vyukov 
Tested-by: Dmitry Vyukov 
Cc: 
Signed-off-by: Takashi Iwai

ALSA: seq: Fix leak of pool buffer at concurrent writes

2016-02-15T15:26:52+00:00

When multiple concurrent writes happen on the ALSA sequencer device
right after the open, it may try to allocate vmalloc buffer for each
write and leak some of them.  It's because the presence check and the
assignment of the buffer is done outside the spinlock for the pool.

The fix is to move the check and the assignment into the spinlock.

(The current implementation is suboptimal, as there can be multiple
 unnecessary vmallocs because the allocation is done before the check
 in the spinlock.  But the pool size is already checked beforehand, so
 this isn't a big problem; that is, the only possible path is the
 multiple writes before any pool assignment, and practically seen, the
 current coverage should be "good enough".)

The issue was triggered by syzkaller fuzzer.

BugLink: http://lkml.kernel.org/r/CACT4Y+bSzazpXNvtAr=WXaL8hptqjHwqEyFA+VN2AWEx=aurkg@mail.gmail.com
Reported-by: Dmitry Vyukov 
Tested-by: Dmitry Vyukov 
Cc: 
Signed-off-by: Takashi Iwai