All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Pavel Emelyanov <xemul@virtuozzo.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH for 4.11] userfaultfd: report actual registered features in fdinfo
Date: Mon, 3 Apr 2017 18:10:24 +0300	[thread overview]
Message-ID: <20170403151024.GA14802@rapoport-lnx> (raw)
In-Reply-To: <20170403143523.GC5107@redhat.com>

On Mon, Apr 03, 2017 at 04:35:23PM +0200, Andrea Arcangeli wrote:
> On Sun, Apr 02, 2017 at 04:36:21PM +0300, Mike Rapoport wrote:
> > fdinfo for userfault file descriptor reports UFFD_API_FEATURES. Up until
> > recently, the UFFD_API_FEATURES was defined as 0, therefore corresponding
> > field in fdinfo always contained zero. Now, with introduction of several
> > additional features, UFFD_API_FEATURES is not longer 0 and it seems better
> > to report actual features requested for the userfaultfd object described by
> > the fdinfo. First, the applications that were using userfault will still
> > see zero at the features field in fdinfo. Next, reporting actual features
> > rather than available features, gives clear indication of what userfault
> > features are used by an application.
> > 
> > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
> > ---
> >  fs/userfaultfd.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> > index 1d227b0..f7555fc 100644
> > --- a/fs/userfaultfd.c
> > +++ b/fs/userfaultfd.c
> > @@ -1756,7 +1756,7 @@ static void userfaultfd_show_fdinfo(struct seq_file *m, struct file *f)
> >  	 *	protocols: aa:... bb:...
> >  	 */
> >  	seq_printf(m, "pending:\t%lu\ntotal:\t%lu\nAPI:\t%Lx:%x:%Lx\n",
> > -		   pending, total, UFFD_API, UFFD_API_FEATURES,
> > +		   pending, total, UFFD_API, ctx->features,
> >  		   UFFD_API_IOCTLS|UFFD_API_RANGE_IOCTLS);
> >  }
> >  #endif
> 
> Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
> 
> I wonder if we've been a bit overkill in showing these details in
> /proc as this innocent change is technically an ABI visible change
> now. It's intended only for informational/debug purposes, no software
> should attempt to decode it, so it'd be better in debugfs, but the
> per-thread fds aren't anywhere in debugfs so it's shown there where
> it's all already in place to provide it with a few liner function.
> 

Actually, I've found these details in /proc useful when I was experimenting
with checkpoint-restore of an application that uses userfaultfd. With
interface in /proc/<pid>/ we know exactly which process use userfaultfd and
can act appropriately.

--
Sincerely yours,
Mike.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-04-03 15:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-02 13:36 [PATCH for 4.11] userfaultfd: report actual registered features in fdinfo Mike Rapoport
2017-04-03 14:35 ` Andrea Arcangeli
2017-04-03 15:10   ` Mike Rapoport [this message]
2017-04-03 16:30     ` Andrea Arcangeli
2017-04-04  7:46       ` Mike Rapoport

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170403151024.GA14802@rapoport-lnx \
    --to=rppt@linux.vnet.ibm.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=xemul@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.