On Sat, Sep 26, 2015 at 04:05:18PM -0400, Tejun Heo wrote: > > Frankly, I don't understand what you've been trying to achieve. > You're actively disregarding best practices (like terminating > synchronization where it starts) and reach the target state by doing a > browian motion in the solution space. Sure, if you do enough of that, > eventually you can arrive somewhere where it's not broken but it leads > to a lot more overhead for everyone involved - the author, reviewers > and later readers of the code and if you spread barrier usages like > this across the kernel, we'll end up with code base which is a lot > harder to verify and maintain. I hope you stop doing things this way > but suppose that you're ignoring any conceptual arguments in this > thread.
Your point so far has been that if you add barriers or use primitives everywhere then races magically disappear. Well guess what the bug that you have discovered supposedly due to a missing barrier in netlink_connect has nothing to do with the barrier. Instead it is caused by a logical error elsewhere that would have gone unnoticed otherwise. So I retain my position that blindly adding barriers do not make bugs go away. Instead you need to have real understanding of what the code is doing and every spot where a barrier may be needed must be audited manually. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/