Subject: explain to me how this works...

From: Greg Lindahl <[email-masked]>
Date: Wed, 13 Nov 2002 17:42:00 -0800

I have a 64-bit kernel and O32 userland.

I notice that arping gets confused because the syscall socket() is
returning 4183 instead of a reasonable value like 3... if strace()
isn't lying to me.

How do I debug this? The O32 userland calls through the socketcall()
syscall. It looks OK.

greg

---

From: [email-masked]
Date: Wed, 13 Nov 2002 20:15:38 -0800

see arch/mips64/kernel/linux32.c

---

From: Greg Lindahl <[email-masked]>
Date: Thu, 14 Nov 2002 08:10:43 -0800

I saw that a long time ago. sys_socket and sys_socketcall seem
to be written just like all the other syscalls that return an int.

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 14 Nov 2002 19:39:24 +0100

> How do I debug this? The O32 userland calls through the socketcall()

Eh?  Nothing on MIPS should use socketcall(2); we have all the calls like
socket(2), bind(2), connect(2) etc. directly in our syscall table unlike
x86 which uses this pointless wrapper for historical reasons.  We only
have socketcall(2) in the o32 syscall interface but it's a candidate for
removal as nothing we still do support and that's glibc 2.0 and higher
binaries uses it.

  Ralf

---

From: Greg Lindahl <[email-masked]>
Date: Thu, 14 Nov 2002 11:30:45 -0800

On Thu, Nov 14, 2002 at 07:39:24PM +0100, Ralf Baechle wrote:

> Eh?  Nothing on MIPS should use socketcall(2);

OK, so let's say it's using socket(). How do I go about debugging
this? I mean, I can start sprinkling printks all over the place, but is
there a more clever way?

greg

---

From: Jun Sun <[email-masked]>
Date: Thu, 14 Nov 2002 12:07:46 -0800

Look like a good case for using kgdb....

Jun

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 14 Nov 2002 21:12:51 +0100

> Look like a good case for using kgdb....

Unlikely to help him.  The return value 4183 of socket that he's observing
is the syscall number of socket(2).  That's making scall_o32.S the first
suspect to look at.

Greg, could this be a case of syscall restarting that you're observing?

  Ralf

---

From: Greg Lindahl <[email-masked]>
Date: Thu, 14 Nov 2002 13:12:32 -0800

On Thu, Nov 14, 2002 at 09:12:51PM +0100, Ralf Baechle wrote:

> is the syscall number of socket(2).

Thank you, I should have noticed that one right off.

My sprinkle of printks already tells me that strace is a liar - no
surprise there.

strace says:

socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
socket(PF_PACKET, SOCK_DGRAM, 0)        = 4183
socket(PF_PACKET, SOCK_DGRAM, 0)        = -1 EAFNOSUPPORT (Address family not supported by protocol)

printk says:

sys_socket returning 0
sys32_socket returning 0
sys_socket returning -124
sys32_socket returning -124

Note strace sees 3 syscalls. I only printk at the return statement, 
and there are 2 of those. I'll add more printks...

-- greg

---

From: Greg Lindahl <[email-masked]>
Date: Thu, 14 Nov 2002 13:50:51 -0800

> socket(PF_PACKET, SOCK_DGRAM, 0)        = -1 EAFNOSUPPORT (Address family not supported by protocol)

strace is useless.

My problem was that CONFIG_PACKET was not set in my .config, which causes
EAFNOSUPPORT.

-- greg

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 14 Nov 2002 23:27:48 +0100

> and there are 2 of those. I'll add more printks...

This smells alot like syscall restarting.  The first two times the
syscall fails with one of ERESTARTNOHAND, ERESTARTSYS or ERESTARTNOINTR,
then the third time is fails with EAFNOSUPPORT.

Enable CONFIG_PACKET and CONFIG_NETLINK_DEV.

The only bug here is strace being to stupid to filter out syscall restarts.

  Ralf