This is the mail archive of the systemtap@sources.redhat.com 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: architecture paper draft


Hi,

On Tue, 2005-02-15 at 13:10, Frank Ch. Eigler wrote:

> I can't enumerate every possibility that a user might dream up,
> which is why having a general soft-fail mechanism that the probe
> functions could use is so attractive.  

Fair enough.

> (There is also some confusion in my mind about how come in_interrupt()
> is zero within kprobe functions, even though they're called from the
> breakpoint int handler.  It's convenient, but I wonder if it has any
> negative implications.)

Traps != interrupts in this context --- you can legally send a process
to sleep from a trap handler (page faults do it all the time, for
example.)

> > Do you want probes to be able to access arbitrary process contexts?  Or
> > just the current one?
> 
> Maybe.

How will you specify that, then?

> > What about locks --- do you want to be able to access the memory deep
> > inside locked sections of the kernel? [...]
> 
> Maybe, which suggests a need to enumerate all the possible locks that,
> if held by someone else, would render access_process_vm() illegal

"Someone else" is the wrong concept: first, in general, locks don't have
owners.  It's perfectly legal for one process to lock an object and for
a completely different one to unlock it; or for it to be unlocked from
an interrupt handler that doesn't "belong" to any process at all.  (Most
IO is handled this way, for example.)  Second, even if the current
process does "hold" a lock (ie. it is expected to release the lock
itself), you'll still deadlock on that lock if the memory access needs
it, as locks in Linux are not recursive.

And finally, the set of locks includes all possible locks that the
filesystem backing the page might need in order to service the page
fault, so you're asking for intimate knowledge of every filesystem that
might ever back an mmap under Linux.  :-)

Rather than enumerating all locks that might be relevant and trying to
test for those (which basically cannot work anyway since you can't tell
if it's this process or another which has them), it might be better to
rely on white-listing points in the kernel where it's known that we can
do this safely --- for example, on syscall entry points.

--Stephen


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