This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: double fault -> PAGE_KERNEL flagged memory
* Tom Zanussi (zanussi@us.ibm.com) wrote:
> Mathieu Desnoyers writes:
> > * Tom Zanussi (zanussi@us.ibm.com) wrote:
> > > Mathieu Desnoyers writes:
> > > > Generally speaking, what would happen if :
> > > >
> > > > - A page fault handler has a trace point that logs an event in the RelayFS
> > > > buffer.
> > > > - This exact write causes a (minor) page fault.
> > > >
> > > > It may not happen often, but I think it would lead to a double fault. Is this
> > > > case possible ?
> > > >
> > >
> > > Yes, I'm sure it is possible, in fact I'm sure it happens all the time
> > > in LTT and it's never been a problem. Have you verified that it is a
> > > problem (e.g. tracing only page faults and seeing a double fault).
> > >
> > >
> >
> > I have just done this, and nothing bad happened and I discovered why :
> >
> > The LTT instrumentation of do_page_fault comes right after the
> > "We fault-in kernel-space virtual memory on-demand." section. So, minor page
> > faults are not instrumented.
> >
> > Maybe this isn't so interesting to instrument it, but if we would like to, I
> > suggest to add an optionnal support for kmalloc'd memory areas in RelayFS so
> > the client can ask for a channel which consists of a small buffer that is
> > reentrant for the memory subsystem. This should be documented with a big
> > warning about the small size the client should ask for.
> >
>
> That would be one option, but how about instrumenting the vmalloc
> fault case to check whether the faulting address lies inside the
> buffer and if so, don't log an event in that case. You wouldn't see
> those vmalloc faults touching the relayfs buffers, but I'm not sure
> that's interesting anyway...
>
What about :
- On any minor page fault
- logging a vmalloc fault (from somewhere else in the kernel)
- test if faulted address lies within the relayfs buffer : no
- generate a vmalloc fault because of buffer access
-> double fault.
I'm afraid it won't fix the problem.
Mathieu
OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68