In practice, the current callers pass PAGE_SIZE aligned inputs, avoiding the bug. Therefore this doesn't need to be backported. Still, that's a happy accident and not a precondition of lock_region, so we let's do the right thing to future proof.
Actually it's worse than that due to the hardware behaviour, the spec states (for LOCKADDR_BASE):
Only the upper bits of the address are used. The address is aligned to a multiple of the region size, so a variable number of low-order bits are ignored, depending on the selected region size. It is recommended that software ensures that these low bits in the address are cleared, to avoid confusion.
It appears that indeed this has caused confusion ;)
So for a simple request like locking from 0xCAFE0000 - 0xCB010000 (size = 0x30000) the region width gets rounded up (to 0x40000) which causes the start address to be effectively rounded down (by the hardware) to 0xCAFC0000 and we fail to lock 0xCB000000-0xCB010000.
Interestingly (unless my reading of this is wrong) that means to lock 0xFFFF0000-0x100010000 (i.e. crossing the 4GB boundary) requires locking *at least* 0x00000000-0x200000000 (i.e. locking the first 8GB).
This appears to be broken in kbase (which actually does zero out the low bits of the address) - I've raised a bug internally so hopefully someone will tell me if I've read the spec completely wrong here.
Horrifying, and not what I wanted to read my last day before 2 weeks of leave. Let's drop this patch, hopefully by the time I'm back, your friends in GPU can confirm that's a spec bug and not an actual hardware/driver one...
Can you apply the other 3 patches in the mean time? Thanks :-)