From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 68D9C490C0B; Thu, 8 Oct 2026 12:00:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791460802; cv=none; b=EzcI5eYnKvyfI1w48SZrIO/V2LMcRtrCAf9WVbGsNNn7+6CkvkDz2KkTO4E9+hQkz3NAAvMCThTeTVd8/yHeRVyM+tOuR1xstXg9/Z/Aczx2RVxun+77GGKIq6V8VVQ9AQl8LpwsLJQ3815iFH2Zj67KAuTo3G8YEZkS8jKm7OI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791460802; c=relaxed/simple; bh=k7jNw8v3RsS5ksPNASdWudNKgG6JpCqHRMkFjsSLdHE=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=hyQQEQYFGy9nRObrzLp1zBSvlzxQolTuT/UMJCDJieSE2eGeCROWfc9sMC5h3xR98R5pD70jVXN2Z/Db/Puw8VXmCIs+R2Cn1jIqbQxZgbKRdvUCshscE7hYq+0ZqyBHP+rDSyhwX5/6Ct8fo4EAi94eeCGvumIxUzvPTyJbTEM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de; spf=pass smtp.mailfrom=suse.de; arc=none smtp.client-ip=195.135.223.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.de Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id A8BDB21B07; Thu, 8 Oct 2026 11:59:58 +0000 (UTC) Authentication-Results: smtp-out1.suse.de; none Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 7DCCD13354; Thu, 8 Oct 2026 11:59:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 67SaC76Fx2pWJAAAD6G6ig (envelope-from ); Thu, 08 Oct 2026 11:59:58 +0000 Date: Thu, 08 Oct 2026 13:59:53 +0200 Message-ID: <87cxtk5rnq.wl-tiwai@suse.de> From: Takashi Iwai To: Cezary Rojewski Cc: Takashi Iwai , , Subject: Re: [PATCH v3 7/7] ALSA: seq: Don't lose partial read failure In-Reply-To: References: <20261007172533.14667-1-tiwai@suse.de> <20261007172533.14667-8-tiwai@suse.de> <87o6d4609l.wl-tiwai@suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/30.2 Mule/6.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Spam-Flag: NO X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Spam-Level: X-Spamd-Result: default: False [0.00 / 50.00] X-Spam-Score: 0.00 On Thu, 08 Oct 2026 13:43:47 +0200, Cezary Rojewski wrote: > > On 10/8/2026 10:53 AM, Takashi Iwai wrote: > > On Thu, 08 Oct 2026 10:32:29 +0200, > > Cezary Rojewski wrote: > > >>> --- a/sound/core/seq/seq_clientmgr.c > >>> +++ b/sound/core/seq/seq_clientmgr.c > >>> @@ -480,11 +480,11 @@ static ssize_t snd_seq_read(struct file *file, char __user *buf, size_t count, > >>> if (err < 0) { > >>> if (cell) > >>> snd_seq_fifo_cell_putback(fifo, cell); > >>> - if (err == -EAGAIN && result > 0) > >>> - err = 0; > >>> } > >>> > >>> - return (err < 0) ? err : result; > >>> + if (result > 0) > >>> + return result; > >>> + return err < 0 ? err : 0; > >> > >> Can 'err' even be positive? Looks to me as if 'result' holds the bytes > >> and flat 'return err' suffices. > > > > Yes, it's just to make sure. > It's not a blocker obviously, I'm just in favor of avoiding > double-protection. I'd rather fix the problem that causes 'err' to be > positive if somehow things turn that way. Well, at this place, I'd rather to be sure than sorry. It's the end return point to user-space, hence we need to have a stricter check. Of course, if it were involving too heavy performance, I'd agree for optimization, but it's not that case :) thanks, Takashi