All of lore.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 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.