Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 8 Jun 2020 16:11:06 -0700 | Subject | Re: [GIT pull - RFC] locking/kcsan for v5.8 |
| |
On Tue, Jun 2, 2020 at 6:07 AM Thomas Gleixner <tglx@linutronix.de> wrote: > > please consider to pull the latest locking/kcsan branch from:
Gaah. So I left this until I had cleared out my queues, and now that I start looking at it, I find myself more annoyed by the messy history than by the kcsan code.
For example, it generates conflicts with the sparc tree, because the sparc page table changes weren't done as a shared branch, but duplicated as commits (and the subsequent changes cause some conflicts).
And the read-once/write-once changes that I was aware of and approve of, are similarly mixed in here randomly, rather than being as a branch of their own. I see that Will then made his own branch, but then we'd have the same issue as with the sparc changes.
The things I was _expecting_ to find annoying (various random changes to random code due to kcsan reports), I don't actually see.
Instead I see odd small completely unrelated things like the x86/purgatory changes that were merged in for odd reasons.
How painful would it be to sort this out properly? I'll happily take the read-once changes as a separate branch, for example. There's nothing really controversial there., even if the gcc version bump might annoy some (I personally think we could bump it further up to 4.9, and require _Generic, for example - I suspect we have a number of places that could use _Generic instead of nasty sizeof games).
I'd even make an exception and say "ok, just rebase the kcsan stuff on top" to clean up the messy history, because this is the kind of new feature that shouldn't affect a normal build, and I'd hate to have other changes that _can_ affect a normal build - like those atomic changes - mixed up in the middle of the kcsan stuff.
So my first reaction from looking at this is that I'd rather get the infrastructure separately (like I already got the sparc32 page table changes), so that once I _do_ get the kcsan bits, they really would be "this introduces no semantic changes what-so-ever when not enabled".
IOW, I'd be inclined to instead pull Will's branch, and then whatever x86 entry branches, and then kcsan last with _just_ kcsan stuff.
Will that make everybody else cry tears of frustration?
Linus
| |