All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] [PATCH v3 02/13] lustre: libcfs: open code cfs_trace_max_debug_mb() into cfs_trace_set_debug_mb()
Date: Mon, 02 Jul 2018 12:17:48 +1000	[thread overview]
Message-ID: <87k1qe2xf7.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <8760225jr0.fsf@notabene.neil.brown.name>

On Fri, Jun 29 2018, NeilBrown wrote:
>> It may be that there is a mechanism to limit the value set by module option
>> in newer kernels, but that wasn't the case in the past.
>
> There is such a mechanism now.
> When the libcfs_debug_mb module parameter is detected,
> libcfs_param_debug_mb_set() is called to parse it.
> This function uses kstrtouint() to convert the string
> to unsigned int, and then...... oh, that's odd.
> If the current value of libcfs_debug_mb is zero, then
> then the number is used without further checking.  I hadn't noticed
> that.
> If that current value is non-zero, then the parsed number
> is passed to cfs_trace_set_debug_mb().  I had assumed that
> always happens, and that function imposes the required limit.
>
> I'll fix that up - make sure it always imposes the
> appropriate limit.

I've inserted the following patch before this one.
That makes it correct :-)

Thanks,
NeilBrown

From: NeilBrown <neilb@suse.com>
Date: Mon, 2 Jul 2018 12:14:15 +1000
Subject: [PATCH] lustre: always range-check libcfs_debug_mb setting.

When the libcfs_debug_mb module parameter is set
at module-load time it isn't range-checked.  When
it is set via sysfs it is.  This inconsistency
makes the code harder to follow.

It is quite safe to call cfs_trace_set_debug_mb()
and cfs_trace_get_debug_mb() before the module
is initialized as cfs_tcd_for_each() does nothing
before initializtion.

So change cfs_trace_set_debug_mb() - which does
range checking - to returned the ranged checked number (it currently
always returns zero) and use that as the new value, unless
cfs_trace_get_debug_mb() now returns a non-zero value.

Signed-off-by: NeilBrown <neilb@suse.com>
---
 drivers/staging/lustre/lnet/libcfs/debug.c     | 16 +++++++---------
 drivers/staging/lustre/lnet/libcfs/tracefile.c |  2 +-
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/lustre/lnet/libcfs/debug.c b/drivers/staging/lustre/lnet/libcfs/debug.c
index 06f694f6a28f..50c2995c1c99 100644
--- a/drivers/staging/lustre/lnet/libcfs/debug.c
+++ b/drivers/staging/lustre/lnet/libcfs/debug.c
@@ -67,17 +67,15 @@ static int libcfs_param_debug_mb_set(const char *val,
 	if (rc < 0)
 		return rc;
 
-	if (!*((unsigned int *)kp->arg)) {
-		*((unsigned int *)kp->arg) = num;
-		return 0;
-	}
-
-	rc = cfs_trace_set_debug_mb(num);
+	num = cfs_trace_set_debug_mb(num);
 
-	if (!rc)
-		*((unsigned int *)kp->arg) = cfs_trace_get_debug_mb();
+	*((unsigned int *)kp->arg) = num;
+	num = cfs_trace_get_debug_mb();
+	if (num)
+		/* This value is more precise */
+		*((unsigned int *)kp->arg) = num;
 
-	return rc;
+	return 0;
 }
 
 /* While debug_mb setting look like unsigned int, in fact
diff --git a/drivers/staging/lustre/lnet/libcfs/tracefile.c b/drivers/staging/lustre/lnet/libcfs/tracefile.c
index 5f319332f60b..3b92fd7d3182 100644
--- a/drivers/staging/lustre/lnet/libcfs/tracefile.c
+++ b/drivers/staging/lustre/lnet/libcfs/tracefile.c
@@ -958,7 +958,7 @@ int cfs_trace_set_debug_mb(int mb)
 
 	up_write(&cfs_tracefile_sem);
 
-	return 0;
+	return mb;
 }
 
 int cfs_trace_get_debug_mb(void)
-- 
2.14.0.rc0.dirty

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20180702/dc2265db/attachment.sig>

  reply	other threads:[~2018-07-02  2:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-27 19:38 [lustre-devel] [PATCH v3 00/13] lustre: libcfs: tracefile cleanups James Simmons
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 01/13] lustre: libcfs: move tracefile locking from linux-tracefile.c to tracefile.c James Simmons
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 02/13] lustre: libcfs: open code cfs_trace_max_debug_mb() into cfs_trace_set_debug_mb() James Simmons
2018-06-28 22:39   ` Andreas Dilger
2018-06-29  3:55     ` NeilBrown
2018-07-02  2:17       ` NeilBrown [this message]
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 03/13] lustre: libcfs: move tcd locking across to tracefile.c James Simmons
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 04/13] lustre: libcfs: fix cfs_print_to_console() James Simmons
2018-06-27 21:27   ` NeilBrown
2018-06-28 22:30   ` Andreas Dilger
2018-06-29 16:17     ` James Simmons
2018-07-02  2:27       ` NeilBrown
2018-07-05 23:34         ` James Simmons
2018-07-05 23:35         ` James Simmons
2018-07-06  4:19           ` NeilBrown
2018-07-06 17:09           ` Andreas Dilger
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 05/13] lustre: libcfs: properly handle failure paths in cfs_tracefile_init_arch() James Simmons
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 06/13] lustre: libcfs: merge linux-tracefile.c into tracefile.c James Simmons
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 07/13] lustre: libcfs: remove cfs_trace_refill_stack() James Simmons
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 08/13] lustre: libcfs: move cfs_trace_data data to tracefile.c James Simmons
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 09/13] lustre: libcfs: cleanup tracefile.h James Simmons
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 10/13] lustre: libcfs: fold cfs_tracefile_*_arch into their only callers James Simmons
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 11/13] lustre: libcfs: renamed CFS_TCD_TYPE_MAX to CFS_TCD_TYPE_CNT James Simmons
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 12/13] lustre: libcfs: discard TCD_MAX_TYPES James Simmons
2018-06-27 19:38 ` [lustre-devel] [PATCH v3 13/13] lustre: libcfs: format macros in tracefile.h James Simmons

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=87k1qe2xf7.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=lustre-devel@lists.lustre.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.