Skip to content
Snippets Groups Projects
  • Linus Torvalds's avatar
    d92007e4
    mm: avoid leaving partial pfn mappings around in error case · d92007e4
    Linus Torvalds authored and Frieder Schrempf's avatar Frieder Schrempf committed
    
    commit 79a61cc3 upstream.
    
    As Jann points out, PFN mappings are special, because unlike normal
    memory mappings, there is no lifetime information associated with the
    mapping - it is just a raw mapping of PFNs with no reference counting of
    a 'struct page'.
    
    That's all very much intentional, but it does mean that it's easy to
    mess up the cleanup in case of errors.  Yes, a failed mmap() will always
    eventually clean up any partial mappings, but without any explicit
    lifetime in the page table mapping itself, it's very easy to do the
    error handling in the wrong order.
    
    In particular, it's easy to mistakenly free the physical backing store
    before the page tables are actually cleaned up and (temporarily) have
    stale dangling PTE entries.
    
    To make this situation less error-prone, just make sure that any partial
    pfn mapping is torn down early, before any other error handling.
    
    Reported-and-tested-by: default avatarJann Horn <jannh@google.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Jason Gunthorpe <jgg@ziepe.ca>
    Cc: Simona Vetter <simona.vetter@ffwll.ch>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    d92007e4
    History
    mm: avoid leaving partial pfn mappings around in error case
    Linus Torvalds authored and Frieder Schrempf's avatar Frieder Schrempf committed
    
    commit 79a61cc3 upstream.
    
    As Jann points out, PFN mappings are special, because unlike normal
    memory mappings, there is no lifetime information associated with the
    mapping - it is just a raw mapping of PFNs with no reference counting of
    a 'struct page'.
    
    That's all very much intentional, but it does mean that it's easy to
    mess up the cleanup in case of errors.  Yes, a failed mmap() will always
    eventually clean up any partial mappings, but without any explicit
    lifetime in the page table mapping itself, it's very easy to do the
    error handling in the wrong order.
    
    In particular, it's easy to mistakenly free the physical backing store
    before the page tables are actually cleaned up and (temporarily) have
    stale dangling PTE entries.
    
    To make this situation less error-prone, just make sure that any partial
    pfn mapping is torn down early, before any other error handling.
    
    Reported-and-tested-by: default avatarJann Horn <jannh@google.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Jason Gunthorpe <jgg@ziepe.ca>
    Cc: Simona Vetter <simona.vetter@ffwll.ch>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>