[LTP] [PATCH 3/6] syscalls/madvise03: Convert to new test API

Li Wang liwang@redhat.com
Thu May 19 12:12:42 CEST 2016


Hi Cyril,

On Tue, May 17, 2016 at 06:20:55PM +0200, Cyril Hrubis wrote:
> > +	/* (1) Test case for MADV_REMOVE */
> > +	TEST(madvise(addr1, 4096, MADV_REMOVE));
> > +	check_and_print("MADV_REMOVE");
> 
> You don't need the shm memory for MADV_REMOVE, just mapping mapped
> PROT_WRITE as well.

There are different ways to support this on different kernels. If
just mapping mmapped as 'RW' shared memory, it will not work on
kernel < 3.5. It seems like we have to keep the orignal method which
based on shmfs.

>From Linux Programmer's Manual:
"MADV_REMOVE (since Linux 2.6.16)
       Free up a given range of pages and its associated backing
       store.  This is equivalent to punching a hole in the
       corresponding byte range of the backing store (see
       fallocate(2)).  Subsequent accesses in the specified address
       range will see bytes containing zero.

       The specified address range must be mapped shared and
       writable.  This flag cannot be applied to locked pages, Huge
       TLB pages, or VM_PFNMAP pages.

       In the initial implementation, only shmfs/tmpfs supported
       MADV_REMOVE; but since Linux 3.5, any filesystem which
       supports the fallocate(2) FALLOC_FL_PUNCH_HOLE mode also
       supports MADV_REMOVE.  Hugetlbfs will fail with the error
       EINVAL and other filesystems fail with the error EOPNOTSUPP."

A simple way is to create the mmaped file under '/dev/shm/' in setup()
	sprintf(filename, "/dev/shm/madvise01.%d", getpid());
and remove it in cleanup(). Or using tmpfs.

What do you think?


Regards,
Li Wang

> 
> 
> -- 
> Cyril Hrubis
> chrubis@suse.cz


More information about the ltp mailing list