[parisc-linux] rpc.lockd hangs (was Re: portmap deb)

[parisc-linux] rpc.lockd hangs (was Re: portmap deb)

[Richard Hirst]

On Fri, Apr 06, 2001 at 03:04:01PM -0600, Matt Taggart wrote:
> nfs-common is currently having problems with rpc.lockd, Richard is looking in 
> to it.

Ugh.  nfs-common tries to invoke nfsservctl() and quotactl() via calls
to syscall() in glibc, such as:

    return syscall(SYS_quotactl, cmd, special, id, addr);

For most architectures, glibc as an asm implementation of syscall(),
and our would be in

glibc/sysdeps/unix/sysv/linux/hppa/syscall.S

except that it is just a cpu loop at the moment - hence rpc.lockd
hangs eating cpu.

I guess a one time glibc didn't provide nfsservctl() and quotactl()
wrappers, so syscall() was used.

Options (somone who knows the area better than me can correct
these):

a) Implement syscall() in glibc - I made an initial stab at that,
included below, but I didn't get as far as building it.  Not sure
if my approach was valid for hppa, with some args on stack, etc.

b) change nfs-common to use the proper glibc wrappers for these
functions, rather than syscall().

c) change nfs-common to use INLINE_SYSCALL or something..


I tried a quick hack at (b) and rebuilt.  I didn't get as far as trying
the new binaries yet, because I was doing this on a 64 bit machine, and...
both nfsservctl and quotactl are unimplemented on 64 bit :(

So, we need to implement wrappers for those, and fix either glibc or
nfs-common.

Richard


==================== quick'n'dirty patch to nfs-common =====================

diff -ur nfs-utils.ori/support/nfs/nfsctl.c nfs-utils/support/nfs/nfsctl.c
--- nfs-utils.ori/support/nfs/nfsctl.c	Mon Oct 18 17:21:12 1999
+++ nfs-utils/support/nfs/nfsctl.c	Fri Apr  6 16:02:28 2001
@@ -20,5 +20,9 @@
 int
 nfsctl (int cmd, struct nfsctl_arg * argp, union nfsctl_res * resp)
 {
+#ifdef __hppa__
+  return nfsservctl(cmd, argp, resp);
+#else
   return syscall (__NR_nfsctl, cmd, argp, resp);
+#endif
 }
diff -ur nfs-utils.ori/utils/rquotad/quotactl.c nfs-utils/utils/rquotad/quotactl.c
--- nfs-utils.ori/utils/rquotad/quotactl.c	Mon Oct 18 17:21:12 1999
+++ nfs-utils/utils/rquotad/quotactl.c	Fri Apr  6 15:58:19 2001
@@ -24,7 +24,9 @@
 #include <unistd.h>
 #include <sys/syscall.h>
 
+#ifndef __hppa__
 int quotactl(int cmd, const char * special, int id, caddr_t addr)
 {
 	return syscall(SYS_quotactl, cmd, special, id, addr);
 }
+#endif

============================================================================


===================== initial attempt at syscall for glibc =================

ENTRY(syscall)
        copy %r26,%r20
        copy %r25,%r26
        copy %r24,%r25
        copy %r23,%r24
        ldw -52(%r30),%r23
#if 0
        /* Hmm, can we be sure there is space for two args on the stack,
         * when the syscall() was called with fewer args?  How many args
	 * must we allow for?
         */
        ldw -56(%r30),%r22
        stw %r22,-52(%r30)
#endif
        ble  0x100(%sr2,%r0)
        nop
        ldi -0x1000,%r1
        cmpb,>>=,n %r1,%ret0,0f
        stw %rp, -20(%sr0,%r30)
        stw %ret0, -24(%sr0,%r30)
        .import __errno_location,code
        bl __errno_location,%rp
        ldo 64(%r30), %r30
        ldo -64(%r30), %r30
        ldw -24(%r30), %r26
        sub %r0, %r26, %r26
        stw %r26, 0(%sr0,%ret0)
        ldo -1(%r0), %ret0
        ldw -20(%r30), %rp
0:
	ret,n

============================================================================

Re: [parisc-linux] rpc.lockd hangs (was Re: portmap deb)

[Matthew Wilcox]

On Sat, Apr 07, 2001 at 12:15:00AM +0100, Richard Hirst wrote:
> Options (somone who knows the area better than me can correct
> these):
> 
> a) Implement syscall() in glibc - I made an initial stab at that,
> included below, but I didn't get as far as building it.  Not sure
> if my approach was valid for hppa, with some args on stack, etc.
> 
> b) change nfs-common to use the proper glibc wrappers for these
> functions, rather than syscall().
> 
> c) change nfs-common to use INLINE_SYSCALL or something..

