On Thu, Oct 7, 2021 at 3:15 AM Pavel Machek <pavel@xxxxxx> wrote: > > Hi! > > > >> Hmm, so the suggestion is to have some directory which contains files > > >> representing IDs, each containing the string name of the associated > > >> vma? Then let's say we are creating a new VMA and want to name it. We > > >> would have to scan that directory, check all files and see if any of > > >> them contain the name we want to reuse the same ID. > > > > > > I believe Pavel meant something as simple as > > > $ YOUR_FILE=$YOUR_IDS_DIR/my_string_name > > > $ touch $YOUR_FILE > > > $ stat -c %i $YOUR_FILE Ah, ok, now I understand the proposal. Thanks for the clarification! So, this would use filesystem as a directory for inode->name mappings. One rough edge for me is that the consumer would still need to parse /proc/$pid/maps and convert [anon:inode] into [anon:name] instead of just dumping the content for the user. Would it be acceptable if we require the ID provided by prctl() to always be a valid inode and show_map_vma() would do the inode-to-filename conversion when generating maps/smaps files? I know that inode->dentry is not one-to-one mapping but we can simply output the first dentry name. WDYT? > > > > So in terms of syscall overhead, that would be open(..., O_CREAT | > > O_CLOEXEC), fstat(), close() - or one could optimistically start by > > You could get to two if you used mkdir instead of open. > > > > YOUR_IDS_DIR can live on a tmpfs and you can even implement a policy on > > > top of that (who can generate new ids, gurantee uniqness etc...). > > > > > > The above is certainly not for free of course but if you really need a > > > system wide consistency when using names then you need some sort of > > > central authority. How you implement that is not all that important > > > but I do not think we want to handle that in the kernel. Ideally it would be great if $YOUR_IDS_DIR/my_string_name entries could be generated by the kernel in response to userspace calling prctl(..., name) but I haven't looked into complexity of doing that, so I would not propose that at this point. Thanks for sharing the ideas! Suren. > > > > IDK. If the whole thing could be put behind a CONFIG_ knob, with _zero_ > > overhead when not enabled (and I'm a bit worried about all the functions > > that grow an extra argument that gets passed around), I don't mind the > > string interface. But I don't really have a say either way. > > If this is ever useful outside of Android, eventually distros will > have it enabled. > > Best regards, > Pavel > -- > http://www.livejournal.com/~pavelmachek
