Re: [LTP] [PATCH 1/1] mremap06: Add mremap() reproducer for 7e7757876f25

[Petr Vorel <pvorel@suse.cz>]

> 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.

Hi Jan,

great, thanks for info.

Kind regards,
Petr


> > @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



-- 
Mailing list info: https://lists.linux.it/listinfo/ltp