[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