Actually I prefer (d) [hands up everyone who's surprised?  :-)]  I
don't see why we should implement syscall in assembler.  After all, that
would be the third implementation :-)  Why not have something along the
lines of:

int syscall(int nr, int arg1, int arg, int arg3, int arg4, int arg5, int arg6)
{
	return INLINE_SYSCALL(nr, arg1, arg2, arg3, arg4, arg5, arg6);
}

I don't have a copy of glibc to hand, so i'm not quite sure on the syntax
of INLINE_SYSCALL.

> I tried a quick hack at (b) and rebuilt.  I didn't get as far as trying
> the new binaries yet, because I was doing this on a 64 bit machine, and...
> both nfsservctl and quotactl are unimplemented on 64 bit :(

Ooops.  Clearly, that needs to get fixed.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] rpc.lockd hangs (was Re: portmap deb)

[Richard Hirst]

On Sun, Apr 08, 2001 at 08:20:46PM +0100, Matthew Wilcox wrote:
> Actually I prefer (d) [hands up everyone who's surprised?  :-)]  I

Not me ;)

> don't see why we should implement syscall in assembler.  After all, that
> would be the third implementation :-)  Why not have something along the
> lines of:
> 
> int syscall(int nr, int arg1, int arg, int arg3, int arg4, int arg5, int arg6)
> {
> 	return INLINE_SYSCALL(nr, arg1, arg2, arg3, arg4, arg5, arg6);
> }
> 
> I don't have a copy of glibc to hand, so i'm not quite sure on the syntax
> of INLINE_SYSCALL.

This is nfs-utils code atm:


/* compatibility hack... */
#ifndef __NR_nfsctl
#define __NR_nfsctl     __NR_nfsservctl
#endif

int
nfsctl (int cmd, struct nfsctl_arg * argp, union nfsctl_res * resp)
{
  return syscall (__NR_nfsctl, cmd, argp, resp);
}


INLINE_SYSCALL wants a name, and an arg count, not a syscall number, eg:

  INLINE_SYSCALL(nfsservctl, 3, cmd, argp, resp);

so passing a syscall number in to syscall() doesn't work, and also
syscall() won't know how many arguments there are to pass on to
INLINE_SYSCALL.  Maybe we could just use '6' to get round that.

Maybe we duplicate INLINE_SYSCALL in sysdeps/unix/sysv/linux/hppa/sysdep.h,
call the new one INLINE_SYSCALL_NR, and replace 'SYS_ify(name)' with 'name'.
Then have

int syscall(int nr, int arg1, int arg, int arg3, int arg4, int arg5, int arg6)
{
      return INLINE_SYSCALL_NR(nr, arg1, arg2, arg3, arg4, arg5, arg6);
}

so long as there is no prototype of that visible to clash with use
in nfs-utils..

Richard

Re: [parisc-linux] rpc.lockd hangs (was Re: portmap deb)

[Matthew Wilcox]

On Mon, Apr 09, 2001 at 10:56:06AM +0100, Richard Hirst wrote:
> INLINE_SYSCALL wants a name, and an arg count, not a syscall number, eg:
> 
>   INLINE_SYSCALL(nfsservctl, 3, cmd, argp, resp);
> 
> so passing a syscall number in to syscall() doesn't work, and also
> syscall() won't know how many arguments there are to pass on to
> INLINE_SYSCALL.  Maybe we could just use '6' to get round that.

Yep, that's my thinking.

> Maybe we duplicate INLINE_SYSCALL in sysdeps/unix/sysv/linux/hppa/sysdep.h,
> call the new one INLINE_SYSCALL_NR, and replace 'SYS_ify(name)' with 'name'.
> Then have
> 
> int syscall(int nr, int arg1, int arg, int arg3, int arg4, int arg5, int arg6)
> {
>       return INLINE_SYSCALL_NR(nr, arg1, arg2, arg3, arg4, arg5, arg6);
> }

umm..

#define INLINE_SYSCALL(name, args...) INLINE_SYSCALL_NR(SYS_ify(name), args)

Otherwise, agreed.  This seems like a more robust approach than doing it
in assembler directly, and I don't believe it will be significantly less
efficient.  syscall() is clearly only used in exceptional cases anyway.

Since these packages have clearly never worked up till now, this seems
like an opportune point to change the sizes of these structures if that's
needed in order to get these syscalls implemented efficiently on 32 &
64 bit.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] rpc.lockd hangs (was Re: portmap deb)

[Richard Hirst]

