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]
Date:	Tue, 13 Mar 2007 11:14:46 +0100
From:	Oliver Neukum <oneukum@...e.de>
To:	Jim Radford <radford@...ckbean.org>
Cc:	Mark Lord <lkml@....ca>, Greg KH <greg@...ah.com>,
	linux-usb-devel@...ts.sourceforge.net,
	Adrian Bunk <bunk@...sta.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb-serial regression fix

Am Dienstag, 13. März 2007 10:14 schrieb Jim Radford:

> > So where does the memory get freed -- the structure pointed at
> > by the serial->port[i] thingie ?  It's not a leak, is it?
> 
> It gets free'd through device_unregister
> 
>     for (i = 0; i < num_ports; ++i) {
>        ...
>        port->dev.release = &port_release;
>        ...
>        retval = device_register(&port->dev);
> 
> which means that until all the drivers get converted to use
> ->port_probe() and ->port_remove() (which gets called by
> device_unregister) and stop using the ->port[] array in ->shutdown()
> we need to have ->shutdown() called before device_unregister.
> 
> > > > > Look at changeset d9a7ecacac5f8274d2afce09aadcf37bdb42b93a in Linus's
> > > > > tree from Jim Radford:
> 
> > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d9a7ecacac5f8274d2afce09aadcf37bdb42b93a
> 
> So, this patch should be reverted for now.

While we are at it, is there a reason we call return_serial() late in the
sequence? Making sure the device is not reopened should be the
first measure. Are we protected by hanging up the tty?

Secondly, what is this code supposed to do:

	for (i = 0; i < serial->num_ports; ++i)
		serial->port[i]->open_count = 0;

If we get to destroy_serial(), how can ports still be open?

	Regards
		Oliver
-
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