Linus Torvalds writes: (Summary) wrote:
Right you are.
Right you are.
We could easily reverse the order of those two checks, but since clearly the s_maxbytes case hadn't gotten as much coverage as I thought it had, let's just simplify file_mmap_size_max() instead, and just make the limit be MAX_LFS_FILESIZE for regular files too, the way we already do for block devices (instead of trying to figure out the size of the block device). It's the random ad-hoc mmap implementations in drivers that it really aimed to protect.
drivers that it really aimed to protect.
So for now, I've committed the minimal fixlet that doesn't affect any existing code (just the new max file size logic), and maybe this can be revisited for 4.18.
revisited for 4.18.
Linus
Linus
[unhandled content-type:application/x-patch]
[...]
so, as it is this patch does not fix the issue.Right you are.
Right you are.
We could easily reverse the order of those two checks, but since clearly the s_maxbytes case hadn't gotten as much coverage as I thought it had, let's just simplify file_mmap_size_max() instead, and just make the limit be MAX_LFS_FILESIZE for regular files too, the way we already do for block devices (instead of trying to figure out the size of the block device). It's the random ad-hoc mmap implementations in drivers that it really aimed to protect.
drivers that it really aimed to protect.
So for now, I've committed the minimal fixlet that doesn't affect any existing code (just the new max file size logic), and maybe this can be revisited for 4.18.
revisited for 4.18.
Linus
Linus
[unhandled content-type:application/x-patch]