Re: [PATCH v4 17/20] mm/vma: only permit MAP_PRIVATE /dev/zero to be mapped anonymous

[David Hildenbrand (Arm)]

>>
>> My brain is a bit slow after digging through this series.
>>
>> We identify shmem, for example, through shmem_vm_ops/shmem_anon_vm_ops.
>>
>> So naturally I am wondering: couldn't we do something similar to identify that?
>> Like, checking for zero_fops?
> 
> We don't assign vm_ops for a MAP_PRIVATE-/dev/zero mapping. So that won't work.
> 
> We could expose zero->f_ops but then it's literally in drivers/char/ and that's
> just weird to expose in mm.h or whatever.

Thinking out loud: could we use a dummy (empty) vm_ops?

We'd place it in mm.h (zero_vm_ops) and just use it in drivers/char/.

See below.

> 
> I'm giving a really minimal possible thing to export, which is the DEVZERO_MINOR
> number which avoids all kinds of weirdness like that. No driver stuff exported,
> just a number :) MEM_MAJOR is already available.
> 
> So I think it's the least bad choice in this one, very very specific scenario.

I'd hope we find something cleaner than the DEVZERO_MINOR thingy.

Something slightly cleaned up chloppedi-schlop on top of mm-unstable.

vma tests seems to still work, but I haven't boot-tested this.