shmat apparently broken on n32 MIPS.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

shmat apparently broken on n32 MIPS.

Kaz Kylheku-3
I'm porting an application to MIPS using kernel 2.6.17.7 (64 bit) and an
n32 user space based on glibc and glibc-ports 2.5 (straight from the
tarballs, with minor patching).

The shmat() function is behaving strangely. In the kernel, do_shmat() is
working fine. It returns 0, and sets *raddr to a valid value from
do_mmap. The value is in the 32 bit address range, respecting the task
size of the caller.

But in user space, it's a different story. The libc function fails: the
pointer compares equal to (void *) -1. The value of errno is observed as
14/EFAULT.
Reply | Threaded
Open this post in threaded view
|

Re: shmat apparently broken on n32 MIPS.

Mike Frysinger
On Friday 01 December 2006 14:36, Kaz Kylheku wrote:
> The shmat() function is behaving strangely.

if you posted a small C test case that exhibits the behavior you're
describing, it'd make everything a lot easier
-mike

attachment0 (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: shmat apparently broken on n32 MIPS.

Kyle McMartin-4
In reply to this post by Kaz Kylheku-3
On Fri, Dec 01, 2006 at 11:36:59AM -0800, Kaz Kylheku wrote:
> The shmat() function is behaving strangely. In the kernel, do_shmat() is
> working fine. It returns 0, and sets *raddr to a valid value from
> do_mmap. The value is in the 32 bit address range, respecting the task
> size of the caller.
>

mips doesn't appear to be using the generic compat_sys_shmat wrapper.

I'd look at the differences between this and another architecture
inside the kernel. Which ABI are you using? 64-o32 seems to use
the ipc demuxer, while 64-n32 seems to use a custom coded shmat.

Probably a good starting place for where to find what's going wrong.

Cheers,
        Kyle
Reply | Threaded
Open this post in threaded view
|

Re: shmat apparently broken on n32 MIPS.

Atsushi Nemoto
On Sat, 2 Dec 2006 22:57:35 -0500, Kyle McMartin <[hidden email]> wrote:
> mips doesn't appear to be using the generic compat_sys_shmat wrapper.
>
> I'd look at the differences between this and another architecture
> inside the kernel. Which ABI are you using? 64-o32 seems to use
> the ipc demuxer, while 64-n32 seems to use a custom coded shmat.
>
> Probably a good starting place for where to find what's going wrong.

I think this problem was fixed on the linux-mips.org kernel a month
ago.  Please refer recent posts in linux-mips ML archive.

---
Atsushi Nemoto
Reply | Threaded
Open this post in threaded view
|

RE: shmat apparently broken on n32 MIPS.

Kaz Kylheku-3
In reply to this post by Kaz Kylheku-3
Mike Frysinger wrote:
> On Friday 01 December 2006 14:36, Kaz Kylheku wrote:
> > The shmat() function is behaving strangely.
>
> if you posted a small C test case that exhibits the behavior you're
> describing, it'd make everything a lot easier
> -mike

It's a kernel problem that, it turns out, has already been fixed in the
linux-mips kernel stream.

The small C test case is: call shmat(<valid-shmid>, 0, 0) and watch it
fail.

The reason for the behavior is that, mistakenly, an incorrectly written
function called sys32_shmat was developed for MIPS and patched into the
n32 syscall table, when in fact the regular sys_shmat is quite
appropriate.

The reason for the EFAULT is that this sys32_shmat thinks that it's
getting an extra parameter from user space: a pointer to a 32 bit
address where to store the result. When it tries the put_user, there is
a null pointer dereference.
Since shmat doesn't in fact have a poiner-to-pointer parameter, there is
no need to have a sys32_ compatibility version of it at all.