This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git. Pull mirroring updated .
  1. 08 Sep, 2021 1 commit
  2. 10 Jun, 2021 1 commit
  3. 15 Dec, 2020 1 commit
    • Bartosz Golaszewski's avatar
      ALSA: pcm: use krealloc_array() · 64f0bd11
      Bartosz Golaszewski authored
      Use the helper that checks for overflows internally instead of manually
      calculating the size of the new array.
      
      Link: https://lkml.kernel.org/r/20201109110654.12547-4-brgl@bgdev.pl
      
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Christian Knig <christian.koenig@amd.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: David Airlie <airlied@linux.ie>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Maxime Ripard <mripard@kernel.org>
      Cc: "Michael S . Tsirkin" <mst@redhat.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Robert Richter <rric@kernel.org>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      64f0bd11
  4. 26 Oct, 2020 1 commit
  5. 18 May, 2020 1 commit
    • Brent Lu's avatar
      ALSA: pcm: fix incorrect hw_base increase · e7513c57
      Brent Lu authored
      
      
      There is a corner case that ALSA keeps increasing the hw_ptr but DMA
      already stop working/updating the position for a long time.
      
      In following log we can see the position returned from DMA driver does
      not move at all but the hw_ptr got increased at some point of time so
      snd_pcm_avail() will return a large number which seems to be a buffer
      underrun event from user space program point of view. The program
      thinks there is space in the buffer and fill more data.
      
      [  418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
      [  418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554
      ...
      [  418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362
      [  418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
      [  418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368
      
      This is because the hw_base will be increased by runtime->buffer_size
      frames unconditionally if the hw_ptr is not updated for over half of
      buffer time. As the hw_base increases, so does the hw_ptr increased
      by the same number.
      
      The avail value returned from snd_pcm_avail() could exceed the limit
      (buffer_size) easily becase the hw_ptr itself got increased by same
      buffer_size samples when the corner case happens. In following log,
      the buffer_size is 16368 samples but the avail is 21810 samples so
      CRAS server complains about it.
      
      [  418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442
      [  418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810
      
      cras_server[1907]: pcm_avail returned frames larger than buf_size:
      sof-glkda7219max: :0,5: 21810 > 16368
      
      By updating runtime->hw_ptr_jiffies each time the HWSYNC is called,
      the hw_base will keep the same when buffer stall happens at long as
      the interval between each HWSYNC call is shorter than half of buffer
      time.
      
      Following is a log captured by a patched kernel. The hw_base/hw_ptr
      value is fixed in this corner case and user space program should be
      aware of the buffer stall and handle it.
      
      [  293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
      [  293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584
      [  293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488
      [  293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392
      [  293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
      ...
      [  381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
      Signed-off-by: default avatarBrent Lu <brent.lu@intel.com>
      Reviewed-by: default avatarJaroslav Kysela <perex@perex.cz>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/1589776238-23877-1-git-send-email-brent.lu@intel.com
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e7513c57
  6. 05 Jan, 2020 1 commit
  7. 04 Jan, 2020 1 commit
    • Takashi Iwai's avatar
      ALSA: control: Add verification for kctl accesses · fbd3eb7f
      Takashi Iwai authored
      The current implementation of ALSA control API fully relies on the
      callbacks of each driver, and there is no verification of the values
      passed via API.  This patch is an attempt to improve the situation
      slightly by adding the validation code for the values stored via info
      and get callbacks.
      
      The patch adds a new kconfig, CONFIG_SND_CTL_VALIDATION.  It depends
      on CONFIG_SND_DEBUG and off as default since the validation would
      require a slight overhead including the additional call of info
      callback at each get callback invocation.
      
      When this config is enabled, the values stored by each info callback
      invocation are verified, namely:
      - Whether the info type is valid
      - Whether the number of enum items is non-zero
      - Whether the given info count is within the allowed boundary
      
      Similarly, the values stored at each get callback are verified as
      well:
      - Whether the values are within the given range
      - Whether the values are aligned with the given step
      - Whether any further changes are seen in the data array over the
        given info count
      
      The last point helps identifying a possibly invalid data type access,
      typically a case where the info callback declares the type being
      SNDRV_CTL_ELEM_TYPE_ENUMERATED while the get/put callbacks store
      the values in value.integer.value[] array.
      
      When a validation fails, the ALSA core logs an error message including
      the device and the control ID, and the API call also returns an
      error.  So, with the new validation turned on, the driver behavior
      difference may be visible on user-space, too -- it's intentional,
      though, so that we can catch an error more clearly.
      
      The patch also introduces a new ctl access type,
      SNDRV_CTL_ELEM_ACCESS_SKIP_CHECK.  A driver may pass this flag with
      other access bits to indicate that the ctl element won't be verified.
      It's useful when a driver code is specially written to access the data
      greater than info->count size by some reason.  For example, this flag
      is actually set now in HD-audio HDMI codec driver which needs to clear
      the data array in the case of the disconnected monitor.
      
      Also, the PCM channel-map helper code is slightly modified to avoid
      the false-positive hit by this validation code, too.
      
      Link: https://lore.kernel.org/r/20200104083556.27789-1-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fbd3eb7f
  8. 14 Dec, 2019 1 commit
  9. 13 Dec, 2019 1 commit
    • Arnd Bergmann's avatar
      ALSA: add new 32-bit layout for snd_pcm_mmap_status/control · 80fe7430
      Arnd Bergmann authored
      
      
      The snd_pcm_mmap_status and snd_pcm_mmap_control interfaces are one of the
      trickiest areas to get right when moving to 64-bit time_t in user space.
      
      The snd_pcm_mmap_status structure layout is incompatible with user space
      that uses a 64-bit time_t, so we need a new layout for it. Since the
      SNDRV_PCM_IOCTL_SYNC_PTR ioctl combines it with snd_pcm_mmap_control
      into snd_pcm_sync_ptr, we need to change those two as well.
      
      Both structures are also exported via an mmap() operation on certain
      architectures, and this suffers from incompatibility between 32-bit
      and 64-bit user space. As we have to change both structures anyway,
      this is a good opportunity to fix the mmap() problem as well, so let's
      standardize on the existing 64-bit layout of the structure where possible.
      
      The downside is that we lose mmap() support for existing 32-bit x86 and
      powerpc applications, adding that would introduce very noticeable runtime
      overhead and complexity. My assumption here is that not too many people
      will miss the removed feature, given that:
      
      - Almost all x86 and powerpc users these days are on 64-bit kernels,
      the majority of today's 32-bit users are on architectures that never
      supported mmap (ARM, MIPS, ...).
      - It never worked in compat mode (it was intentionally disabled there)
      - The application already needs to work with a fallback to
      SNDRV_PCM_IOCTL_SYNC_PTR, which will keep working with both the old
      and new structure layout.
      
      Both the ioctl() and mmap() based interfaces are changed at the same
      time, as they are based on the same structures. Unlike other interfaces,
      we change the uapi header to export both the traditional structure and
      a version that is portable between 32-bit and 64-bit user space code
      and that corresponds to the existing 64-bit layout. We further check the
      __USE_TIME_BITS64 macro that will be defined by future C library versions
      whenever we use the new time_t definition, so any existing user space
      source code will not see any changes until it gets rebuilt against a new
      C library. However, the new structures are all visible in addition to the
      old ones, allowing applications to explicitly request the new structures.
      
      In order to detect the difference between the old snd_pcm_mmap_status and
      the new __snd_pcm_mmap_status64 structure from the ioctl command number,
      we rely on one quirk in the structure definition: snd_pcm_mmap_status
      must be aligned to alignof(time_t), which leads the compiler to insert
      four bytes of padding in struct snd_pcm_sync_ptr after 'flags' and a
      corresponding change in the size of snd_pcm_sync_ptr itself. On x86-32
      (and only there), the compiler doesn't use 64-bit alignment in structure,
      so I'm adding an explicit pad in the structure that has no effect on the
      existing 64-bit architectures but ensures that the layout matches for x86.
      
      The snd_pcm_uframes_t type compatibility requires another hack: we can't
      easily make that 64 bit wide, so I leave the type as 'unsigned long',
      but add padding before and after it, to ensure that the data is properly
      aligned to the respective 64-bit field in the in-kernel structure.
      
      For the SNDRV_PCM_MMAP_OFFSET_STATUS/CONTROL constants that are used
      as the virtual file offset in the mmap() function, we also have to
      introduce new constants that depend on hte __USE_TIME_BITS64 macro:
      The existing macros are renamed to SNDRV_PCM_MMAP_OFFSET_STATUS_OLD
      and SNDRV_PCM_MMAP_OFFSET_CONTROL_OLD, they continue to work fine on
      64-bit architectures, but stop working on native 32-bit user space.
      The replacement _NEW constants are now used by default for user space
      built with __USE_TIME_BITS64, those now work on all new kernels for x86,
      ppc and alpha (32 and 64 bit, native and compat). It might be a good idea
      for a future alsa-lib to support both the _OLD and _NEW macros and use
      the corresponding structures directly. Unmodified alsa-lib source code
      will retain the current behavior, so it will no longer be able to use
      mmap() for the status/control structures on 32-bit systems, until either
      the C library gets updated to 64-bit time_t or alsa-lib gets updated to
      support both mmap() layouts.
      
      Co-developed-with: Baolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      80fe7430
  10. 11 Dec, 2019 1 commit
  11. 13 Nov, 2019 1 commit
  12. 30 May, 2019 1 commit
    • Thomas Gleixner's avatar
      treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156 · 1a59d1b8
      Thomas Gleixner authored
      
      
      Based on 1 normalized pattern(s):
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version this program is distributed in the
        hope that it will be useful but without any warranty without even
        the implied warranty of merchantability or fitness for a particular
        purpose see the gnu general public license for more details you
        should have received a copy of the gnu general public license along
        with this program if not write to the free software foundation inc
        59 temple place suite 330 boston ma 02111 1307 usa
      
      extracted by the scancode license scanner the SPDX license identifier
      
        GPL-2.0-or-later
      
      has been chosen to replace the boilerplate/reference in 1334 file(s).
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: Allison Randal <a...
      1a59d1b8
  13. 13 Feb, 2019 1 commit
  14. 08 Feb, 2019 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Revert capture stream behavior change in blocking mode · 00a399ca
      Takashi Iwai authored
      In the commit 62ba568f ("ALSA: pcm: Return 0 when size <
      start_threshold in capture"), we changed the behavior of
      __snd_pcm_lib_xfer() to return immediately with 0 when a capture
      stream has a high start_threshold.  This was intended to be a
      correction of the behavior consistency and looked harmless, but this
      was the culprit of the recent breakage reported by syzkaller, which
      was fixed by the commit e190161f ("ALSA: pcm: Fix tight loop of
      OSS capture stream").
      
      At the time for the OSS fix, I didn't touch the behavior for ALSA
      native API, as assuming that this behavior actually is good.  But this
      turned out to be also broken actually for a similar deployment,
      e.g. one thread goes to a write loop in blocking mode while another
      thread controls the start/stop of the stream manually.
      
      Overall, the original commit is harmful, and it brings less merit to
      keep that behavior.  Let's revert it.
      
      Fixes: 62ba568f ("ALSA: pcm: Return 0 when size < start_threshold in capture")
      Fixes: e190161f
      
       ("ALSA: pcm: Fix tight loop of OSS capture stream")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      00a399ca
  15. 25 Jan, 2019 2 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Fix tight loop of OSS capture stream · e190161f
      Takashi Iwai authored
      
      
      When the trigger=off is passed for a PCM OSS stream, it sets the
      start_threshold of the given substream to the boundary size, so that
      it won't be automatically started.  This can be problematic for a
      capture stream, unfortunately, as detected by syzkaller.  The scenario
      is like the following:
      
      - In __snd_pcm_lib_xfer() that is invoked from snd_pcm_oss_read()
        loop, we have a check whether the stream was already started or the
        stream can be auto-started.
      - The function at this check returns 0 with trigger=off since we
        explicitly disable the auto-start.
      - The loop continues and repeats calling __snd_pcm_lib_xfer() tightly,
        which may lead to an RCU stall.
      
      This patch fixes the bug by simply allowing the wait for non-started
      stream in the case of OSS capture.  For native usages, it's supposed
      to be done by the caller side (which is user-space), hence it returns
      zero like before.
      
      (In theory, __snd_pcm_lib_xfer() could wait even for the native API
       usage cases, too; but I'd like to stay in a safer side for not
       breaking the existing stuff for now.)
      
      Reported-by: syzbot+fbe0496f92a0ce7b786c@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e190161f
    • Takashi Iwai's avatar
      ALSA: pcm: Use the common error path in __snd_pcm_lib_xfer() · 315d9f1b
      Takashi Iwai authored
      
      
      An open-coded error path in __snd_pcm_lib_xfer() can be replaced with
      the simple goto to the common error path.  This also makes the error
      handling more consistent, i.e. when some samples have been already
      processed, return that size instead of the error code.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      315d9f1b
  16. 10 Sep, 2018 1 commit
  17. 27 Aug, 2018 1 commit
  18. 11 Jul, 2018 1 commit
    • Timo Wischer's avatar
      ALSA: pcm: Fix snd_interval_refine first/last with open min/max · ff2d6acd
      Timo Wischer authored
      
      
      Without this commit the following intervals [x y), (x y) were be
      replaced to (y-1 y) by snd_interval_refine_last(). This was also done
      if y-1 is part of the previous interval.
      With this changes it will be replaced with [y-1 y) in case of y-1 is
      part of the previous interval. A similar behavior will be used for
      snd_interval_refine_first().
      
      This commit adapts the changes for alsa-lib of commit
      9bb985c ("pcm: snd_interval_refine_first/last: exclude value only if
      also excluded before")
      Signed-off-by: default avatarTimo Wischer <twischer@de.adit-jv.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ff2d6acd
  19. 06 Jul, 2018 1 commit
  20. 04 Jul, 2018 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: trace XRUN event at injection, too · 9cd641ed
      Takashi Iwai authored
      
      
      The PCM xrun injection triggers directly snd_pcm_stop() without the
      standard xrun handler, hence it's not recorded on the event buffer.
      Ditto for snd_pcm_stop_xrun() call and SNDRV_PCM_IOCTL_XRUN ioctl.
      They are inconvenient from the debugging POV.
      
      Let's make them to trigger XRUN via the standard helper more
      consistently.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9cd641ed
  21. 17 Apr, 2018 1 commit
  22. 13 Mar, 2018 1 commit
  23. 10 Jan, 2018 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Remove yet superfluous WARN_ON() · 23b19b7b
      Takashi Iwai authored
      
      
      muldiv32() contains a snd_BUG_ON() (which is morphed as WARN_ON() with
      debug option) for checking the case of 0 / 0.  This would be helpful
      if this happens only as a logical error; however, since the hw refine
      is performed with any data set provided by user, the inconsistent
      values that can trigger such a condition might be passed easily.
      Actually, syzbot caught this by passing some zero'ed old hw_params
      ioctl.
      
      So, having snd_BUG_ON() there is simply superfluous and rather
      harmful to give unnecessary confusions.  Let's get rid of it.
      
      Reported-by: syzbot+7e6ee55011deeebce15d@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      23b19b7b
  24. 02 Jan, 2018 2 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Set config update bits only when really changed · 7a0a8716
      Takashi Iwai authored
      
      
      The PCM config space refine codes touch the parameter rmask and cmask
      bits when the given config parameter is changed.  But in most places
      it checks only whether the changed value is non-zero or not, and they
      don't consider whether a negative error value is returned.  This will
      lead to the incorrect update bits set upon the error path.
      
      Fix the codes to check properly the return code whether it's really
      updated or an error.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7a0a8716
    • Takashi Iwai's avatar
      ALSA: pcm: Remove incorrect snd_BUG_ON() usages · fe08f34d
      Takashi Iwai authored
      
      
      syzkaller triggered kernel warnings through PCM OSS emulation at
      closing a stream:
        WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635
        snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635
        Call Trace:
        ....
         snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457
         snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969
         snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128
         snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638
         snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
         __fput+0x327/0x7e0 fs/file_table.c:210
         ....
      
      This happens while it tries to open and set up the aloop device
      concurrently.  The warning above (invoked from snd_BUG_ON() macro) is
      to detect the unexpected logical error where snd_pcm_hw_refine() call
      shouldn't fail.  The theory is true for the case where the hw_params
      config rules are static.  But for an aloop device, the hw_params rule
      condition does vary dynamically depending on the connected target;
      when another device is opened and changes the parameters, the device
      connected in another side is also affected, and it caused the error
      from snd_pcm_hw_refine().
      
      That is, the simplest "solution" for this is to remove the incorrect
      assumption of static rules, and treat such an error as a normal error
      path.  As there are a couple of other places using snd_BUG_ON()
      incorrectly, this patch removes these spurious snd_BUG_ON() calls.
      
      Reported-by: syzbot+6f11c7e2a1b91d466432@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fe08f34d
  25. 21 Nov, 2017 1 commit
    • Henrik Eriksson's avatar
      ALSA: pcm: update tstamp only if audio_tstamp changed · 20e3f985
      Henrik Eriksson authored
      commit 3179f620 ("ALSA: core: add .get_time_info") had a side effect
      of changing the behaviour of the PCM runtime tstamp.  Prior to this
      change tstamp was not updated by snd_pcm_update_hw_ptr0() unless the
      hw_ptr had moved, after this change tstamp was always updated.
      
      For an application using alsa-lib, doing snd_pcm_readi() followed by
      snd_pcm_status() to estimate the age of the read samples by subtracting
      status->avail * [sample rate] from status->tstamp this change degraded
      the accuracy of the estimate on devices where the pcm hw does not
      provide a granular hw_ptr, e.g., devices using
      soc-generic-dmaengine-pcm.c and a dma-engine with residue_granularity
      DMA_RESIDUE_GRANULARITY_DESCRIPTOR.  The accuracy of the estimate
      depended on the latency between the PCM hw completing a period and the
      driver called snd_pcm_period_elapsed() to notify ALSA core, typically
      determined by interrupt handling latency.  After the change the accuracy
      of the estimate depended on the latency between the PCM hw completing a
      period and the application calling snd_pcm_status(), determined by the
      scheduling of the application process.  The maximum error of the
      estimate is one period length in both cases, but the error average and
      variance is smaller when it depends on interrupt latency.
      
      Instead of always updating tstamp, update it only if audio_tstamp
      changed.
      
      Fixes: 3179f620
      
       ("ALSA: core: add .get_time_info")
      Suggested-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarHenrik Eriksson <henrik.eriksson@axis.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      20e3f985
  26. 20 Jun, 2017 2 commits
    • Ingo Molnar's avatar
      sched/wait: Rename wait_queue_t => wait_queue_entry_t · ac6424b9
      Ingo Molnar authored
      
      
      Rename:
      
      	wait_queue_t		=>	wait_queue_entry_t
      
      'wait_queue_t' was always a slight misnomer: its name implies that it's a "queue",
      but in reality it's a queue *entry*. The 'real' queue is the wait queue head,
      which had to carry the name.
      
      Start sorting this out by renaming it to 'wait_queue_entry_t'.
      
      This also allows the real structure name 'struct __wait_queue' to
      lose its double underscore and become 'struct wait_queue_entry',
      which is the more canonical nomenclature for such data types.
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      ac6424b9
    • Takashi Iwai's avatar
      ALSA: pcm: Fix possible inconsistent appl_ptr update via mmap · aa30db06
      Takashi Iwai authored
      
      
      The ALSA PCM core refers to the appl_ptr value stored on the mmapped
      page that is shared between kernel and user-space.  Although the
      reference is performed in the PCM stream lock, it doesn't guarantee
      the atomic access when the value gets updated concurrently from the
      user-space on another CPU.
      
      In most of codes, this is no big problem, but still there are a few
      places that may result in slight inconsistencies because they access
      runtime->control->appl_ptr multiple times; that is, the second read
      might be a different value from the first value.  It can be even
      backward or jumping, as we have no control for it.  Hence, the
      calculation may give an unexpected value.  Luckily, there is no
      security vulnerability by that, as far as I've checked.  But still we
      should address it.
      
      This patch tries to reduce such possible cases.  The fix is simple --
      we just read once, store it to a local variable and use it for the
      rest calculations.  The READ_ONCE() macro is used for it in order to
      avoid the ill-effect by possible compiler optimizations.
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      aa30db06
  27. 16 Jun, 2017 1 commit
  28. 14 Jun, 2017 3 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Don't treat NULL chmap as a fatal error · 2deaeaf1
      Takashi Iwai authored
      
      
      The standard PCM chmap helper callbacks treat the NULL info->chmap as
      a fatal error and spews the kernel warning with stack trace when
      CONFIG_SND_DEBUG is on.  This was OK, originally it was supposed to be
      always static and non-NULL.  But, as the recent addition of Intel LPE
      audio driver shows, the chmap content may vary dynamically, and it can
      be even NULL when disconnected.  The user still sees the kernel
      warning unnecessarily.
      
      For clearing such a confusion, this patch simply removes the
      snd_BUG_ON() in each place, just returns an error without warning.
      
      Cc: <stable@vger.kernel.org> # v4.11+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2deaeaf1
    • Takashi Sakamoto's avatar
      ALSA: pcm: remove SNDRV_PCM_IOCTL1_INFO internal command · e11f0f90
      Takashi Sakamoto authored
      
      
      Drivers can implement 'struct snd_pcm_ops.ioctl' to handle some requests
      from ALSA PCM core. These requests are internal purpose in kernel land.
      Usually common set of operations are used for it.
      
      SNDRV_PCM_IOCTL1_INFO is one of the requests. According to code comment,
      it has been obsoleted in the old days.
      
      We can see old releases in ftp.alsa-project.org. The command was firstly
      introduced in v0.5.0 release as SND_PCM_IOCTL1_INFO, to allow drivers to
      fill data of 'struct snd_pcm_channel_info' type. In v0.9.0 release,
      this was obsoleted by the other commands for ioctl(2) such as
      SNDRV_PCM_IOCTL_CHANNEL_INFO.
      
      This commit removes the long-abandoned command, bye.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e11f0f90
    • Takashi Iwai's avatar
      ALSA: pcm: Skip ack callback without actual appl_ptr update · f8ff2f28
      Takashi Iwai authored
      
      
      We call ack callback whenever appl_ptr gets updated via
      pcm_lib_apply_appl_ptr().  There are various code paths to call this
      function.  A part of them are for read/write/forward/rewind, where the
      appl_ptr is always changed and thus the call of ack is mandatory.
      OTOH, another part of code paths are from the explicit user call,
      e.g. via SYNC_PTR ioctl.  There, we may receive the same appl_ptr
      value, and in such a case, calling ack is obviously superfluous.
      
      This patch adds the check of the given appl_ptr value, and returns
      immediately if it's no real update.
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f8ff2f28
  29. 12 Jun, 2017 2 commits
    • Takashi Sakamoto's avatar
      ALSA: pcm: add 'applptr' event of tracepoint · fccf5388
      Takashi Sakamoto authored
      
      
      In design of ALSA PCM core, status and control data for runtime of ALSA
      PCM substream are shared between kernel/user spaces by page frame
      mapping with read-only attribute. Both of hardware-side and
      application-side position on PCM buffer are maintained as a part of
      the status data. In a view of ALSA PCM application, these two positions
      can be updated by executing ioctl(2) with some commands.
      
      There's an event of tracepoint for hardware-side position; 'hwptr'.
      On the other hand, no events for application-side position. This commit
      adds a new event for this purpose; 'applptr'. When the application-side
      position is changed in kernel space, this event is probed with useful
      information for developers.
      
      I note that the event is not probed for all of ALSA PCM applications, When
      applications are written by read/write programming scenario, the event is
      surely probed. The applications execute ioctl(2) with
      SNDRV_PCM_IOCTL_[READ|WRITE][N/I]_FRAMES to read/write any PCM frame, then
      ALSA PCM core updates the application-side position in kernel land.
      However, when applications are written by mmap programming scenario, if
      maintaining the application side position in kernel space accurately,
      applications should voluntarily execute ioctl(2) with
      SNDRV_PCM_IOCTL_SYNC_PTR to commit the number of handled PCM frames. If
      not voluntarily, the application-side position is not changed, thus the
      added event is not probed.
      
      There's a loophole, using architectures to which ALSA PCM core judges
      non cache coherent. In this case, the status and control data is not mapped
      into processe's VMA for any applications. Userland library, alsa-lib, is
      programmed for this case. It executes ioctl(2) with
      SNDRV_PCM_IOCTL_SYNC_PTR command every time to requiring the status and
      control data.
      
      ARM is such an architecture. Below is an example with serial sound interface
      (ssi) on i.mx6 quad core SoC. I use v4.1 kernel released by fsl-community
      with patches from VIA Tech. Inc. for VAB820, and my backport patches for
      relevant features for this patchset. I use Ubuntu 17.04 from
      ports.ubuntu.com as user land for armhf architecture.
      
      $ aplay -v -M -D hw:imx6vab820sgtl5,0 /dev/urandom -f S16_LE -r 48000 --period-size=128 --buffer-size=256
      Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
      Hardware PCM card 0 'imx6-vab820-sgtl5000' device 0 subdevice 0
      Its setup is:
        stream       : PLAYBACK
        access       : MMAP_INTERLEAVED
        format       : S16_LE
        subformat    : STD
        channels     : 1
        rate         : 48000
        exact rate   : 48000 (48000/1)
        msbits       : 16
        buffer_size  : 256
        period_size  : 128
        period_time  : 2666
        tstamp_mode  : NONE
        tstamp_type  : MONOTONIC
        period_step  : 1
        avail_min    : 128
        period_event : 0
        start_threshold  : 256
        stop_threshold   : 256
        silence_threshold: 0
        silence_size : 0
        boundary     : 1073741824
        appl_ptr     : 0
        hw_ptr       : 0
      mmap_area[0] = 0x76f98000,0,16 (16)
      
      $ trace-cmd record -e snd_pcm:hwptr -e snd_pcm:applptr
      $ trace-cmd report
      ...
      60.208495: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256
      60.208633: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256
      60.210022: hwptr:   pcmC0D0p/sub0: IRQ: pos=128, old=1536, base=1536, period=128, buf=256
      60.210202: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
      60.210344: hwptr:   pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256
      60.210348: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
      60.210486: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
      60.210626: applptr: pcmC0D0p/sub0: prev=1792, curr=1920, avail=0, period=128, buf=256
      60.211002: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
      60.211142: hwptr:   pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256
      60.211146: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
      60.211287: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
      60.212690: hwptr:   pcmC0D0p/sub0: IRQ: pos=0, old=1664, base=1536, period=128, buf=256
      60.212866: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
      60.212999: hwptr:   pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256
      60.213003: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
      60.213135: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
      60.213276: applptr: pcmC0D0p/sub0: prev=1920, curr=2048, avail=0, period=128, buf=256
      60.213654: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
      60.213796: hwptr:   pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256
      60.213800: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
      60.213937: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
      60.215356: hwptr:   pcmC0D0p/sub0: IRQ: pos=128, old=1792, base=1792, period=128, buf=256
      60.215542: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
      60.215679: hwptr:   pcmC0D0p/sub0: POS: pos=128, old=1920, base=1792, period=128, buf=256
      60.215683: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
      60.215813: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
      60.215947: applptr: pcmC0D0p/sub0: prev=2048, curr=2176, avail=0, period=128, buf=256
      ...
      
      We can surely see 'applptr' event is probed even if the application run
      for mmap programming scenario ('-M' option and 'hw' plugin). Below is a
      result of strace:
      
      02:44:15.886382 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887203 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
      02:44:15.887471 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887637 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887805 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887969 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.888132 read(3, "..."..., 256) = 256
      02:44:15.889040 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889221 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889431 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889606 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
      02:44:15.889833 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889998 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.890164 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891048 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891228 read(3, "..."..., 256) = 256
      02:44:15.891497 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891661 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891829 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891991 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
      02:44:15.893007 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      
      We can see 7 calls of ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR per loop with
      call of poll(2). 128 PCM frames are transferred per loop of one poll(2),
      because the PCM substream is configured with S16_LE format and 1 channel
      (2 byte * 1 * 128 = 256 bytes). This equals to the size of period of PCM
      buffer. Comparing to the probed data, one of the 7 calls of ioctl(2) is
      actually used to commit the number of copied PCM frames to kernel space.
      The other calls are just used to check runtime status of PCM substream;
      e.g. XRUN.
      
      The tracepoint event is useful to investigate this case. I note that below
      modules are related to the above sample.
      
       * snd-soc-dummy.ko
       * snd-soc-imx-sgtl5000.ko
       * snd-soc-fsl-ssi.ko
       * snd-soc-imx-pcm-dma.ko
       * snd-soc-sgtl5000.ko
      
      My additional note is lock acquisition. The event is probed under acquiring
      PCM stream lock. This means that calculation in the event is free from
      any hardware events.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fccf5388
    • Takashi Sakamoto's avatar
      ALSA: pcm: unify codes to operate application-side position on PCM buffer · 66e01a5c
      Takashi Sakamoto authored
      
      
      In a series of recent work, ALSA PCM core got some arrangements to handle
      application-side position on PCM buffer. However, relevant codes still
      disperse to two translation units
      
      This commit unifies these codes into a helper function.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      66e01a5c
  30. 09 Jun, 2017 1 commit
  31. 02 Jun, 2017 4 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Direct in-kernel read/write support · 68541213
      Takashi Iwai authored
      
      
      Now all materials are ready, let's allow the direct in-kernel
      read/write, i.e. a kernel-space buffer is passed for read or write,
      instead of the normal user-space buffer.  This feature is used by OSS
      layer and UAC1 driver, for example.
      
      The __snd_pcm_lib_xfer() takes in_kernel argument that indicates the
      in-kernel buffer copy.  When this flag is set, another transfer code
      is used.  It's either via copy_kernel PCM ops or the normal memcpy(),
      depending on the driver setup.
      
      As external API, snd_pcm_kernel_read(), *_write() and other variants
      are provided.
      
      That's all.  This support is really simple because of the code
      refactoring until now.
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      68541213
    • Takashi Iwai's avatar
      ALSA: pcm: Simplify snd_pcm_playback_silence() · a9cd29e7
      Takashi Iwai authored
      
      
      Use the existing silence helper codes for simplification.
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a9cd29e7
    • Takashi Iwai's avatar
      ALSA: pcm: Unify read/write loop · 5c7264cf
      Takashi Iwai authored
      
      
      Both __snd_pcm_lib_read() and __snd_pcm_write() functions have almost
      the same code to loop over samples.  For simplification, this patch
      unifies both as the single helper, __snd_pcm_lib_xfer().
      
      Other than that, there should be no functional change by this patch.
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5c7264cf
    • Takashi Iwai's avatar
      ALSA: pcm: More unification of PCM transfer codes · 9f600630
      Takashi Iwai authored
      
      
      This patch proceeds more abstraction of PCM read/write loop codes.
      
      For both interleaved and non-interleaved transfers, the same copy or
      silence transfer code (which is defined as pcm_transfer_f) is used
      now.  This became possible since we switched to byte size to copy_*
      and fill_silence ops argument instead of frames.
      
      And, for both read and write, we can use the same copy function (which
      is defined as pcm_copy_f), just depending on whether interleaved or
      non-interleaved mode.
      
      The transfer function is determined at the beginning of the loop,
      depending on whether the driver gives the specific copy ops or it's
      the standard read/write.
      
      Another bonus by this change is that we now guarantee the silencing
      behavior when NULL buffer is passed to write helpers.  It'll simplify
      some codes later.
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9f600630