Alsa-devel April 2018

alsa-devel@alsa-project.org

144 participants
268 discussions

[alsa-devel] [PATCH] ASoC: mediatek: add the .probe() callback in mt2701_afe_pcm_dai_component
by Ryder Lee 01 May '18

01 May '18

For the sake of uniformity, this patch adds a callback mt2701_afe_pcm_probe() in mt2701_afe_pcm_dai_component to retrieve the regmap - the canonical way to obtain the pointer.. Doing so, we could switch to use devm_snd_soc_register_component() to register the component driver. Signed-off-by: Ryder Lee <ryder.lee(a)mediatek.com> --- sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 31 ++++++++++++++---------------- 1 file changed, 14 insertions(+), 17 deletions(-) diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c index d6eeb4c..828d11c 100644 --- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c +++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c @@ -958,7 +958,17 @@ static int mt2701_irq_fs(struct snd_pcm_substream *substream, unsigned int rate) { "O31", "I35 Switch", "I35" }, }; +static int mt2701_afe_pcm_probe(struct snd_soc_component *component) +{ + struct mtk_base_afe *afe = snd_soc_component_get_drvdata(component); + + snd_soc_component_init_regmap(component, afe->regmap); + + return 0; +} + static const struct snd_soc_component_driver mt2701_afe_pcm_dai_component = { + .probe = mt2701_afe_pcm_probe, .name = "mt2701-afe-pcm-dai", .dapm_widgets = mt2701_afe_pcm_widgets, .num_dapm_widgets = ARRAY_SIZE(mt2701_afe_pcm_widgets), @@ -1316,22 +1326,6 @@ static int mt2701_afe_runtime_resume(struct device *dev) return mt2701_afe_enable_clock(afe); } -static int mt2701_afe_add_component(struct mtk_base_afe *afe) -{ - struct snd_soc_component *component; - - component = kzalloc(sizeof(*component), GFP_KERNEL); - if (!component) - return -ENOMEM; - - component->regmap = afe->regmap; - - return snd_soc_add_component(afe->dev, component, - &mt2701_afe_pcm_dai_component, - mt2701_afe_pcm_dais, - ARRAY_SIZE(mt2701_afe_pcm_dais)); -} - static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev) { struct mtk_base_afe *afe; @@ -1442,7 +1436,10 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev) goto err_platform; } - ret = mt2701_afe_add_component(afe); + ret = devm_snd_soc_register_component(&pdev->dev, + &mt2701_afe_pcm_dai_component, + mt2701_afe_pcm_dais, + ARRAY_SIZE(mt2701_afe_pcm_dais)); if (ret) { dev_warn(dev, "err_dai_component\n"); goto err_platform; -- 1.9.1

2 1

[alsa-devel] [PATCH RFC] ASoC: dai playback_active and capture_active may be greater than 1
by Jerome Brunet 01 May '18

01 May '18

At the moment playback_active and capture_active are using only 1 bit so the maximum active count is 1. However, snd_soc_runtime_activate() may be called several time on the same dai. This happens when a dai is part of several dai_links. It is often the case for "snd-soc-dummy-dai". This is a problem if snd_soc_runtime_activate() is called an even number of times on a dai. In this case the active count overflow back to 0. As consequence, ASoC functions, such as soc_dpcm_runtime_update(), won't run correctly. Storing these usage counts on plain 'unsigned int' solves the problem. Fixes: f0fba2ad1b6b ("ASoC: multi-component - ASoC Multi-Component Support") Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> --- Hi, I found this problem while working on ASoC support for a new platform. During a playback, using DPCM, if I changed the backend dai, nothing happened, old backend path was not pruned, new backend path was not added. Here is how it goes: 1 FE and 2 BE, all 3 using snd-soc-dummy-dai for the codec_dai (ATM). On playback start: - BE #1 activates and increments snd-soc-dummy-dai's playback_active - FE activates and increments snd-soc-dummy-dai's playback_active The playback works but snd-soc-dummy-dai's playback_active value is now 0. Through a mux kcontrol, change BE client of FE, from BE #1 to BE #2. -> trigger soc_dpcm_runtime_update(). -> checks fe's codec_dai playback_active which is zero so playback path processing is skipped, keeping the old invalid path. include/sound/soc-dai.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h index 8ad11669e4d8..35ebb0be5114 100644 --- a/include/sound/soc-dai.h +++ b/include/sound/soc-dai.h @@ -294,8 +294,8 @@ struct snd_soc_dai { struct snd_soc_dai_driver *driver; /* DAI runtime info */ - unsigned int capture_active:1; /* stream is in use */ - unsigned int playback_active:1; /* stream is in use */ + unsigned int capture_active; /* stream usage count */ + unsigned int playback_active; /* stream usage count */ unsigned int probed:1; unsigned int active; -- 2.14.3

3 2

[alsa-devel] [PATCH v3 0/3] ASoc: TAS6424: Add support for mute, standby, and faster power on
by Jean-Jacques Hiblot 01 May '18

01 May '18

mute and standby pins are available on the codec. If they are connected, they should be managed by the driver, instead of relying on gpio hogs or on the initial state of the GPIOs. This series also includes a patch to improve the start-up time of the channels by disabling built-in DC diagnostics. Those diagnosdtics basically serve to detect : - wires shorted together - wire shorted to ground or vbat - wire disconnected This is not useful for all platforms and the addition to the startup time is quite noticeable (230ms). The diagnostics can be enabled/disabled using a dedicated ALSA control. Changes in v3: - use SOC_SINGLE_STROBE() to register the "auto diagniostics switch" control Changes in v2: - use a ALSA control to enable/disable the auto diagnostics instead of relying on a DTS property. - fixed typos - use gpios (plural) instead of gpio in the documentation of the bindings Jean-Jacques Hiblot (3): ASoC: tas6424: Add support for the standby pin ASoC: tas6424: Add support for the mute pin ASoC: tas6424: Allow disabling auto diagnostics for faster power-on .../devicetree/bindings/sound/ti,tas6424.txt | 2 + sound/soc/codecs/tas6424.c | 72 +++++++++++++++++++++- sound/soc/codecs/tas6424.h | 4 ++ 3 files changed, 75 insertions(+), 3 deletions(-) -- 2.7.4

2 5

[alsa-devel] [PATCH v2 0/6] ARM/ASoC: omap: n810 audio support
by Peter Ujfalusi 01 May '18

01 May '18

Hi, Changes since v1: - Fixed up the aic33 dts patch with missing entries needed for capture - Added comment and new widget for the non working HS Mic The verification of the sdma-pcm on OMAP2 got delayed by non working audio on n810. With the following patches audio works on n810 (both with the old omap-pcm and the new sdma-pcm). I believe the DTS and ASoC patches are fine to go via different tree, but I wanted to keep the patches together for easier testing. The series does not have any dependencies, I will rebase the sdma-pcm series on top of this and resend. Playback to Speaker, Headset is working. Capture from DMIC is working. Capture from HS mic is not working due to missing mic bias (from Retu/Vilma). Regards, Peter --- Jarkko Nikula (1): ASoC: omap: Remove OMAP_MUX dependency from Nokia N810 audio support Peter Ujfalusi (5): ARM: dts: omap2420-n810: Enable McBSP2 for audio ARM: dts: omap2420-n810: Correct the audio codec (tlv320aic33) node ASoC: omap: n810: Correct the card level dapm_route ASoC: omap: n810: Correct the cpu_dai, platform and codec name ASoC: omap: n810: HS mic is not working, add a widget for it with comment arch/arm/boot/dts/omap2420-n810.dts | 63 ++++++++++++++++++++++++++++- sound/soc/omap/Kconfig | 1 - sound/soc/omap/n810.c | 21 ++++++---- 3 files changed, 75 insertions(+), 10 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

4 10

[alsa-devel] [PATCH 0/2] ASoC: add mt6351 codec driver
by KaiChieh Chuang 01 May '18

01 May '18

This patch adds the MediaTek MT6351 codec driver. KaiChieh Chuang (2): ASoC: add documents for mt6351 ASoC: add mt6351 codec driver Documentation/devicetree/bindings/sound/mt6351.txt | 16 + sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/mt6351.c | 1506 ++++++++++++++++++++ sound/soc/codecs/mt6351.h | 105 ++ 5 files changed, 1633 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/mt6351.txt create mode 100644 sound/soc/codecs/mt6351.c create mode 100644 sound/soc/codecs/mt6351.h -- 2.12.5

2 3

[alsa-devel] [PATCH v2 00/13] ALSA: dice: use cache of stream formats to generate PCM rules/constraints
by Takashi Sakamoto 01 May '18

01 May '18

Hi, This patchset updates my previous one: [alsa-devel] [PATCH 00/11] ALSA: dice: use cache of stream formats to generate PCM rules/constraints http://mailman.alsa-project.org/pipermail/alsa-devel/2018-April/134983.html Once, ALSA dice driver cached stream formats to generate PCM constraints/rules. The cache is created by changing current sampling transmission frequency step by step directly at unit probing process. This feature was dropped because it changes state of clock on target device thus it's against users' expectation[1]. However this is not necessarily convenient because reconfiguration of sampling rate is not available. TC Applied Technologies (TCAT) has extended protocol for DICE interface, a.k.a EAP (Extended Application Protocol). In this extension, drivers can retrieve information of stream formats without changing state of target unit. Fortunately, this protocol is supported widely by many models. This patchset regain the cache to generate PCM constraints/rules by using this protocol. Userspace applications can reconfigure sampling rate via ALSA PCM interface. For units which doesn't support the extension, available set of sampling rate is still restricted at current sampling transmission frequency. This is also inconvenient and this patchset introduces a solution. Structure for unit entry (struct ieee1394_device_id) has a member for unit-specific data. This patchset uses it for callback function to handle hard-coded stream format. In this time, I adopt this way for some known models produced by TC Electronic and Alesis. If users find their models still have restrictions in a point of available sampling transmission frequency, it's preferable to work for this way. Changes from v1: - rename members for the channel cache. - add minor refactoring. - fix a bug that sampling transmission frequency is not changed via ALSA PCM interface. - fix a bug that current stream formats are reused after changing sampling transmission frequency. [1] [alsa-devel] [PATCH 0/6 v2] ALSA: dice: constrain PCM substreams to current sampling transfer frequency http://mailman.alsa-project.org/pipermail/alsa-devel/2016-February/104065.h… [2] [alsa-devel] [PATCH] ALSA: dice: fix OUI for TC group http://mailman.alsa-project.org/pipermail/alsa-devel/2018-April/134804.html Takashi Sakamoto (13): ALSA: dice: add cache of stream formats ALSA: dice: add 'firewire' directory for proc nodes ALSA: dice: add proc node for stream formation ALSA: dice: cache stream formats at current mode of sampling transmission frequency ALSA: dice: add parameters of stream formats for models produced by TC Electronic ALSA: dice: add parameters of stream formats for models produced by Alesis ALSA: dice: use extended protocol to detect available stream formats ALSA: dice: use cache of stream format to check running stream ALSA: dice: add a helper function to restart all of available streams ALSA: dice: enable to change current sampling transmission frequency ALSA: dice: use stream formats to add MIDI substreams ALSA: dice: use cache for PCM constraints and rules ALSA: dice: remove local frag of force_two_pcms sound/firewire/dice/Makefile | 3 +- sound/firewire/dice/dice-alesis.c | 48 ++++++ sound/firewire/dice/dice-extension.c | 172 ++++++++++++++++++++ sound/firewire/dice/dice-midi.c | 23 +-- sound/firewire/dice/dice-pcm.c | 230 ++++++++++++++++++--------- sound/firewire/dice/dice-proc.c | 70 +++++++- sound/firewire/dice/dice-stream.c | 273 ++++++++++++++++++++++++-------- sound/firewire/dice/dice-tcelectronic.c | 100 ++++++++++++ sound/firewire/dice/dice.c | 139 ++++++++++------ sound/firewire/dice/dice.h | 17 +- 10 files changed, 867 insertions(+), 208 deletions(-) create mode 100644 sound/firewire/dice/dice-alesis.c create mode 100644 sound/firewire/dice/dice-extension.c create mode 100644 sound/firewire/dice/dice-tcelectronic.c -- 2.14.1

2 20

[alsa-devel] [PATCH] ASoC: mediatek: preallocate pages use platform device
by KaiChieh Chuang 01 May '18

01 May '18

preallocate pages should use platform device, since we set dma mask for platform device. Signed-off-by: KaiChieh Chuang <kaichieh.chuang(a)mediatek.com> --- sound/soc/mediatek/common/mtk-afe-platform-driver.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/mediatek/common/mtk-afe-platform-driver.c b/sound/soc/mediatek/common/mtk-afe-platform-driver.c index 53215b52e4f2..f8a06709f76d 100644 --- a/sound/soc/mediatek/common/mtk-afe-platform-driver.c +++ b/sound/soc/mediatek/common/mtk-afe-platform-driver.c @@ -64,14 +64,14 @@ static const struct snd_pcm_ops mtk_afe_pcm_ops = { static int mtk_afe_pcm_new(struct snd_soc_pcm_runtime *rtd) { size_t size; - struct snd_card *card = rtd->card->snd_card; struct snd_pcm *pcm = rtd->pcm; struct snd_soc_component *component = snd_soc_rtdcom_lookup(rtd, AFE_PCM_NAME); struct mtk_base_afe *afe = snd_soc_component_get_drvdata(component); size = afe->mtk_afe_hardware->buffer_bytes_max; return snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV, - card->dev, size, size); + rtd->platform->dev, + size, size); } static void mtk_afe_pcm_free(struct snd_pcm *pcm) -- 2.12.5

