On Wed, 7 Nov 2007, Kay Sievers wrote:
> It would remove another implicit "magic" from the core, which is good.
Yes.
> Otherwise we will need to introduce a kobject_orphan(), to disassociate
> an object from its parent, which would be kind of weird, just to break
> out of the default core
On Wed, 2007-11-07 at 10:54 -0500, Alan Stern wrote:
> On Wed, 7 Nov 2007, Hannes Reinecke wrote:
>
> > Alan Stern wrote:
> > >
> > > Thus we have a cycle:
> > >
> > > 1&2: request_queue isn't released before scsi_device;
> > >
> > > 3: scsi_device isn't released before gendisk;
> > >
> >
On Wed, 7 Nov 2007, Hannes Reinecke wrote:
> Alan Stern wrote:
> >
> > Thus we have a cycle:
> >
> > 1&2: request_queue isn't released before scsi_device;
> >
> > 3: scsi_device isn't released before gendisk;
> >
> > 4: gendisk isn't released before request_queue.
> >
> > The
Alan Stern wrote:
> On Mon, 5 Nov 2007, Greg KH wrote:
>
>> On Mon, Nov 05, 2007 at 04:49:21PM -0500, Alan Stern wrote:
>>> Greg:
>>>
>>> So what's our status? Do you think it's worthwhile adding the
>>> "drop reference to parent kobject at remove time instead of release
>>> time" patch?
>>
Alan Stern wrote:
On Mon, 5 Nov 2007, Greg KH wrote:
On Mon, Nov 05, 2007 at 04:49:21PM -0500, Alan Stern wrote:
Greg:
So what's our status? Do you think it's worthwhile adding the
drop reference to parent kobject at remove time instead of release
time patch?
No.
I still need to
On Wed, 7 Nov 2007, Hannes Reinecke wrote:
Alan Stern wrote:
Thus we have a cycle:
12: request_queue isn't released before scsi_device;
3: scsi_device isn't released before gendisk;
4: gendisk isn't released before request_queue.
The dependency in 12 is
On Wed, 2007-11-07 at 10:54 -0500, Alan Stern wrote:
On Wed, 7 Nov 2007, Hannes Reinecke wrote:
Alan Stern wrote:
Thus we have a cycle:
12: request_queue isn't released before scsi_device;
3: scsi_device isn't released before gendisk;
4: gendisk isn't
On Wed, 7 Nov 2007, Kay Sievers wrote:
It would remove another implicit magic from the core, which is good.
Yes.
Otherwise we will need to introduce a kobject_orphan(), to disassociate
an object from its parent, which would be kind of weird, just to break
out of the default core logic.
I
On Mon, 5 Nov 2007, Greg KH wrote:
> On Mon, Nov 05, 2007 at 04:49:21PM -0500, Alan Stern wrote:
> > Greg:
> >
> > So what's our status? Do you think it's worthwhile adding the
> > "drop reference to parent kobject at remove time instead of release
> > time" patch?
>
> No.
>
> I still need
On Mon, 5 Nov 2007, Greg KH wrote:
On Mon, Nov 05, 2007 at 04:49:21PM -0500, Alan Stern wrote:
Greg:
So what's our status? Do you think it's worthwhile adding the
drop reference to parent kobject at remove time instead of release
time patch?
No.
I still need to take the time
On Mon, Nov 05, 2007 at 04:49:21PM -0500, Alan Stern wrote:
> Greg:
>
> So what's our status? Do you think it's worthwhile adding the
> "drop reference to parent kobject at remove time instead of release
> time" patch?
No.
I still need to take the time and read this thread and find the real
Greg:
So what's our status? Do you think it's worthwhile adding the
"drop reference to parent kobject at remove time instead of release
time" patch?
Also, what's the story on the updates to the USB uevent routines? Do
you want separate patches from Kay and me or should we combine them
into
Greg:
So what's our status? Do you think it's worthwhile adding the
drop reference to parent kobject at remove time instead of release
time patch?
Also, what's the story on the updates to the USB uevent routines? Do
you want separate patches from Kay and me or should we combine them
into a
On Mon, Nov 05, 2007 at 04:49:21PM -0500, Alan Stern wrote:
Greg:
So what's our status? Do you think it's worthwhile adding the
drop reference to parent kobject at remove time instead of release
time patch?
No.
I still need to take the time and read this thread and find the real
problem
On Tue, 23 Oct 2007, Kay Sievers wrote:
> > Yes; I haven't been able to figure out why we get different results.
> >
> > > There must be something going wrong with the block patch in conjunction
> > > with the crazy SCSI release logic.
I found out why it works on my system -- which still leaves
On Tue, 23 Oct 2007, Kay Sievers wrote:
Yes; I haven't been able to figure out why we get different results.
There must be something going wrong with the block patch in conjunction
with the crazy SCSI release logic.
I found out why it works on my system -- which still leaves open the
On Tue, 2007-10-23 at 00:14 -0400, Alan Stern wrote:
> On Tue, 23 Oct 2007, Kay Sievers wrote:
>
> > There is definitely something wrong, I tried all sorts of options now,
> > and a second machine, and I can never get the behavior you see. I even
> > booted with init=/bin/sh.
> > But true,
On Tue, 2007-10-23 at 00:14 -0400, Alan Stern wrote:
On Tue, 23 Oct 2007, Kay Sievers wrote:
There is definitely something wrong, I tried all sorts of options now,
and a second machine, and I can never get the behavior you see. I even
booted with init=/bin/sh.
But true, looking at the
On Tue, 23 Oct 2007, Kay Sievers wrote:
> There is definitely something wrong, I tried all sorts of options now,
> and a second machine, and I can never get the behavior you see. I even
> booted with init=/bin/sh.
> But true, looking at the kobject debugging for loop devices, and usb
> storage
On Sun, 2007-10-21 at 20:26 -0400, Alan Stern wrote:
> On Sun, 21 Oct 2007, Kay Sievers wrote:
>
> > > [ 458.013133] scsi_disk_release: disk sda, kobj ce8be990, refcount
> > > before put_disk 2
> > > [ 458.032420] scsi_device_dev_release: rq cd9b2000
> >
> > Hmm, I still don't see this
On Sun, 2007-10-21 at 20:26 -0400, Alan Stern wrote:
On Sun, 21 Oct 2007, Kay Sievers wrote:
[ 458.013133] scsi_disk_release: disk sda, kobj ce8be990, refcount
before put_disk 2
[ 458.032420] scsi_device_dev_release: rq cd9b2000
Hmm, I still don't see this without the final
On Tue, 23 Oct 2007, Kay Sievers wrote:
There is definitely something wrong, I tried all sorts of options now,
and a second machine, and I can never get the behavior you see. I even
booted with init=/bin/sh.
But true, looking at the kobject debugging for loop devices, and usb
storage driven
On Sun, 21 Oct 2007, Kay Sievers wrote:
> > [ 458.013133] scsi_disk_release: disk sda, kobj ce8be990, refcount before
> > put_disk 2
> > [ 458.032420] scsi_device_dev_release: rq cd9b2000
>
> Hmm, I still don't see this without the final put.
Yes, I see your point. Suppose you try doing the
On Sat, 2007-10-20 at 21:33 -0400, Alan Stern wrote:
> On Sat, 20 Oct 2007, Kay Sievers wrote:
>
> > Here is what I see, the error handler hangs without the final put and
> > the kobject never gets cleaned up. Note the missing:
> > kobject sdb: cleaning up
> >
> > What is your
On Sat, 2007-10-20 at 21:33 -0400, Alan Stern wrote:
On Sat, 20 Oct 2007, Kay Sievers wrote:
Here is what I see, the error handler hangs without the final put and
the kobject never gets cleaned up. Note the missing:
kobject sdb: cleaning up
What is your CONFIG_SYSFS_DEPRECATED
On Sun, 21 Oct 2007, Kay Sievers wrote:
[ 458.013133] scsi_disk_release: disk sda, kobj ce8be990, refcount before
put_disk 2
[ 458.032420] scsi_device_dev_release: rq cd9b2000
Hmm, I still don't see this without the final put.
Yes, I see your point. Suppose you try doing the exact
On Sat, 20 Oct 2007, Kay Sievers wrote:
> Here is what I see, the error handler hangs without the final put and
> the kobject never gets cleaned up. Note the missing:
> kobject sdb: cleaning up
>
> What is your CONFIG_SYSFS_DEPRECATED option? I have it unset, and that
> may be the difference
On Sat, 20 Oct 2007, Kay Sievers wrote:
Here is what I see, the error handler hangs without the final put and
the kobject never gets cleaned up. Note the missing:
kobject sdb: cleaning up
What is your CONFIG_SYSFS_DEPRECATED option? I have it unset, and that
may be the difference in the
On Fri, 2007-10-19 at 13:11 -0400, Alan Stern wrote:
> On Fri, 19 Oct 2007, Kay Sievers wrote:
> > > Don't you have a USB storage device? It should be easy for you to
> test
> > > this on your own system.
> >
> > Sure, I have, and tried a lot of times, and all seemed correct here
> with
> >
On Fri, 19 Oct 2007, Kay Sievers wrote:
> > Don't you have a USB storage device? It should be easy for you to test
> > this on your own system.
>
> Sure, I have, and tried a lot of times, and all seemed correct here with
> the final put. I don't say that it's the right fix, but without it, the
On Fri, 2007-10-19 at 10:09 -0400, Alan Stern wrote:
> On Fri, 19 Oct 2007, Kay Sievers wrote:
>
> > > This accounts for everything in del_gendisk except the final
> > > put_device. Evidently it doesn't belong there. There's no matching
> > > get_device in add_disk or register_disk.
> >
> >
On Fri, 19 Oct 2007, Kay Sievers wrote:
> > This accounts for everything in del_gendisk except the final
> > put_device. Evidently it doesn't belong there. There's no matching
> > get_device in add_disk or register_disk.
>
> Hmm, do you have kobject debugging enabled? Do you ever see
On Fri, 2007-10-19 at 10:09 -0400, Alan Stern wrote:
On Fri, 19 Oct 2007, Kay Sievers wrote:
This accounts for everything in del_gendisk except the final
put_device. Evidently it doesn't belong there. There's no matching
get_device in add_disk or register_disk.
Hmm, do you
On Fri, 19 Oct 2007, Kay Sievers wrote:
This accounts for everything in del_gendisk except the final
put_device. Evidently it doesn't belong there. There's no matching
get_device in add_disk or register_disk.
Hmm, do you have kobject debugging enabled? Do you ever see something
like:
On Fri, 2007-10-19 at 13:11 -0400, Alan Stern wrote:
On Fri, 19 Oct 2007, Kay Sievers wrote:
Don't you have a USB storage device? It should be easy for you to
test
this on your own system.
Sure, I have, and tried a lot of times, and all seemed correct here
with
the final put. I
On Fri, 19 Oct 2007, Kay Sievers wrote:
Don't you have a USB storage device? It should be easy for you to test
this on your own system.
Sure, I have, and tried a lot of times, and all seemed correct here with
the final put. I don't say that it's the right fix, but without it, the
disk
On Thu, 2007-10-18 at 16:08 -0400, Alan Stern wrote:
> On Thu, 18 Oct 2007, Kay Sievers wrote:
>
> > On Thu, 2007-10-18 at 15:23 -0400, Alan Stern wrote:
> > > This patch (as1004) fixes a refcounting bug in the development version
> > > of the block-device core.
> > >
> > > Signed-off-by: Alan
On Thu, 18 Oct 2007, Kay Sievers wrote:
> On Thu, 2007-10-18 at 15:23 -0400, Alan Stern wrote:
> > This patch (as1004) fixes a refcounting bug in the development version
> > of the block-device core.
> >
> > Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
> >
> > ---
> >
> > Kay, you have got to
On Thu, Oct 18, 2007 at 03:23:49PM -0400, Alan Stern wrote:
> This patch (as1004) fixes a refcounting bug in the development version
> of the block-device core.
>
> Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
>
> ---
>
> Kay, you have got to start testing your patches better! Finding and
>
On Thu, 2007-10-18 at 15:23 -0400, Alan Stern wrote:
> This patch (as1004) fixes a refcounting bug in the development version
> of the block-device core.
>
> Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
>
> ---
>
> Kay, you have got to start testing your patches better!
That leaves references
This patch (as1004) fixes a refcounting bug in the development version
of the block-device core.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
Kay, you have got to start testing your patches better! Finding and
fixing refcount errors is _not_ one of my favorite ways to pass the
time. For
This patch (as1004) fixes a refcounting bug in the development version
of the block-device core.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Kay, you have got to start testing your patches better! Finding and
fixing refcount errors is _not_ one of my favorite ways to pass the
time. For
On Thu, 2007-10-18 at 15:23 -0400, Alan Stern wrote:
This patch (as1004) fixes a refcounting bug in the development version
of the block-device core.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Kay, you have got to start testing your patches better!
That leaves references around
On Thu, Oct 18, 2007 at 03:23:49PM -0400, Alan Stern wrote:
This patch (as1004) fixes a refcounting bug in the development version
of the block-device core.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Kay, you have got to start testing your patches better! Finding and
fixing
On Thu, 18 Oct 2007, Kay Sievers wrote:
On Thu, 2007-10-18 at 15:23 -0400, Alan Stern wrote:
This patch (as1004) fixes a refcounting bug in the development version
of the block-device core.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Kay, you have got to start testing your
On Thu, 2007-10-18 at 16:08 -0400, Alan Stern wrote:
On Thu, 18 Oct 2007, Kay Sievers wrote:
On Thu, 2007-10-18 at 15:23 -0400, Alan Stern wrote:
This patch (as1004) fixes a refcounting bug in the development version
of the block-device core.
Signed-off-by: Alan Stern [EMAIL
46 matches
Mail list logo
