On Sun, Mar 1, 2026 at 11:29 PM Simon Horman <[email protected]> wrote: > Hi, > > Thanks for your patches. > > I would like to understand what testing has been performed on these patches. > > With the possible exception of patch 3/4, I feel that unless they > are motivated as bug fixes, these changes are too complex to accept > without testing. Although the opinions of the relevant maintainers > may differ. > > And as for 3/4, I lean towards falling into the policy regarding > clean-ups not being generally accepted unless it is part of other work.
Hi, Thanks for the feedback. I've verified the series using virtme-ng and a userspace mock harness (for the 9p tokenizing logic). Regarding Patch 1: This is primarily a stability fix. I've tested the error paths by forcing init failures on a non-Xen system; dmesg confirms the new sentinel-based cleanup (NULL-ing intf/data and checking INVALID_GRANT_REF) correctly prevents double-frees and Oops during teardown. Regarding the "complexity" in Patch 2: The strsep + kstrtouint approach was chosen for strictness. I've verified it handles cases like "1,,2" (empty tokens) and "1abc" (malformed input) correctly. The latter is now rejected with -EINVAL, whereas simple_strto* would have silently accepted partial values. The same applies to Patches 3 and 4. The migration to kstrto* ensures that sysfs/procfs interfaces now properly validate the entire input string. P.S. I used a translation tool for the message above, so please excuse any awkward wording. Thanks,
