linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: [LSF/MM TOPIC] Page fault locking
Date: Mon, 17 Mar 2014 21:17:21 +0100	[thread overview]
Message-ID: <20140317201721.GA8743@quack.suse.cz> (raw)

  Hello,

  so this is a continuation of the topic we spoke about at last LSF/MM
(http://lwn.net/Articles/548098/) about problems filesystems have with
mmap_sem held over page fault. Over the year I have slowly worked through
get_user_pages() users and was converting them to hide mmap_sem locking
inside helpers. Some of the patches were merged, some patches still just
sit in my queue (but most of them is luckily trivial), I've sent out
probably the most complex part - conversion of video4linux2 core - today.

What I'm interested in is:
1) Some feedback regarding the proposed get_vaddr_pfn() helper function.
2) Discuss changes of get_user_pages() function - my idea is that all users
   that need non-trivial locking should use __get_user_pages() (so far
   there are about 8 such callers after my series). get_user_pages() call
   will now grab mmap_sem on its own.
3) Overview remaining call sites of get_user_pages() with non-trivial
   locking - at some places I think we could change the locking so that
   they could use get_user_pages() variant which takes care of grabbing
   mmap_sem. Also I have one place (yes, the only place in the whole
   kernel) in kernel/events/uprobes.c where it's not clear to me how to
   handle situation if fault handler would drop mmap_sem. So I'd like to
   bounce that off the people in the room in case someone comes up with
   anything clever.

								Honza

-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

--
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:[~2014-03-17 20:17 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20140317201721.GA8743@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).