[haiku-commits] Re: r35194 - in haiku/trunk/src/add-ons/kernel/file_systems/layers: . log_overlay
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 20 Jan 2010 08:23:13 +0100
On 2010-01-20 at 06:01:28 [+0100], mmlr@xxxxxxxx wrote:
> +static status_t
> +overlay_put_vnode(fs_volume *volume, fs_vnode *vnode, bool reenter)
> +{
> + DO_LOG("put_vnode reenter: %s\n", reenter ? "yes" : "no");
[...]
> +static status_t
> +overlay_remove_vnode(fs_volume *volume, fs_vnode *vnode, bool reenter)
> +{
> + DO_LOG("remove_vnode reenter: %s\n", reenter ? "yes" : "no");
Those two are a bit problematical, if you log to file. The reason lies in
the unused vnode management of the VFS. Let's say some syscall or whatever
causes BFS for the boot volume to be entered. BFS calls the VFS's
get_vnode() (e.g. for an index) and later put_vnode(). Either call
(currently only the latter) can cause unrelated unused vnodes to be freed.
If one of those belongs to the volume with the log overlay, either of these
two hooks is called. The write() will reenter BFS, potentially causing a
deadlock. I don't know our BFS implementation well enough to say whether a
deadlock can actually happen (under BeOS it could), but since file systems
are not required to deal with those situations, I wouldn't risk it anyway.
CU, Ingo
Other related posts:
