On 6/12/07, Jan Beulich <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
