On 2022-09-28 13:27-0700, Hugh Dickins wrote: > From: Hugh Dickins <hughd@xxxxxxxxxx> > > On Wed, 28 Sep 2022, Thomas Weißschuh wrote: > > From: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxx> > > > > Without this check open() will open large files on tmpfs although > > O_LARGEFILE was not specified. This is inconsistent with other > > filesystems. > > Also it will later result in EOVERFLOW on stat() or EFBIG on write(). > > > > Link: https://lore.kernel.org/lkml/76bedae6-22ea-4abc-8c06-b424ceb39217@xxxxxxxx/ > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxx> > > Acked-by: Hugh Dickins <hughd@xxxxxxxxxx> > > Thanks! I think you deserve some special award for finding and fixing > such an ancient bug/inconsistency - dating back to early v2.4 it seems. Seems to be my special talent. > But only affecting 32-bit; and since we've happily lived with it so long, > and the fix does change behaviour for userspace, better not to Cc stable. That was my feeling, too. > There are some other filesystems still behaving as tmpfs was (ramfs, > hugetlbfsi, and I didn't look further); but we do make more of an effort > to keep tmpfs in line with the major filesystems - thank you. NFS seems also to be affected, which I think warrants a fix. My plan was to wait for the feedback to this patch and if it works out to then submit patches for NFS as validating that will be a bit more involved. > > --- > > mm/shmem.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/mm/shmem.c b/mm/shmem.c > > index 42e5888bf84d..902c5550fabc 100644 > > --- a/mm/shmem.c > > +++ b/mm/shmem.c > > @@ -3876,6 +3876,7 @@ EXPORT_SYMBOL(shmem_aops); > > > > static const struct file_operations shmem_file_operations = { > > .mmap = shmem_mmap, > > + .open = generic_file_open, > > .get_unmapped_area = shmem_get_unmapped_area, > > #ifdef CONFIG_TMPFS > > .llseek = shmem_file_llseek, > > > > base-commit: f76349cf41451c5c42a99f18a9163377e4b364ff > > -- > > 2.37.3
