public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Momchil Velikov <velco@fadata.bg>
To: "David Gomez" <davidge@jazzfree.com>
Cc: Dave Jones <davej@suse.de>,
	Linux-kernel <linux-kernel@vger.kernel.org>,
	Marcelo Tosatti <marcelo@conectiva.com.br>
Subject: Re: Copying to loop device hangs up everything
Date: 16 Dec 2001 23:52:40 +0200	[thread overview]
Message-ID: <871yhu25p3.fsf@fadata.bg> (raw)
In-Reply-To: <Pine.LNX.4.33.0112162036370.475-100000@fargo> <877krnq70g.fsf@fadata.bg>
In-Reply-To: <877krnq70g.fsf@fadata.bg>

>>>>> "Momchil" == Momchil Velikov <velco@fadata.bg> writes:

>>>>> "David" == David Gomez <davidge@jazzfree.com> writes:
David> On 16 Dec 2001, Momchil Velikov wrote:

>>> [...]
>>> 
David> Thanks ;), this patch solves the problem and copying a lot of data to the
David> loop device now doesn't hang the computer.
>>> 
David> Is this patch going to be applied to the stable kernel ? Marcelo ?
>>> 
>>> I've had exactly the same hangups with or without the patch.

David> I've tested several times after applying the loop-deadlock patch and the
David> bug seems to be fixed. No more hangups while copying a lot of data to
David> loopback devices. Post more info about your hangups, maybe is another
David> different loop device deadlock.

Momchil> Maybe it's different I don't know. Looks like I've found a fix and in
Momchil> a minute I'll test _without_ the Andrea's patch and post whatever
Momchil> comes out of it.

It turned out that Andrea's patch is needed and it needs to be
augmented slightly.  The loop_thread can do the following:

loop_thread
-> do_bh_filebacked
-> lo_send
-> ...
->  kmem_cache_alloc
-> ...
-> shrink_cache
-> try_to_release_page
-> try_to_free_buffers
-> sync_page_buffers
-> __wait_on_buffer

And if the buffer must be flushed to the loopback device we deadlock.

The following patch is the Andrea's one + one additional change -- we
don't allow the loop_thread to wait in sync_page_buffers.

Regards,
-velco

diff -Nru a/drivers/block/loop.c b/drivers/block/loop.c
--- a/drivers/block/loop.c	Sun Dec 16 23:50:25 2001
+++ b/drivers/block/loop.c	Sun Dec 16 23:50:25 2001
@@ -578,6 +578,8 @@
 	atomic_inc(&lo->lo_pending);
 	spin_unlock_irq(&lo->lo_lock);
 
+	current->flags |= PF_NOIO;
+
 	/*
 	 * up sem, we are running
 	 */
diff -Nru a/fs/buffer.c b/fs/buffer.c
--- a/fs/buffer.c	Sun Dec 16 23:50:25 2001
+++ b/fs/buffer.c	Sun Dec 16 23:50:25 2001
@@ -1045,7 +1045,7 @@
 
 	/* First, check for the "real" dirty limit. */
 	if (dirty > soft_dirty_limit) {
-		if (dirty > hard_dirty_limit)
+		if (dirty > hard_dirty_limit && !(current->flags & PF_NOIO))
 			return 1;
 		return 0;
 	}
@@ -2448,6 +2448,8 @@
 		/* Second time through we start actively writing out.. */
 		if (test_and_set_bit(BH_Lock, &bh->b_state)) {
 			if (!test_bit(BH_launder, &bh->b_state))
+				continue;
+			if (current->flags & PF_NOIO)
 				continue;
 			wait_on_buffer(bh);
 			tryagain = 1;
diff -Nru a/include/linux/sched.h b/include/linux/sched.h
--- a/include/linux/sched.h	Sun Dec 16 23:50:25 2001
+++ b/include/linux/sched.h	Sun Dec 16 23:50:25 2001
@@ -426,6 +426,7 @@
 #define PF_MEMALLOC	0x00000800	/* Allocating memory */
 #define PF_MEMDIE	0x00001000	/* Killed for out-of-memory */
 #define PF_FREE_PAGES	0x00002000	/* per process page freeing */
+#define PF_NOIO		0x00004000	/* avoid generating further I/O */
 
 #define PF_USEDFPU	0x00100000	/* task used FPU this quantum (SMP) */
 

  reply	other threads:[~2001-12-16 22:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-16  3:40 Copying to loop device hangs up everything David Gomez
2001-12-16  4:00 ` Dave Jones
2001-12-16 11:41   ` David Gomez
2001-12-16 16:53     ` Momchil Velikov
2001-12-16 19:42       ` David Gomez
2001-12-16 19:50         ` Momchil Velikov
2001-12-16 21:52           ` Momchil Velikov [this message]
2001-12-18 19:46             ` Marcelo Tosatti
2001-12-18 20:54               ` Momchil Velikov
2001-12-18 19:57                 ` Marcelo Tosatti
2001-12-18 21:26                   ` Momchil Velikov
     [not found]                   ` <3C1FC254.525B9108@zip.com.au>
     [not found]                     ` <3C1FCB96.83E49ECB@zip.com.au>
     [not found]                       ` <3C204C4F.C989AD71@zip.com.au>
2001-12-19 13:42                         ` Andrea Arcangeli
2001-12-20  7:41                           ` Andrew Morton
2001-12-20 11:27                             ` Andrea Arcangeli
2001-12-20 11:34                               ` Andrea Arcangeli
2001-12-17  3:30       ` Dave Jones
  -- strict thread matches above, loose matches on Subject: below --
2001-12-20 21:05 Momchil Velikov

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=871yhu25p3.fsf@fadata.bg \
    --to=velco@fadata.bg \
    --cc=davej@suse.de \
    --cc=davidge@jazzfree.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /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