Hi Willy, On Tue, Sep 17, 2024 at 07:55:29AM +1000, Dave Chinner wrote: > On Fri, Sep 13, 2024 at 07:21:54PM +0100, Matthew Wilcox wrote: > > On Fri, Sep 13, 2024 at 01:57:04PM -0400, trondmy@xxxxxxxxxx wrote: > > > If the caller supplies an iocb->ki_pos value that is close to the > > > filesystem upper limit, and an iterator with a count that causes us to > > > overflow that limit, then filemap_read() enters an infinite loop. > > > > Are we guaranteed that ki_pos lies in the range [0..s_maxbytes)? > > I'm not too familiar with the upper paths of the VFS and what guarantees > > we can depend on. If we are guaranteed that, could somebody document > > it (and indeed create kernel-doc for struct kiocb)? > > filemap_read() checks this itself before doing anything else: > > if (unlikely(iocb->ki_pos >= inode->i_sb->s_maxbytes)) > return 0; > > i.e. there is no guarantee provided by the upper layers, it's first > checked right here in any buffered read path... > > -Dave. > > -- > Dave Chinner > david@xxxxxxxxxxxxx Linus merged the NFS LOCALIO changes via the NFS client tree a couple days ago. LOCALIO teased out this filemap_read infinite loop bug, so it is important to fix this for 6.12 (probably should get marked for stable@ too): https://lore.kernel.org/all/c6f35a86fe9ae6aa33b2fd3983b4023c2f4f9c13.1726250071.git.trond.myklebust@xxxxxxxxxxxxxxx/ (weirdly, Trond's reply to you didn't make it to the linux-nfs or linux-fsdevel list archives, but Dave's above reply covers the same) Trond also offered this additional filemap_read negative check: https://lore.kernel.org/all/482ee0b8a30b62324adb9f7c551a99926f037393.1726257832.git.trond.myklebust@xxxxxxxxxxxxxxx/ Could be you've been busy with travel or whatever, but for future reference, should linux-mm and/or Andrew always be cc'd on filemap fixes? Thanks, Mike
