All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uli Luckas <u.luckas@road.de>
To: linux-mtd@lists.infradead.org
Cc: David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] jffs2_gcd_mtd3, Stopping kernel threads timed out
Date: Tue, 26 Jun 2007 17:34:24 +0200	[thread overview]
Message-ID: <200706261734.25107.u.luckas@road.de> (raw)
In-Reply-To: <1182863977.19501.4.camel@weaponx.rchland.ibm.com>

On Tuesday, 26. June 2007, Josh Boyer wrote:
> On Tue, 2007-06-26 at 15:06 +0200, Uli Luckas wrote:
> > On Tuesday, 19. June 2007, Uli Luckas wrote:
> > > Hi,
> > > is there anything in the way of apllying this patch?
> >
> > Please, can someone tell me what it takes to get a jffs2 bug fix into the
> > kernel? Or even reviewed? This patch should even get into 2.6.22. Am I
> > doing something wrong here?
>
> You aren't doing anything wrong.  David is away on business.
>
does that mean, we won't get any fixes applied, before David is back? And does 
anyone know, when he will be back?

> The one thing I would hesitate with about your patch is that you've now
> broken the existing behavior of the thread in regards to SIGHUP.  You
> used to be able to send the threads a SIGHUP and it would do a single
> pass.  With your patch, it won't do that unless the thresholds are
> right.  Being able to send SIGHUP to force a GC pass is a pretty useful
> thing for debugging, etc.
>
thanks Josh, alot for reviewing the patch. Following your advise, I force GC 
now, if SIGHUP was received.
The patch still introduces a change in sematics though for all other signals 
(except SIGKILL). But I feel, the new behavior is more what one would expect. 
In case, the old behavior is desired, it is simple enough to set force_gc in 
the coresponding branches.

regards,
Uli

Signed-off-by: Uli Luckas <u.luckas@road.de>

diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c
index 888f236..1843786 100644
--- a/fs/jffs2/background.c
+++ b/fs/jffs2/background.c
@@ -71,6 +71,7 @@ void jffs2_stop_garbage_collect_thread(struct jffs2_sb_info *c)
 
 static int jffs2_garbage_collect_thread(void *_c)
 {
+	int force_gc;
 	struct jffs2_sb_info *c = _c;
 
 	daemonize("jffs2_gcd_mtd%d", c->mtd->index);
@@ -96,9 +97,6 @@ static int jffs2_garbage_collect_thread(void *_c)
 			schedule();
 		}
 
-		if (try_to_freeze())
-			continue;
-
 		/* This thread is purely an optimisation. But if it runs when
 		   other things could be running, it actually makes things a
 		   lot worse. Use yield() and put it at the back of the runqueue
@@ -109,10 +107,14 @@ static int jffs2_garbage_collect_thread(void *_c)
 
 		/* Put_super will send a SIGKILL and then wait on the sem.
 		 */
+		force_gc = 0;
 		while (signal_pending(current)) {
 			siginfo_t info;
 			unsigned long signr;
 
+			if (try_to_freeze())
+				continue;
+
 			signr = dequeue_signal_lock(current, &current->blocked, &info);
 
 			switch(signr) {
@@ -128,6 +130,7 @@ static int jffs2_garbage_collect_thread(void *_c)
 
 			case SIGHUP:
 				D1(printk(KERN_DEBUG "jffs2_garbage_collect_thread(): SIGHUP received.\n"));
+				force_gc = 1;
 				break;
 			default:
 				D1(printk(KERN_DEBUG "jffs2_garbage_collect_thread(): signal %ld received\n", signr));
@@ -137,7 +140,8 @@ static int jffs2_garbage_collect_thread(void *_c)
 		disallow_signal(SIGHUP);
 
 		D1(printk(KERN_DEBUG "jffs2_garbage_collect_thread(): pass\n"));
-		if (jffs2_garbage_collect_pass(c) == -ENOSPC) {
+		if ((force_gc || jffs2_thread_should_wake(c))
+		     && jffs2_garbage_collect_pass(c) == -ENOSPC) {
 			printk(KERN_NOTICE "No space for garbage collection. Aborting GC thread\n");
 			goto die;
 		}

-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing directors: Hans-Peter Constien, Hubertus von Streit

  reply	other threads:[~2007-06-26 15:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-14 13:09 [PATCH] jffs2_gcd_mtd3, Stopping kernel threads timed out Uli Luckas
2007-06-19  9:49 ` Uli Luckas
2007-06-26 13:06   ` Uli Luckas
2007-06-26 13:19     ` Josh Boyer
2007-06-26 15:34       ` Uli Luckas [this message]
     [not found]       ` <200706261639.49486.u.luckas@road.de>
2007-06-26 15:36         ` [PATCH][update] " Josh Boyer
2007-06-27  7:53           ` Uli Luckas
2007-06-28 18:52 ` [PATCH] " David Woodhouse
2007-06-29  8:24   ` Uli Luckas
2007-06-29  8:28     ` David Woodhouse
2007-06-29  8:59       ` Uli Luckas
2007-07-24  7:35   ` Uli Luckas
  -- strict thread matches above, loose matches on Subject: below --
2007-06-12 12:58 Uli Luckas
2007-06-12 12:13 Uli Luckas

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=200706261734.25107.u.luckas@road.de \
    --to=u.luckas@road.de \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.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.