This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]