On Thu, Jun 23, 2016 at 11:46 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> Ugh. Looking around at this, it turns out that a great example of this >> kind of legacy issue is the debug_mutex stuff. > > Interestingly, the *only* other user of ti->task for a full > allmodconfig build of x86-64 seems to be > > arch/x86/kernel/dumpstack.c > > with the print_context_stack() -> print_ftrace_graph_addr() -> task = > tinfo->task chain. > > And that doesn't really seem to want thread_info either. The callers > all have 'task', and have to generate thread_info from that anyway. > > So this attached patch (which includes the previous one) seems to > build. I didn't actually boot it, but there should be no users left > unless there is some asm code that has hardcoded offsets.. I think you'll break some architectures when you remove the initialization of ti->task. That either needs to be pushed down into arch code in unicore32, openrisc, microblaze, powerpx, xtensa, sparc, parisc, arm, mips, s390, and whatever I missed, or you should leave the field initialized and existing and wait for my patch to conditionally remove/embed thread_info to get rid of the initialization part. On the C side, there's: arm's contextidr_notifier (easily fixable) sh's irqctx->tinfo.task = curctx->task; (probably useless) and print_ftrace_graph_addr cris's ugdb_trap_user (probably easily fixable) sparc's arch_trigger_all_cpu_backtrace (possibly quite hard to fix) sparc's flush_thread (trivial) sparc's __save_stack_trace (not sure) unicore's __die (probably easy) metag's do_softirq_own_stack (not sure if it's useful) I found these with this coccinelle script: @@ struct thread_info *ti; @@ * ti->task $ spatch --sp-file titask.cocci --dir . -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
