On Thu, Dec 07, 2023 at 04:43:03PM +0100, Arnd Bergmann wrote: > On Thu, Dec 7, 2023, at 15:58, Gregory Price wrote: > > On Thu, Dec 07, 2023 at 08:13:22AM +0100, Arnd Bergmann wrote: > >> On Thu, Dec 7, 2023, at 01:27, Gregory Price wrote: > >> > >> Aside from this, you should avoid holes in the data structure. > >> On 64-bit architectures, the layout above has holes after > >> policy_node and after addr_node. > >> > >> Arnd > > > > doh, clearly i didn't stop to think about alignment. Good eye. > > I'll redo this with __u/s members and fix the holes. > > > > Didn't stop to think about compat pointers. I don't think the > > u64_to_user_ptr pattern is offensive, so i'll make that change. > > At least I don't see what the other options are beyond compat. > > Ok, sounds good. > > I see you already call wrappers for compat mode to convert > iovec and nodemask layouts for the indirect pointers, and they > look correct. If you wanted to do handle the compat syscalls > using the same entry point, you could add the same kind of > helper to copy the mempolicy args from user space with an > optional conversion, but not having to do this is clearly > easier. > > Arnd I don't know that either is easier, it's basically just what annoying way do you want to handle this annoying problem. I'll poke at it and decide which one I hate less. One thing i didn't really think about, probably the iovec/len fields should just be args for mbind2, rather than embedded in mpol_args - since mpol_args is supposed to describe the mpol while the iovec/len describes what it applies to. Simplifies the mpol_args structure a bit. Doesn't change the handling at all. (bit of a rubber ducky comment here) As always, I appreciate the input ~Gregory
