From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH] ALSA: seq: Correct unlock sequence at snd_seq_client_ioctl_unlock() Date: Mon, 15 Apr 2019 12:05:11 +0200 Message-ID: References: <20190415093105.23965-1-tiwai@suse.de> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id F109AF896E2 for ; Mon, 15 Apr 2019 12:05:12 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" To: Kai Vehmanen Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org On Mon, 15 Apr 2019 12:05:07 +0200, Kai Vehmanen wrote: > > Hi, > > On Mon, 15 Apr 2019, Takashi Iwai wrote: > > > The doubly unlock sequence at snd_seq_client_ioctl_unlock() is tricky. > > I took a direct unref call since I thought it would avoid > > misunderstanding, but rather this seems more confusing. Let's use > > snd_seq_client_unlock() consistently even if they look strange to be > > called twice, and add more comments for avoiding reader's confusion. > > > > Fixes: 6b580f523172 ("ALSA: seq: Protect racy pool manipulation from OSS sequencer") > > Signed-off-by: Takashi Iwai > > --- > > sound/core/seq/seq_clientmgr.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > thanks, looks good now (this and rest of the clean-up series): > Reviewed-by: Kai Vehmanen Thanks! Takashi