Re: cdevsw close never called
Re: cdevsw close never called
- Subject: Re: cdevsw close never called
- From: mm w <email@hidden>
- Date: Fri, 6 Mar 2009 12:18:01 -0800
Hello Andrew,
a simple question,
A has opened /dev/file000
B for obscur reason wants to access /dev/file000 (could create an alias)
tuple processes
if (proc (A...B C...) hold /dev/file000 || /dev/file000 on job)
return copy refA;
else
... open stuff
I think it's at your design level that you have to deal with that
you have to create your own stack to know what's going on, but maybe
there is a prebuilt
stuff to handle it I don't know, but I almost sure not
Cheers!
On Fri, Mar 6, 2009 at 11:36 AM, Andrew Gallatin <email@hidden> wrote:
> I have a character driver which enforces a single
> open per device node. It will fail to open (return
> EBUSY) if the device node is already open. I've recently
> started seeing cases where my driver's close is not called. I
> suspect this is due to the "last close" semantics of
> character device nodes in Darwin.
>
> What is happening is that process B is trying to
> open /dev/foo0, while process A already has it open,
> and tries to close it. Process B's open fails (EBUSY).
> Meanwhile, process A races through spec_close() and our
> cdevsw() entry point is not called, because B is also
> holding a reference on the vnode. B then returns to
> userspace without a reference to the vnode because the
> cdevsw open() failed. So now my driver's cdevsw close()
> never gets called, and I'm left with an orphaned port,
> which is stuck in the open state, even though nobody
> has it open.
>
> My question is: Is there anything I can do to either close
> the race and get my cdevsw close() routine called to
> avoid this bug? Using a thread funnel hack like the
> IOSerialFamily does seems to narrow the race,
> but does not close it. As far as I can tell, there is
> nothing I can do to close the race because I'm on the
> wrong side of the action.
>
> The best I've been able to achieve so far is to
> periodically reap state which look dead. But that
> is just gross.
>
> Thanks,
> Drew
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-kernel mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
--
-mmw
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden