From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: Re: [RFC][PATCH] Fix another namespace issue with devices assigned to classes Date: Tue, 08 Jun 2010 16:26:14 +0200 Message-ID: <1276007174.3706.133.camel@jlt3.sipsolutions.net> References: <1275484611.3915.11.camel@jlt3.sipsolutions.net> <20100602154608.GB12361@kroah.com> <1275493693.3915.12.camel@jlt3.sipsolutions.net> <1275495677.3915.16.camel@jlt3.sipsolutions.net> <1275498007.3915.20.camel@jlt3.sipsolutions.net> <1275501157.3915.22.camel@jlt3.sipsolutions.net> <1275506732.3915.41.camel@jlt3.sipsolutions.net> <1275634452.5189.1.camel@jlt3.sipsolutions.net> <1275640113.9953.8.camel@jlt3.sipsolutions.net> <1275829701.3615.54.camel@jlt3.sipsolutions.net> <1275903773.29978.1.camel@jlt3.sipsolutions.net> <1275905686.29978.3.camel@jlt3.sipsolutions.net> <1275910905.29978.7.camel@jlt3.sipsolutions.net> <1275913563.1823.1.camel@yio.site> <1275914205.29978.10.camel@jlt3.sipsolutions.net> <1275989260.3706.115.camel@jlt3.sipsolutions.net> <1275990325.3706.116.camel@jlt3.sipsolutions.net> <1275998127.1899.38.camel@yio.site> <1275998603.3706.118.camel@jlt3.sipsolutions.net> <1276005970.3706.132.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: "Eric W. Biederman" , Greg KH , netdev To: Kay Sievers Return-path: Received: from he.sipsolutions.net ([78.46.109.217]:38910 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755170Ab0FHO0W (ORCPT ); Tue, 8 Jun 2010 10:26:22 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Tue, 2010-06-08 at 16:21 +0200, Kay Sievers wrote: > > Well they will be unregistered and everything, but once all the netdevs > > are gone etc. the devices you create in the patch might stick around > > because somebody has them open in sysfs, and I see nothing that would > > pin the module in that case? > > That's what I mean, I have no idea how to solve that with network > devices. I don't think any other subsytem allows to unload the module, > when devices, the module has created, are in use. You're right ... the would only be unregistered from your release, which would happen after the module is long gone ... > The current code uses the in-core class_create() logic, which was only > meant for devices with a device node, and which is cleaned up by the > core itself. That's why this issue never appeared before. > > But as said, I have no idea how to solve that with a single module. It > might not work at all without moving stuff into the core. That people > use device_create() with no major/minor might indicate that something > else is needed here. :) So ... can we apply Eric's patch for now then? johannes