Date: Thu, 10 Dec 2009 09:47:55 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: xorquewasp@googlemail.com Cc: freebsd-hackers@freebsd.org Subject: Re: UNIX domain sockets on nullfs still broken? Message-ID: <alpine.BSF.2.00.0912100947270.23303@fledge.watson.org> In-Reply-To: <alpine.BSF.2.00.0912100928200.23303@fledge.watson.org> References: <20091130142950.GA86528@logik.internal.network> <alpine.BSF.2.00.0912100928200.23303@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Dec 2009, Robert Watson wrote:
> On Mon, 30 Nov 2009, xorquewasp@googlemail.com wrote:
>
>> jackd (audio/jack) creates a directory in /tmp with a UNIX domain socket in
>> it. Clients connect to this socket to communicate with the server.
>
> We currently support the sharing of UNIX domain sockets between file system
> layers on either nullfs or unionfs. In the former case, this is a bug, and
Should read "neither ... nor".
Robert N M Watson
Computer Laboratory
University of Cambridge
> in the latter case, it is a feature.
>
> The specific nature of the bug is that you can't just copy the socket pointer
> between layers in the vnode stack without additional reference counting (and
> other similar state propagation), so if we allowed inter-layer access it
> would lead to use-after-free panics and similar sorts of problems.
>
> This occurs, BTW, because the socket pointer is directly in struct vnode, and
> not queried by a VOP, which could be forwarded by nullfs down a layer. The
> fixes here aren't easy, so I would anticipate UNIX domain sockets not working
> across nullfs layers for some time to come. It's not immediately clear to me
> which approach is the best way to fix it, since it likely requires UNIX
> domain sockets to learn about stacked file systems in some form, which will
> significantly complicate an already complicated relationship.
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
>
>>
>> $ jackd -d oss -r 44100 -p 128
>> $ ls -alF /tmp/jack-11001/default
>> total 4
>> drwx------ 2 xw wheel 512 30 Nov 14:19 ./
>> drwx------ 3 xw wheel 512 30 Nov 14:19 ../
>> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-0|
>> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-1|
>> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-2|
>> srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_0=
>> srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_ack_0=
>>
>> $ sudo mount_nullfs /tmp/ /jail/k4m/tmp
>>
>> In the jail:
>>
>> k4m$ ls -alF /tmp/jack-11001/default
>> drwx------ 2 xw wheel 512 30 Nov 14:19 ./
>> drwx------ 3 xw wheel 512 30 Nov 14:19 ../
>> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-0|
>> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-1|
>> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-2|
>> srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_0=
>> srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_ack_0=
>>
>> k4m$ ktrace jack_showtime
>> jack server not running?
>>
>> k4m$ kdump | grep '/tmp/jack-11001'
>> 76030 initial thread STRU struct sockaddr { AF_LOCAL,
>> /tmp/jack-11001/default/jack_0 }
>> 76030 initial thread NAMI "/tmp/jack-11001/default/jack_0"
>> 76030 initial thread RET connect -1 errno 61 Connection refused
>>
>> $ uname -a
>> FreeBSD viper.internal.network 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov
>> 21 15:02:08 UTC 2009
>> root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
>>
>> xw
>> _______________________________________________
>> freebsd-hackers@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>>
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0912100947270.23303>