diff options
| author | Gustavo Sousa <gustavo.sousa@intel.com> | 2026-05-22 05:45:18 -0300 |
|---|---|---|
| committer | Gustavo Sousa <gustavo.sousa@intel.com> | 2026-05-22 10:52:29 -0300 |
| commit | f6d460e33e537b576d74c67bb9b6352511f5bb96 (patch) | |
| tree | 3a91404e17015ca96a89f8208baa41b6b21f2136 /include/linux/debugobjects.h | |
| parent | ff7746336b2325087aa7958d40f327bcc50185f8 (diff) | |
drm/xe/rtp: Don't short-circuit to false in or-yes case
While RTP processing evaluates true on the "yes-or" case (i.e. a
conjunction of rules that evaluate to true followed by an "OR" without
the right hand operand), it does not on the "or-yes" one.
Both cases are considered malformed and could be a result of someone
dropping checks deemed not necessary anymore and forgetting to drop the
superfluous "OR". Nevertheless, we should aim for consistency, and
having the "or-yes" case also evaluating to true while also causing a
warning seems reasonable. So let's do that.
The "or-yes" pattern being evaluated to false comes from the fact that
that we unconditionally short-circuit upon finding XE_RTP_MATCH_OR on
the outer loop. We should only do that if the preceding conjunction of
rules evaluated to true (meaning that rcount must be non-zero) and
continue the evaluation otherwise.
Do that and also add extra test cases to validate the short-circuiting
behavior.
Notice that some of the new test cases have a "FIXME" comment, which
comes from the fact that we are unable to detect syntax errors after the
short-circuit point. That is going to be fixed in a follow-up change.
Link: https://lore.kernel.org/intel-xe/871pfw4lo9.fsf@intel.com/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-3-0c51039899f4@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Diffstat (limited to 'include/linux/debugobjects.h')
0 files changed, 0 insertions, 0 deletions
