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


Hi -

hunt wrote:

> > 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.

And yet, that is what code reviewers do.  There is no obligation to
produce a complete bug report.  A well-founded concern (your call of a
generally sleep-capable function, deliberately bypassing of the
might_sleep warning, offering little justification and testing, and
until recently, no analysis) should have been enough.  Had you taken
my early warnings more seriously, the problem may have been solved
already.


> [...]  And now we're off on a completely different course. [...]
> But not in the copy functions which don't sleep, lock, or
> reschedule.

Maybe you are missing the fact that consequences of a normal fault can
*include* sleeping, locking, rescheduling.


> > [...] 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. [...]

Thank you for doing the analysis now.  It looks plausible, though will
need more testing and may veer during the ongoing discussion regarding
improved kprobes fault handling.


- FChE


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