|Josef Karthauser||Feb 4, 2007 2:57 am|
|Eric Anderson||Feb 6, 2007 4:48 pm|
|Josef Karthauser||Feb 7, 2007 10:47 am|
|Jeremie Le Hen||Feb 15, 2007 2:21 pm|
|Josef Karthauser||Feb 15, 2007 3:22 pm|
|Kostik Belousov||Feb 15, 2007 3:31 pm|
|Josef Karthauser||Feb 15, 2007 4:34 pm|
|Julian Elischer||Feb 15, 2007 6:11 pm|
|Jeremie Le Hen||Feb 16, 2007 10:30 am|
|Robert Watson||Feb 16, 2007 12:54 pm|
|Kostik Belousov||Feb 16, 2007 2:36 pm|
|Josef Karthauser||Feb 18, 2007 10:41 pm|
|Robert Watson||Feb 19, 2007 2:01 pm|
|Robert Watson||Feb 19, 2007 2:08 pm|
|Robert Watson||Feb 19, 2007 2:28 pm|
|Subject:||nullfs and named pipes.|
|From:||Robert Watson (rwat...@FreeBSD.org)|
|Date:||Feb 19, 2007 2:01:06 pm|
On Sun, 18 Feb 2007, Josef Karthauser wrote:
On Fri, Feb 16, 2007 at 04:36:56PM +0200, Kostik Belousov wrote:
cvs diff: Diffing . Index: null_subr.c =================================================================== RCS file: /home/ncvs/src/sys/fs/nullfs/null_subr.c,v retrieving revision 184.108.40.206 diff -u -r220.127.116.11 null_subr.c --- null_subr.c 13 Mar 2006 03:05:17 -0000 18.104.22.168 +++ null_subr.c 14 Feb 2007 00:02:28 -0000 @@ -235,6 +235,8 @@ xp->null_vnode = vp; xp->null_lowervp = lowervp; vp->v_type = lowervp->v_type; + if (vp->v_type == VSOCK || vp->v_type == VFIFO) + vp->v_un = lowervp->v_un;
I'm wondering is some reference counting needed there ?
Yes, I find this a bit worrying also, but I don't know enough about how nullfs works to reason about it. What happens when a vnode in the bottom layer has its on-disk reference count drop to zero -- is the vnode in the top layer invalidated somehow?
Vnode reclamation from lower layer cannot do anithing for corresponding nullfs vnode, but that vnode has reference from nullfs vnode. On the other hand, can forced unmount proceed for lower layer ?
Does know of any reason why I can't commit this as it is, at least for now. It doesn't appear that it would break anything that works currently, and in its current form it at least fixes named pipe functionality for the kinds of cases that people would want to use it.
Well, the worry would be that you would be replacing a clean error on failure with an occasional panic, the normal symptom of a race condition.
I think I'm alright with the VFIFO case above, but I'm quite uncomfortable with the VSOCK case. In particular, I suspect that if the socket is closed, v_un will be reset in the lower layer, but continue to be a stale pointer in the upper layer, leading to accessing free'd or re-allocated kernel memory resulting in much badness. I've noticed tested this, but you might give it a try and see what happens.
Robert N M Watson Computer Laboratory University of Cambridge