On Sat, Oct 31, 2020 at 9:31 AM Michael Kerrisk (man-pages) <mtk.manpages@xxxxxxxxx> wrote: > On 10/30/20 8:14 PM, Jann Horn wrote: > > With the caveat that a cancelled syscall > > could've also led to the memory being munmap()ed, so the nread==0 case > > could also happen legitimately - so you might want to move this check > > up above the nread==0 (mm went away) and nread==-1 (mm still exists, > > but read from address failed, errno EIO) checks if the error message > > shouldn't appear spuriously. > > In any case, I've been refactoring (simplifying) that code a little. > I haven't so far rearranged the order of the checks, but I already > log message for the nread==0 case. (Instead, there will eventually > be an error when the response is sent.) > > I also haven't exactly tested the scenario you describe in the > seccomp unotify scenario, but I think the above is not correct. Here > are two scenarios I did test, simply with mmap() and /proc/PID/mem > (no seccomp involved): > > Scenario 1: > A creates a mapping at address X > B opens /proc/A/mem and and lseeks on resulting FD to offset X > A terminates > B reads from FD ==> read() returns 0 (EOF) > > Scenario 2: > A creates a mapping at address X > B opens /proc/A/mem and and lseeks on resulting FD to offset X > A unmaps mapping at address X > B reads from FD ==> read() returns -1 / EIO. > > That last scenario seems to contradict what you say, since I > think you meant that in this case read() should return 0 in > that case. Have I misunderstood you? Sorry, I messed up the description when I wrote that. Yes, this looks as expected - EIO if the VMA is gone, 0 if the mm_users of the mm_struct have dropped to zero because all tasks that use the mm have exited.
