All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Davidlohr Bueso <dave@stgolabs.net>, Oleg Nesterov <oleg@redhat.com>
Cc: akpm@linux-foundation.org, hughd@google.com, riel@redhat.com,
	mgorman@suse.de, peterz@infradead.org, mingo@kernel.org,
	linux-kernel@vger.kernel.org, dbueso@suse.de, linux-mm@kvack.org
Subject: Re: [PATCH 05/10] uprobes: share the i_mmap_rwsem
Date: Mon, 27 Oct 2014 12:33:29 +0530	[thread overview]
Message-ID: <20141027070329.GA10867@linux.vnet.ibm.com> (raw)
In-Reply-To: <1414188380-17376-6-git-send-email-dave@stgolabs.net>

* Davidlohr Bueso <dave@stgolabs.net> [2014-10-24 15:06:15]:

> Both register and unregister call build_map_info() in order
> to create the list of mappings before installing or removing
> breakpoints for every mm which maps file backed memory. As
> such, there is no reason to hold the i_mmap_rwsem exclusively,
> so share it and allow concurrent readers to build the mapping
> data.
> 
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>


Copying Oleg (since he should have been copied on this one)

Please see one comment below.

Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> 

> ---
>  kernel/events/uprobes.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 045b649..7a9e620 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -724,7 +724,7 @@ build_map_info(struct address_space *mapping, loff_t offset, bool is_register)
>  	int more = 0;
>  
>   again:
> -	i_mmap_lock_write(mapping);
> +	i_mmap_lock_read(mapping);
>  	vma_interval_tree_foreach(vma, &mapping->i_mmap, pgoff, pgoff) {
>  		if (!valid_vma(vma, is_register))
>  			continue;


Just after this, we have
if (!prev && !more) {
	/*
	 * Needs GFP_NOWAIT to avoid i_mmap_mutex recursion through
	 * reclaim. This is optimistic, no harm done if it fails.
	 */
	prev = kmalloc(sizeof(struct map_info),
			GFP_NOWAIT | __GFP_NOMEMALLOC | __GFP_NOWARN);
	if (prev)
		prev->next = NULL;
}

However in patch 02/10
I dont think the comment referring to i_mmap_mutex was modified to
refer i_mmap_lock_write.

When thats taken care off, this patch should change that part accordingly.


-- 
Thanks and Regards
Srikar Dronamraju

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Davidlohr Bueso <dave@stgolabs.net>, Oleg Nesterov <oleg@redhat.com>
Cc: akpm@linux-foundation.org, hughd@google.com, riel@redhat.com,
	mgorman@suse.de, peterz@infradead.org, mingo@kernel.org,
	linux-kernel@vger.kernel.org, dbueso@suse.de, linux-mm@kvack.org
Subject: Re: [PATCH 05/10] uprobes: share the i_mmap_rwsem
Date: Mon, 27 Oct 2014 12:33:29 +0530	[thread overview]
Message-ID: <20141027070329.GA10867@linux.vnet.ibm.com> (raw)
In-Reply-To: <1414188380-17376-6-git-send-email-dave@stgolabs.net>

* Davidlohr Bueso <dave@stgolabs.net> [2014-10-24 15:06:15]:

> Both register and unregister call build_map_info() in order
> to create the list of mappings before installing or removing
> breakpoints for every mm which maps file backed memory. As
> such, there is no reason to hold the i_mmap_rwsem exclusively,
> so share it and allow concurrent readers to build the mapping
> data.
> 
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>


Copying Oleg (since he should have been copied on this one)

Please see one comment below.

Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> 

> ---
>  kernel/events/uprobes.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 045b649..7a9e620 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -724,7 +724,7 @@ build_map_info(struct address_space *mapping, loff_t offset, bool is_register)
>  	int more = 0;
>  
>   again:
> -	i_mmap_lock_write(mapping);
> +	i_mmap_lock_read(mapping);
>  	vma_interval_tree_foreach(vma, &mapping->i_mmap, pgoff, pgoff) {
>  		if (!valid_vma(vma, is_register))
>  			continue;


Just after this, we have
if (!prev && !more) {
	/*
	 * Needs GFP_NOWAIT to avoid i_mmap_mutex recursion through
	 * reclaim. This is optimistic, no harm done if it fails.
	 */
	prev = kmalloc(sizeof(struct map_info),
			GFP_NOWAIT | __GFP_NOMEMALLOC | __GFP_NOWARN);
	if (prev)
		prev->next = NULL;
}

However in patch 02/10
I dont think the comment referring to i_mmap_mutex was modified to
refer i_mmap_lock_write.

When thats taken care off, this patch should change that part accordingly.


-- 
Thanks and Regards
Srikar Dronamraju


  reply	other threads:[~2014-10-27  7:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24 22:06 [PATCH 00/10] mm: improve usage of the i_mmap lock Davidlohr Bueso
2014-10-24 22:06 ` Davidlohr Bueso
2014-10-24 22:06 ` [PATCH 01/10] mm,fs: introduce helpers around the i_mmap_mutex Davidlohr Bueso
2014-10-24 22:06   ` Davidlohr Bueso
2014-10-24 22:06 ` [PATCH 02/10] mm: use new helper functions " Davidlohr Bueso
2014-10-24 22:06   ` Davidlohr Bueso
2014-10-24 22:06 ` [PATCH 03/10] mm: convert i_mmap_mutex to rwsem Davidlohr Bueso
2014-10-24 22:06   ` Davidlohr Bueso
2014-10-24 22:45   ` Kirill A. Shutemov
2014-10-24 22:45     ` Kirill A. Shutemov
2014-10-28 20:27     ` Davidlohr Bueso
2014-10-28 20:27       ` Davidlohr Bueso
2014-10-24 22:06 ` [PATCH 04/10] mm/rmap: share the i_mmap_rwsem Davidlohr Bueso
2014-10-24 22:06   ` Davidlohr Bueso
2014-10-24 22:06 ` [PATCH 05/10] uprobes: " Davidlohr Bueso
2014-10-24 22:06   ` Davidlohr Bueso
2014-10-27  7:03   ` Srikar Dronamraju [this message]
2014-10-27  7:03     ` Srikar Dronamraju
2014-10-28  2:02     ` Oleg Nesterov
2014-10-28  2:02       ` Oleg Nesterov
2014-10-24 22:06 ` [PATCH 06/10] mm/xip: " Davidlohr Bueso
2014-10-24 22:06   ` Davidlohr Bueso
2014-10-24 22:06 ` [PATCH 07/10] mm/memory-failure: " Davidlohr Bueso
2014-10-24 22:06   ` Davidlohr Bueso
2014-10-24 22:06 ` [PATCH 08/10] mm/mremap: " Davidlohr Bueso
2014-10-24 22:06   ` Davidlohr Bueso
2014-10-24 22:06 ` [PATCH 09/10] mm/nommu: " Davidlohr Bueso
2014-10-24 22:06   ` Davidlohr Bueso
2014-10-24 22:16 ` [PATCH 10/10] mm/hugetlb: " Davidlohr Bueso
2014-10-24 22:16   ` Davidlohr Bueso
2014-10-28 14:08 ` [PATCH 00/10] mm: improve usage of the i_mmap lock Kirill A. Shutemov
2014-10-28 14:08   ` Kirill A. Shutemov
  -- strict thread matches above, loose matches on Subject: below --
2014-10-30 19:34 [PATCH v2 -next " Davidlohr Bueso
2014-10-30 19:34 ` [PATCH 05/10] uprobes: share the i_mmap_rwsem Davidlohr Bueso

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=20141027070329.GA10867@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave@stgolabs.net \
    --cc=dbueso@suse.de \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.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.