On Wed, 15 Dec 2010, Miklos Szeredi wrote: > On Tue, 14 Dec 2010, Hugh Dickins wrote: > > I'd feel rather happier about it if I thought it would also fix > > Robert's kernel BUG at /build/buildd/linux-2.6.35/mm/filemap.c:128! > > but I've still not found time to explain that one. > > Me neither, all unmap_mapping_range() calls from shmfs are either with > i_mutex or from evict_inode. And the page returned by shmem_fault is already locked. > > Hmm, is there anything preventing remap_file_pages() installing a pte > at an address that unmap_mapping_range() has already processed? Interesting line of thought: nothing I think, but isn't that okay? Though its zap_pte can take out present ptes pointing to actual pages, all populate_range ever installs is non-present pte_file entries: and a fault on one of those goes through the same checks as in a linear mapping. (I thought I was going to find an inconsistency with zap_pte_range there, but no: truncation does not remove pte_file entries beyond end of file, I remember now thinking that we need to keep SIGBUS-beyond-EOF on them, instead of letting truncation silently revert those offsets to linear.) Or am I missing something? (Well, we know I am, because I've not explained Robert's BUG.) Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>