lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 5 Jan 2011 14:42:21 -0800
From:	Greg KH <greg@...ah.com>
To:	Pete Zaitcev <zaitcev@...hat.com>
Cc:	Tsozik <tsozik@...oo.com>, Greg Kroah-Hartman <gregkh@...e.de>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] mct_u232: added _ioctl, _msr_to_icount and
 _get_icount functions

On Mon, Dec 27, 2010 at 11:40:47PM -0700, Pete Zaitcev wrote:
> On Mon, 27 Dec 2010 20:04:51 -0800 (PST)
> Tsozik <tsozik@...oo.com> wrote:
> 
> > So I ran geiger counter against /dev/ttyS0 device for 20 minutes and
> > acquired 20 measurements. Then I compared last average with last 20
> > minute measurement average acquired via mct_u232 on the laptop placed
> > nearby. The error was ~4% (rounded up).
> 
> Great, I'm ready to ack.
> 
> There's just one thing that is bugging me... I think it would be best
> if Alan Cox or Greg Kroah commented on it. The edgeport does the
> following, which we copied:
> 
> 
> 		schedule();
> 		........
> 		if (cnow.rng == cprev.rng && cnow.dsr == cprev.dsr &&
> 		    cnow.dcd == cprev.dcd && cnow.cts == cprev.cts)
> 			return -EIO; /* no change => error */
> 		if (((arg & TIOCM_RNG) && (cnow.rng != cprev.rng)) ||
> 		    ((arg & TIOCM_DSR) && (cnow.dsr != cprev.dsr)) ||
> 		    ((arg & TIOCM_CD)  && (cnow.dcd != cprev.dcd)) ||
> 		    ((arg & TIOCM_CTS) && (cnow.cts != cprev.cts))) {
> 			return 0;
> 		}
> 
> So, if there was a status report, but no change to bits, the ioctl
> TIOCMIWAIT would return with -EIO. In serial_core.c, that serves
> conventional non-USB UARTs, nothing like this occurs. I am not quite
> sure what the point of doing this -EIO check is.

Odd, I don't really remember where I copied that logic from, that was a
long time ago.

> Oh and BTW, I'm wondering what is going to happen if the device is
> disconnected while an application is blocked waiting for the status
> change. The patch is not particularly bad here, it just copies
> an existing code from elsewhere.

It should handle the disconnect, if not, we should fix it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