All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: OK to set PF_MEMDIE on cleanup tasks?
Date: Thu, 16 Oct 2003 10:10:45 -0700	[thread overview]
Message-ID: <20031016171045.GA3012@us.ibm.com> (raw)
In-Reply-To: <20031014171227.014f0d2f.akpm@osdl.org>

Hello, Andrew,

On Tue, Oct 14, 2003 at 05:12:27PM -0700, Andrew Morton wrote:
> > So...  Is it considered legit to simply set PF_MEMDIE when creating
> > the cleanup task?  Or is there some reason that one should deal with
> > signal 15?
> 
> Well it's all very unconventional.  Catching SIGTERM seems like a suitable
> way to do what you want to do.

OK, since this particular case is a strictly in-kernel task, SIGTERM
should be a no-op anyway.  Unless I am missing something in the signal
delivery code, which is quite probable.  ;-)

So the magic code would then be:

	cap_raise(current->cap_effective, CAP_SYS_RAWIO);

perhaps with:

	cap_raise(current->cap_effective, CAP_SYS_ADMIN);

thrown in for good measure.

> Possibly your special process should also run as PF_MEMALLOC.  I've seen
> that done before, with success.  There is no existing API with which this
> can be set.

This would certainly head off at least some OOM deadlock situations.
On the (perhaps unlikely) chance that this was an invitation, here
is a patch to create an API.

					Thanx, Paul

diff -urN -X /home/linux/2.5/dontdiff linux-2.6.0-test7-mm1/include/linux/sched.h linux-2.6.0-test7-mm1-PF_MEMALLOC/include/linux/sched.h
--- linux-2.6.0-test7-mm1/include/linux/sched.h	2003-10-16 07:16:05.000000000 -0700
+++ linux-2.6.0-test7-mm1-PF_MEMALLOC/include/linux/sched.h	2003-10-16 09:20:34.000000000 -0700
@@ -508,6 +508,27 @@
 #define PF_LESS_THROTTLE 0x00100000	/* Throttle me less: I clean memory */
 #define PF_SYNCWRITE	0x00200000	/* I am doing a sync write */
 
+/**
+ * mark_task_memalloc - mark the specified task as deserving of preferential
+ * access to free memory.  Note that with great power comes great
+ * responsibility.
+ * @p: the task structure to be granted preferential access.
+ */
+static inline void mark_task_memalloc(task_t *p)
+{
+	p->flags |= PF_MEMALLOC;
+}
+
+/**
+ * unmark_task_memalloc - mark the specified task as no longer deserving
+ * of preferential access to free memory.
+ * @p: the task structure to have its preferential access revoked.
+ */
+static inline void unmark_task_memalloc(task_t *p)
+{
+	p->flags &= ~PF_MEMALLOC;
+}
+
 #ifdef CONFIG_SMP
 extern int set_cpus_allowed(task_t *p, cpumask_t new_mask);
 #else

      parent reply	other threads:[~2003-10-17  0:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-14 15:17 OK to set PF_MEMDIE on cleanup tasks? Paul E. McKenney
2003-10-15  0:12 ` Andrew Morton
2003-10-15  1:34   ` Gerrit Huizenga
2003-10-16 17:10   ` Paul E. McKenney [this message]

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=20031016171045.GA3012@us.ibm.com \
    --to=paulmck@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.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 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.