Re: [PATCH v3 7/7] ALSA: seq: Don't lose partial read failure

[Takashi Iwai <tiwai@suse.de>]

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