On Mon, Apr 09, 2001 at 03:21:25PM +0100, Matthew Wilcox wrote:
> On Mon, Apr 09, 2001 at 10:56:06AM +0100, Richard Hirst wrote:
> > INLINE_SYSCALL wants a name, and an arg count, not a syscall number, eg:
> > 
> >   INLINE_SYSCALL(nfsservctl, 3, cmd, argp, resp);
> > 
> > so passing a syscall number in to syscall() doesn't work, and also
> > syscall() won't know how many arguments there are to pass on to
> > INLINE_SYSCALL.  Maybe we could just use '6' to get round that.
> 
> Yep, that's my thinking.
> 
> > Maybe we duplicate INLINE_SYSCALL in sysdeps/unix/sysv/linux/hppa/sysdep.h,
> > call the new one INLINE_SYSCALL_NR, and replace 'SYS_ify(name)' with 'name'.
> > Then have
> > 
> > int syscall(int nr, int arg1, int arg, int arg3, int arg4, int arg5, int arg6)
> > {
> >       return INLINE_SYSCALL_NR(nr, arg1, arg2, arg3, arg4, arg5, arg6);

That would need a '6' as well:

	return INLINE_SYSCALL_NR(nr, 6, arg1, arg2, arg3, arg4, arg5, arg6)

> umm..
> 
> #define INLINE_SYSCALL(name, args...) INLINE_SYSCALL_NR(SYS_ify(name), args)

No, doesn't work, because INLINE_SYSCALL() does

                asm volatile(                                   \
                        "ble  0x100(%%sr2, %%r0)\n\t"   \
                        " ldi %1, %%r20"                        \
                        : "=r" (__res)                          \
                        : "i" (SYS_ify(name)) ASM_ARGS_##nr     \
                         );                                     \

while INLINE_SYSCALL_NR needs

                asm volatile(                                   \
                        "ble  0x100(%%sr2, %%r0)\n\t"   \
                        " copy %1, %%r20"                       \
                        : "=r" (__res)                          \
                        : "r" (sysnum) ASM_ARGS_##nr            \
                         );                                     \

note the ldi --> copy and "i" --> "r".

I think we need to duplicate INLINE_SYSCALL rather than define one in terms
of the other.

The next question then is where to put the 'C' version of syscall().  Other
archs have a syscall.S (as do we, but ours will now be empty).  For now I've
put in it sysdep.c, that lives in the same dir as syscall.S and sysdep.h,
where INLINE_SYSCALL is defined.  Is that acceptable do you think?
Or do I have to replace syscall.S with syscall.c (which will mean
understanding the build process rather better than I currently do)?

> Otherwise, agreed.  This seems like a more robust approach than doing it
> in assembler directly, and I don't believe it will be significantly less
> efficient.  syscall() is clearly only used in exceptional cases anyway.

OK, although other ports have syscall as asm in syscall.S.

> Since these packages have clearly never worked up till now, this seems
> like an opportune point to change the sizes of these structures if that's
> needed in order to get these syscalls implemented efficiently on 32 &
> 64 bit.

Good point.

Richard

Re: [parisc-linux] rpc.lockd hangs (was Re: portmap deb)

[Ulrich Drepper]

Richard Hirst <rhirst@linuxcare.com> writes:

> No, doesn't work, because INLINE_SYSCALL() does
> 
>                 asm volatile(                                   \
>                         "ble  0x100(%%sr2, %%r0)\n\t"   \
>                         " ldi %1, %%r20"                        \
>                         : "=r" (__res)                          \
>                         : "i" (SYS_ify(name)) ASM_ARGS_##nr     \
>                          );                                     \
> 
> while INLINE_SYSCALL_NR needs
> 
>                 asm volatile(                                   \
>                         "ble  0x100(%%sr2, %%r0)\n\t"   \
>                         " copy %1, %%r20"                       \
>                         : "=r" (__res)                          \
>                         : "r" (sysnum) ASM_ARGS_##nr            \
>                          );                                     \

Why should you need two macros?  The second one is not used on any
other architecture and therefore no non-machine specific code uses it.
Get rid of it.  If you only use it to implement syscall() do it right
and don't hide it in a macro.  Even though we have many macros this
does not mean this is the way code should always be written.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: [parisc-linux] rpc.lockd hangs (was Re: portmap deb)

[Matthew Wilcox]

On Tue, Apr 10, 2001 at 09:58:57AM -0700, Ulrich Drepper wrote:
> Why should you need two macros?

I think you're missing the context here, Ulrich.  I'd prefer not to have
multiple implementations of syscall.  This discussion was about how to
have only _one_ implementation in glibc, not two.  I'm not sure we have
a solution to that yet.

-- 
Revolutions do not require corporate support.