Re: [PATCH v1 03/10] kconfig-checker: Add the configuration checker code

[Ahmed S. Darwish]

On Sat, 07 Nov 2026, sashiko-bot@xxxxxxxxxx wrote:
> >
> > + def _find_issue_pattern(self, pattern_rule: PatternRule) -> Optional[PatternIssue]:
> > +	  """Check the .config against a pattern rule. Return found issues, if any."""
> > +	  if pattern_rule.expected == ExpectedValue.allowed:
> > +	      return None
> > +
> > +	  violation_type = 'unset' if pattern_rule.expected == ExpectedValue.y else 'set'
> > +	  docs_url = self.rules.get_docs_url_for(pattern_rule)
> > +
> > +	  violating_symbols = []
> > +
> > +	  for symbol in self.kconfig.get_matching_symbols(pattern_rule.symbol_regex):
> > +	      symbol_value = self.kconfig.get_symbol_value(symbol)
> > +
> > +	      if pattern_rule.expected == ExpectedValue.y and symbol_value == 'n':
> > +		  # Exclude the config symbol if it's explicitly disabled elsewhere
> > +		  symbol_rule = self.rules.get_symbol_rule(symbol)
> > +		  if symbol_rule and symbol_rule.expected == ExpectedValue.n:
> > +		      continue
> > +
> > +		  violating_symbols.append(symbol)
> > +
> > +	      if pattern_rule.expected == ExpectedValue.n and symbol_value in ('y', 'm'):
> > +		  # Exclude the config symbol if it's explicitly allowed elsewhere
> > +		  symbol_rule = self.rules.get_symbol_rule(symbol)
> > +		  if symbol_rule and symbol_rule.expected in (ExpectedValue.y, ExpectedValue.allowed):
> > +		      continue
> > +
> > +		  violating_symbols.append(symbol)
>
> [Severity: Low]
> Should _find_issue_pattern() skip any symbol that has an explicit
> SymbolRule, regardless of symbol_rule.expected?
>
> Only checking for opposing expected values causes two issues: when
> pattern_rule.expected is ExpectedValue.y, a symbol with a SymbolRule of
> ExpectedValue.allowed is not exempted and is falsely reported as unset,

I think you misunderstand what 'allowed' means.

'expected: allowed', means that an option is permitted. Quoting the schema:

        #
        # Expected value for the matching kernel configuration option.
        #
        # Values:
        #
        #   y        option is expected to be enabled (built-in or module).
        #   n        option is expected to be disabled or unset.
        #   allowed  option is permitted and must not be reported as a violation.
        #            This is to be used either by overlays, or to exempt a specific
        #            symbol from a broader `name_pattern` rule  with `expected: n`.
        #
        expected:
          type: string
          enum: [y, n, allowed]

So, for below policy:

  - name_pattern: CONFIG_DEBUG_.*
    expected: n

  - name: CONFIG_DEBUG_ATOMIC_SLEEP
    expected: allowed

having a CONFIG_DEBUG_ATOMIC_SLEEP=y should not trigger an audit warning.

But for below policy:

  - name_pattern: CONFIG_DEBUG_.*
    expected: y

  - name: CONFIG_DEBUG_ATOMIC_SLEEP
    expected: allowed

having CONFIG_DEBUG_ATOMIC_SLEEP=y should trigger no warning, but having
'CONFIG_DEBUG_ATOMIC_SLEEP is unset' should definitely trigger a warning,
even with the second 'expected: allowed' rule.

TLDR; the pattern expected: y / symbol expected: allowed case is not a bug.

>
> and when a SymbolRule has the same expected value as the PatternRule (for
> example, to give a specific symbol its own severity or rationale), the
> violation is reported twice—once by _find_issue_symbol() and once by
> _find_issue_pattern().
>

Hmm, the tool does not handle below case:

  - name_pattern: CONFIG_DEBUG_.*
    expected: n
    serverity: medium

  - name: CONFIG_DEBUG_ATOMIC_SLEEP
    expected: n
    severity: fatal
    rationale: Danger! must disable! Danger!

But on a second look, maybe it should... I'll think about it.

Thanks,
Ahmed