[PATCH 0/8] mmap_cache subsystem (re-factoring)

[Dmitry V. Levin]

On Wed, Apr 25, 2018 at 02:34:32AM +0900, Masatake YAMATO wrote:
> On Tue, 24 Apr 2018 16:56:34 +0300, "Dmitry V. Levin" <ldv at altlinux.org> wrote:
> > On Tue, Apr 24, 2018 at 02:25:14PM +0900, Masatake YAMATO wrote:
> >> > On Tue, Feb 27, 2018 at 02:30:06AM +0300, Dmitry V. Levin wrote:
> >> >> On Sat, Jan 27, 2018 at 05:36:36AM +0900, Masatake YAMATO wrote:
> >> >> > When we added unwinding feature (activated with -k option), we also added
> >> >> > a code for caching the entries of /proc/$pid/maps.
> >> >> > 
> >> >> > The code for caching was tightly integrated with the code for
> >> >> > unwinding. However, while prototyping kvm vcpu state dump feature to
> >> >> > strace[1], I found the code for caching is useful for other purposes
> >> >> > than unwinding feature.
> >> >> > 
> >> >> > This patch set makes the code for caching usable independently of
> >> >> > unwinding feature. In the changes, I call the newly separated
> >> >> > code for caching "mmap_cache subsystem".
> >> >> > 
> >> >> > [1] https://marc.info/?l=kvm&m=151531408406144&w=2
> >> >> > 
> >> >> > Masatake YAMATO (8):
> >> >> >   unwind: lift up unw_flush_cache from mmap cache management code
> >> >> >   Introduce mmap_cache subsystem derived from unwind.c
> >> >> >   mmap_cache: Move code for searching an mmap cache from unwind
> >> >> >   mmap_cache: record protection bits
> >> >> >   Lift up mmap_cache_delete invocation from unwind.c
> >> >> >   mmap_cache: add function to enable mmap_cache
> >> >> >   mmap_cache: record device major and minor numbers
> >> >> >   mmap_cache: add customizable search function
> >> >> 
> >> >> Thanks, I'll merge the first 7 of them, with minor corrections
> >> >> (mostly related to commit messages) and a single build fix.
> >> > 
> >> > With introduction of libdw-based unwinder this mmap_cache subsystem looks
> >> > very odd: despite the fact that libdw-based unwinder does not use mmap_cache,
> >> > it's use is forced by unwind.c for no visible purpose.
> >> 
> >> mmap_cache calls tcb_flush_cache (and dwfl_linux_proc_report) when
> >> the memory mapping of a target process is changed.
> > 
> > Well, it's not mmap_cache.c but unwind.c that calls tcb_flush_cache.
> > Generic unwind uses just the return code of mmap_cache_rebuild_if_invalid.
> 
> Oh, I see. What unwind-libdw needs tcp->mmap_cache_generation and
> mmap_cache.c::mmap_cache_generation. How about introducing a function
> that allows libdw unwinder to access (or comapre) mmap_cache.c::mmap_cache_generation ?

I don't think it would help if we assume that nothing outside mmap_cache.c
modifies tcp->mmap_cache* fields.

What unwind-libdw needs to know is whether any mmap_cache_invalidate has
been called since the last unwinder.tcb_flush_cache invocation for that tcb.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20180424/75736a06/attachment.bin>