<div dir="ltr">Webrev: <a href="http://cr.openjdk.java.net/~aeubanks/8238566/webrev.00/">http://cr.openjdk.java.net/~aeubanks/8238566/webrev.00/</a><div>Bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8238566">https://bugs.openjdk.java.net/browse/JDK-8238566</a></div><div><br></div><div>Found by TSAN, java.security.Provider$Service.supportsParameter() is racy. We haven't observed any actual bad behavior, but reasoning through it seems like bad behavior is possible.<br><br><a href="http://hg.openjdk.java.net/jdk/jdk/file/62b5bfef8d61/src/java.base/share/classes/java/security/Provider.java#l1927">http://hg.openjdk.java.net/jdk/jdk/file/62b5bfef8d61/src/java.base/share/classes/java/security/Provider.java#l1927</a><br><br>The synchronized block seems to not have any effect on correctness.<br><br>Example race:<br>T1 in hasKeyAttributes() writes true to hasKeyAttributes and fills out supportedFormats/supportedClasses.<br><br>T2 in hasKeyAttributes() racily reads hasKeyAttributes as true, but then in supportsKeyFormat() racily reads supportedFormats as null. It can then improperly return false from supportsParameter().<br>There is no synchronization between T1 and T2 because T2 never does any synchronization, so T2 can read what T1 writes in any order.<br></div><div><br></div><div>Fix is to make all of hasKeyAttributes() synchronized.</div></div>