RE: Why yield in coredump_wait? [was: Re: Resent: BUG in RT 45-01 whenRT program dumps core]

[kus Kusche Klaus]

> In the function coredump_wait there's a yield called:
> 
> static void coredump_wait(struct mm_struct *mm)
> {
> [...]
>         /* give other threads a chance to run: */
>         yield();
> 
>         zap_threads(mm);
> [...]
> 
> I don't see any reason for this.  Although the comment says 
> it's giving
> other threads a chance to run, but the zap_threads below it will just
> send a kill signal to all those sharing the mm and then this 
> thread will
> wait for completion (if there were threads to wait on).
> 
> Now if there were no other threads to wait on it would just continue.
> So, is there some real reason that this yield is there? Or is it just
> trying to be nice, as in saying, "I'm dieing now and just 
> don't want to
> waste others time" (which I highly doubt is the case).
> 
> The reason I'm asking this, is that RT tasks should not call yield,
> since it is pretty much meaningless, since an RT task won't 
> yield to any
> task of lesser priority, and in Ingo's current kernel the yield will
> send a bug message if it was called by an RT task.
> 
> Thanks,
> 
> -- Steve

Does that mean that the core dump is written 
with the rt prio of the task which dumps?

I'm not sure if this is a good idea: 
Dumping a big core might take *ages* (at least w.r.t. realtime),
especially because it usually goes to flash memory, a CF card,
or some other really slow device.

Doing that on a high rt prio is not nice; in an rt kernel, 
it may even keep interrupt handlers from responding...
Is there any way to do it in the background / at low prio?

-- 
Klaus Kusche                 (Software Development - Control Systems)
KEBA AG             Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120                 Fax: +43 / 732 / 7090-6301
E-Mail: kus@xxxxxxxx                                WWW: www.keba.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/