pty tcdrain() bug in 2.6.27 to 2.6.30/current

pty tcdrain() bug in 2.6.27 to 2.6.30/current

[Luke-Jr]

tcdrain blocks on ptys since 2.6.27; at least 2.6.26 returns in a timely 
manner. The following test case reproduces the bug, and hangs only on affected 
kernels. Examination of 2.6.26 and 2.6.27 suggests the ioctl used by tcdrain 
underwent a rewrite for 2.6.27, and thus fixing this bug is beyond my 
capabilities at this time.

-------

#define _POSIX_C_SOURCE 200112L
#define _XOPEN_SOURCE

#include <assert.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>

int
main() {
	int masterfd, slavefd;
	char test[] = "test";
	
	masterfd = posix_openpt(O_RDWR | O_NOCTTY);
	assert(masterfd != -1);
	grantpt(masterfd);
	unlockpt(masterfd);
	
	slavefd = open(ptsname(masterfd), O_NOCTTY | O_RDWR);
	assert(slavefd != -1);
	
	assert(sizeof(test) == write(slavefd, test, sizeof(test)));
	assert(!tcdrain(slavefd));
}

Re: pty tcdrain() bug in 2.6.27 to 2.6.30/current

[Luke-Jr]

On Wednesday 10 June 2009 01:39:14 am Mike Galbraith wrote:
> On Tue, 2009-06-09 at 23:38 -0500, Luke-Jr wrote:
> > tcdrain blocks on ptys since 2.6.27; at least 2.6.26 returns in a timely
> > manner. The following test case reproduces the bug, and hangs only on
> > affected kernels. Examination of 2.6.26 and 2.6.27 suggests the ioctl
> > used by tcdrain underwent a rewrite for 2.6.27, and thus fixing this bug
> > is beyond my capabilities at this time.
>
> It looks to me like it's doing what it should do, and any bug would be
> in kernels before the break handling (by Alan Cox, CC'd) rework.
>
> Disclaimer:  My knowledge wrt tty IO approaches 0, but since I burned a
> bit of time rummaging, you get one absolutely free reply.

My knowledge on how it *should* work also approaches 0, but I am unfortunately 
faced with a proprietary (user-space) blob GPS driver (which never reads its 
NMEA-providing pty) that relies on this behaviour (or gpsd not doing the 
tcdrain). However, the manual page for tcdrain says it waits until data is 
*trasmitted*, not necessarily received... Not sure if that makes a difference 
for this scenario?

Luke

Re: pty tcdrain() bug in 2.6.27 to 2.6.30/current

[Alan Cox]

> manner. The following test case reproduces the bug, and hangs only on affected 
> kernels. Examination of 2.6.26 and 2.6.27 suggests the ioctl used by tcdrain 
> underwent a rewrite for 2.6.27, and thus fixing this bug is beyond my 
> capabilities at this time.

I don't see a bug at this point

> 	slavefd = open(ptsname(masterfd), O_NOCTTY | O_RDWR);
> 	assert(slavefd != -1);
> 	
> 	assert(sizeof(test) == write(slavefd, test, sizeof(test)));

Queue data to the other end...

> 	assert(!tcdrain(slavefd));

Wait for it to be read, but with nothing reading it.

So it waits as it should.


What is the bug here ?

Alan