From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Hajkowski <marcinx.hajkowski@intel.com>, david.hunt@intel.com
Cc: dev@dpdk.org, Lukasz Krakowiak <lukaszx.krakowiak@intel.com>,
Lukasz Gosiewski <lukaszx.gosiewski@intel.com>
Subject: Re: [dpdk-dev] [PATCH v4 1/2] power: add fifo per core for JSON interface
Date: Mon, 8 Jul 2019 14:44:32 +0100 [thread overview]
Message-ID: <400b5cf3-7b47-3335-18bd-df250e32e6ad@intel.com> (raw)
In-Reply-To: <20190613092117.7252-2-marcinx.hajkowski@intel.com>
On 13-Jun-19 10:21 AM, Hajkowski wrote:
> From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
>
> This patch implement a separate FIFO for each cpu core.
> For proper handling JSON interface, removed fields from cmds:
> core_list, resource_id, name.
>
> Signed-off-by: Lukasz Krakowiak <lukaszx.krakowiak@intel.com>
> Signed-off-by: Lukasz Gosiewski <lukaszx.gosiewski@intel.com>
> Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
> ---
<snip>
> - RTE_LOG(ERR, CHANNEL_MANAGER, "Error allocating memory for "
> - "channel '%s'\n", socket_path);
> - return 0;
> - }
> - rte_strlcpy(chan_info->channel_path, socket_path, UNIX_PATH_MAX);
> + do {
> + if (ci->cd[num_channels_enabled].global_enabled_cpus == 0)
> + continue;
>
> - if (setup_host_channel_info(&chan_info, 0) < 0) {
> - rte_free(chan_info);
> - return 0;
> - }
> - num_channels_enabled++;
> + ret = fifo_path(socket_path, sizeof(socket_path),
> + num_channels_enabled);
> + if (ret < 0)
> + return 0;
So if we encounter *any* failure, *all* channels become invalid? Should
we at least roll back the changes we've made by this point? This is
consistent with previous behavior so maybe not in this patch, but still...
> +
> + ret = mkfifo(socket_path, 0660);
> + RTE_LOG(DEBUG, CHANNEL_MANAGER, "TRY CREATE fifo '%s'\n",
> + socket_path);
> + if ((errno != EEXIST) && (ret < 0)) {
> + RTE_LOG(ERR, CHANNEL_MANAGER, "Cannot create fifo '%s' error: "
> + "%s\n", socket_path, strerror(errno));
> + return 0;
> + }
> +
> + if (access(socket_path, F_OK) < 0) {
> + RTE_LOG(ERR, CHANNEL_MANAGER, "Channel path '%s' error: "
> + "%s\n", socket_path, strerror(errno));
> + return 0;
> + }
I believe this is not needed. Trying to do this here is a TOCTOU issue,
and if the access fails on open later, you handle that and free the
channel info anyway, so this check is essentially useless.
> + chan_info = rte_malloc(NULL, sizeof(*chan_info), 0);
> + if (chan_info == NULL) {
> + RTE_LOG(ERR, CHANNEL_MANAGER, "Error allocating memory for "
> + "channel '%s'\n", socket_path);
> + return 0;
> + }
> + strlcpy(chan_info->channel_path, socket_path,
> + sizeof(chan_info->channel_path));
should this be rte_strlcpy?
> +
> + if (setup_host_channel_info(&chan_info,
> + num_channels_enabled) < 0) {
> + rte_free(chan_info);
> + return 0;
> + }
> + } while (++num_channels_enabled <= ci->core_count);
This looks like a for-loop, why is `while` used here? I mean, i don't
care either way, it's just a for-loop would have been a more obvious
choice...
--
Thanks,
Anatoly
next prev parent reply other threads:[~2019-07-08 13:44 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-08 10:45 [dpdk-dev] [PATCH 0/2] " Lukasz Krakowiak
2019-04-08 10:45 ` Lukasz Krakowiak
2019-04-08 10:45 ` [dpdk-dev] [PATCH 1/2] " Lukasz Krakowiak
2019-04-08 10:45 ` Lukasz Krakowiak
2019-04-08 10:45 ` [dpdk-dev] [PATCH 2/2] doc: update according to the fifo per core impl Lukasz Krakowiak
2019-04-08 10:45 ` Lukasz Krakowiak
2019-04-12 13:54 ` [dpdk-dev] [PATCH v2 0/2] power: add fifo per core for JSON interface Lukasz Gosiewski
2019-04-12 13:54 ` Lukasz Gosiewski
2019-04-12 13:54 ` [dpdk-dev] [PATCH v2 1/2] " Lukasz Gosiewski
2019-04-12 13:54 ` Lukasz Gosiewski
2019-04-12 13:54 ` [dpdk-dev] [PATCH v2 2/2] doc: update according to the fifo per core impl Lukasz Gosiewski
2019-04-12 13:54 ` Lukasz Gosiewski
2019-04-22 20:37 ` [dpdk-dev] [PATCH v2 0/2] power: add fifo per core for JSON interface Thomas Monjalon
2019-04-22 20:37 ` Thomas Monjalon
2019-04-24 8:21 ` [dpdk-dev] [PATCH v3 0/2] " Lukasz Gosiewski
2019-04-24 8:21 ` Lukasz Gosiewski
2019-04-24 8:21 ` [dpdk-dev] [PATCH v3 1/2] power: " Lukasz Gosiewski
2019-04-24 8:21 ` Lukasz Gosiewski
2019-06-07 8:26 ` Hajkowski, MarcinX
2019-04-24 8:21 ` [dpdk-dev] [PATCH v3 2/2] doc: update according to the fifo per core impl Lukasz Gosiewski
2019-04-24 8:21 ` Lukasz Gosiewski
2019-06-13 9:21 ` [dpdk-dev] [PATCH v4 0/2] Fifo per core Hajkowski
2019-06-13 9:21 ` [dpdk-dev] [PATCH v4 1/2] power: add fifo per core for JSON interface Hajkowski
2019-07-08 13:44 ` Burakov, Anatoly [this message]
2019-07-09 15:07 ` [dpdk-dev] [PATCH v5] " David Hunt
2019-07-09 15:12 ` Burakov, Anatoly
2019-07-09 15:23 ` Hunt, David
2019-07-09 15:21 ` [dpdk-dev] [PATCH v6] " David Hunt
2019-07-09 15:27 ` Hunt, David
2019-07-09 15:38 ` Thomas Monjalon
2019-07-10 21:55 ` Thomas Monjalon
2019-06-13 9:21 ` [dpdk-dev] [PATCH v4 2/2] doc: update according to the fifo per core impl Hajkowski
2019-07-08 13:34 ` Burakov, Anatoly
2019-07-08 15:46 ` Hunt, David
2019-07-04 20:09 ` [dpdk-dev] [PATCH v4 0/2] Fifo per core Thomas Monjalon
2019-06-07 8:50 ` [dpdk-dev] [PATCH 0/2] power: add fifo per core for JSON interface Hajkowski, MarcinX
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=400b5cf3-7b47-3335-18bd-df250e32e6ad@intel.com \
--to=anatoly.burakov@intel.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=lukaszx.gosiewski@intel.com \
--cc=lukaszx.krakowiak@intel.com \
--cc=marcinx.hajkowski@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).