On Sun, Oct 01, 2023 at 12:10:29AM +0100, Lorenzo Stoakes wrote: > The existing comments in filemap_fault() suggest that, after either a minor > fault has occurred and filemap_get_folio() found a folio in the page cache, > or a major fault arose and __filemap_get_folio(FGP_CREATE...) did the job > (having relied on do_sync_mmap_readahead() or filemap_read_folio() to read > in the folio), the only possible reason it could not be uptodate is because > of an error. > > This is not so, as if, for instance, the fault occurred within a VMA which > had the VM_RAND_READ flag set (via madvise() with the MADV_RANDOM flag > specified), this would cause even synchronous readahead to fail to read in > the folio. > > I confirmed this by dropping page caches and faulting in memory madvise()'d > this way, observing that this code path was reached on each occasion. > > Clarify the comments to include this case, and additionally update the > comment recently added around the invalidate lock logic to make it clear > the comment explicitly refers to the minor fault case. I do appreciate the comment being made accurate, but I wonder if we shouldn't change the code to match the comment. We're got two "should"s pointing in different directions -- we "should" not use readahead if readahead is disabled, and we "should" always use readahead first, using read_folio() only if readahead doesn't succeed. The code isn't ideally structured for this, but I'm going to play with it a bit and see what I can create.
