Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1678637

Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery

From Michal Hocko <mhocko@kernel.org>
Newsgroups linux.kernel
Subject Re: [RFC PATCH] userfaultfd: Add feature to request for a signal delivery
Date 2017-06-30 11:50 +0200
Message-ID <tY0IN-3Mu-3@gated-at.bofh.it> (permalink)
References (3 earlier) <tX1dV-2UD-45@gated-at.bofh.it> <tXl2W-7fD-19@gated-at.bofh.it> <tXpSX-V2-31@gated-at.bofh.it> <tXCGt-56U-3@gated-at.bofh.it> <tXPu3-4Pd-35@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[CC John, the thread started
http://lkml.kernel.org/r/9363561f-a9cd-7ab6-9c11-ab9a99dc89f1@oracle.com]

On Thu 29-06-17 14:41:22, prakash.sangappa wrote:
> 
> 
> On 06/29/2017 01:09 AM, Michal Hocko wrote:
> >On Wed 28-06-17 11:23:32, Prakash Sangappa wrote:
> >>
> >>On 6/28/17 6:18 AM, Mike Rapoport wrote:
> >[...]
> >>>I've just been thinking that maybe it would be possible to use
> >>>UFFD_EVENT_REMOVE for this case. We anyway need to implement the generation
> >>>of UFFD_EVENT_REMOVE for the case of hole punching in hugetlbfs for
> >>>non-cooperative userfaultfd. It could be that it will solve your issue as
> >>>well.
> >>>
> >>Will this result in a signal delivery?
> >>
> >>In the use case described, the database application does not need any event
> >>for  hole punching. Basically, just a signal for any invalid access to
> >>mapped area over holes in the file.
> >OK, but it would be better to think that through for other potential
> >usecases so that this doesn't end up as a single hugetlb feature. E.g.
> >what should happen if a regular anonymous memory gets swapped out?
> >Should we deliver signal as well? How does userspace tell whether this
> >was a no backing page from unavailable backing page?
> 
> This may not be useful in all cases. Potential, it could be used
> with use of mlock() on anonymous memory to ensure any access
> to memory that is not locked is caught, again for robustness
> purpose.

The thing I wanted to point out is that not only this should be a single
usecase thing (I believe others will pop out as well - see below) but it
should also be well defined as this is a user visible API. Please try to
write a patch to the userfaultfd man page to clarify the exact semantic.
This should help the further discussion.

As an aside, I rememeber that prior to MADV_FREE there was long
discussion about lazy freeing of memory from userspace. Some users
wanted to be signalled when their memory was freed by the system so that
they could rebuild the original content (e.g. uncompressed images in
memory). It seems like MADV_FREE + this signalling could be used for
that usecase. John would surely know more about those usecases.
-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH] userfaultfd: Add feature to request for a signal delivery Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-06-26 21:50 +0200
  Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery Michal Hocko <mhocko@kernel.org> - 2017-06-27 09:10 +0200
    Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery Mike Rapoport <rppt@linux.vnet.ibm.com> - 2017-06-27 17:40 +0200
      Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-06-27 18:10 +0200
        Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery Mike Rapoport <rppt@linux.vnet.ibm.com> - 2017-06-28 15:20 +0200
          Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-06-28 20:30 +0200
            Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery Michal Hocko <mhocko@kernel.org> - 2017-06-29 10:10 +0200
              Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery "prakash.sangappa" <prakash.sangappa@oracle.com> - 2017-06-29 23:50 +0200
                Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery Michal Hocko <mhocko@kernel.org> - 2017-06-30 11:50 +0200
                Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery Andrea Arcangeli <aarcange@redhat.com> - 2017-06-30 15:10 +0200
                Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery prakash sangappa <prakash.sangappa@oracle.com> - 2017-07-01 03:00 +0200
            Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery Mike Rapoport <rppt@linux.vnet.ibm.com> - 2017-06-29 12:50 +0200
              Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery "prakash.sangappa" <prakash.sangappa@oracle.com> - 2017-06-29 23:50 +0200
    Re: [RFC PATCH] userfaultfd: Add feature to request for a signal  delivery Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-06-27 17:50 +0200

csiph-web