Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Mon, Mar 28, 2022 at 4:56 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: >> >> The removal of tracehook.h is quite significant as it has been a major >> source of confusion in recent years. Much of that confusion was >> around task_work and TIF_NOTIFY_SIGNAL (which I have now decoupled >> making the semantics clearer). > > Hmm. I love removing tracehook.c, but this looks like it hasn't been > in linux-next. > > The header file changes messes with other changes, and we have > > kernel/sched/fair.c:2884:9: error: implicit declaration of function > ‘init_task_work’; did you mean ‘init_irq_work’? > [-Werror=implicit-function-declaration] > 2884 | init_task_work(&p->numa_work, task_numa_work); > | ^~~~~~~~~~~~~~ > > as a result (also a few other things in that same file). > > Now, this is trivial to fix - just add an include for > <linux/task_work.h> from that file - and that's the right thing to do > anyway. > > But I'm a bit unhappy that this was either not tested in linux-next, > or if it was, I wasn't notified about the semantic in the pull > request. > > So I've pulled this, and fixed up things in my merge, but I'm a bit > worried that there might be other situations like this where some > header file is no longer included and it was included implicitly > before through that disgusting tracehook.h header.. > > I *hope* it was just the scheduler header file updates that ended up > having this effect, and nothing else is affected. > > Let's see if the test robots start complaining about non-x86 > architecture-specific stuff that I don't build test. Sorry for not mentioning that. I had tracked it down. It was fundamentally in the scheduler headers changes removing an include of task_work.h, so it didn't feel like there was anything I could do in my tree. I asked Ingo if he could fix his tree and unfortunately forgot about it. For the record there were also a couple of other pretty trivial conflicts, the removal of nds32, some block_cgroup header where an adjacent line was modified to what I was changing. But it thankfully looks like none of those caused you any problems. Sorry about all of that I am about that. I am running pretty weak this last couple of days as a cold has been running through the household. Dumb question because this seems to burning a few extra creativity points. Is there any way to create a signed tag and a branch with the same name? Or in general is there a good way to manage topic branches and then tag them at the end before I send them? Having a tag and a branch with the same name seems to completely confuse git and it just tells me no I won't push anything to another git tree, because what you are asking me to do is ambiguous. So now I am having to come up with two names for each topic branch, even if I only push the tags upstream. I feel like there is a best practice on how to manage tags and topic branches and I just haven't seen it yet. Eric
