>> >> >>my reading of the kcopy() man page made me think that i could pass it
>> >> >>a "src" pointer and a "dst" pointer, and it would return EFAULT if
>> >> >>either of the pointers were invalid.
>> >> >>
>> >> >>instead, i'm getting kernel panics.
>> >> >>
>> >> >>is there a better interface for copying from place to place when you
>> >> >>don't know the exact disposition of the pointers (so i can't really
>> >> >>use memcpy())?
>> >> >
>> >> >Who is giving you pointers you can't trust?  That sounds like a broken
>> >> >interface.
>> >>
>> >>the kernel, device drivers, lkms, and some users.  i don't trust
>> >>everyone and i'd like not to have to trust anyone.
>> >
>> >The first 3 can be wholely trusted.  The last can't be trusted at all.
>>
>>um...and in the presence of bugs?  i'd prefer to take the other path
>>and simply not trust anyone.
>
>You should assume the kernel is bug free.  Though sprinkling KASSERT and
>KDASSERT to make sure things are as you expect would be good.  Kernel code
>is always trusted to be correct.

okay, fine.

>> >And really, you should NEVER accept a kernel address from a user process.
>> >That is a violation of the user-kernel schism.
>>
>>yet this is precisely what happens when a process reads from kmem.  an
>>address in kernel space is given (which might be invalid) along with
>>an address in user space (which might also be invalid), yet mmrw()
>>manages to cope.  the only problem from my point of view is that
>>mmrw() is in md code and i'm not.
>
>That's MD code and has the ability to use faultbuf to recover from failures.

i know it's md code.  kcopy() is also md code.  copyout() is also md
code.  the difference is that mmrw() and copyout() manage not to panic
when used.  kcopy() panics.

>Note that, unlike sysctl's, mmrw's use of the address is only fleeting.

actually, sysctl doesn't continuously read from the same address.  it
only happens when someone requests the data from a particular node.
the fact that it has it recorded is somewhat irrelevant.

it's really no different from me having an address in the kernel and
periodically reading from it via /dev/kmem.  it works most of the
time, but if it doesn't, the kernel doesn't panic.  it just tells me
it didn't work.

>> >>just because you trust that the pointer you give me is valid doesn't
>> >>mean i trust you to give me a valid pointer, and if i keep the pointer
>> >>for a few hours, will it still be valid?
>> >
>> >If it's given to you from another part of the kernel, you have to
>> >trust they won't go away and if they do go away, you will be informed
>> >ahead of time.
>>
>>that's the ideal situation, yes, but being paranoid, i don't expect
>>everyone to play by those rules.
>
>You have to expect kernel code to play by the rules.  To do otherwise
>is to not trust your kernel at all.  That leads to madness.  Kernel
>code may be incorrect but then that means there is a bug which will be
>fixed.

then i expect kcopy() not to cause a panic.

incidentally...if i can always know that the kernel is bug-free and
thereby know that all pointers to kernel address space are valid, why
is there a need for kcopy()?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."