From: Andrew Morton <akpm@linux-foundation.org>
To: Ying Han <yinghan@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
menage@google.com, rientjes@google.com, rohitseth@google.com
Subject: Re: Make the get_user_pages interruptible
Date: Fri, 21 Nov 2008 14:50:43 -0800 [thread overview]
Message-ID: <20081121145043.0e4b2bf9.akpm@linux-foundation.org> (raw)
In-Reply-To: <604427e00811201403k26e4bf93tdb2dee9506756a82@mail.gmail.com>
On Thu, 20 Nov 2008 14:03:36 -0800
Ying Han <yinghan@google.com> wrote:
> make get_user_pages interruptible
> The initial implementation of checking TIF_MEMDIE covers the cases of OOM
> killing. If the process has been OOM killed, the TIF_MEMDIE is set and it
> return immediately. This patch includes:
>
> 1. add the case that the SIGKILL is sent by user processes. The process can
> try to get_user_pages() unlimited memory even if a user process has sent a
> SIGKILL to it(maybe a monitor find the process exceed its memory limit and
> try to kill it). In the old implementation, the SIGKILL won't be handled
> until the get_user_pages() returns.
>
> 2. change the return value to be ERESTARTSYS. It makes no sense to return
> ENOMEM if the get_user_pages returned by getting a SIGKILL signal.
> Considering the general convention for a system call interrupted by a
> signal is ERESTARTNOSYS, so the current return value is consistant to that.
>
> Signed-off-by: Paul Menage <menage@google.com>
> Ying Han <yinghan@google.com>
>
>
This isn't right?
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1218,12 +1218,11 @@ int __get_user_pages(struct task_struct *tsk, struct m
> struct page *page;
>
> /*
> - * If tsk is ooming, cut off its access to large memory
> - * allocations. It has a pending SIGKILL, but it can't
> - * be processed until returning to user space.
> + * If we have a pending SIGKILL, don't keep
> + * allocating memory.
> */
> - if (unlikely(test_tsk_thread_flag(tsk, TIF_MEMDIE)))
> - return i ? i : -ENOMEM;
> + if (sigkill_pending(current))
> + return -ERESTARTSYS;
>
> if (write)
> foll_flags |= FOLL_WRITE;
If this function has already put some page*'s into *pages, they will be
leaked. The function fails to release those pages and it does not
provide sufficient information to callers to allow them to release the
pages.
I thought I already mentioned that last time I saw this patch?
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Ying Han <yinghan@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
menage@google.com, rientjes@google.com, rohitseth@google.com
Subject: Re: Make the get_user_pages interruptible
Date: Fri, 21 Nov 2008 14:50:43 -0800 [thread overview]
Message-ID: <20081121145043.0e4b2bf9.akpm@linux-foundation.org> (raw)
In-Reply-To: <604427e00811201403k26e4bf93tdb2dee9506756a82@mail.gmail.com>
On Thu, 20 Nov 2008 14:03:36 -0800
Ying Han <yinghan@google.com> wrote:
> make get_user_pages interruptible
> The initial implementation of checking TIF_MEMDIE covers the cases of OOM
> killing. If the process has been OOM killed, the TIF_MEMDIE is set and it
> return immediately. This patch includes:
>
> 1. add the case that the SIGKILL is sent by user processes. The process can
> try to get_user_pages() unlimited memory even if a user process has sent a
> SIGKILL to it(maybe a monitor find the process exceed its memory limit and
> try to kill it). In the old implementation, the SIGKILL won't be handled
> until the get_user_pages() returns.
>
> 2. change the return value to be ERESTARTSYS. It makes no sense to return
> ENOMEM if the get_user_pages returned by getting a SIGKILL signal.
> Considering the general convention for a system call interrupted by a
> signal is ERESTARTNOSYS, so the current return value is consistant to that.
>
> Signed-off-by: Paul Menage <menage@google.com>
> Ying Han <yinghan@google.com>
>
>
This isn't right?
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1218,12 +1218,11 @@ int __get_user_pages(struct task_struct *tsk, struct m
> struct page *page;
>
> /*
> - * If tsk is ooming, cut off its access to large memory
> - * allocations. It has a pending SIGKILL, but it can't
> - * be processed until returning to user space.
> + * If we have a pending SIGKILL, don't keep
> + * allocating memory.
> */
> - if (unlikely(test_tsk_thread_flag(tsk, TIF_MEMDIE)))
> - return i ? i : -ENOMEM;
> + if (sigkill_pending(current))
> + return -ERESTARTSYS;
>
> if (write)
> foll_flags |= FOLL_WRITE;
If this function has already put some page*'s into *pages, they will be
leaked. The function fails to release those pages and it does not
provide sufficient information to callers to allow them to release the
pages.
I thought I already mentioned that last time I saw this patch?
--
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>
next prev parent reply other threads:[~2008-11-21 22:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-20 22:03 Make the get_user_pages interruptible Ying Han
2008-11-20 22:03 ` Ying Han
2008-11-21 22:50 ` Andrew Morton [this message]
2008-11-21 22:50 ` Andrew Morton
2008-11-21 23:24 ` David Rientjes
2008-11-21 23:24 ` David Rientjes
2008-11-22 0:06 ` Ying Han
2008-11-22 0:06 ` Ying Han
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=20081121145043.0e4b2bf9.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=menage@google.com \
--cc=rientjes@google.com \
--cc=rohitseth@google.com \
--cc=yinghan@google.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.