lkml.org 
[lkml]   [2007]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fix improper .init-type section references
On 6/12/07, Jan Beulich <jbeulich@novell.com> wrote:
> >> -static __init void kthreadd_setup(void)
> >> +static noinline __init_refok void kthreadd_setup(void)
> >> {
> >> struct task_struct *tsk = current;
> >
> >This isn't ok. There isn't any __init function that is (safely) referenced
> >by kthreadd_setup(), so we shouldn't really be marking it as such.
> >Also, kthreadd_setup() is really only ever called at init time, so we'd
> >want it to remain __init.
>
> Oh, I see, I misunderstood the purpose of the tag - I assumed it would
> mark an __init function that is known to only be referenced from init-only
> code paths inside non-init functions (i.e. I didn't pay attention that the
> resulting section's name is .text.init.refok, not .init.text.refok).
>
> I have to admit I have some difficulty understanding when the tags
> are going to be useful the way they are implemented right now.

Yup, I had discussed precisely the same issue (whether to associate
__init_refok with callers or callees) with Sam earlier, but he thought
it'd be more useful to have normal-caller-can-ref-init-callees semantics
for the same.

> >I believe the correct fix to silence modpost here would be to mark its
> >caller kthreadd() also as __init, because it too is used only at init time?
>
> I don't think so - it is my understanding that this is the body of a thread
> that never dies.

Ugh, yes, I'm smoking God-knows-what, and you're absolutely correct!

So we should be marking kthreadd() as __init_refok instead, it seems.

Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-06-12 13:23    [W:0.045 / U:20.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site