On Thu, Jan 23, 2025 at 3:40 AM Vlastimil Babka <vbabka@xxxxxxx> wrote: > > On 1/22/25 23:29, enh wrote: > > On Wed, Jan 22, 2025 at 12:24 PM Liam R. Howlett > > <Liam.Howlett@xxxxxxxxxx> wrote: > >> > >> > >> We are making changes in this area. Can you elaborate on the 'awkward' > >> part? The locking or the tearing of data? > >> > >> The way you state the page, it makes me think it's the tearing that is > >> the issue? I think the ioctl would be worse for the possible tearing of > >> data. > > > > there are two main styles of use of the /proc/<pid>/maps data i've > > seen in userspace: > > > > 1. i need to know about _all_ the vmas, so i'm reading the whole file > > and stitching it together. > > 2. i need to know about the vma containing a specific address, so i'm > > reading line-by-line looking for a match. > > > > the former is typically just for humans anyway (to be added to a crash > > report) -- so the ability to sendfile() or whatever would be something > > we could use there (though i've no idea whether that actually solves > > the tearing issue) -- so those use cases mostly tend to ignore (or not > > notice) the problem. > > > > for the latter, tearing is a bigger problem because what does "not > > found" mean? do we try again? how many times do we try? so i think the > > ioctl() would solve those problems. plus it would be a lot cheaper, > > and in particular not require [or at least "strongly benefit from"] > > dynamic memory allocation like parsing a text file does. > > IIUC tearing can only happen in place of parallel changes (mmap/munmap etc) > by another thread, but if it does not affect the VMA in question it > shouldn't lead to skipping it. If it does affect it, the query would be > inherently racy anyway. yeah, at this point i should (a) drag in +cferris who may have actual experience of this and (b) admit that iirc i've never personally seen _evidence_ of this, just claims. most famously in the chrome source... if you `grep -r /proc/.*/maps` you'll find lots of examples, but something like https://chromium.googlesource.com/chromium/src/+/main/base/debug/proc_maps_linux.h#61 is quite representative of the "folklore" in this area. > One corner case I can however think of is a modification of a previous vma > leads to merging with the vma we are querying but even then IIRC the races > could mean the previous vma could be reported still as separate, but then > followed by the merged result, so the virtual address range corresponding of > the previous vma would appear twice in the report, not that a range would be > skipped. > > But if you have examples of a different experience, i.e. where a vma would > indeed be missing, we would be eager to hear that! > > I think the ioctl interface lets you "seek" to the address of interest > quickly, but I believe it also can't eliminate these racing issues completely. i wasn't thinking of changing the "i inherently need to read the whole thing" uses out for the ioctl(), just the "i need to know more about the vma containing this specific address" cases. > >> Thanks, > >> Liam > >> > >> >
