diff mbox series

[1/2] 9p/xen: fix version parsing

Message ID 20230130113036.7087-2-jgross@suse.com (mailing list archive)
State Not Applicable
Delegated to: Netdev Maintainers
Headers show
Series 9p/xen: fix 2 issues with connecting to backend | expand

Checks

Context Check Description
netdev/tree_selection success Guessed tree name to be net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/subject_prefix warning Target tree name not specified in the subject
netdev/cover_letter success Series has a cover letter
netdev/patch_count success Link
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/cc_maintainers fail 1 blamed authors not CCed: sstabellini@kernel.org; 1 maintainers not CCed: sstabellini@kernel.org
netdev/build_clang success Errors and warnings before: 0 this patch: 0
netdev/module_param success Was 0 now: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success Fixes tag looks correct
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/checkpatch warning WARNING: simple_strtoul is obsolete, use kstrtoul instead
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Jürgen Groß Jan. 30, 2023, 11:30 a.m. UTC
When connecting the Xen 9pfs frontend to the backend, the "versions"
Xenstore entry written by the backend is parsed in a wrong way.

The "versions" entry is defined to contain the versions supported by
the backend separated by commas (e.g. "1,2"). Today only version "1"
is defined. Unfortunately the frontend doesn't look for "1" being
listed in the entry, but it is expecting the entry to have the value
"1".

This will result in failure as soon as the backend will support e.g.
versions "1" and "2".

Fix that by scanning the entry correctly.

Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 net/9p/trans_xen.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

Comments

Simon Horman Jan. 31, 2023, 6:48 p.m. UTC | #1
On Mon, Jan 30, 2023 at 12:30:35PM +0100, Juergen Gross wrote:
> When connecting the Xen 9pfs frontend to the backend, the "versions"
> Xenstore entry written by the backend is parsed in a wrong way.
> 
> The "versions" entry is defined to contain the versions supported by
> the backend separated by commas (e.g. "1,2"). Today only version "1"
> is defined. Unfortunately the frontend doesn't look for "1" being
> listed in the entry, but it is expecting the entry to have the value
> "1".
> 
> This will result in failure as soon as the backend will support e.g.
> versions "1" and "2".
> 
> Fix that by scanning the entry correctly.
> 
> Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend")
> Signed-off-by: Juergen Gross <jgross@suse.com>

It's unclear if this series is targeted at 'net' or 'net-next'.
FWIIW, I feel I feel it would be more appropriate for the latter
as these do not feel like bug fixes: feel free to differ on that.

Regardless,

Reviewed-by: Simon Horman <simon.horman@corigine.com>
Jürgen Groß Feb. 1, 2023, 6:37 a.m. UTC | #2
On 31.01.23 19:48, Simon Horman wrote:
> On Mon, Jan 30, 2023 at 12:30:35PM +0100, Juergen Gross wrote:
>> When connecting the Xen 9pfs frontend to the backend, the "versions"
>> Xenstore entry written by the backend is parsed in a wrong way.
>>
>> The "versions" entry is defined to contain the versions supported by
>> the backend separated by commas (e.g. "1,2"). Today only version "1"
>> is defined. Unfortunately the frontend doesn't look for "1" being
>> listed in the entry, but it is expecting the entry to have the value
>> "1".
>>
>> This will result in failure as soon as the backend will support e.g.
>> versions "1" and "2".
>>
>> Fix that by scanning the entry correctly.
>>
>> Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend")
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> It's unclear if this series is targeted at 'net' or 'net-next'.
> FWIIW, I feel I feel it would be more appropriate for the latter
> as these do not feel like bug fixes: feel free to differ on that.

I'm fine with net-next.

Right now there is no problem with the current behavior. This will
change only in case Xen starts to support a new transport version.

For the other patch the problem would show up only if Xen starts
supporting dynamical attach/detach of 9pfs devices, which is not
the case right now.

> 
> Regardless,
> 
> Reviewed-by: Simon Horman <simon.horman@corigine.com>
> 

Thanks,


Juergen
Dominique Martinet Feb. 11, 2023, 12:11 a.m. UTC | #3
Juergen Gross wrote on Wed, Feb 01, 2023 at 07:37:04AM +0100:
> > It's unclear if this series is targeted at 'net' or 'net-next'.
> > FWIIW, I feel I feel it would be more appropriate for the latter
> > as these do not feel like bug fixes: feel free to differ on that.
> 
> I'm fine with net-next.

It doesn't look like it got picked up in net-next, so I'm queueing it up in the
9p tree.

Thanks for the patches and the review!
diff mbox series

Patch

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 82c7005ede65..ad2947a3b376 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -378,13 +378,19 @@  static int xen_9pfs_front_probe(struct xenbus_device *dev,
 	int ret, i;
 	struct xenbus_transaction xbt;
 	struct xen_9pfs_front_priv *priv = NULL;
-	char *versions;
+	char *versions, *v;
 	unsigned int max_rings, max_ring_order, len = 0;
 
 	versions = xenbus_read(XBT_NIL, dev->otherend, "versions", &len);
 	if (IS_ERR(versions))
 		return PTR_ERR(versions);
-	if (strcmp(versions, "1")) {
+	for (v = versions; *v; v++) {
+		if (simple_strtoul(v, &v, 10) == 1) {
+			v = NULL;
+			break;
+		}
+	}
+	if (v) {
 		kfree(versions);
 		return -EINVAL;
 	}