From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 22 19:20:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91158106564A for ; Tue, 22 Jun 2010 19:20:08 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 08B128FC16 for ; Tue, 22 Jun 2010 19:20:06 +0000 (UTC) Received: by vws14 with SMTP id 14so354527vws.13 for ; Tue, 22 Jun 2010 12:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=/x/wYY3jyHlH44DtjHg3OOmW2qOFUIag/nxx2reSbvY=; b=v+DrVHhgcUlFfjRUNGDlTYTMcRvfI0fNQTRQFDjs6131/Dy9arrRwKARsQXMg6A/Ps 0P6IppLwxxsUcmqsz58VgQB0Rebaz8VVwiO/ecwVfdEoY1cAFYEKLCXwsjYAGQOqtoyp 3JN1ID+gZ8xsINRGR8ptXruguyB55iU7a1ukM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OwyPxyHayG+hKBv3PnQGSDP1pAPmplkd37j8r12fbFH6Q+lHGSwTujb0FBULduBna+ TowTCVnqnaLtU5I5fUaxSqLPIJJiwwJqFxfK1KaaosfQHZVyRrbIqWxo83WAEakrzHRP BZAGS5vaCUhI9yYNMRhad8HI8aJmf5mZS/fBM= MIME-Version: 1.0 Received: by 10.224.24.203 with SMTP id w11mr4277971qab.296.1277228752737; Tue, 22 Jun 2010 10:45:52 -0700 (PDT) Received: by 10.229.91.8 with HTTP; Tue, 22 Jun 2010 10:45:52 -0700 (PDT) Date: Tue, 22 Jun 2010 23:15:52 +0530 Message-ID: From: Shrikanth Kamath To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [DTrace][FreeBSD 6.1] Should a kernel global variable reference land up for validation in dtrace_canstore? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 19:20:08 -0000 I have the following simple DTrace script % cat fbt_test.d BEGIN { trace(kernel`my_kern_variable); } When I run the script I get the following error dtrace: error on enabled probe ID 1 (ID 1: dtrace:::BEGIN): invalid kernel access in action #1 at DIF offset 4 This is a FreeBSD 6.1 base (I am attempting to get DTrace to work in a FreeBSD 6.1 cross compiler env) On limited debugging... I see this 'dtrace_dif_emulate' sets the CPU_DTRACE_KPRIV error... case DIF_OP_RLDX: if (!dtrace_canstore(regs[r1], 8, mstate, vstate)) { *flags |= CPU_DTRACE_KPRIV; *illval = regs[r1]; I tried figuring out the semantics of "dtrace_canstore", looks like it checks if the asked variable resides anywhere in the DTrace 'scratch base' or in the space of thread local variables. My query is since I marked the variable in the script with a back quote should it not consider it as a external reference? I have inlined the following lines from my debugging session (kgdb) info address my_kern_variable Symbol "my_kern_variable" is static storage at address 0xc0bd68ec. (kgdb) up #3 0xc5018967 in dtrace_dif_emulate (difo=0xc5bf38c0, mstate=0xee972b00, vstate=0xc4f59c1c, state=0xc4f59c00) (kgdb) p /x regs[1] $165 = 0xc0bd68ec <== Same as my_kern_variable, and this gets passed to dtrace_canstore as shown above (kgdb) p /x mstate->dtms_scratch_base <== Starting at 0xc6a52010 which is greater than the global my_kern_variable $166 = 0xc6a52010 (kgdb) p /x mstate->dtms_scratch_size $167 = 0xbffff0 (kgdb) p /x vstate->dtvs_dynvars.dtds_base <== Thread locals base, 0xc7652000 which is also greater than my_kern_variable $169 = 0xc7652000 (kgdb) p /x vstate->dtvs_dynvars.dtds_size $170 = 0x100000 If we look at the implementation of "dtrace_canstore" it looks very obvious to fail...with the above parameters. In a dumb way, what I am trying to figure out is whether to a reference to a kernel global which is external to the dtrace memory areas land up for validation in dtrace_canstore? Any pointers where to look, how to debug further? -- Shrikanth R K