dtrace discuss - Oct 2008 - Problems with fds[fd].fi_pathname within Solaris zone

Hi,

It seems that fds[fd].fi_pathname doesn''t work within Solaris zone.
The following script:

  syscall::close:entry
  /pid == $target/
  {
     printf("file: %s\n", stringof(fds[arg0].fi_pathname));
  }

fails:
  > d.d -c date
  dtrace: error on enabled probe ID 1 (ID 1954: syscall::close:entry): invalid
kernel access in action #1 at DIF offset 64
  dtrace: error on enabled probe ID 1 (ID 1954: syscall::close:entry): invalid
kernel access in action #1 at DIF offset 64

However, it works fine when running within global Solaris zone or without zones:
  > d.d -c date
  file: /platform/sun4v/lib/libc_psr.so.1
  file: /usr/share/lib/zoneinfo/Europe/Moscow

Is it known problem or using fds structure in not correct within Solaris zones?

thanks,
-katya

Unfortunately, you''re running into an inherent limitation of DTrace  
running
in a zone: you can''t dereference kernel memory as that would violate
the
zones containment model. The fds[] array implicitly sifts around kernel
structures; this is why you''re getting the error.

Adam

On Oct 17, 2008, at 8:37 AM, Ekaterina Pavlova wrote:
> Hi,
>
> It seems that fds[fd].fi_pathname doesn''t work within Solaris
zone.
> The following script:
>
>  syscall::close:entry
>  /pid == $target/
>  {
>     printf("file: %s\n", stringof(fds[arg0].fi_pathname));
>  }
>
> fails:
>> d.d -c date
>  dtrace: error on enabled probe ID 1 (ID 1954:  
> syscall::close:entry): invalid kernel access in action #1 at DIF  
> offset 64
>  dtrace: error on enabled probe ID 1 (ID 1954:  
> syscall::close:entry): invalid kernel access in action #1 at DIF  
> offset 64
>
> However, it works fine when running within global Solaris zone or  
> without zones:
>> d.d -c date
>  file: /platform/sun4v/lib/libc_psr.so.1
>  file: /usr/share/lib/zoneinfo/Europe/Moscow
>
> Is it known problem or using fds structure in not correct within  
> Solaris zones?
>
> thanks,
> -katya
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

Thanks Adam.

Is any other way in DTrace to get the same information which will work in zones
as well?

-katya

Adam Leventhal wrote:
> Unfortunately, you''re running into an inherent limitation of
DTrace running
> in a zone: you can''t dereference kernel memory as that would
violate the
> zones containment model. The fds[] array implicitly sifts around kernel
> structures; this is why you''re getting the error.
> 
> Adam
> 
> On Oct 17, 2008, at 8:37 AM, Ekaterina Pavlova wrote:
> 
>> Hi,
>>
>> It seems that fds[fd].fi_pathname doesn''t work within Solaris
zone.
>> The following script:
>>
>>  syscall::close:entry
>>  /pid == $target/
>>  {
>>     printf("file: %s\n", stringof(fds[arg0].fi_pathname));
>>  }
>>
>> fails:
>>> d.d -c date
>>  dtrace: error on enabled probe ID 1 (ID 1954: syscall::close:entry): 
>> invalid kernel access in action #1 at DIF offset 64
>>  dtrace: error on enabled probe ID 1 (ID 1954: syscall::close:entry): 
>> invalid kernel access in action #1 at DIF offset 64
>>
>> However, it works fine when running within global Solaris zone or 
>> without zones:
>>> d.d -c date
>>  file: /platform/sun4v/lib/libc_psr.so.1
>>  file: /usr/share/lib/zoneinfo/Europe/Moscow
>>
>> Is it known problem or using fds structure in not correct within 
>> Solaris zones?
>>
>> thanks,
>> -katya
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
> 
> 
> -- 
> Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl
> 
-- 
---   \(^_^)/   ---

Ekaterina Pavlova,
VMSQE Team, St. Petersburg.
http://blogs.sun.com/vmrobot/
http://blogs.sun.com/theaquarium_ru/

> Is any other way in DTrace to get the same information which will work in
> zones as well?
Unfortunately, I don''t believe that there is a way to access the
information
in the fds[] array from a local zone.

Adam

-- 
Adam Leventhal, Fishworks                     http://blogs.sun.com/ahl