On Tue, Sep 16, 2025 at 02:40:06PM -0300, Jason Gunthorpe wrote: > On Tue, Sep 16, 2025 at 03:11:57PM +0100, Lorenzo Stoakes wrote: > > Update the mem char driver (backing /dev/mem and /dev/zero) to use > > f_op->mmap_prepare hook rather than the deprecated f_op->mmap. > > > > The /dev/zero implementation has a very unique and rather concerning > > characteristic in that it converts MAP_PRIVATE mmap() mappings anonymous > > when they are, in fact, not. > > > > The new f_op->mmap_prepare() can support this, but rather than introducing > > a helper function to perform this hack (and risk introducing other users), > > simply set desc->vm_op to NULL here and add a comment describing what's > > going on. > > > > We also introduce shmem_zero_setup_desc() to allow for the shared mapping > > case via an f_op->mmap_prepare() hook, and generalise the code between > > this and shmem_zero_setup(). > > > > We also use the desc->action_error_hook to filter the remap error to > > -EAGAIN to keep behaviour consistent. > > Hurm, in practice this converts reserve_pfn_range()/etc conflicts into > from EINVAL into EAGAIN and converts all the unlikely OOM ENOMEM > failures to EAGAIN. Seems wrong/unnecessary to me, I wouldn't have > preserved it.
Yeah I don't love it, people get antsy sometimes about changing what the error code is. I'd rather pass through than filter but there we are. > > But oh well > > Reviewed-by: Jason Gunthorpe <[email protected]> Thanks! > > > diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h > > index 0e47465ef0fd..5b368f9549d6 100644 > > --- a/include/linux/shmem_fs.h > > +++ b/include/linux/shmem_fs.h > > This little bit should probably be its own patch "Add > shmem_zero_setup_desc()", and I wonder if the caller from vma.c can > call the desc version now? Ack! Let me look into whether vma.c caller can use that also. > > Too bad the usage in ppc is such an adventure through sysfs :\ The arch code sure can be fun! > > But the code looks fine Cheers! > > Jason Cheers, Lorenzo
