vnode_put(...): iocount < 1 revisited
vnode_put(...): iocount < 1 revisited
- Subject: vnode_put(...): iocount < 1 revisited
- From: mogambo <email@hidden>
- Date: Mon, 25 Jul 2011 18:33:11 -0700
Hi,
I have a question about the protocol for dropping iocount on the vnode in the following scenario with my file system driver. On one client, an application opens a file on the network file system through the driver, does some i/o and closes it. The file is deleted from other client. On the first client, the application tries to open the file again, but hangs forever. Tracing what the application is doing with the driver shows that the application is stuck in lookup()/getattr() loop. I saw that lookup was succeding, but getattr was failing with ENOENT; that seemed to confuse the application.
I discovered that the vn_lookup() in my driver was essentially a cache_lookup() and returning success since the file was still in the name cache. The getattr() call was doing a stat to the network file system and since the file was deleted already, it was returning ENOENT. My fix was to purge name cache when stat fails and call vnode_put() so that the vnode can be reclaimed. However, I hit the "iocount <= 1" panic. The panic went away when I removed vnode_put(), however, I do not understand where the last iocount is dropped in this scenario. I tried looking in the kernel code, but I was not able to figure this out.
Any help? I'd appreciate if you can point out the piece of code that deals with this as well, so that I can go check it out more.
Thanks,
-m.
_______________________________________________
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