linux-kernel - Re: HTLB mapping for drivers. Driver example

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202cde0e0908190201p4c2e2701xf18bdecbc53df905@mail.gmail.com>
Date:	Wed, 19 Aug 2009 21:01:17 +1200
From:	Alexey Korolev <akorolex@...il.com>
To:	Mel Gorman <mel@....ul.ie>
Cc:	Alexey Korolev <akorolev@...radead.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: HTLB mapping for drivers. Driver example

Mel,


>
> This seems a lot of burden to put on a device driver, particularly with
> respect to the reservations.

Thanks a lot for review you did. That is right.  I don't like this
burden as well.
>
>> File operations of /dev/hpage_map do the following:
>>
>> In file open we  associate mappings of /dev/xxx with the file on hugetlbfs (like it is done in ipc/shm.c)
>>       file->f_mapping = h_file->f_mapping;
>>
>> In get_unmapped_area we should tell about addressing constraints in case of huge pages by calling hugetlbfs procedures. (as in ipc/shm.c)
>>       return get_unmapped_area(h_file, addr, len, pgoff, flags);
>>
>> We need to let hugetlbfs do architecture specific operations with mapping in mmap call. This driver does not reserve any memory for private mappings
>> so driver requests reservation from hugetlbfs. (Actually driver can do this as well but it will make it more complex)
>>
>> The exit procedure:
>> * removes memory from page cache
>> * deletes file on hugetlbfs vfs mount
>> *  free pages
>>
>> Application example is not shown here but it is very simple. It does the following: open file /dev/hpage_map, mmap a region, read/write memory, unmap file, close file.
>>
>
> For the use-model you have in mind, could you look at Eric Munson's patches
> and determine if the target application would have been happy to call the
> following please?
>
> mmap(0, len, prot, MAP_ANONYMOUS|MAP_HUGETLB, 0, 0)
>
Hmm. But how can I at least identify which driver this call is addressed to?

Thanks,
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/