3 4

[alsa-devel] [PATCH v2 0/7] ASoC: omap: Deprecate omap-pcm for sdma-pcm
by Peter Ujfalusi 30 Apr '18

30 Apr '18

Hi, Changes since v1: - Rebased on the n810 patches (Kconfig conflict) - Delete the omap-pcm as the last step instead of keeping the .c/.h file. If there is a need it can be resurrected with a simple revert. - I left out the Acked-by from Jarkko for the last patch since I have changed it omap-pcm served us well over the years, but there is no reason to keep it around as we can rely on generic dmaengine_pcm code without the need to maintain custom code. The series has been tested on: omap2 n810, omap3 beagle-xm, omap4 PandaES, omap4 Blaze (SDP), am57xx beagle-x15, dra7 evm. McBSP, McASP, McPDM, DMIC and HDMI audio was tested and I have found no issue with them. I was not able to test on OMAP1 for various reasons, but mainly because the Nokia 770 audio is not supported in mainline... Regards, Peter --- Peter Ujfalusi (7): ASoC: omap: Introduce the generic_dmaengine_pcm based sdma-pcm ASoC: davinci-mcasp: Convert to use the sdma-pcm instead of omap-pcm ASoC: omap-hdmi-audio: Convert to use the sdma-pcm instead of omap-pcm ASoC: omap-dmic: Convert to use the sdma-pcm instead of omap-pcm ASoC: omap-mcpdm: Convert to use the sdma-pcm instead of omap-pcm ASoC: omap-mcbsp: Convert to use the sdma-pcm instead of omap-pcm ASoC: omap: Delete the obsolete omap-pcm include/sound/omap-pcm.h | 30 ---- sound/soc/davinci/Kconfig | 2 +- sound/soc/davinci/davinci-mcasp.c | 8 +- sound/soc/omap/Kconfig | 33 ++-- sound/soc/omap/Makefile | 4 +- sound/soc/omap/omap-dmic.c | 4 +- sound/soc/omap/omap-hdmi-audio.c | 5 +- sound/soc/omap/omap-mcbsp.c | 4 +- sound/soc/omap/omap-mcpdm.c | 4 +- sound/soc/omap/omap-pcm.c | 262 ------------------------------ sound/soc/omap/sdma-pcm.c | 68 ++++++++ sound/soc/omap/sdma-pcm.h | 21 +++ 12 files changed, 124 insertions(+), 321 deletions(-) delete mode 100644 include/sound/omap-pcm.h delete mode 100644 sound/soc/omap/omap-pcm.c create mode 100644 sound/soc/omap/sdma-pcm.c create mode 100644 sound/soc/omap/sdma-pcm.h -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2 11

