Re: kern/60760: lpt(4) concurrency issues

["Johann Höpfner via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60760; it has been noted by GNATS.

From: Johann =?utf-8?Q?H=C3=B6pfner?= <hoepf%cit.tum.de@localhost>
To: Taylor R Campbell <riastradh%netbsd.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/60760: lpt(4) concurrency issues
Date: Thu, 24 Sep 2026 15:18:21 +0200

 > Thanks, I filed a problem report in gnats to track this:
 > 
 > PR kern/60760: lpt(4) concurrency issues
 > https://gnats.NetBSD.org/60760
 > 
 > (Followups to this message, to gnats-bugs%NetBSD.org@localhost with subject line
 > `Re: kern/60760: lpt(4) concurrency issues', will get appended to the
 > PR, and if you want, I can add you to the notify-list.)
 
 Feel free to do that.
 
 > It's not clear to me that there is any value in allowing concurrent
 > lptwrite calls at all.
 > 
 > So rather than try to mitigate the damage of interleaving internal
 > data structure updates like that, I'm inclined to just set a flag
 > sc->sc_state |= LPT_WRITING while the first lptwrite is in progress,
 > to block subsequent attempts to lptwrite until the first one is done.
 
 I agree. If someone relied on writing to the same port concurrently they
 would have probably noticed the mangled output by now. Especially since,
 now that I think of it, the bug should get worse with slower printers.
 
 Two things, without further looking at the patch:
 
 > +out:	if (locked) {
 > +		sc->sc_state &= LPT_WRITING;
 > +		wakeup(&sc->sc_state);
 > +	}
 > +	splx(s);
 
 I believe you want to clear LPT_WRITING here. You are clearing all other
 bits though.
 
 >  	return 0;
 
 Maybe return error here instead of 0.