On Fri, Jun 22, 2012 at 19:50:01 +0300, Alexander Motin wrote:
Hi.
I understand problem you are going to fix and I think your patch should
do it. What I don't very like is addition of new GEOM method. Now GEOM
doesn't need it because all internal open/close operations and provider
Hi.
I understand problem you are going to fix and I think your patch should
do it. What I don't very like is addition of new GEOM method. Now GEOM
doesn't need it because all internal open/close operations and provider
destructions there protected by the topology SX lock. Unluckily that
lock
On 21.06.2012 08:29, Kenneth D. Merry wrote:
Fix a bug which causes a panic in daopen(). The panic is caused by
a da(4) instance going away while GEOM is still probing it.
In this case, the GEOM disk class instance has been created by
disk_create(), and the
On Thu, Jun 21, 2012 at 19:53:03 +0400, Andrey V. Elsukov wrote:
On 21.06.2012 08:29, Kenneth D. Merry wrote:
Fix a bug which causes a panic in daopen(). The panic is caused by
a da(4) instance going away while GEOM is still probing it.
In this case, the GEOM disk class
On 21.06.2012 20:48, Kenneth D. Merry wrote:
In this case, the GEOM disk class instance has been created by
disk_create(), and the taste of the disk is queued in the GEOM
event queue.
While that event is queued, the da(4) instance goes away. When the
open call comes
On Thu, Jun 21, 2012 at 23:58:10 +0400, Andrey V. Elsukov wrote:
On 21.06.2012 20:48, Kenneth D. Merry wrote:
In this case, the GEOM disk class instance has been created by
disk_create(), and the taste of the disk is queued in the GEOM
event queue.
While that event is queued,
Hi folks,
I have attached some patches that fix an object lifetime issue between CAM
and GEOM.
Fixing the bug required adding a callback to the GEOM disk code, and adding
a callback that a GEOM class can register to get notified when a provider
is destroyed.
The probable commit message is
