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 [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt