andrewboie
commented
6 years ago So for the specific use-case of i2s subsystem, we can't find a way to expose the actual queue slabs to user mode without introducing issues where user mode could do things like free slabs unexpectedly and get the kernel to blow up when it tries to take them off the queue and do things with them in interrupt context. The current plan is to do a data copy and not expose the slabs to user mode directly.
However this still could be generally useful. We could define macros to define the bitfield area statically or just allocate it on the heap.
In order to enable certain driver subsystems (such as I2S) to work with user mode enabled, the slab allocator must be changed to work with user mode.
The way it works right now is that it maintains a free list in the unused memory block. If a user thread has access to this buffer, it's possible for it to corrupt the free list and get the kernel to write anywhere in memory.
By keeping the metadata separate (e.g. a bitmap), it's possible to make the API work with user land. The only caveat I see with this is that the bitmap has to be allocated somewhere and the kernel heap has to be used; for a limited number of slab elements, the kernel heap overhead is quite large.