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: <20140106192353.GA32664@kroah.com>
Date:	Mon, 6 Jan 2014 11:23:53 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Mikulas Patocka <mpatocka@...hat.com>
Cc:	Bart Van Assche <bvanassche@....org>,
	Jeff Mahoney <jeffm@...e.com>, torvalds@...ux-foundation.org,
	device-mapper development <dm-devel@...hat.com>,
	paulmck@...ux.vnet.ibm.com, tglx@...utronix.de,
	linux-kernel@...r.kernel.org, mingo@...nel.org
Subject: Re: [dm-devel] [PATCH] kobject: provide kobject_put_wait to fix
 module unload race

On Mon, Jan 06, 2014 at 01:55:11PM -0500, Mikulas Patocka wrote:
> 
> 
> On Sun, 5 Jan 2014, Greg Kroah-Hartman wrote:
> 
> > On Sun, Jan 05, 2014 at 05:43:56PM +0100, Bart Van Assche wrote:
> > > On 01/04/14 19:06, Mikulas Patocka wrote:
> > > > -	if (t && !t->release)
> > > > -		pr_debug("kobject: '%s' (%p): does not have a release() "
> > > > -			 "function, it is broken and must be fixed.\n",
> > > > -			 kobject_name(kobj), kobj);
> > > > -
> > > 
> > > Has it been considered to issue a warning if no release function has
> > > been defined and free_completion == NULL instead of removing the above
> > > debug message entirely ? I think even with this patch applied it is
> > > still wrong to invoke kobject_put() on an object without defining a
> > > release function.
> > 
> > This patch isn't going to be applied, and I've reverted the original
> > commit, so there shouldn't be any issues anymore with this code.
> 
> Why? This patch does the same thing as 
> eee031649707db3c9920d9498f8d03819b74fc23, but it's smaller. So why did you 
> accept eee031649707db3c9920d9498f8d03819b74fc23 and not this?

I have now reverted that commit, it will not be in 3.14, so consider it
rejected as well :)

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