----- Original Message ----- > OK, thanks for explanation! I missed that GFS2 glocks are task local. But > then I have another question. We have the following: > > gfs2_file_read_iter() > grabs inode glock in shared mode > generic_file_read_iter() > filemap_read() > copy_page_to_iter() > <page fault> > grabs mmap_sem > gfs2_fault() > - tries to grab inode glock again -> possible recursive locking > > And even if the locking isn't recursive, you have glock->mmap_sem and > mmap_sem->glock lock orderings so ABBA deadlocks are possible AFAICT. > > And there's a similar problem with the write path as well, just the lock is > grabbed exclusively. > > Honza > -- > Jan Kara <j...@suse.com> > SUSE Labs, CR
Hi Jan, IIRC, gfs2 tries to prevent the page fault by having gfs2_file_read_iter call into generic_file_read_iter twice: The first time without the glock held, but specifying IOCB_NOIO, which brings the pages in and returns -EAGAIN. Then it acquires the glock, then calls into generic_file_read_iter a second time. I'm not sure if that prevents the deadlock or just makes it less likely. I still need to investigate that. Regards, Bob Peterson Red Hat File Systems
