> The main codepath which runs into this (... -> cache_lookup -> vhold) most > definitely does not need the fence for production operation. > > What is unclear without audit is whether there are vhold users which need > one. I think the patch is fine to go in if the other VI_FREE place gets a > comment about a fence stemming from mtx_unlock and there is another one > prior to the assertion explaining that this orders against v_iflag tests and > may > or may not be needed for other consumers. > > In general the code is *full* of data races and accidental reliance of > ordering > provided by amd64. Weeding this all out will be a painful exercise. > > Part of the problem is lack of primitives like READ_ONCE/WRITE_ONCE as > seen in the linux kernel, someone should hack up equivalents.
CK of course has these. We can create a wrapper around them if we don't want to use them directly. -M _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
