This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug ports/15054] New: MIPS/Linux syscall restart convention not respected by INTERNAL_SYSCALL_NCS


http://sourceware.org/bugzilla/show_bug.cgi?id=15054

             Bug #: 15054
           Summary: MIPS/Linux syscall restart convention not respected by
                    INTERNAL_SYSCALL_NCS
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ports
        AssignedTo: unassigned@sourceware.org
        ReportedBy: macro@linux-mips.org
                CC: carlos@systemhalted.org, roland@gnu.org
    Classification: Unclassified


We have an issue with the INTERNAL_SYSCALL_NCS wrapper in that it does not
respect the kernel's syscall restart convention.

That convention requires the instruction immediately preceding SYSCALL to
initialize $v0 with the syscall number.  Then if a restart triggers, $v0
will have been clobbered by the syscall interrupted, and needs to be
reinititalized.  The kernel will decrement the PC by 4 before switching
back to the user mode so that $v0 has been reloaded before SYSCALL is
executed again.  This implies the place $v0 is loaded from must be
preserved across a syscall, e.g. an immediate, static register, stack slot,
etc.

We use two wrapper macros to dispatch syscalls to the relevant pieces of
code: INTERNAL_SYSCALL and INTERNAL_SYSCALL_NCS.  They both ultimately
cause a piece of inline assembly to be emitted.  In the former case the
piece starts with an LI instruction that loads $v0 with an immediate number
of the syscall required.  A SYSCALL instruction then immediately follows.
In the latter case $v0 is arranged to have been preloaded and the piece
starts with a SYSCALL instruction.

That works if the syscall is executed the first time, because the compiler
will have arranged for $v0 to contain the correct value.  It does not in
the case of a syscall restart as the compiler-generated instruction
immediately preceding SYSCALL may not necessarily be one to load $v0 with
the value required.

The failure mode is unlikely to trigger as the INTERNAL_SYSCALL_NCS wrapper
is only used in a couple of places and then the offending syscall would
have to be restarted as well.  The symptom would usually be an intermittent
program failure and would be hard to debug.  The issue was noticed by code
inspection while making changes in this area.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]