From: Nishanth Aravamudan <nacc-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Chris J Arges <chris.j.arges-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-numa-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
Subject: Re: [PATCH v2] openvswitch: allocate nr_node_ids flow_stats instead of num_possible_nodes
Date: Tue, 21 Jul 2015 15:02:22 -0700 [thread overview]
Message-ID: <20150721220222.GB29402@linux.vnet.ibm.com> (raw)
In-Reply-To: <1437500193-10255-1-git-send-email-chris.j.arges-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
On 21.07.2015 [12:36:33 -0500], Chris J Arges wrote:
> Some architectures like POWER can have a NUMA node_possible_map that
> contains sparse entries. This causes memory corruption with openvswitch
> since it allocates flow_cache with a multiple of num_possible_nodes() and
> assumes the node variable returned by for_each_node will index into
> flow->stats[node].
>
> Use nr_node_ids to allocate a maximal sparse array instead of
> num_possible_nodes().
>
> The crash was noticed after 3af229f2 was applied as it changed the
> node_possible_map to match node_online_map on boot.
> Fixes: 3af229f2071f5b5cb31664be6109561fbe19c861
>
> Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
> ---
> net/openvswitch/flow_table.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
> index 4613df8..6552394 100644
> --- a/net/openvswitch/flow_table.c
> +++ b/net/openvswitch/flow_table.c
> @@ -752,7 +752,7 @@ int ovs_flow_init(void)
> BUILD_BUG_ON(sizeof(struct sw_flow_key) % sizeof(long));
>
> flow_cache = kmem_cache_create("sw_flow", sizeof(struct sw_flow)
> - + (num_possible_nodes()
> + + (nr_node_ids
> * sizeof(struct flow_stats *)),
> 0, 0, NULL);
> if (flow_cache == NULL)
> --
> 1.9.1
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
To: Chris J Arges <chris.j.arges@canonical.com>
Cc: pshelar@nicira.com, linuxppc-dev@lists.ozlabs.org,
benh@kernel.crashing.org, linux-numa@vger.kernel.org,
davem@davemloft.net, netdev@vger.kernel.org, dev@openvswitch.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] openvswitch: allocate nr_node_ids flow_stats instead of num_possible_nodes
Date: Tue, 21 Jul 2015 15:02:22 -0700 [thread overview]
Message-ID: <20150721220222.GB29402@linux.vnet.ibm.com> (raw)
In-Reply-To: <1437500193-10255-1-git-send-email-chris.j.arges@canonical.com>
On 21.07.2015 [12:36:33 -0500], Chris J Arges wrote:
> Some architectures like POWER can have a NUMA node_possible_map that
> contains sparse entries. This causes memory corruption with openvswitch
> since it allocates flow_cache with a multiple of num_possible_nodes() and
> assumes the node variable returned by for_each_node will index into
> flow->stats[node].
>
> Use nr_node_ids to allocate a maximal sparse array instead of
> num_possible_nodes().
>
> The crash was noticed after 3af229f2 was applied as it changed the
> node_possible_map to match node_online_map on boot.
> Fixes: 3af229f2071f5b5cb31664be6109561fbe19c861
>
> Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
> ---
> net/openvswitch/flow_table.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
> index 4613df8..6552394 100644
> --- a/net/openvswitch/flow_table.c
> +++ b/net/openvswitch/flow_table.c
> @@ -752,7 +752,7 @@ int ovs_flow_init(void)
> BUILD_BUG_ON(sizeof(struct sw_flow_key) % sizeof(long));
>
> flow_cache = kmem_cache_create("sw_flow", sizeof(struct sw_flow)
> - + (num_possible_nodes()
> + + (nr_node_ids
> * sizeof(struct flow_stats *)),
> 0, 0, NULL);
> if (flow_cache == NULL)
> --
> 1.9.1
>
next prev parent reply other threads:[~2015-07-21 22:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-21 15:32 [PATCH] openvswitch: make for_each_node loops work with sparse numa systems Chris J Arges
2015-07-21 16:24 ` Nishanth Aravamudan
2015-07-21 16:30 ` Chris J Arges
2015-07-21 22:04 ` Nishanth Aravamudan
2015-07-21 17:36 ` [PATCH v2] openvswitch: allocate nr_node_ids flow_stats instead of num_possible_nodes Chris J Arges
[not found] ` <1437500193-10255-1-git-send-email-chris.j.arges-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2015-07-21 18:29 ` Pravin Shelar
2015-07-21 18:29 ` Pravin Shelar
2015-07-21 22:02 ` Nishanth Aravamudan [this message]
2015-07-21 22:02 ` Nishanth Aravamudan
2015-07-22 5:26 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150721220222.GB29402@linux.vnet.ibm.com \
--to=nacc-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
--cc=benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org \
--cc=chris.j.arges-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-numa-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.