vms-eeb: DLM rung H9 — cross-node LVB READ crossing (a client reads the master's LVB via cross-node $ENQ) (0.6) - #925
Merged
Merged
Conversation
…s value block on $ENQ (rung H9)
The symmetric mirror of the write crossing (vms-d81): a client on node A reads
the lock value block that the master (node B) holds for a resource, over the
GRANT wire, on a cross-node $ENQ. Rides the EXISTING GRANT frame + ioctl ABI --
no ABI change; the field was already there.
Executive (vms_lock.c):
- struct vms_dlm_origin gains valblk[16] + valblk_valid.
- The cross-node $ENQ dispatch now honors LCK_M_VALBLK and reads the master's
res->valblk back into the reply (a zero inbound block triggers the read in
vms_enq_core_ex's grant path), so the GRANT carries the master's LVB.
- grant_recv stores the GRANT reply's value block into the requester's origin
record when a real grant lands (non-NL); a queued-reply leaves it unset.
- vms_lock_dlm_origin_getlki gains a valblk out-param; vms_ioctl_getlki's
origin-record path returns it (was zeroed), so GETLKI(req_lkid) surfaces the
master's LVB to the requester's $ENQ. Unset -> honest zeros, never stale.
scsd (scsd.c, master side): scsd_dlm_held carries the master's valblk, copied
from the ENQ ioctl and set into the GRANT reply frame (g.valblk). The requester
side needs no new marshalling -- the inbound GRANT valblk already reaches
grant_recv.
Harness (h9, SCS-wire, mirrors h6): node B seeds a known 16-byte LVB into RRD via
a local $ENQ(VALBLK)+$DEQ; node A does a cross-node $ENQ RRD and GETLKIs its own
handle to read the value back. Runner asserts both joined, B seeded, A read, and
A_read == B_seed == the expected pattern ("OVMXLVB-READ9"). scsd OVMX_DLM_H9
drive is additive/env-gated. ci.yml adds the dlm-harness-h9 job.
PROVEN GREEN locally (docker + KVM, 2 QEMU nodes, full VAXcluster join): "DLM
HARNESS H9 PASSED" -- B seeded 4f564d584c56422d5245414439000000, A read the
identical 16 bytes back over the GRANT wire (GETLKI rc=1). vms.ko + scsd_exe +
the wire unit test build clean; no ABI/census impact.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
baron-3dl
added a commit
that referenced
this pull request
Aug 30, 2026
…der is COMPLETE (H0→H11) (#931) The cluster-dlm.yaml was last_reviewed 2026-08-28, before H10b/e84/H11 landed — it still read remaster/LVB/deadlock 'absent' and BLKAST 'deferred', which the merges (#918 BLKAST H6, #923/#925 LVB H8/H9, #927/#928 remaster H10a/H10b, #929 e84 directory-guard, #930 H11 deadlock — all on main) made false. Update all four items partial→verified with verified_against pointing at the multi-node /dev/vms harnesses that prove them, rewrite the summary to the complete ladder + the honest remaining DEPTH (vms-04f concurrent-initiate proof, vms-b96 directory REDIRECT, vms-d1f post-1.0 app-acquisition), add REBUILD=5/DLKSRCH=6 to the opcode set, and render_compat.py (docs/compatibility-surface.md regenerated, drift gate clean). Closes the vms-7fa epic on the compat surface. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symmetric READ-crossing mirror of vms-d81's write-crossing (#923, merged). A client reads the master's LVB back over the existing GRANT wire — no ABI change, no new send site.
Mechanism (executive, src/kernel-core/vms_lock.c): cross-node $ENQ dispatch reads master
res->valblkinto the reply;grant_recvstores the GRANT reply's valblk into the origin record (valblk_valid) when granted non-NL;vms_lock_dlm_origin_getlkireturnsorg->valblkif valid else zeros; the $GETLKI origin path passes it through (was zeroed). SCSD master side addsheld.valblk+ copies args.valblk into the GRANT reply builder. Requester side reuses the existing marshalled inbound GRANT valblk → grant_recv. H9 only OR-s the VALBLK flag onto the existing send_enq — no new SCS send site (census non-issue, verified).Proof: rebased onto post-#923 main (993d2e8); vms_lock.c auto-merged clean (read-crossing edits orthogonal to #923's DEQ handler, both present); scsd.c conflicts resolved (reuse #923's scsd_hex16 + LCK_M_VALBLK; union'd flags/hooks/arming); ci.yml union'd (h7+h8+h9). Local rail-prove (docker+KVM, 2 QEMU nodes, full join): DLM HARNESS H9 PASSED — B seeds LVB via local $ENQ(VALBLK), A cross-node $ENQ + GETLKI reads it back; 3-way equality A_read == B_seed == 4F564D584C56422D5245414439000000 ("OVMXLVB-READ9").
Closes the LVB pair: write (vms-d81/#923) + read (this).
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com