shmem_file_setup creating SYSV00000000 files in (ext3) root filesystem

shmem_file_setup creating SYSV00000000 files in (ext3) root filesystem

[desrt]

kernel version is 2.4.23.

the problem is caused by the fact that the checks that shmem_file_setup
does to determine the location of the mountpoint of tmpfs fail to take
into account the effect of pivot_root.

that is: if i mount a tmpfs as /, then mount a ext3 filesystem and
pivot_root into it with put_old as, say, /var/tmp, then shmem_file_setup
will still think that the tmpfs is mounted at / (and as a result creates
shared memory files on the root filesystem instead of on /var/tmp as it
ought to)

i'm not actually sure what the code in mm/shmem.c:shmem_file_setup()
does, but i assume the problem is this line:
	        root = shm_mnt->mnt_root;

and somehow as a result, this happens:
peloton:/proc# grep deleted */maps
17923/maps:4201a000-4207a000 rw-s 00000000 00:04 21233690  
/SYSV00000000 (deleted)
17923/maps:424dd000-4253d000 rw-s 00000000 00:04 21266460  
/SYSV00000000 (deleted)
17926/maps:4201a000-4207a000 rw-s 00000000 00:04 21233690  
/SYSV00000000 (deleted)
17926/maps:424dd000-4253d000 rw-s 00000000 00:04 21266460  
/SYSV00000000 (deleted)
17927/maps:4201a000-4207a000 rw-s 00000000 00:04 21233690  
/SYSV00000000 (deleted)
[many many many lines follow]

if you have any advice or can confirm to me that this is actually a bug
in the kernel, please reply.  i'm not on the list.

thanks,
ryan.

Re: shmem_file_setup creating SYSV00000000 files in (ext3) root filesystem

[Christoph Rohland]

Hi Ryan,

On Fri, 05 Dec 2003, desrt@desrt.ca wrote:
> the problem is caused by the fact that the checks that
> shmem_file_setup does to determine the location of the mountpoint of
> tmpfs fail to take into account the effect of pivot_root.

No, see below.

> and somehow as a result, this happens:
> peloton:/proc# grep deleted */maps
> 17923/maps:4201a000-4207a000 rw-s 00000000 00:04 21233690  
> /SYSV00000000 (deleted)
> [many many many lines follow]
> 
> if you have any advice or can confirm to me that this is actually a
> bug in the kernel, please reply.  i'm not on the list.

It's not a bug. It is simply a display issue designed in this
way. These names are artificial names which were never linked to a real
directory entry. So they end up displayed in this way. But they are
not connected to your root filesystem.

Greetings
		Christoph