Re: [PATCH 01/19] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



So did we settle on the new mmap_validate vs adding a new argument
to ->mmap for real now?  I have to say I'd much prefer passing an
additional argument instead, but if higher powers rule that out
this version is ok.

> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 13dab191a23e..5aee97d64cae 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1701,6 +1701,8 @@ struct file_operations {
>  	long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
>  	long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
>  	int (*mmap) (struct file *, struct vm_area_struct *);
> +	int (*mmap_validate) (struct file *, struct vm_area_struct *,
> +			unsigned long);

Can we make this return a bool for ok vs not ok?  That way we only
need to have the error code discussion in one place instead of every
file system.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux