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: kprobe fault handling


On Fri, 2006-02-10 at 19:49 -0500, Frank Ch. Eigler wrote: 
> Hi -
> 
> > > Those kernel functions are similarly unsafe (for purposes of
> > > systemtap), since they can sleep (wait while page faults are being
> > > serviced).  
> >
> > I started this whole thread to explain that my tests were now
> > showing that was indeed the case.
> 
> Why was that news, given my repeated warning to this effect?

The problem with your warnings is that they are vague and lack any
analysis or data.  Saying that there may be bugs now or in the future in
a system is not the same as reporting a specific bug.

> > However that was due to an easily fixed bug in the fault handler.
> 
> Perhaps so, but:
> 
> > You can't deem high-level functions unsafe to use because a bug in a
> > lower-level routine temporarily made them that way.
> 
> Temporarily?  And it's not just that routine.  The larger problem is
> sleeping/rescheduling/locking, not just faulting.  This lesson made an
> earlier appearance with printk.

And now we're off on a completely different course. You have bad
feelings that there are bugs involving sleeping/rescheduling/locking
somewhere. I agree there could be a few we haven't detected; I haven't
finished reviewing the code for them. But not in the copy functions
which don't sleep, lock, or reschedule.

> > > This is why Roland went out of his way to collect
> > > alternatives in loc2c-runtime.h.  This was explained at the time.
> > 
> > IIRC, he explained to you why using __get_user_asm was safe. That is the
> > same function used by copy_from_user and get_user. 
> 
> It may be that even those are not sufficiently safe (i.e., not
> stressed enough on pessimistic cases such as valid user addresses that
> are paged out).  Or maybe they are used just differently enough to
> have made them work.  How much analysis went into your variant, beyond
> bypassing the might_sleep warning?

Certainly less time than I have spent arguing over it.  I writing a
quick summary of my analysis and posting it separately. We can continue
this debate there if you wish. 

Martin



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