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

From: "Frank Ch. Eigler" <fche at redhat dot com>
To: Martin Hunt <hunt at redhat dot com>
Cc: systemtap at sources dot redhat dot com
Date: Fri, 10 Feb 2006 17:20:51 -0500
Subject: Re: kprobe fault handling
References: <20060208043831.GA9313@in.ibm.com> <OFD9B8CED9.AB543156-ON8025710F.003BD103-8025710F.003EFA68@uk.ibm.com> <20060209072338.GA2902@in.ibm.com> <1139520938.2779.171.camel@dyn9047018079.beaverton.ibm.com> <1139522818.4127.15.camel@monkey2> <1139550026.4025.4.camel@monkey2> <y0mr76asx9o.fsf@ton.toronto.redhat.com> <1139608530.3947.12.camel@monkey2> <20060210221202.GA19238@redhat.com> <1139609899.3947.13.camel@monkey2>

Hi -

> > Always for the same reason: because it invokes functions that can
> > might sleep (and are in fact documented as such).  
> 
> Which function are those?

Er, the "__copy_from_user" family?!  The "_inatomic" function, whose
name encodes its very inatomicity?

- FChE

Follow-Ups:
- Re: kprobe fault handling
  - From: Martin Hunt

References:
- Re: kprobe fault handling
  - From: Suparna Bhattacharya
- Re: kprobe fault handling
  - From: Richard J Moore
- Re: kprobe fault handling
  - From: Prasanna S Panchamukhi
- Re: kprobe fault handling
  - From: Jim Keniston
- Re: kprobe fault handling
  - From: Martin Hunt
- Re: kprobe fault handling
  - From: Martin Hunt
- Re: kprobe fault handling
  - From: Frank Ch. Eigler
- Re: kprobe fault handling
  - From: Martin Hunt
- Re: kprobe fault handling
  - From: Frank Ch. Eigler
- Re: kprobe fault handling
  - From: Martin Hunt

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