From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: James Simmons <jsimmons@infradead.org>
Cc: devel@driverdev.osuosl.org,
Andreas Dilger <andreas.dilger@intel.com>,
Oleg Drokin <oleg.drokin@intel.com>, NeilBrown <neilb@suse.com>,
Dmitry Eremin <dmitry.eremin@intel.com>,
Amir Shehata <amir.shehata@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lustre Development List <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH v2 23/25] staging: lustre: libcfs: rework CPU pattern parsing code
Date: Fri, 1 Jun 2018 10:43:47 +0200 [thread overview]
Message-ID: <20180601084347.GH19242@kroah.com> (raw)
In-Reply-To: <1527603725-30560-24-git-send-email-jsimmons@infradead.org>
On Tue, May 29, 2018 at 10:22:03AM -0400, James Simmons wrote:
> From: Dmitry Eremin <dmitry.eremin@intel.com>
>
> Currently the module param string for CPU pattern can be
> modified which is wrong. Rewrite CPU pattern parsing code
> to avoid the passed buffer from being changed. This change
> also enables us to add real errors propogation to the caller
> functions.
>
> Signed-off-by: Dmitry Eremin <dmitry.eremin@intel.com>
> Signed-off-by: Amir Shehata <amir.shehata@intel.com>
> Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8703
> Reviewed-on: https://review.whamcloud.com/23306
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-9715
> Reviewed-on: https://review.whamcloud.com/27872
> Reviewed-by: James Simmons <uja.ornl@yahoo.com>
> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
> Reviewed-by: Patrick Farrell <paf@cray.com>
> Reviewed-by: Olaf Weber <olaf.weber@hpe.com>
> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
> Signed-off-by: James Simmons <jsimmons@infradead.org>
> ---
> Changelog:
>
> v1) Initial patch
> v2) Rebased patch. No changes in code from earlier patch
>
> .../lustre/include/linux/libcfs/libcfs_cpu.h | 2 +-
> drivers/staging/lustre/lnet/libcfs/libcfs_cpu.c | 146 ++++++++++++---------
> 2 files changed, 87 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_cpu.h b/drivers/staging/lustre/include/linux/libcfs/libcfs_cpu.h
> index c0aa0b3..12ed0a9 100644
> --- a/drivers/staging/lustre/include/linux/libcfs/libcfs_cpu.h
> +++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_cpu.h
> @@ -393,7 +393,7 @@ static inline int cfs_cpu_init(void)
>
> static inline void cfs_cpu_fini(void)
> {
> - if (cfs_cpt_tab) {
> + if (!IS_ERR_OR_NULL(cfs_cpt_tab)) {
> cfs_cpt_table_free(cfs_cpt_tab);
> cfs_cpt_tab = NULL;
> }
> diff --git a/drivers/staging/lustre/lnet/libcfs/libcfs_cpu.c b/drivers/staging/lustre/lnet/libcfs/libcfs_cpu.c
> index 649f7f9..aed48de 100644
> --- a/drivers/staging/lustre/lnet/libcfs/libcfs_cpu.c
> +++ b/drivers/staging/lustre/lnet/libcfs/libcfs_cpu.c
> @@ -692,11 +692,11 @@ int cfs_cpt_bind(struct cfs_cpt_table *cptab, int cpt)
> nodemask = cptab->ctb_parts[cpt].cpt_nodemask;
> }
>
> - if (cpumask_any_and(*cpumask, cpu_online_mask) >= nr_cpu_ids) {
> + if (!cpumask_intersects(*cpumask, cpu_online_mask)) {
> CDEBUG(D_INFO,
> "No online CPU found in CPU partition %d, did someone do CPU hotplug on system? You might need to reload Lustre modules to keep system working well.\n",
> cpt);
This is the funniest error message I have seen in a while.
No one should have to reload all kernel modules just because the CPU
topology changed, that's crazy. You have the ability to read all of
this at runtime, and react to changes that happen while the system is
running. You should never need/rely on userspace passing in random
strings to pretend to match up with what the system really has at the
moment, that way lies madness.
All of this should be ripped out and use the proper apis instead. No
special userspace api should be needed at all.
greg k-h
next prev parent reply other threads:[~2018-06-01 8:44 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-29 14:21 [PATCH v2 00/25] staging: lustre: libcfs: SMP rework James Simmons
2018-05-29 14:21 ` [PATCH v2 01/25] staging: lustre: libcfs: restore UMP handling James Simmons
2018-05-29 23:45 ` NeilBrown
2018-06-13 22:02 ` James Simmons
2018-06-13 22:18 ` [lustre-devel] " Doug Oucharek
2018-06-13 22:29 ` NeilBrown
2018-05-30 10:05 ` Dan Carpenter
2018-05-29 14:21 ` [PATCH v2 02/25] staging: lustre: libcfs: remove useless CPU partition code James Simmons
2018-05-29 14:21 ` [PATCH v2 03/25] staging: lustre: libcfs: rename variable i to cpu James Simmons
2018-05-29 14:21 ` [PATCH v2 04/25] staging: lustre: libcfs: properly handle failure cases in SMP code James Simmons
2018-05-29 14:21 ` [PATCH v2 05/25] staging: lustre: libcfs: replace MAX_NUMNODES with nr_node_ids James Simmons
2018-05-29 14:21 ` [PATCH v2 06/25] staging: lustre: libcfs: remove excess space James Simmons
2018-05-29 14:21 ` [PATCH v2 v2 07/25] staging: lustre: libcfs: replace num_possible_cpus() with nr_cpu_ids James Simmons
2018-06-01 8:29 ` Greg Kroah-Hartman
2018-06-01 8:31 ` Greg Kroah-Hartman
2018-05-29 14:21 ` [PATCH v2 08/25] staging: lustre: libcfs: NUMA support James Simmons
2018-06-01 8:37 ` Greg Kroah-Hartman
2018-05-29 14:21 ` [PATCH v2 09/25] staging: lustre: libcfs: add cpu distance handling James Simmons
2018-05-29 14:21 ` [PATCH v2 10/25] staging: lustre: libcfs: use distance in cpu and node handling James Simmons
2018-05-29 14:21 ` [PATCH v2 11/25] staging: lustre: libcfs: provide debugfs files for distance handling James Simmons
2018-06-01 8:41 ` Greg Kroah-Hartman
2018-05-29 14:21 ` [PATCH v2 12/25] staging: lustre: libcfs: invert error handling for cfs_cpt_table_print James Simmons
2018-05-29 14:21 ` [PATCH v2 13/25] staging: lustre: libcfs: fix libcfs_cpu coding style James Simmons
2018-06-01 8:39 ` Greg Kroah-Hartman
2018-05-29 14:21 ` [PATCH v2 14/25] staging: lustre: libcfs: use int type for CPT identification James Simmons
2018-05-29 14:21 ` [PATCH v2 15/25] staging: lustre: libcfs: rename i to node for cfs_cpt_set_nodemask James Simmons
2018-05-29 14:21 ` [PATCH v2 16/25] staging: lustre: libcfs: rename i to cpu for cfs_cpt_bind James Simmons
2018-05-29 14:21 ` [PATCH v2 17/25] staging: lustre: libcfs: rename cpumask_var_t variables to *_mask James Simmons
2018-05-29 14:21 ` [PATCH v2 18/25] staging: lustre: libcfs: rename goto label in cfs_cpt_table_print James Simmons
2018-06-01 8:33 ` Greg Kroah-Hartman
2018-05-29 14:21 ` [PATCH v2 19/25] staging: lustre: libcfs: update debug messages James Simmons
2018-05-29 14:22 ` [PATCH v2 20/25] staging: lustre: libcfs: make tolerant to offline CPUs and empty NUMA nodes James Simmons
2018-05-29 14:22 ` [PATCH v2 21/25] staging: lustre: libcfs: report NUMA node instead of just node James Simmons
2018-05-29 14:22 ` [PATCH v2 22/25] staging: lustre: libcfs: update debug messages in CPT code James Simmons
2018-05-29 14:22 ` [PATCH v2 23/25] staging: lustre: libcfs: rework CPU pattern parsing code James Simmons
2018-06-01 8:43 ` Greg Kroah-Hartman [this message]
2018-05-29 14:22 ` [PATCH v2 24/25] staging: lustre: libcfs: change CPT estimate algorithm James Simmons
2018-05-29 14:22 ` [PATCH v2 25/25] staging: lustre: ptlrpc: use current CPU instead of hardcoded 0 James Simmons
2018-06-01 8:28 ` [PATCH v2 00/25] staging: lustre: libcfs: SMP rework Greg Kroah-Hartman
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=20180601084347.GH19242@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=amir.shehata@intel.com \
--cc=andreas.dilger@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=dmitry.eremin@intel.com \
--cc=jsimmons@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lustre-devel@lists.lustre.org \
--cc=neilb@suse.com \
--cc=oleg.drokin@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