Re: Oops in pdflush

From: Andrew Morton <>
Date: 2004-02-28 21:23:23
Keith Owens <> wrote:
>  >So if I'm reading this right, we get a case that looks like unbounded
>  >recursion:
>  >
>  >	pdflush -> start_one_pdflush_thread -> kernel_thread -> pdflush ...
>  >

Yes.  Ow.  Thanks.

>  >Except, I don't think this is real recursion.  Instead, we effectively
>  >get a (potentially unbounded) sequence of one kernel thread creating
>  >another thread.  Each new kernel thread gets nested one deeper,
>  >eventually leading to a stack overflow...
>  >
>  >Hmmh, I think perhaps the right way to fix this is to use a separate
>  >continuation function, which will then take care of doing the
>  >child-specific actions.  Let me see if I can come up with something.
>  Separate the pdflush thread creation and move it to a single master
>  thread.  This restricts the maximum stack depth already in use when
>  starting a worker pdflush thread.

We should use the new kthread infrastructure rather than open-coding it. 
It delegates thread startup to keventd and should thus avoid the stack

I'll take a look at this over the weekend unless someone else tell me
they're doing it.

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Sat Feb 28 05:23:21 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:23 EST