Re: mmap port from 9 not working

 
Van: Laurie Jennings <laurie_jennings_1977_at_yahoo.com>
Datum: maandag, 22 juli 2019 14:56
Aan: Ronald Klop <ronald-lists_at_klop.ws>
Onderwerp: Re: mmap port from 9 not working
> 
>  
>  
>  
>  
>  
>  
>  
> Van: Laurie Jennings <laurie_jennings_1977_at_yahoo.com>
> Datum: zondag, 21 juli 2019 16:58
> Aan: Konstantin Belousov <kostikbel_at_gmail.com>
> CC: FreeBSD Current <freebsd-current_at_freebsd.org>
> Onderwerp: Re: mmap port from 9 not working
>> 
>>  On Sunday, July 21, 2019, 10:44:14 AM EDT, Konstantin Belousov <kostikbel_at_gmail.com> wrote:
>> 
>> On Sun, Jul 21, 2019 at 03:48:03AM +0000, Laurie Jennings wrote:
>> > I have some custom stuff I'm porting from Freebsd 9.x using mmap. I get a pointer from the kernel via an ioctl and I map it into a shared buffer.
>> > char *kptr;   // mem ptr from kernel
>> > fd=open("/dev/kmem",O_RDWR);memp=mmap(0,size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,(off_t) ptr);
>> > 
>> > This worked perfectly in 9; memp I had a shared block of memory between the kernel and user space.
>> > In 11.3 this returns an errno 22, which is pretty murky. I did notice that off_t doesnt yield an actual offset; I've tried putting in the correct value manuallybut it just fails and fails.I've tried read only also. 
>> > Please Help!
>> 
>> | Start with providing (and looking yourself) at the output of kdump/ktrace
>> | around the failing mmap.  The checks for correctness of the mmap(2) arguments
>> | were greatly improved during years after FreeBSD 9.
>> Since posting this I found a thread that said something about mmap no longer supporting /dev/kmem. If that's that case I need to find another method. No sense spending a day debugging something thatisn't supposed to work. 
>> SHOULD this still work? This always worked fine with non-wired memory but maybe things have changed since 9. 
>>  
>>  
>>  
> 
>  
> On Monday, July 22, 2019, 8:03:33 AM EDT, Ronald Klop <ronald-lists_at_klop.ws> wrote: "
>  
> It looks like this is not possible anymore. Here is the code change with some explanation.
> https://svnweb.freebsd.org/base?view=revision&revision=307332
> https://reviews.freebsd.org/D8248
> 
> Just a question of my site out of interest to people who know more about this than I do. Does Page Table Isolation (PTI) also prevent mapping /dev/kmem in user space?
> https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities#Meltdown_.28CVE-2017-5754.29
> 
> Regards,
> Ronald.
>  
> "
>  
> Just FYI, I got this to work using '/dev/mem' by passing up the physical address of the block. Probably more intuitive.
>  
> Just a question; the docs say contigmalloc() returns wired memory; is this guaranteed to be the case or do I need to run vm_map_wire() on it to be sure? vm_map_lookup() doesnt return "wired" as true after a contigmalloc(); but maybe all kernel_map memory is wired? 
>  
> LJ
>  

Laurie,

I have no idea. I'll cc the mailinglist back into the conversation.

Ronald.