Hi Simon and maintainers, Just a gentle ping on this patch series.
Following up on my previous email regarding the testing methodology (using virtme-ng, verifying the Oops fix in Patch 1, and confirming the strictness of strsep + kstrtouint). Does the provided testing information address the concerns? Please let me know if there's anything else I should clarify, or if a v3 is needed to move this forward. Thanks, Yufan On Wed, Mar 4, 2026 at 11:28 PM Eric_Terminal <[email protected]> wrote: > > 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,
