Rework handling for Linux character device mmap handling.

[jhb]

Summary

Currently the Linux character device mmap handling only supports mmap
operations that map a single page that has an associated vm_page_t.
This does not permit mapping larger regions (such as a PCI memory
BAR) and it does not permit mapping addresses beyond the top of RAM
(such as a 64-bit BAR located above the top of RAM).

Instead of using a single OBJT_DEVICE object and passing the physaddr via
the offset as a hack, create a new sglist and OBJT_SG object for each
mmap request. The requested memory attribute is applied to the object
thus affecting all pages mapped by the request.

Longer term I think the Linux files should become a new file type instead
of a normal cdevsw. This would allow them to use fo_mmap() and to then
change io_remap_pfn_range() to actually do the mmap instead (it would
still create an OBJT_SG object for the mapping). This can be implemented
by using a d_fdopen callback in the cdevsw to install a custom fileops
(see the existing pts/ptmux code for an example). This would also allow
the Linux file ops to use f_data directly and simplify what is now done
via cdevpriv.

Test Plan

I have only verified that linuxapi compiles. The cxgbe iwarp driver wants
to map two PCI BARs into userland and should be a good test of this change.
It would be good to verify that mlxen doesn't see any regressions either.

[• hselasky]

Hi,

Make sure the patch doesn't conflict with D3182 .

If the patch is tested and works it's good to go.

Some questions:

Linux has a special keyword "MAP_FAILED". Do we need to use/or check ptr's against that?

What about security: Are mmapped areas destructed properly or differently than on Linux?

--HPS

[jhb]

In D3386#69029, @hselasky wrote:

Hi,

Make sure the patch doesn't conflict with D3182 .

Whichever one goes in first, the other person will have to resolve it just because the files move around.

If the patch is tested and works it's good to go.

I can't easily test it myself. I have no Mellanox hardware, hence my request for you to test it (Navdeep will get the Chelsio bits tested).

Some questions:

Linux has a special keyword "MAP_FAILED". Do we need to use/or check ptr's against that?

Every system has MAP_FAILED for the return value from mmap(), it's POSIX. However, that is in userland. Do you know how/when Linux uses this in the kernel?

What about security: Are mmapped areas destructed properly or differently than on Linux?

This doesn't really affect destruction compared to the current code. Both OBJT_DEVICE and OBJT_SG use fake pages that alias real pages. Neither use managed pages, so you cannot forcefully evict existing mappings of the object (e.g. for device detach or unload).