Re: rename on socket fails :-(

On Fri, Feb 18, 2011 at 05:33:58PM -0500, michael butler wrote:
> On Sat, Feb 19, 2011 at 12:11:09AM +0200, Kostik Belousov wrote:
> > On Fri, Feb 18, 2011 at 04:53:30PM -0500, michael butler wrote:
> > > Just upgraded my mail-server to -current only to be greated by:
> > > 
> > > Feb 18 16:26:00 mail authdaemond: modules="authpam", daemons=5
> > > Feb 18 16:26:00 mail authdaemond: Installing libauthpam
> > > Feb 18 16:26:00 mail authdaemond: Installation complete: authpam
> > > Feb 18 16:26:00 mail authdaemond: /var/run/authdaemond/socket: Cross-device
> > > link
> > > 
> > > Essentially, authdaemond creates /var/run/authdaemond/socket.tmp and then
> > > tries to rename it to the above. In releng7_4, this worked, on -current, it
> > > doesn't. What broke it? This is on a normal UFS2 + soft-updates file-system
> > > :-(
> > 
> > Are you sure that /var/run/authdaemond/socket.tmp is
> > renamed to /var/run/authdaemond/socket ? Can you show the
> > ktrace/kdump output ?
> 
> The relevant section of ktrace.out is:
> 
>  10905 authdaemond.bin CALL  unlink(0xbfbfeadc)
>  10905 authdaemond.bin NAMI  "/var/run/authdaemond/socket.tmp"
>  10905 authdaemond.bin RET   unlink 0
>  10905 authdaemond.bin CALL  bind(0x5,0xbfbfeada,0x6a)
>  10905 authdaemond.bin STRU  struct sockaddr { AF_LOCAL,
>  /var/run/authdaemond/socket.tmp }
>  10905 authdaemond.bin NAMI  "/var/run/authdaemond/socket.tmp"
>  10905 authdaemond.bin RET   bind 0
>  10905 authdaemond.bin CALL  listen(0x5,0x80)
>  10905 authdaemond.bin RET   listen 0
>  10905 authdaemond.bin CALL
>  chmod(0xbfbfeadc,0x1ff<S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IWGRP|S_IXGRP|S_IROTH|S_IWOTH|S_IXOTH>)
>  10905 authdaemond.bin NAMI  "/var/run/authdaemond/socket.tmp"
>  10905 authdaemond.bin RET   chmod 0
>  10905 authdaemond.bin CALL  rename(0xbfbfeadc,0x804b1c1)
>  10905 authdaemond.bin NAMI  "/var/run/authdaemond/socket.tmp"
>  10905 authdaemond.bin NAMI  "/var/run/authdaemond/socket"
>  10905 authdaemond.bin RET   rename -1 errno 18 Cross-device link
Thanks, this immediately pointed to the problem.

>  
> I also made sure that the relevant components were properly linked against
> the -current shared libs ..
This is not needed.

The patch below fixed the bug for the test extracted from your kdump.

diff --git a/sys/ufs/ufs/ufs_vnops.c b/sys/ufs/ufs/ufs_vnops.c
index 084971e..34b1758 100644
--- a/sys/ufs/ufs/ufs_vnops.c
+++ b/sys/ufs/ufs/ufs_vnops.c
_at__at_ -1295,7 +1295,9 _at__at_ relock:
 			newparent = tdp->i_number;
 		doingdirectory = 1;
 	}
-	if (fvp->v_mountedhere != NULL || (tvp && tvp->v_mountedhere != NULL)) {
+	if ((fvp->v_type == VDIR && fvp->v_mountedhere != NULL) ||
+	    (tvp != NULL && tvp->v_type == VDIR &&
+	    tvp->v_mountedhere != NULL)) {
 		error = EXDEV;
 		goto unlockout;
 	}