Re: [Evolution] kernel 2.5 and evolution

[Chris Toshok <toshok ximian com>]

On Tue, 2003-01-07 at 08:39, Mika Liljeberg wrote:
> > I can't speak to what 2.5.x's output is for this program, but i bet it's
> > the same.  If it's not it must be a bug in my code :P
>
> According to Joaquim, and I can confirm this, Linux 2.5 returns the
> following:
>
> sock1's peer = '/tmp/sock1'
> sock2's peer = '/tmp/sock2'
>
> I have to agree that definately looks like a bug in Linux 2.5.
> getpeername() seems to return the local address rather than the remote.

Ah yeah, looking at the code I *think* I see the problem.  Man, as a
freebsd person I never thought I'd be mucking around with linux kernel
source :)

anyway, here's the body of unix_getname (from linux 2.5.49,
net/unix/af_unix.c) with a 1 line patch:


1110         struct sock *sk = sock->sk;
1111         struct unix_sock *u = unix_sk(sk);
1112         struct sockaddr_un *sunaddr=(struct sockaddr_un *)uaddr;
1113         int err = 0;
1114
1115         if (peer) {
1116                 sk = unix_peer_get(sk);
1117
1118                 err = -ENOTCONN;
1119                 if (!sk)
1120                         goto out;
+                    u = unix_sk (sk);
1121                 err = 0;
1122         } else {
1123                 sock_hold(sk);
1124         }
1125
1126         unix_state_rlock(sk);
1127         if (!u->addr) {
1128                 sunaddr->sun_family = AF_UNIX;
1129                 sunaddr->sun_path[0] = 0;
1130                 *uaddr_len = sizeof(short);
1131         } else {
1132                 struct unix_address *addr = u->addr;
1133
1134                 *uaddr_len = addr->len;
1135                 memcpy(sunaddr, addr->name, *uaddr_len);
1136

Please excuse the weird diff syntax, i'm using LXR since I don't have a
unix kernel tree on my machine here.

> > If you comment out the bind(2) call before sock1's connect(2) call then
> > sock2's peer shows up as "", but that's because it's not being bound.
>
> Incidentally, orbit does *not* bind the client socket. This means that
> getpeername() is *supposed* to return a zero path. Thus, zeroing the
> path name is harmless. It's a valid workaround for the Linux 2.5 bug,
> and merely redundant with Linux 2.4.

Hrm, yeah.

> What I *don't* understand is why the orbit code calls getpeername() in
> the first place. Maybe they just thought that was the easiest way to get
> a valid address structure.

Yeah, that's a good question,  although it does open the code up to bugs
(obviously :)

Chris