Messages in this thread | | | Date | Fri, 9 Mar 2012 15:59:01 -0800 | From | Matt Helsley <> | Subject | Re: [RFC] c/r: prctl: Add ability to set new mm_struct::exe_file v3 |
| |
On Sat, Mar 10, 2012 at 02:39:32AM +0400, Cyrill Gorcunov wrote: > On Fri, Mar 09, 2012 at 02:02:44PM -0800, Matt Helsley wrote: > ... > > > > Sorry about the other email -- hadn't full caught up on this thread. > > No problem. > > > This is even better, yes. > > > > Well, in final version I switched back to > > + if (mm->num_exe_file_vmas) > + return -EBUSY; > > simply because it's more flexible than mm->exe_file. > > With mm->exe_file this prctl option become a one-shot > only, and while at moment our user-space tool can perfectly > live with that I thought that there is no strict need to > limit the option this way from the very beginning.
As far as backward compatibility, isn't it better to lift that restriction later rather than add it? I think the latter would very likely "break" things whereas the former would not.
I also prefer that restriction because it establishes a bound on how frequently the symlink can change. Keeping it a one-shot deal makes the values that show up in tools like top more reliable for admins.
> > > Of course I'd prefer it if there was a way to keep num_exe_file_vmas > > correct and not special-case c/r. The first approximation of a solution > > It remains correct actually. There is no way to map new VM_EXECUTABLE > from user-space after we've unmapped previous ones, so num_exe_file_vmas > will remain 0. > > > might be to increment the count whenever a new mmap filp == mm->exe_file > > and decrement on unmap. I think there are a bunch of details needed to > > make that work but my feeling is it's do-able. Have you investigated this > > already and rejected it for some reason (did I miss that discussion > > somehow?)? > > As far as I understand overall num_exe_file_vmas concept -- we track > a number of VM_EXECUTABLE with it, so setting new exe_file should not > change num_exe_file_vmas I think.
True, it's literally correct. However the whole reason for having it is to turn the mm->exe_file reference into a sort of weak reference which happens to coincide with counting the number of VM_EXECUTABLE vmas until you do c/r (really just the restart side of c/r).
Cheers, -Matt
| |