From: Andrew Morton <akpm@osdl.org>
To: Zou Nan hai <nanhai.zou@intel.com>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [Patch] jbd commit code deadloop when installing Linux
Date: Wed, 28 Jun 2006 00:40:29 -0700 [thread overview]
Message-ID: <20060628004029.efcc8a03.akpm@osdl.org> (raw)
In-Reply-To: <1151473582.6052.28.camel@linux-znh>
On 28 Jun 2006 13:46:22 +0800
Zou Nan hai <nanhai.zou@intel.com> wrote:
> On Wed, 2006-06-28 at 14:55, Andrew Morton wrote:
> > On Wed, 28 Jun 2006 08:38:59 +0200
> > Ingo Molnar <mingo@elte.hu> wrote:
> >
> > >
> > > * Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > > > We see system hang in ext3 jbd code
> > > > > when Linux install program anaconda copying
> > > > > packages.
> > > > >
> > > > > That is because anaconda is invoked from linuxrc
> > > > > in initrd when system_state is still SYSTEM_BOOTING.
> > >
> > > [ argh ...! ]
> >
> > That's what I thought ;)
> >
> > > > > Thus the cond_resched checks in journal_commit_transaction
> > > > > will always return 1 without actually schedule,
> > > > > then the system fall into deadloop.
> > > >
> > > > That's a bug in cond_resched().
> > > >
> > > > Something like this..
> > >
> > > Acked-by: Ingo Molnar <mingo@elte.hu>
> > >
> >
> > Thanks. Zou, it'd be great if you could test this in your setup, please.
> > I've tagged it as 2.6.17.x material.
>
> Andrew,
> I am building the env to test.
> The patch was my original idea, but I was afraid of breaking any code
> that rely on the OLD wrong cond_sched semantic.
We prefer the "right" fix, however painful or risky that might be.
> However later I did a
> grep found that there is very few code that checks the return value of
> cond_resched. So the patch should be safe.
Hope so.
> However I think cond_resched_lock and cond_resched_softirq also need fix
> to make the semantic consistent.
>
> Please check the following patch.
>
Ah. I think the return value from these functions should mean "something
disruptive happened", if you like.
See, the callers of cond_resched_lock() aren't interested in whether
cond_resched_lock() actually called schedule(). They want to know whether
cond_resched_lock() dropped the lock. Because if the lock was dropped, the
caller needs to take some special action, regardless of whether schedule()
was finally called.
So I think the patch I queued is OK, agree?
next prev parent reply other threads:[~2006-06-28 7:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-28 4:48 [Patch] jbd commit code deadloop when installing Linux Zou Nan hai
2006-06-28 6:40 ` Andrew Morton
2006-06-28 6:38 ` Ingo Molnar
2006-06-28 6:55 ` Andrew Morton
2006-06-28 5:46 ` Zou Nan hai
2006-06-28 7:39 ` Ingo Molnar
2006-06-28 7:40 ` Andrew Morton [this message]
2006-06-28 6:02 ` Zou Nan hai
2006-06-28 8:04 ` Andrew Morton
2006-06-28 6:50 ` Zou Nan hai
2006-06-28 8:45 ` Andrew Morton
2006-06-28 7:14 ` Zou Nan hai
2006-06-28 9:29 ` Ingo Molnar
2006-06-28 7:55 ` Ingo Molnar
2006-06-28 9:10 ` Arjan van de Ven
2006-06-28 7:32 ` Zou Nan hai
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=20060628004029.efcc8a03.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nanhai.zou@intel.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.