On Thu, Apr 01, 2004 at 09:56:16AM -0500, Alan Stern wrote:
> On Thu, 1 Apr 2004, Maneesh Soni wrote:
>
> > On Wed, Mar 31, 2004 at 10:11:37AM -0500, Alan Stern wrote:
> > >
> > > Here's a suggestion. At the start of check_perm() grab the dentry
> > > semaphore, then check whether d_fsdata is N
On Thu, 1 Apr 2004, Maneesh Soni wrote:
> On Wed, Mar 31, 2004 at 10:11:37AM -0500, Alan Stern wrote:
> >
> > Here's a suggestion. At the start of check_perm() grab the dentry
> > semaphore, then check whether d_fsdata is NULL, if it isn't then do the
> > kobject_get(), then unlock the semapho
On Thu, Apr 01, 2004 at 10:47:40AM +0530, Maneesh Soni wrote:
> I am out of any more ideas except something like making sysfs single threaded
> or requesting people to try my sysfs backing store patch set. It does not
> suffer from the negative dentries problem as it does not create any negative
>
> > I just had a lng discussion with Rusty on that subject, it's
> > indeed a nasty one.
>
> Ah, he sucks another person into the "module unload" discussion. My
> sympathies :)
Nah, I started it, since he is about 2 meters from me in the
office, that isn't difficult :)
> I agree, it's a di
On Thu, Apr 01, 2004 at 11:56:09AM +1000, Benjamin Herrenschmidt wrote:
>
> > But that is impossible as has already been pointed out by Alan Stern.
> > If a module creates a kobject, how can the module_exit() function ever
> > be called if that kobject incremented the module reference count?
>
>
On Wed, Mar 31, 2004 at 10:11:37AM -0500, Alan Stern wrote:
> On Wed, 31 Mar 2004, Maneesh Soni wrote:
>
> > For convenience I will explain the race here..
> >
> > cpu 0 cpu 1
> > kobject_unregister() sysfs_op
On Thu, 1 Apr 2004, Benjamin Herrenschmidt wrote:
> > But that is impossible as has already been pointed out by Alan Stern.
> > If a module creates a kobject, how can the module_exit() function ever
> > be called if that kobject incremented the module reference count?
>
> I just had a lng dis
> But that is impossible as has already been pointed out by Alan Stern.
> If a module creates a kobject, how can the module_exit() function ever
> be called if that kobject incremented the module reference count?
I just had a lng discussion with Rusty on that subject, it's
indeed a nasty one.
On Wed, Mar 31, 2004 at 12:11:30PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2004-03-31 at 09:55, Greg KH wrote:
> > Hi,
> >
> > The patch below backs out Maneesh's sysfs patch that was recently added
> > to the kernel. In its defense, the original patch did solve some fixes
> > that could b
On Wed, 31 Mar 2004, Maneesh Soni wrote:
> For convenience I will explain the race here..
>
> cpu 0 cpu 1
> kobject_unregister() sysfs_open_file()
> kobject_del()check_perm()
On Tue, Mar 30, 2004 at 06:19:15PM -0800, Andrew Morton wrote:
>
> But it looks like that's all in a faraway perfect world, and Greg is going
> to fix stuff up somehow ;)
For convenience I will explain the race here..
cpu 0 cpu 1
kobject_unregist
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> I think that the bug in the first place is to have an existing
> kobject that didn't bump the module ref count.
>
> If a kobject exists that have a pointer to the module code (the
> release function), it _MUST_ have bumped the module ref co
On Wed, 2004-03-31 at 09:55, Greg KH wrote:
> Hi,
>
> The patch below backs out Maneesh's sysfs patch that was recently added
> to the kernel. In its defense, the original patch did solve some fixes
> that could be duplicated on SMP machines, but the side affect of the
> patch caused lots of prob
Hi,
The patch below backs out Maneesh's sysfs patch that was recently added
to the kernel. In its defense, the original patch did solve some fixes
that could be duplicated on SMP machines, but the side affect of the
patch caused lots of problems. Basically it caused kobjects to get
their referen
14 matches
Mail list logo
