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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20071029212433.c9837c4b.zaitcev@redhat.com>
Date:	Mon, 29 Oct 2007 21:24:33 -0700
From:	Pete Zaitcev <zaitcev@...hat.com>
To:	vitalivanov@...il.com
Cc:	Oliver Neukum <oliver@...kum.org>,
	linux-usb-devel@...ts.sourceforge.net, greg@...ah.com,
	linux-kernel@...r.kernel.org, netwiz@....id.au, zaitcev@...hat.com
Subject: Re: USB: FIx locks and urb->status in adutux

On Mon, 29 Oct 2007 20:04:57 +0200, Vitaliy Ivanov <vitalivanov@...il.com> wrote:

> Finally had a time on my weekend to perform tests and fix Pete's patch a little. Now it seems to be correct.

Great!

> 1. One device per user space application. Old driver allowed many users application to work with same device which can lead to IO mess.

OK. This trick was popular in UNIX. Personally I think it's in a bad
taste, because good applications still need to verify if only one
instance is running, and threfore can use application level locking.
But if you are gunning for the maintenership I'm not going to argue
your style. The busy lock-out certainly works better than "/dev/cua" :-)

However, this looks wrong:

> +			 dev->interrupt_in_endpoint->bInterval);
> +	dev->read_urb_finished = 0;
> +	retval = usb_submit_urb(dev->interrupt_in_urb, GFP_KERNEL);
> +	/* we ignore failure */
> +	/* end of fixup for first read */
> +
> +	/* initialize out direction */
> +	dev->out_urb_finished = 1;

The finished flag is only set when URB is not in use anymore. Did you
observe an anomaly with my code? Any hangs? If so, I assure you this
is not the fix. As it's written, even if we ignore the failure (e.g.
do not pass it to userland), we sill have to maintain the correct
flag state.

-- Pete
-
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