Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3696983ybl; Mon, 13 Jan 2020 00:42:52 -0800 (PST) X-Google-Smtp-Source: APXvYqyww7phk+jknYD+G3+zKWjGBYxbuiQL//ePa7I6Jei6JY/VAbKkAUiHTPglShP9LJ1ud/Vo X-Received: by 2002:a9d:7d85:: with SMTP id j5mr12491160otn.86.1578904972841; Mon, 13 Jan 2020 00:42:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578904972; cv=none; d=google.com; s=arc-20160816; b=LPY0BF16QXHC2kHsvgH+Rima5j1k8SwuqDlZGmpnRo8LStx602sZddtcYrWeFyOi08 xNfuTFpUTH8kII0T9bkpTziLmw3geDdO8NFhAVtYR9SYdTiFod3EQ7djrOzQxEVY3Q9k 6p4s70qmUU5/47gVb/MX2piUoMK6o9tf3YJt4+CTPDtPgccSFA2Yh+A+4VRyKz4KydxC DXdurCoEJ+40PwCX+FqawewFL0aATyJX1Vjq6+wMHuarn36paBfgYB9gLoelX4KcasQE zejCYaRSP3uN6EV3pC6mejU5JDWYkQhIHftI0xETmTnVDZjhiMsc8322V0sBplGlaDah ZZwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:subject:cc:to:from:message-id :date; bh=vbyTiiPyQsBMoOAddTaL/g+88RFYqVcdEvl1kFyf0hI=; b=BQI7idIFTDvrZCocNtPK96R3YS6G+3w84Nrzd2YWREbGeacIBexTuXSoqTepKfgvnI gy+6MvUTPVdBXG81oTDy2wJ4zfy6P7SH/pkak6AbXclRnXBYs2g+T5BRn8td02GdYwTB GhPcZRB1e1I0s0pmOLClwWU3oRNauW+pQW1idEtvI4/pipY5B7/B3aO3LIqsTLMJ4FF7 HuBYsYM1XeGl8tsw7JynsabZLIw9pTqL3dvjhryuzDwnDdDhpEPOawdACbyC/4ldDbZA 368f4HUcuUT/vAlim8w9WiSHJIBqrtjk47QqmrmDMJ3Gf3xCV8tQTJIUncMV/Y4bjsq3 gNlg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t4si6642737otc.160.2020.01.13.00.42.40; Mon, 13 Jan 2020 00:42:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728966AbgAMIkn (ORCPT + 99 others); Mon, 13 Jan 2020 03:40:43 -0500 Received: from mx2.suse.de ([195.135.220.15]:42054 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728946AbgAMIkl (ORCPT ); Mon, 13 Jan 2020 03:40:41 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0F65AAEBA; Mon, 13 Jan 2020 08:40:39 +0000 (UTC) Date: Mon, 13 Jan 2020 09:40:38 +0100 Message-ID: From: Takashi Iwai To: Jia-Ju Bai Cc: perex@perex.cz, tiwai@suse.com, rfontana@redhat.com, tglx@linutronix.de, allison@lohutok.net, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ALSA: cmipci: Fix possible a data race in snd_cmipci_interrupt() In-Reply-To: References: <20200111163027.27135-1-baijiaju1990@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 13 Jan 2020 09:20:37 +0100, Jia-Ju Bai wrote: > > > > On 2020/1/12 16:20, Takashi Iwai wrote: > > On Sat, 11 Jan 2020 17:30:27 +0100, > > Jia-Ju Bai wrote: > >> The functions snd_cmipci_interrupt() and snd_cmipci_capture_trigger() > >> may be concurrently executed. > >> > >> The function snd_cmipci_capture_trigger() calls > >> snd_cmipci_pcm_trigger(). In snd_cmipci_pcm_trigger(), the variable > >> rec->running is written with holding a spinlock cm->reg_lock. But in > >> snd_cmipci_interrupt(), the identical variable cm->channel[0].running > >> or cm->channel[1].running is read without holding this spinlock. Thus, > >> a possible data race may occur. > >> > >> To fix this data race, in snd_cmipci_interrupt(), the variables > >> cm->channel[0].running and cm->channel[1].running are read with holding > >> the spinlock cm->reg_lock. > >> > >> This data race is found by the runtime testing of our tool DILP-2. > >> > >> Signed-off-by: Jia-Ju Bai > > Thanks for the patch. > > > > That's indeed a kind of race, but this change won't fix anything in > > practice, though. The inconsistent running flag between those places, > > there are two cases: > > > > - running became 0 to 1; this cannot happen, as the irq isn't issued > > before the stream gets started > > > > - running became 1 to 0; this means that the stream gets stopped > > between two points, and it's not better to call > > snd_pcm_period_elapsed() for an already stopped stream. > > Thanks for the reply :) > > I am not sure to understand your words. > > Do you mean that this code should be also protected by the spinlock? >     if (cm->pcm) { >         if ((status & CM_CHINT0) && cm->channel[0].running) >             snd_pcm_period_elapsed(cm->channel[0].substream); >         if ((status & CM_CHINT1) && cm->channel[1].running) >             snd_pcm_period_elapsed(cm->channel[1].substream); >     } No, it can't be protected as it would lead to ABBA deadlock. That said, it's rather safe to leave the code as is. thanks, Takashi