On 3/21/2022 8:32 PM, Michal Hocko wrote: >> It can return EINTR when: >> ------------------------- >> 1) PTRACE_MODE_READ is being checked in mm_access() where it is waiting >> on task->signal->exec_update_lock. EINTR returned from here guarantees >> that process_madvise() didn't event start processing. >> https://elixir.bootlin.com/linux/v5.16.14/source/mm/madvise.c#L1264 --> >> https://elixir.bootlin.com/linux/v5.16.14/source/kernel/fork.c#L1318 >> >> 2) The process_madvise() started processing VMA's but the required >> behavior on a VMA needs mmap_write_lock_killable(), from where EINTR is >> returned. > Please note this will happen if the task has been killed. The return > value doesn't really matter because the process won't run in userspace. Okay, thanks here. > >> The current behaviours supported by process_madvise(), >> MADV_COLD, PAGEOUT, WILLNEED, just need read lock here. >> https://elixir.bootlin.com/linux/v5.16.14/source/mm/madvise.c#L1164 >> **Thus I think no way for EINTR can be returned by process_madvise() in >> the middle of processing.** . No? > Maybe not with the current implementation but I can easily imagine that > there is a requirement to break out early when there is a signal pending > (e.g. to support terminating madvise on a large memory rage). You would > get EINTR then somehow need to communicate that to the userspace. Agree. Will implement this.
