On Mon 06-07-20 14:52:07, Jann Horn wrote: > On Mon, Jul 6, 2020 at 2:27 PM Alexander Graf <graf@xxxxxxxxxx> wrote: > > Unless we create a vsyscall that returns both the PID as well as the > > epoch and thus handles fork *and* suspend. I need to think about this a > > bit more :). > > You can't reliably detect forking by checking the PID if it is > possible for multiple forks to be chained before the reuse check runs: > > - pid 1000 remembers its PID > - pid 1000 forks, creating child pid 1001 > - pid 1000 exits and is waited on by init > - the pid allocator wraps around > - pid 1001 forks, creating child pid 1000 > - child with pid 1000 tries to check for forking, determines that its > PID is 1000, and concludes that it is still the original process I must be really missing something here because I really fail to see why there has to be something new even invented. Sure, checking for pid is certainly a suboptimal solution because pids are terrible tokens to work with. We do have a concept of file descriptors which a much better and supports signaling. There is a clear source of the signal IIUC (migration) and there are consumers to act upon that (e.g. crypto backends). So what does really prevent to use a standard signal delivery over fd for this usecase? -- Michal Hocko SUSE Labs
