Change Details

We have a number of false-positive LORs that get logged regularly on WITNESS kernels. These warnings alarm new users and confuse test automation which looks for genuine LORs. For instance, we regularly get PRs reporting benign LORs. WITNESS cannot track the complex locking relationships that make these LORs harmless. There have been some proposals in the past for a finer-grained mechanism to ignore these false positives, e.g., by adding NOWITNESS flags to the various lock functions, or by specifying one or more blessed lock pairs at a given lock site. These proposals all have shortcomings, however, and worse, they were not implemented. We do however have the ability to ignore LORs refering to specific lock pairs. In the absence of a better solution, start using it to silence a couple of commonly reported LORs. I unconditionally enabled the blessing code; I didn't see a good reason to make it conditional. I have no issue making it so if anyone can suggest a reason.

We have a number of false-positive LORs that get logged regularly on WITNESS kernels. These warnings alarm new users and confuse test automation which looks for genuine LORs. For instance, we regularly get PRs reporting benign LORs. WITNESS cannot track the complex locking relationships that make these LORs harmless. There have been some proposals in the past for a finer-grained mechanism to ignore these false positives, e.g., by adding NOWITNESS flags to the various lock functions, or by specifying one or more blessed lock pairs at a given lock site. These proposals all have shortcomings, however, and worse, they were not implemented. We do however have the ability to ignore LORs referring to specific lock pairs. In the absence of a better solution, start using it to silence a couple of commonly reported LORs. I unconditionally enabled the blessing code; I didn't see a good reason to make it conditional. I have no issue making it so if anyone can suggest a reason.

We have a number of false-positive LORs that get logged regularly on WITNESS kernels. These warnings alarm new users and confuse test automation which looks for genuine LORs. For instance, we regularly get PRs reporting benign LORs. WITNESS cannot track the complex locking relationships that make these LORs harmless. There have been some proposals in the past for a finer-grained mechanism to ignore these false positives, e.g., by adding NOWITNESS flags to the various lock functions, or by specifying one or more blessed lock pairs at a given lock site. These proposals all have shortcomings, however, and worse, they were not implemented. We do however have the ability to ignore LORs referring to specific lock pairs. In the absence of a better solution, start using it to silence a couple of commonly reported LORs. I unconditionally enabled the blessing code; I didn't see a good reason to make it conditional. I have no issue making it so if anyone can suggest a reason.