Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

m001.c (B_MEM_02) detects only 2 of the 4 rule-permitted terminations

Open
  • Is something wrong?
#531 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
operating-systems, testing-qa

Research direction

Start with test_pool/memory_map/m001.c, especially the two ESR registrations, esr(), the store probe, and the verdict after val_mem_issue_dsb(). Compare GIC ISR registration in test_pool/exerciser/e004.c and related tests, then review val_gic_install_isr in val/include/val_interface.h. Done means SPI/LPI terminations are handled without false failure, or the result is explicitly indeterminate and docs/bsa/arm_bsa_testcase_checklist.md records the limitation.

Written by the indexing model from the issue text.

Description

Component: sysarch-acs, test_pool/memory_map/m001.c
Rule: B_MEM_02 (BSA), test num 101, "Memory Access to Un-Populated addr"
Type: Incomplete test coverage / false negative

Summary

B_MEM_02 permits four different terminations for an access to unpopulated
address space. m001.c can only observe two of them. A platform that
terminates via the other two - both explicitly allowed by the rule - is reported
as FAILED even though it is conformant.

Rule text

Where a memory access is to an unpopulated part of the addressable memory
space, accesses must be terminated in a manner that is presented to the PE as
either a precise Data Abort, or as a system error interrupt, or an SPI, or LPI
interrupt to be delivered to the GIC.

Four permitted terminations:

# Termination Detected by m001.c
1 Precise Data Abort Yes - EXCEPT_AARCH64_SYNCHRONOUS_EXCEPTIONS
2 System error interrupt (SError) Yes - EXCEPT_AARCH64_SERROR
3 SPI delivered to the GIC No
4 LPI delivered to the GIC No

Evidence

m001.c installs exactly two handlers, both PE exception handlers, and no GIC
interrupt handler:

60:  val_pe_install_esr(EXCEPT_AARCH64_SYNCHRONOUS_EXCEPTIONS, esr);
61:  val_pe_install_esr(EXCEPT_AARCH64_SERROR, esr);

The verdict is pre-set to FAIL and is only ever cleared by that PE exception
handler:

84:          val_set_status(index, RESULT_FAIL(1));   /* default */
88:          *((volatile uint64_t*)addr) = 0x100;     /* the probe (a STORE) */
91:          val_mem_issue_dsb();

esr() at line 46 is the sole writer of RESULT_PASS. There is no path by
which an SPI or LPI can produce a PASS, so options 3 and 4 are unreachable
verdicts.

Impact

Any platform that reports unpopulated-address accesses by interrupt to the GIC -
a legal choice under the rule - fails B_MEM_02 unconditionally. The failure
signature is indistinguishable from a platform that reports nothing at all,
which is a genuine violation. The test cannot separate a conformant
interrupt-reporting platform from a non-conformant silent one, which is the
practical harm: it forces manual architectural investigation on every platform
that does not use aborts.

Additional finding: the checklist overstates coverage

docs/bsa/arm_bsa_testcase_checklist.md (lines 302-303) lists B_MEM_02 with
coverage "Yes / Yes" and records no limitation. If partial coverage is intended
and accepted, the checklist should say so; as written it implies the rule is
fully verified.

The framework already supports the fix

This is not a missing-infrastructure problem. val_gic_install_isr(uint32_t int_id, void (*isr)(void)) is declared in val/include/val_interface.h:205,
and the pattern is already used across the suite - test_pool/exerciser/e004.c,
e006.c, e012.c, e013.c, e023.c, e024.c, e027.c, e033.c and others.

Suggested resolution

Preferred - close the coverage gap:

  1. Register a GIC ISR alongside the two ESRs, using the existing
    val_gic_install_isr path, and set RESULT_PASS from it as esr() does.
  2. Poll for a bounded interval after val_mem_issue_dsb() before declaring
    FAIL, since interrupt delivery is asynchronous whereas an abort is
    synchronous with the store. The current code evaluates the verdict
    immediately after the dsb, which would race an interrupt even if a handler
    were installed.
  3. Source the interrupt ID from the PAL so platforms can declare which SPI/LPI
    signals the condition.

Minimum acceptable alternative - if interrupt observation is considered out of
scope, emit a distinct, non-FAIL result (e.g. WARNING or a documented
"indeterminate") stating that options 3 and 4 were not evaluated, and record the
limitation in the checklist. That preserves the useful signal while not
mislabelling conformant platforms as failing.

Notes for the reviewer

  • The probe is a store, so on platforms whose unmapped-access behaviour is
    write-ignore the write is silently dropped; there is no returned data for the
    test to inspect as a fallback signal.
  • Point 2 above (the async race) is worth fixing regardless of whether point 1
    is accepted, and is arguably a latent bug in its own right.
Dominant language
C
Stars
23
Forks
39
Avg merge
21h 56m
Merged PRs (30d)
28

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ARM-software/sysarch-acs

All issues in ARM-software/sysarch-acs

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.