DTrace panic while probing syscall::open (and possibly many others)

[Andriy Gapon]

on 19/06/2009 20:41 Thomas Backman said the following:
> On Jun 19, 2009, at 07:32 PM, Thomas Backman wrote:
>> Very interesting.
>> I replaced the ASSERT line temporarily:
>>
>> ---
>> ../src_r194478-UNTOUCHED/sys/cddl/dev/dtrace/amd64/dtrace_isa.c    
>> 2009-06-19 13:10:05.661079736 +0200
>> +++ sys/cddl/dev/dtrace/amd64/dtrace_isa.c      2009-06-19
>> 19:24:42.362125129 +0200
>> @@ -524,7 +524,7 @@
>> static int
>> dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size)
>> {
>> -       ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr);
>> +       ASSERT(kaddr >= 0xffffff8000000000 && kaddr + size >= kaddr);
>>
>>        if (uaddr + size >= kernelbase || uaddr + size < uaddr) {
>>                DTRACE_CPUFLAG_SET(CPU_DTRACE_BADADDR);
>>
>> ... and it works! I obviously haven't tried it for extended periods or
>> anything, but at least it's working so far.
>> Should the ASSERT simply use this (as a #define somewhere) or the
>> INKERNEL macro, though?

I think that this should be sufficient, because I don't think that 'kaddr' of
dtrace scratch buffer could be in direct map.

> BTW... Should "kernelbase" in the line following the ASSERT also be
> replaced, or not? As far as I can understand (not too far in these
> contexts ;) it (should) check/s to see whether the userspace data, to be
> copied, is inside the kernel *map*(?)... which at the moment, I guess it
> doesn't. Correct?

Yes, I think so too.

-- 
Andriy Gapon