[alsa-devel] [PATCH] ASoC: da7219: read fmw property to get mclk for non-dts systems
by Akshu Agrawal 30 Apr '18

30 Apr '18

Non-dts based systems can use ACPI DSDT to pass on the mclk to da7219. This enables da7219 mclk to be linked to system clock. Enable/Disable of the mclk is already handled in the codec so platform drivers don't have to explicitly do handling of mclk. Signed-off-by: Akshu Agrawal <akshu.agrawal(a)amd.com> --- include/sound/da7219.h | 2 ++ sound/soc/codecs/da7219.c | 7 ++++++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/include/sound/da7219.h b/include/sound/da7219.h index 1bfcb16..df7ddf4 100644 --- a/include/sound/da7219.h +++ b/include/sound/da7219.h @@ -38,6 +38,8 @@ struct da7219_pdata { const char *dai_clks_name; + const char *mclk_name; + /* Mic */ enum da7219_micbias_voltage micbias_lvl; enum da7219_mic_amp_in_sel mic_amp_in_sel; diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c index 980a6a8..47ffb35 100644 --- a/sound/soc/codecs/da7219.c +++ b/sound/soc/codecs/da7219.c @@ -1624,6 +1624,8 @@ static struct da7219_pdata *da7219_fw_to_pdata(struct snd_soc_component *compone dev_warn(dev, "Using default clk name: %s\n", pdata->dai_clks_name); + device_property_read_string(dev, "dlg,mclk-name", &pdata->mclk_name); + if (device_property_read_u32(dev, "dlg,micbias-lvl", &of_val32) >= 0) pdata->micbias_lvl = da7219_fw_micbias_lvl(dev, of_val32); else @@ -1905,7 +1907,10 @@ static int da7219_probe(struct snd_soc_component *component) da7219_handle_pdata(component); /* Check if MCLK provided */ - da7219->mclk = devm_clk_get(component->dev, "mclk"); + if (da7219->pdata->mclk_name) + da7219->mclk = clk_get(NULL, da7219->pdata->mclk_name); + if (!da7219->mclk) + da7219->mclk = devm_clk_get(codec->dev, "mclk"); if (IS_ERR(da7219->mclk)) { if (PTR_ERR(da7219->mclk) != -ENOENT) { ret = PTR_ERR(da7219->mclk); -- 1.9.1

