[LTP] [PATCH 1/1] mremap06: Add mremap() reproducer for 7e7757876f25
Jan Stancek
jstancek@redhat.com
Tue Jul 4 11:15:29 CEST 2023
On Mon, Jul 3, 2023 at 10:07 PM Petr Vorel <pvorel@suse.cz> wrote:
>
> Hi,
>
> [ drop kernel developers, add Jan, Li ]
>
> > ---
> > @Cyril: I plan to add SAFE_FALLOCATE() (3 other sources),
> > SAFE_MPROTECT() (7 other sources) and SAFE_MREMAP()
> > (2 other sources), but as a separate effort.
>
> @Jan, you added in 9120d8a22 ("safe_macros: turn functions with off_t parameter
> into static inline") note "following functions are inline because the behaviour
> may depend on -D_FILE_OFFSET_BITS=64 -DOFF_T=__off64_t compile flags". IMHO the
> only source which uses SAFE_MMAP() is testcases/kernel/mem/mmapstress/mmapstress01.c
sendfile04.c potentially too, it's also compiled with 64bit offsets,
though offset is always 0
> I'm asking because I wonder if SAFE_MPROTECT() and SAFE_MREMAP() should be also
> static inline, IMHO it's not needed.
Doesn't appear to be needed here.
>
> @all: SAFE_MPROTECT() would be needed also on some still old API sources
> (testcases/kernel/syscalls/signal/signal06.c,
> testcases/kernel/syscalls/mprotect/mprotect02.c,
> testcases/kernel/syscalls/mprotect/mprotect03.c)
> Should I ignore that and add it just to new API?
>
> Kind regards,
> Petr
>
> > Kind regards,
> > Petr
>
More information about the ltp
mailing list