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.
Hmm, is there anything preventing remap_file_pages() installing a pte
at an address that unmap_mapping_range() has already processed?
Thanks,
Miklos
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. 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@kvack.org"> email@kvack.org </a>
On Wed, 15 Dec 2010, Miklos Szeredi wrote:
On Tue, 14 Dec 2010, Hugh Dickins wrote:
quoted
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@kvack.org. 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@kvack.org"> email@kvack.org </a>