2 4

[alsa-devel] KASAN: use-after-free in loopback_active_get
by DaeRyong Jeong 30 Apr '18

30 Apr '18

We report the crash: KASAN: use-after-free in loopback_active_get This crash has been found in v4.17-rc1 using RaceFuzzer (a modified version of Syzkaller), which we describe more at the end of this report. Our analysis shows that the race occurs when invoking two syscalls concurrently, ioctl$SNDRV_CTL_IOCTL_ELEM_READ and syz_open_dev$audion. kernel config: https://kiwi.cs.purdue.ed/static/race-fuzzer/KASAN_use-after-free_in_loopba… Analysis: When there is a race between sound/drivers/aloop.c:895 (loopback_active_get) and sound/drivers/aloop.c:678 (free_cable), the retrieved cable pointer in loopback_active_get() may point to the freed memory region. When loopback_active_get() dereferences this pointer, use-after-free occurs. Possible CPU execution: CPU0 CPU1 loopback_active_get() free_cable() ---- ---- struct loopback_cable *cable = ... loopback->cables[substream->number][dev] = NULL; kfree(cable); cable->running <-- Use-after-free Call Sequence: CPU0 loopback_active_get snd_ctl_elem_read snd_ctl_elem_read_user snd_ctl_ioctl CPU1 free_cable loopback_close snd_pcm_release_substream snd_pcm_release_substream snd_pcm_oss_release_file snd_pcm_oss_release_file snd_pcm_oss_release We observed that snd_pcm_oss_release() is called during the open("/dev/audio1") syscall. In our configuration, the function do_dentry_open() returns -EINVAL since below if statement is evaluated as true. if ((f->f_flags & O_DIRECT) (!f->f_mapping->a_ops || !f->f_mapping->a_ops->direct_IO)) Therefore, fput() is called and snd_pcm_oss_release() is called as a pending work before returning to the user space. But we suspect that the insufficient locking between snd_ctl_ioctl() and snd_pcm_oss_release(), not the vfs_layer, is the cause of the crash. -------- Read of size 4 at addr ffff88023aa4899c by task syz-executor0/27703 CPU: 0 PID: 27703 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x182/0x24c lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] __asan_load4+0x78/0x80 mm/kasan/kasan.c:698 loopback_active_get+0x71/0xb0 sound/drivers/aloop.c:900 snd_ctl_elem_read+0x14e/0x190 sound/core/control.c:896 snd_ctl_elem_read_user sound/core/control.c:914 [inline] snd_ctl_ioctl+0xaf7/0xce0 sound/core/control.c:1560 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:500 [inline] do_vfs_ioctl+0x179/0xf40 fs/ioctl.c:684 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701 __do_sys_ioctl fs/ioctl.c:708 [inline] __se_sys_ioctl fs/ioctl.c:706 [inline] __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:706 do_syscall_64+0x17a/0x530 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x453bc9 RSP: 002b:00007fc5fba5eaf8 EFLAGS: 00000212 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000708020 RCX: 0000000000453bc9 RDX: 0000000020003b38 RSI: 00000000c4c85512 RDI: 0000000000000005 RBP: 00000000000025a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000212 R12: 00000000004aed78 R13: 00000000ffffffff R14: 0000000000000005 R15: 00000000c4c85512 Allocated by task 27704: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620 kmalloc include/linux/slab.h:512 [inline] kzalloc include/linux/slab.h:701 [inline] loopback_open+0x4d2/0x720 sound/drivers/aloop.c:704 snd_pcm_open_substream+0x174/0x250 sound/core/pcm_native.c:2391 snd_pcm_oss_open_file sound/core/oss/pcm_oss.c:2423 [inline] snd_pcm_oss_open+0x799/0xfc0 sound/core/oss/pcm_oss.c:2505 soundcore_open+0x2db/0x3e0 sound/sound_core.c:597 chrdev_open+0x1c6/0x450 fs/char_dev.c:417 do_dentry_open+0x520/0x7c0 fs/open.c:784 vfs_open+0xc5/0x120 fs/open.c:906 do_last fs/namei.c:3365 [inline] path_openat+0x1133/0x31a0 fs/namei.c:3501 do_filp_open+0x15a/0x1e0 fs/namei.c:3535 do_sys_open+0x464/0x540 fs/open.c:1093 __do_sys_open fs/open.c:1111 [inline] __se_sys_open fs/open.c:1106 [inline] __x64_sys_open+0x4c/0x60 fs/open.c:1106 do_syscall_64+0x17a/0x530 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 27704: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xd9/0x260 mm/slab.c:3813 free_cable+0x148/0x160 sound/drivers/aloop.c:679 loopback_close+0x63/0x80 sound/drivers/aloop.c:766 snd_pcm_release_substream.part.46+0x10e/0x1b0 sound/core/pcm_native.c:2357 snd_pcm_release_substream+0x49/0x60 sound/core/pcm_native.c:2349 snd_pcm_oss_release_file.part.23+0x50/0x70 sound/core/oss/pcm_oss.c:2382 snd_pcm_oss_release_file sound/core/oss/pcm_oss.c:2377 [inline] snd_pcm_oss_release+0xa9/0x160 sound/core/oss/pcm_oss.c:2562 __fput+0x246/0x4f0 fs/file_table.c:209 ____fput+0x15/0x20 fs/file_table.c:243 task_work_run+0x1b6/0x220 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:191 [inline] exit_to_usermode_loop+0x28d/0x290 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline] syscall_return_slowpath arch/x86/entry/common.c:265 [inline] do_syscall_64+0x51a/0x530 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff88023aa48900 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 156 bytes inside of 192-byte region [ffff88023aa48900, ffff88023aa489c0) The buggy address belongs to the page: page:ffffea0008ea9200 count:1 mapcount:0 mapping:ffff88023aa48000 index:0x0 flags: 0x6fffc0000000100(slab) raw: 06fffc0000000100 ffff88023aa48000 0000000000000000 0000000100000010 raw: ffffea0008eceb60 ffffea0008d95960 ffff8800b6800040 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88023aa48880: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff88023aa48900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff88023aa48980: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ffff88023aa48a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88023aa48a80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== = About RaceFuzzer RaceFuzzer is a customized version of Syzkaller, specifically tailored to find race condition bugs in the Linux kernel. While we leverage many different technique, the notable feature of RaceFuzzer is in leveraging a custom hypervisor (QEMU/KVM) to interleave the scheduling. In particular, we modified the hypervisor to intentionally stall a per-core execution, which is similar to supporting per-core breakpoint functionality. This allows RaceFuzzer to force the kernel to deterministically trigger racy condition (which may rarely happen in practice due to randomness in scheduling). RaceFuzzer's C repro always pinpoints two racy syscalls. Since C repro's scheduling synchronization should be performed at the user space, its reproducibility is limited (reproduction may take from 1 second to 10 minutes (or even more), depending on a bug). This is because, while RaceFuzzer precisely interleaves the scheduling at the kernel's instruction level when finding this bug, C repro cannot fully utilize such a feature. Please disregard all code related to "should_hypercall" in the C repro, as this is only for our debugging purposes using our own hypervisor.

2 1

← Newer
1
2
3
4
5
6
7
8
...
27
Older →

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Alsa-devel April 2018