From: Yufan Chen <ericterminal@gmail.com>

This series replaces deprecated simple_strto* parsers in net paths with
kstrto* helpers and keeps parser behavior strict.

v2:
Split the original large patch into a 4-patch series for easier review.
Added a prerequisite fix for xen_9pfs dataring cleanup idempotency
(Patch 1) to ensure safe error handling during the parser transition.
Refined the xen_9pfs version parsing logic to use strsep() for better
token handling.

Patch 1/4 fixes xen_9pfs dataring cleanup idempotency to avoid repeated
resource teardown on init error paths.
Patch 2/4 switches xen_9pfs backend version parsing to kstrtouint().
Patch 3/4 updates bridge brport_store() to use kstrtoul().
Patch 4/4 updates sunrpc proc_dodebug() to use kstrtouint().

Yufan Chen (4):
  9p/trans_xen: make cleanup idempotent after dataring alloc errors
  9p/trans_xen: replace simple_strto* with kstrtouint
  net: bridge: replace deprecated simple_strtoul with kstrtoul
  sunrpc: sysctl: replace simple_strtol with kstrtouint

 net/9p/trans_xen.c       | 77 +++++++++++++++++++++++++++-------------
 net/bridge/br_sysfs_if.c |  5 ++-
 net/sunrpc/sysctl.c      | 24 ++++++-------
 3 files changed, 67 insertions(+), 39 deletions(-)

-- 
2.47.3

On Wed, Feb 25, 2026 at 11:38:36AM +0800, Eric-Terminal wrote:
> From: Yufan Chen <ericterminal@gmail.com>
> 
> This series replaces deprecated simple_strto* parsers in net paths with
> kstrto* helpers and keeps parser behavior strict.
> 
> v2:
> Split the original large patch into a 4-patch series for easier review.
> Added a prerequisite fix for xen_9pfs dataring cleanup idempotency
> (Patch 1) to ensure safe error handling during the parser transition.
> Refined the xen_9pfs version parsing logic to use strsep() for better
> token handling.
> 
> Patch 1/4 fixes xen_9pfs dataring cleanup idempotency to avoid repeated
> resource teardown on init error paths.
> Patch 2/4 switches xen_9pfs backend version parsing to kstrtouint().
> Patch 3/4 updates bridge brport_store() to use kstrtoul().
> Patch 4/4 updates sunrpc proc_dodebug() to use kstrtouint().

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.

On Sun, Mar 1, 2026 at 11:29 PM Simon Horman <horms@kernel.org> 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,

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 <ericterminal@gmail.com> wrote:
>
> On Sun, Mar 1, 2026 at 11:29 PM Simon Horman <horms@kernel.org> 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,

Eric_Terminal wrote on Tue, Mar 24, 2026 at 12:27:50PM +0800:
> 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.

Part of the problem is that you've mixed a semi-complex 9p patch with
other net patches, I think it'd be easiser to move forward if you'd
split this (I can't take non-9p patches, and I'm not sure the -net tree
wants the 9p patches as we're a small world appart sometimes...)


For 9p, I can't (easily) test xen, so I'd appreciate if you could resend
with Stefano Stabellini <stefano.stabellini@amd.com> in Ccs as he has
been looking after this transport; I can have a quick look but don't
have the time for a proper review

Thanks,
-- 
Dominique Martinet | Asmadeus