Before sending my patch, I did a duplicate check against the upstream
linux-next tree, upstream history, publicly searchable mailing-list archives,
and Patchwork. I searched using the vhost-scsi and scatterlist function names,
T10-PI, invalid protection SGL counts, and the OOM/resource-exhaustion
symptoms. I did not find Linfeng's earlier patch.
Could you please point me to Linfeng's patch, or confirm what the additional
check covers? In particular, does it also validate:
prot_bytes <= exp_data_len
before subtracting prot_bytes from exp_data_len and entering the SGL
mapping path? I had identified this as a related PI length-mismatch path, but
did not include it in the patch I sent.
With a one-byte combined payload and
pi_bytesout=2, KGDB stopped at the following call stack:
#0 sg_alloc_table_chained(
table=0xffff88810bbc5108,
nents=0,
first_chunk=0xffff888110050000,
nents_first_chunk=2048)
at lib/sg_pool.c:117
#1 vhost_scsi_handle_vq+2295
#2 vhost worker task
#3 srso_alias_return_thunk
The stop was at the `BUG_ON(!nents)` instruction in
`sg_alloc_table_chained()`, and the kernel log recorded `kernel BUG at
lib/sg_pool.c:117!`. This confirms that the PI length check is needed before
the iterator adjustment and SGL mapping path.
If Linfeng's patch covers both the invalid protection SGL count and this PI
length check, I will not submit duplicate work.
Regarding the AI question: AI assistance was used during the source analysis
and test development. I also checked the relevant code path and the
host-side behavior.
