[PATCH v3 0/3] lib: sbi: fix shared memory double-fetch in DBTR and SSE

[liutong]

Hi Himanshu,

You asked for the patch that fails if M=1 is being set. Sent as
"lib: sbi: dbtr: validate trigger configuration in update_trig":

  https://lore.kernel.org/opensbi/20261103081001.2948003-1-liutong@iscas.ac.cn/

It covers update only. install_trig still runs dbtr_trigger_valid() on
one read of the entry and programs a later one, so the escalation is
still reachable there; the commit message says so rather than leaving
it to be assumed. I have a tested patch for that which moves the check
into dbtr_trigger_setup(), where the value is actually stored, so one
check covers both paths. It restructures install_trig, and after your
note about churn I did not want to fold it into this patch or send it
unasked. Say the word and I will.

On the rest of your mail. Validation and allocation in one pass with
installation in another is what that second patch does, and rollback
there is just the free, since nothing before the install pass writes a
CSR - you were right that clearing CSRs was the wrong shape for it.

The one I could not reconcile is restoring prior triggers to their
original values on failure. On update that needs the old tdata1/2/3
kept for the whole batch, which is the per-entry array you objected to
in the first place. I did not want to pick one of your comments over
the other silently. My own preference is to leave update's batch
behaviour as it is today, but it is your call.

Regards,
liutong