Re: SHMFS_SUPER_MAGIC discrepancy, Linux 2.4.2, glibc 2.2.2

[Andreas Jaeger]

Jean-Francois Panisset <address@hidden> writes:

> I've been running into problems trying to get shm_open() to return
> something else than ENOSYS running glibc 2.2.2 and Linux 2.4.2.
> In sysdeps/unix/sysv/linux/shm_open.c, I find:
> 
> /* Determine where the shmfs is mounted (if at all).  */
> static void
> where_is_shmfs (void)
> {
>   char buf[512];
>   struct statfs f;
>   struct mntent resmem;
>   struct mntent *mp;
>   FILE *fp;
> 
>   /* The canonical place is /dev/shm.  This is at least what the
>      documentation tells everybody to do.  */
>   if (__statfs (defaultdir, &f) == 0 && f.f_type == SHMFS_SUPER_MAGIC)
>     {
>       /* It is in the normal place.  */
>       mountpoint.dir = (char *) defaultdir;
>       mountpoint.dirlen = sizeof (defaultdir) - 1;
> 
>       return;
>     }
> 
> 
> and in sysdeps/unix/sysv/linux/linux_fsinfo.h, I find:
> 
> /* Constant that identifies the `shm' filesystem.  */
> #define SHMFS_SUPER_MAGIC       0x02011994
> 
> Unfortunately, in the Linux 2.4.2 source tree, in mm/shmem.c, I find:
> 
> #define SHMEM_MAGIC     0x01021994
> 
> which is close, but not quite what I want. Tracing through a call
> to shm_open(), it does seem that the kernel is returning 0x01021994
> as the fs type for the shmfs filesystem, causing shm_open() to fail
> and return ENOSYS.
> 
> So it seems that in the short term, linux_fsinfo.h should be updated.

glibc has been fixed already, this will be in the next release.

> In the long term, there should be a way to have a single place where
> these magic numbers are defined so that they don't get out of sync.

Discuss this with the kernel folks, so far there's no way for glibc to
get those values.

> Of course, I could be completely mistaken on this.

You aren't.

Thanks,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs address@hidden
   private address@hidden
    http://www.suse.de/~aj