All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH v2.6.36-rc7] init: don't call flush_scheduled_work() from do_initcalls()
Date: Fri, 22 Oct 2010 10:27:06 +0200	[thread overview]
Message-ID: <4CC14ADA.9080706@kernel.org> (raw)
In-Reply-To: <20101021171203.37d0d6d6.akpm@linux-foundation.org>

Hello,

On 10/22/2010 02:12 AM, Andrew Morton wrote:
>> Index: work/init/main.c
>> ===================================================================
>> --- work.orig/init/main.c
>> +++ work/init/main.c
>> @@ -778,9 +778,6 @@ static void __init do_initcalls(void)
>>
>>  	for (fn = __early_initcall_end; fn < __initcall_end; fn++)
>>  		do_one_initcall(*fn);
>> -
>> -	/* Make sure there is no pending stuff from the initcall sequence */
>> -	flush_scheduled_work();
>>  }
>>
> 
> hm, that predates the initial 2002 BK tree.
> 
> If some initcall function leaves a work scheduled and doesn't flush it
> then free_initmem() can come along and pull the rug out from under its
> feet.  Then you will own both pieces :)

Ah, okay, so that's the rationale behind it.  That at least explains
why it made sense back then.  :-)

I don't think it makes much sense anymore tho for the following
reasons.

* As I wrote in the patch description, there are many other workqueues
  and, after auditing many workqueue users in kernel, my impression is
  that switching to different or dedicated workqueues is done quite
  casually and I've never seen any caller which notes explicit
  dependency on the auto flush behvaior.

* I don't think using workqueue that way is common and we already have
  a specialized mechanism for parallel probing - async - which has
  well defined flushing/ordering behavior during booting.

* System workqueue now can happily host long running works.  We can
  end up sitting there for undetermined amount of time.

> If you really don't like people sending you angry emails then I suppose
> you could add some warning here if a scheduled work is pending, and
> that the scheduled work's callback existed in init.text memory.  Which
> would be a bit of a pain to implement.
> 
> Oh well.  The oops traces will make it fairly clear what happened.

I haven't pushed the patch to Linus yet.  I'll remove it for now and
try to implement something which at least checks the text section of
pending and running works.

Thanks.

-- 
tejun

  reply	other threads:[~2010-10-22  8:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-15 15:13 [PATCH v2.6.36-rc7] init: don't call flush_scheduled_work() from do_initcalls() Tejun Heo
2010-10-19 15:28 ` Tejun Heo
2010-10-22  0:12 ` Andrew Morton
2010-10-22  8:27   ` Tejun Heo [this message]
2010-10-22 18:09     ` Andrew Morton
2010-11-03 10:59       ` Tejun Heo
2010-11-03 12:48         ` Andrew Morton

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=4CC14ADA.9080706@kernel.org \
    --to=tj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@linux-foundation.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.