From patchwork Mon Oct 23 23:37:02 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dominique Martinet X-Patchwork-Id: 13433717 Received: from nautica.notk.org (nautica.notk.org [91.121.71.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C0BDB2376A for ; Mon, 23 Oct 2023 23:37:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codewreck.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codewreck.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b="2DLrhRRq"; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b="H9q202+p" Received: by nautica.notk.org (Postfix, from userid 108) id 2CA8BC01F; Tue, 24 Oct 2023 01:37:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1698104243; bh=/A34CTskJseJi+dcqA1uEIZC2XG2pVw2hHNklQEakQo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2DLrhRRq6njg7SLrk3WbzcM8N/46q79mgTGyaP+Y4UsZA9IAsvLg8UrMUkQDnhLai 47r5jW+s0LYnQ+kUlpNRGbHdIW6ce4qjFqAWaNZGQb8wrYsLUmyBopuThwZQ4tzVLY ns++BcHak+wS9q+Mw+8M8i0lDqOVcr1rjCP1v236lW9x5gQ5pXmEqrhizKiIRIVnCf 1fT9nYAtamv3TQrZsgIRRhpgBjbiRhU+8KC+8nRYDmzXYaKdh3pWzZnbaT6IwiWe8a 28u3H1rA0xiZGPPfskQ8D76BQll/+zcjFRXNn8lP5TZktmJhEOLFMr+ojPRiiNtwgj iVL1rbm5tnGmw== X-Spam-Level: Received: from gaia (localhost [127.0.0.1]) by nautica.notk.org (Postfix) with ESMTPS id B3BC4C009; Tue, 24 Oct 2023 01:37:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1698104242; bh=/A34CTskJseJi+dcqA1uEIZC2XG2pVw2hHNklQEakQo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H9q202+phVyt45nk/teha6weJN6/png6bkYoZNW6ao1p6BRyO4FgYWMGIk6gSm4yv x+Rdsf2lO5NyDeiJocV63AiF77nMyntK2AXb0yjd4QgRJaPRTcnGAizwfR8OFCU3Fh XGmc27IUykFBEgB2AYeA47YCFFx3H4+HUc2gTcEebovIS63OVAshRNGQGfhUF9UsAq VZKjILf2nDgY/sL0cr0KcwiBiGWQPEdquVObzzsD2EHShTwkze9tF78G9Qeztdu6lN OpODxoG+xIiGbgNx9U7Slo+cW1IeCiPRfOKXnae6VxgHyg2KvuSZJ1ZlcmsdakVcxP 7AD0G8iwggf8Q== Received: from gaia.codewreck.org (localhost.lan [::1]) by gaia (OpenSMTPD) with ESMTP id 1bf2bc7c; Mon, 23 Oct 2023 23:37:15 +0000 (UTC) From: Dominique Martinet To: v9fs@lists.linux.dev, ericvh@kernel.org, linux_oss@crudebyte.com Cc: lucho@ionkov.net, linux-kernel@vger.kernel.org, Marco Elver , syzbot+e441aeeb422763cc5511@syzkaller.appspotmail.com, Dominique Martinet Subject: [PATCH 1/3] 9p: Annotate data-racy writes to file::f_flags on fd mount Date: Tue, 24 Oct 2023 08:37:02 +0900 Message-ID: <20231023233704.1185154-2-asmadeus@codewreck.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231023233704.1185154-1-asmadeus@codewreck.org> References: <20231023233704.1185154-1-asmadeus@codewreck.org> Precedence: bulk X-Mailing-List: v9fs@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Marco Elver syzbot reported: | BUG: KCSAN: data-race in p9_fd_create / p9_fd_create | | read-write to 0xffff888130fb3d48 of 4 bytes by task 15599 on cpu 0: | p9_fd_open net/9p/trans_fd.c:842 [inline] | p9_fd_create+0x210/0x250 net/9p/trans_fd.c:1092 | p9_client_create+0x595/0xa70 net/9p/client.c:1010 | v9fs_session_init+0xf9/0xd90 fs/9p/v9fs.c:410 | v9fs_mount+0x69/0x630 fs/9p/vfs_super.c:123 | legacy_get_tree+0x74/0xd0 fs/fs_context.c:611 | vfs_get_tree+0x51/0x190 fs/super.c:1519 | do_new_mount+0x203/0x660 fs/namespace.c:3335 | path_mount+0x496/0xb30 fs/namespace.c:3662 | do_mount fs/namespace.c:3675 [inline] | __do_sys_mount fs/namespace.c:3884 [inline] | [...] | | read-write to 0xffff888130fb3d48 of 4 bytes by task 15563 on cpu 1: | p9_fd_open net/9p/trans_fd.c:842 [inline] | p9_fd_create+0x210/0x250 net/9p/trans_fd.c:1092 | p9_client_create+0x595/0xa70 net/9p/client.c:1010 | v9fs_session_init+0xf9/0xd90 fs/9p/v9fs.c:410 | v9fs_mount+0x69/0x630 fs/9p/vfs_super.c:123 | legacy_get_tree+0x74/0xd0 fs/fs_context.c:611 | vfs_get_tree+0x51/0x190 fs/super.c:1519 | do_new_mount+0x203/0x660 fs/namespace.c:3335 | path_mount+0x496/0xb30 fs/namespace.c:3662 | do_mount fs/namespace.c:3675 [inline] | __do_sys_mount fs/namespace.c:3884 [inline] | [...] | | value changed: 0x00008002 -> 0x00008802 Within p9_fd_open(), O_NONBLOCK is added to f_flags of the read and write files. This may happen concurrently if e.g. mounting process modifies the fd in another thread. Mark the plain read-modify-writes as intentional data-races, with the assumption that the result of executing the accesses concurrently will always result in the same result despite the accesses themselves not being atomic. Reported-by: syzbot+e441aeeb422763cc5511@syzkaller.appspotmail.com Signed-off-by: Marco Elver Link: https://lore.kernel.org/r/ZO38mqkS0TYUlpFp@elver.google.com Signed-off-by: Dominique Martinet --- Hi Marco, sorry for taking ages to process this patch. I've reworded the commit message a bit and added a comment, so given this has your name on it please have a look. I'm planning to send this to Linus during the merge window next week net/9p/trans_fd.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c index f226953577b2..d89c88986950 100644 --- a/net/9p/trans_fd.c +++ b/net/9p/trans_fd.c @@ -836,14 +836,16 @@ static int p9_fd_open(struct p9_client *client, int rfd, int wfd) goto out_free_ts; if (!(ts->rd->f_mode & FMODE_READ)) goto out_put_rd; - /* prevent workers from hanging on IO when fd is a pipe */ - ts->rd->f_flags |= O_NONBLOCK; + /* Prevent workers from hanging on IO when fd is a pipe + * We don't support userspace messing with the fd after passing it + * to mount, so flag possible data race for KCSAN */ + data_race(ts->rd->f_flags |= O_NONBLOCK); ts->wr = fget(wfd); if (!ts->wr) goto out_put_rd; if (!(ts->wr->f_mode & FMODE_WRITE)) goto out_put_wr; - ts->wr->f_flags |= O_NONBLOCK; + data_race(ts->wr->f_flags |= O_NONBLOCK); client->trans = ts; client->status = Connected; From patchwork Mon Oct 23 23:37:03 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Dominique Martinet X-Patchwork-Id: 13433718 Received: from nautica.notk.org (nautica.notk.org [91.121.71.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE0742376A for ; Mon, 23 Oct 2023 23:37:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codewreck.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codewreck.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b="ldMR/5s1"; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b="ldMR/5s1" Received: by nautica.notk.org (Postfix, from userid 108) id EC9C3C01C; Tue, 24 Oct 2023 01:37:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1698104246; bh=DieO6nLmhMIqZKysrRjkquiB3ylJYMRIAY1/0apJM7M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ldMR/5s1aEDMSt/4JHtx3ytpCH02TK1IjzclsiD3vV/jGgHI5o4CAEEhdbe2VFiuL ykV2SYqK0o+3+L/OuICoC3lDjOBVAqiiePcA7vPx7a4MZCKE7qTI4S1miw2pH4/6ed 8xfaPCcrejJKMtvSqj1aXXBAStHbpf2jmHahWlRZkaMz0X+uu70vqBIcZMGOncxpst 1fMe7I/m5YLEZC+ARzv/al35YRI36tAoQ2I8O48RVsL5kuf9qOUUlHElKPX46GWkBr iPm3ZB1VHBNxcceiTYj9V15Svz0cq8saNQOZNa1zmc/vbE0f7fxIKy2bmERd5V+ZXM gxtY4orBogjCA== X-Spam-Level: Received: from gaia (localhost [127.0.0.1]) by nautica.notk.org (Postfix) with ESMTPS id 40535C01A; Tue, 24 Oct 2023 01:37:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1698104246; bh=DieO6nLmhMIqZKysrRjkquiB3ylJYMRIAY1/0apJM7M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ldMR/5s1aEDMSt/4JHtx3ytpCH02TK1IjzclsiD3vV/jGgHI5o4CAEEhdbe2VFiuL ykV2SYqK0o+3+L/OuICoC3lDjOBVAqiiePcA7vPx7a4MZCKE7qTI4S1miw2pH4/6ed 8xfaPCcrejJKMtvSqj1aXXBAStHbpf2jmHahWlRZkaMz0X+uu70vqBIcZMGOncxpst 1fMe7I/m5YLEZC+ARzv/al35YRI36tAoQ2I8O48RVsL5kuf9qOUUlHElKPX46GWkBr iPm3ZB1VHBNxcceiTYj9V15Svz0cq8saNQOZNa1zmc/vbE0f7fxIKy2bmERd5V+ZXM gxtY4orBogjCA== Received: from gaia.codewreck.org (localhost.lan [::1]) by gaia (OpenSMTPD) with ESMTP id c8ad982d; Mon, 23 Oct 2023 23:37:16 +0000 (UTC) From: Dominique Martinet To: v9fs@lists.linux.dev, ericvh@kernel.org, linux_oss@crudebyte.com Cc: lucho@ionkov.net, linux-kernel@vger.kernel.org, Dominique Martinet , Su Hui , Dan Carpenter Subject: [PATCH 2/3] 9p: v9fs_listxattr: fix %s null argument warning Date: Tue, 24 Oct 2023 08:37:03 +0900 Message-ID: <20231023233704.1185154-3-asmadeus@codewreck.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231023233704.1185154-1-asmadeus@codewreck.org> References: <20231023233704.1185154-1-asmadeus@codewreck.org> Precedence: bulk X-Mailing-List: v9fs@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 W=1 warns about null argument to kprintf: In file included from fs/9p/xattr.c:12: In function ‘v9fs_xattr_get’, inlined from ‘v9fs_listxattr’ at fs/9p/xattr.c:142:9: include/net/9p/9p.h:55:2: error: ‘%s’ directive argument is null [-Werror=format-overflow=] 55 | _p9_debug(level, __func__, fmt, ##__VA_ARGS__) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Use an empty string instead of : - this is ok 9p-wise because p9pdu_vwritef serializes a null string and an empty string the same way (one '0' word for length) - since this degrades the print statements, add new single quotes for xattr's name delimter (Old: "file = (null)", new: "file = ''") Signed-off-by: Dominique Martinet Link: https://lore.kernel.org/r/20231008060138.517057-1-suhui@nfschina.com Suggested-by: Su Hui Cc: Dan Carpenter Acked-by: Christian Schoenebeck --- I've checked this works as expected (getfattr listing all user.* xattrs after setting some), so let's fix this warning. As pointed out by Dan this makes the message les clear, so I added single quotes to make it clear we're dealing with an empty string; I think it's good enough. Su, I made you only Suggested-by because of the extra legwork and format changes, but happy to give you authorship if it's something you care about; I'd just like to get it out during the next merge window in a couple of weeks so please say the word. This makes fs/9p build warning-free with W=1 on gcc 12 fs/9p/xattr.c | 4 ++-- net/9p/client.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/9p/xattr.c b/fs/9p/xattr.c index e00cf8109b3f..d29907c378fd 100644 --- a/fs/9p/xattr.c +++ b/fs/9p/xattr.c @@ -68,7 +68,7 @@ ssize_t v9fs_xattr_get(struct dentry *dentry, const char *name, struct p9_fid *fid; int ret; - p9_debug(P9_DEBUG_VFS, "name = %s value_len = %zu\n", + p9_debug(P9_DEBUG_VFS, "name = '%s' value_len = %zu\n", name, buffer_size); fid = v9fs_fid_lookup(dentry); if (IS_ERR(fid)) @@ -139,7 +139,7 @@ int v9fs_fid_xattr_set(struct p9_fid *fid, const char *name, ssize_t v9fs_listxattr(struct dentry *dentry, char *buffer, size_t buffer_size) { - return v9fs_xattr_get(dentry, NULL, buffer, buffer_size); + return v9fs_xattr_get(dentry, "", buffer, buffer_size); } static int v9fs_xattr_handler_get(const struct xattr_handler *handler, diff --git a/net/9p/client.c b/net/9p/client.c index 86bbc7147fc1..9c2bc15e3cfa 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -1979,7 +1979,7 @@ struct p9_fid *p9_client_xattrwalk(struct p9_fid *file_fid, goto error; } p9_debug(P9_DEBUG_9P, - ">>> TXATTRWALK file_fid %d, attr_fid %d name %s\n", + ">>> TXATTRWALK file_fid %d, attr_fid %d name '%s'\n", file_fid->fid, attr_fid->fid, attr_name); req = p9_client_rpc(clnt, P9_TXATTRWALK, "dds", From patchwork Mon Oct 23 23:37:04 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Dominique Martinet X-Patchwork-Id: 13433719 Received: from nautica.notk.org (nautica.notk.org [91.121.71.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7EE3024211 for ; Mon, 23 Oct 2023 23:37:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codewreck.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codewreck.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b="JoAGkMLw"; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b="yTkF16U1" Received: by nautica.notk.org (Postfix, from userid 108) id 446C0C027; Tue, 24 Oct 2023 01:37:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1698104248; bh=PAQp5SIrJ7XuUtekxxpfQVf8Z9TTes94CioyEDOPYG4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JoAGkMLwF/hU60s6Sgh6rf6EguqlKFuoHACG0Fy8iSD+CB2vnarVD57Z++VTvSxAe xCNg8/ezhNR/eerd763GH06GEG2fjtZ7UdP0g//Kj/hYtR5zfVIkC2YUxqnkniHvLY jYO0BBOKNLelxt6ZVXTeCxmq57ssiPf2r+PjlCO9s1K/AZQYAGncXc3tghwCOE4Rnb +dQdkHTp9MNOo9fOOnD6MwFCytqnTjIBqTwKj0gSenKAqFp8M8LEl4oLGpmNcGRwKR jrm9szAuoRa7U64tQVtaQtjEfGyA96vtgHPih25D18Gj5h47sIFsr39GbU5ZuL53fK roNPIulDdFgOg== X-Spam-Level: Received: from gaia (localhost [127.0.0.1]) by nautica.notk.org (Postfix) with ESMTPS id D30EAC009; Tue, 24 Oct 2023 01:37:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1698104247; bh=PAQp5SIrJ7XuUtekxxpfQVf8Z9TTes94CioyEDOPYG4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yTkF16U1S0b5LURxbJwpDpE8+qs0L83azlbkQc8rpwPkYLUiztpmKeMRFHxtjkwEO uPiqz3RQGZO7C4oVxea87MzcKR71nqC8b7HgbhaiPh8A3voiGHGEYfi8XeCVdfXBdN QGv0WKg/jWAB64PEbFEc18LG4kFh5OzMcnn0VVgT3o/c/mmC7TH+2iEO+9ne0CPsxI 9Hg9gNFAjAEQHOQVL8ylY97Wlw4a11NQKhnhPEdlEHqdoNjxMPsQsvtPYqx5aY4DO+ 3VDoLhOChf5YgixX329Sk8PgD6Oq/2wJ85b1Vok7JZQp3uQX3p6nQAbRefi4NRCT24 79aw9kHvY/ulg== Received: from gaia.codewreck.org (localhost.lan [::1]) by gaia (OpenSMTPD) with ESMTP id 0a3de4cb; Mon, 23 Oct 2023 23:37:17 +0000 (UTC) From: Dominique Martinet To: v9fs@lists.linux.dev, ericvh@kernel.org, linux_oss@crudebyte.com Cc: lucho@ionkov.net, linux-kernel@vger.kernel.org, Dominique Martinet Subject: [PATCH 3/3] 9p/net: xen: fix false positive printf format overflow warning Date: Tue, 24 Oct 2023 08:37:04 +0900 Message-ID: <20231023233704.1185154-4-asmadeus@codewreck.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231023233704.1185154-1-asmadeus@codewreck.org> References: <20231023233704.1185154-1-asmadeus@codewreck.org> Precedence: bulk X-Mailing-List: v9fs@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Use a local variable to make the compiler happy about this warning: net/9p/trans_xen.c: In function ‘xen_9pfs_front_changed’: net/9p/trans_xen.c:444:39: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of size 8 [-Wformat-overflow=] 444 | sprintf(str, "ring-ref%d", i); | ^~ In function ‘xen_9pfs_front_init’, inlined from ‘xen_9pfs_front_changed’ at net/9p/trans_xen.c:516:8, inlined from ‘xen_9pfs_front_changed’ at net/9p/trans_xen.c:504:13: net/9p/trans_xen.c:444:30: note: directive argument in the range [-2147483644, 2147483646] 444 | sprintf(str, "ring-ref%d", i); | ^~~~~~~~~~~~ net/9p/trans_xen.c:444:17: note: ‘sprintf’ output between 10 and 20 bytes into a destination of size 16 444 | sprintf(str, "ring-ref%d", i); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ net/9p/trans_xen.c: In function ‘xen_9pfs_front_changed’: net/9p/trans_xen.c:450:45: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of size 2 [-Wformat-overflow=] 450 | sprintf(str, "event-channel-%d", i); | ^~ In function ‘xen_9pfs_front_init’, inlined from ‘xen_9pfs_front_changed’ at net/9p/trans_xen.c:516:8, inlined from ‘xen_9pfs_front_changed’ at net/9p/trans_xen.c:504:13: net/9p/trans_xen.c:450:30: note: directive argument in the range [-2147483644, 2147483646] 450 | sprintf(str, "event-channel-%d", i); | ^~~~~~~~~~~~~~~~~~ net/9p/trans_xen.c:450:17: note: ‘sprintf’ output between 16 and 26 bytes into a destination of size 16 450 | sprintf(str, "event-channel-%d", i); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There is no change in logic: there only are a constant number of rings, and there also already is a BUILD_BUG_ON that checks if that constant goes over 9 as anything bigger would no longer fit the event-channel-%d destination size. In theory having that size as part of the struct means it could be modified by another thread and makes the compiler lose track of possible values for 'i' here, using a local variable makes it happy. Signed-off-by: Dominique Martinet --- While looking at warnings with W=1, I noticed this one in net/9p. This is silly but shouldn't hurt, num_rings is never changed so there is no risk of introducing a race here, it's just helping the compiler a bit. net/9p is also now warning-free at W=1 net/9p/trans_xen.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c index 1fffe2bed5b0..79e91f31a84a 100644 --- a/net/9p/trans_xen.c +++ b/net/9p/trans_xen.c @@ -382,7 +382,7 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) struct xenbus_transaction xbt; struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev); char *versions, *v; - unsigned int max_rings, max_ring_order, len = 0; + unsigned int num_rings, max_rings, max_ring_order, len = 0; versions = xenbus_read(XBT_NIL, dev->otherend, "versions", &len); if (IS_ERR(versions)) @@ -408,15 +408,15 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) if (p9_xen_trans.maxsize > XEN_FLEX_RING_SIZE(max_ring_order)) p9_xen_trans.maxsize = XEN_FLEX_RING_SIZE(max_ring_order) / 2; - priv->num_rings = XEN_9PFS_NUM_RINGS; - priv->rings = kcalloc(priv->num_rings, sizeof(*priv->rings), + num_rings = priv->num_rings = XEN_9PFS_NUM_RINGS; + priv->rings = kcalloc(num_rings, sizeof(*priv->rings), GFP_KERNEL); if (!priv->rings) { kfree(priv); return -ENOMEM; } - for (i = 0; i < priv->num_rings; i++) { + for (i = 0; i < num_rings; i++) { priv->rings[i].priv = priv; ret = xen_9pfs_front_alloc_dataring(dev, &priv->rings[i], max_ring_order); @@ -434,10 +434,11 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) if (ret) goto error_xenbus; ret = xenbus_printf(xbt, dev->nodename, "num-rings", "%u", - priv->num_rings); + num_rings); if (ret) goto error_xenbus; - for (i = 0; i < priv->num_rings; i++) { + + for (i = 0; i < num_rings; i++) { char str[16]; BUILD_BUG_ON(XEN_9PFS_NUM_RINGS > 9);