linux-next build conflict between modules and metag trees (LOCKDEP_NOW_UNRELIABLE)

Hi Rusty,

The metag architecture tree adds an add_taint(TAINT_DIE) like other architectures do, and the modules-next tree adds the LOCKDEP_NOW_UNRELIABLE flag to all uses of add_taint (but obviously misses arch/metag since it doesn't exist yet), causing a compile error on metag in -next when the two are merged together.

Is it okay for me to merge your commit 373d4d0 ("taint: add explicit flag to show whether lock dep is still OK.") in modules-next into the base of the metag tree and expect it not to be rebased, so that I can then squash the fix into the metag tree?

Hi Rusty,

The metag architecture tree adds an add_taint(TAINT_DIE) like other architectures do, and the modules-next tree adds the LOCKDEP_NOW_UNRELIABLE flag to all uses of add_taint (but obviously misses arch/metag since it doesn't exist yet), causing a compile error on metag in -next when the two are merged together.

Is it okay for me to merge your commit 373d4d0 ("taint: add explicit flag to show whether lock dep is still OK.") in modules-next into the base of the metag tree and expect it not to be rebased, so that I can then squash the fix into the metag tree?

The only commits this would include are:

$ git log --oneline linus/master..373d4d0
373d4d0 taint: add explicit flag to show whether lock dep is still OK.
64748a2 module: printk message when module signature fail taints kernel.

Thanks
James

Quoted 12 lines · James Hogan

The metag architecture tree adds an add_taint(TAINT_DIE) like other architectures do, and the modules-next tree adds the LOCKDEP_NOW_UNRELIABLE flag to all uses of add_taint (but obviously misses arch/metag since it doesn't exist yet), causing a compile error on metag in -next when the two are merged together.

Is it okay for me to merge your commit 373d4d0 ("taint: add explicit flag to show whether lock dep is still OK.") in modules-next into the base of the metag tree and expect it not to be rebased, so that I can then squash the fix into the metag tree?

Quoted 4 lines

The only commits this would include are:

$ git log --oneline linus/master..373d4d0
373d4d0 taint: add explicit flag to show whether lock dep is still OK.
64748a2 module: printk message when module signature fail taints kernel.

Being in the same situation as metag (ARC Port), what's the recommended practice here - do we simply cherry-pick these changes into our tree - or do we merge the "other" tree on top - ofcourse with premise that "other" tree will not rebase.

Quoted 8 lines · James Hogan

Hi Rusty,

The metag architecture tree adds an add_taint(TAINT_DIE) like other architectures do, and the modules-next tree adds the LOCKDEP_NOW_UNRELIABLE flag to all uses of add_taint (but obviously misses arch/metag since it doesn't exist yet), causing a compile error on metag in -next when the two are merged together.

Quoted 4 lines

Is it okay for me to merge your commit 373d4d0 ("taint: add explicit flag to show whether lock dep is still OK.") in modules-next into the base of the metag tree and expect it not to be rebased, so that I can then squash the fix into the metag tree?

This was my fault for taking a shortcut. I should have changed the name so the old add_taint worked still (set_taint?), then remove add_taint after the merge.

But I won't be rebasing, so you should be fine to merge it.