lkml.org 
[lkml]   [2021]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v1 5/7] mm: introduce page_offline_(begin|end|freeze|unfreeze) to synchronize setting PageOffline()
    On Wed, May 05, 2021 at 05:10:33PM +0200, David Hildenbrand wrote:
    > On 05.05.21 15:24, Michal Hocko wrote:
    > > On Thu 29-04-21 14:25:17, David Hildenbrand wrote:
    > > > A driver might set a page logically offline -- PageOffline() -- and
    > > > turn the page inaccessible in the hypervisor; after that, access to page
    > > > content can be fatal. One example is virtio-mem; while unplugged memory
    > > > -- marked as PageOffline() can currently be read in the hypervisor, this
    > > > will no longer be the case in the future; for example, when having
    > > > a virtio-mem device backed by huge pages in the hypervisor.
    > > >
    > > > Some special PFN walkers -- i.e., /proc/kcore -- read content of random
    > > > pages after checking PageOffline(); however, these PFN walkers can race
    > > > with drivers that set PageOffline().
    > > >
    > > > Let's introduce page_offline_(begin|end|freeze|unfreeze) for
    > > > synchronizing.
    > > >
    > > > page_offline_freeze()/page_offline_unfreeze() allows for a subsystem to
    > > > synchronize with such drivers, achieving that a page cannot be set
    > > > PageOffline() while frozen.
    > > >
    > > > page_offline_begin()/page_offline_end() is used by drivers that care about
    > > > such races when setting a page PageOffline().
    > > >
    > > > For simplicity, use a rwsem for now; neither drivers nor users are
    > > > performance sensitive.
    > >
    > > Please add a note to the PageOffline documentation as well. While are
    > > adding the api close enough an explicit note there wouldn't hurt.
    >
    > Will do.
    >
    > >
    > > > Signed-off-by: David Hildenbrand <david@redhat.com>
    > >
    > > As to the patch itself, I am slightly worried that other pfn walkers
    > > might be less tolerant to the locking than the proc ones. On the other
    > > hand most users shouldn't really care as they do not tend to touch the
    > > memory content and PageOffline check without any synchronization should
    > > be sufficient for those. Let's try this out and see where we get...
    >
    > My thinking. Users that actually read random page content (as discussed in
    > the cover letter) are
    >
    > 1. Hibernation
    > 2. Dumping (/proc/kcore, /proc/vmcore)
    > 3. Physical memory access bypassing the kernel via /dev/mem
    > 4. Live debug tools (kgdb)

    I think you can add

    5. Very old drivers

    > Other PFN walkers really shouldn't (and don't) access random page content.
    >
    > Thanks!
    >
    > --
    > Thanks,
    >
    > David / dhildenb
    >
    >

    --
    Sincerely yours,
    Mike.

    \
     
     \ /
      Last update: 2021-05-05 19:44    [W:3.541 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site