From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30289 invoked by alias); 17 May 2007 19:46:58 -0000 Received: (qmail 30261 invoked by uid 22791); 17 May 2007 19:46:53 -0000 X-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_50,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 May 2007 19:46:40 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l4HJkbeP032256; Thu, 17 May 2007 15:46:37 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4HJkaQd030755; Thu, 17 May 2007 15:46:36 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l4HJkadq014310; Thu, 17 May 2007 15:46:36 -0400 Received: from ton.toronto.redhat.com (ton.toronto.redhat.com [172.16.14.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 3A566800087; Thu, 17 May 2007 15:46:36 -0400 (EDT) Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id l4HJkZ5i015018; Thu, 17 May 2007 15:46:35 -0400 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id l4HJkT1h015016; Thu, 17 May 2007 15:46:29 -0400 Date: Thu, 17 May 2007 19:46:00 -0000 From: "Frank Ch. Eigler" To: Mike Mason Cc: systemtap@sources.redhat.com Subject: Re: Functions that require interrupts be enabled Message-ID: <20070517194628.GC2520@redhat.com> References: <464A352A.8010608@us.ibm.com> <464B54D6.2070309@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <464B54D6.2070309@us.ibm.com> User-Agent: Mutt/1.4.1i Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00336.txt.bz2 Hi - On Wed, May 16, 2007 at 12:00:38PM -0700, Mike Mason wrote: > [...] > >Why must this new routine be permitted to sleep? We can tolerate > >paged-out data via soft errors (=> blank strings). > > My script filters based on the arguments, so having the routine randomly > fail to return the actual arguments isn't good. Yeah, though I wonder how frequently that can happens, considering that running tools like "top" would keep those pages around. > Plus I don't think whether the page is paged in or not is an issue. > I think the routine I'm using handles that (see below). Yes, via possible sleeps during the other routines. > > > >>Now that begin/end probes no longer require that interrupts be > >>disabled, this function can be used in begin/end probes at least. > > > >AFAIK, interrupts being enabled is not exactly the same thing as being > >able to sleep. > > Here's the routine I'm using to grab the arguments from user space. It's a > modified version of access_process_vm(), which isn't callable from a > module. It can potentially sleep in two places: down_read() and kmap(). > These functions do a might_sleep() check and fail if interrupts are > disabled. > I considered using down_read_trylock() and kmap_atomic() (which > won't sleep) but I don't clearly understand the side-effects of > doing so. Any suggestions would be appreciated. I too only have limited understanding of this. For the _trylock, that is not a problem, as one can detect contention and return early rather than blocking. For kmap_atomic(), it seems trickier. You'd need to use one of the KM_USER[01] slots. But we're in trouble if we are running this code within a probe in a kernel routine that is already using that slot. Then we still have this stuff that might sleep indirectly via a page fault (unless I'm mistaken): > ret = get_user_pages(tsk, mm, addr, 1, 0, 1, &page, &vma); > copy_from_user_page(vma, page, addr, buf, maddr + offset, bytes); So it seems like our options are: (a) write such a tapset function, permit it to only be called from begin/end-like probe contexts, and let it sleep and whatnot (b) write a related tapset function, which uses very conservative atomic routines everywhere, and may return blanks (c) accept an approximation, such as a deferred result. It might look like this: # ------------------------------------------------------------------------ # tapset/proc-args.stp %{ // helper C code %} void deferred_lookup(...) %{ // enqueue a possibly-sleepy lookup of process args using // auxiliary thread or defer_work type callback // arrange to put results into _process_args[] when available // return right away %} global _process_args function process_args:string (pid) { if (pid in _process_args) return _process_args [pid] else { deferred_lookup (pid) return "" } } # ------------------------------------------------------------------------ Then, ordinary user scripts would just call process_args(NNN), and would have to accept & ignore empty results. Eventually valid strings should come by. - FChE