From paf at cray.com  Thu May  4 18:24:40 2017
From: paf at cray.com (Patrick Farrell)
Date: Thu, 4 May 2017 18:24:40 +0000
Subject: [lustre-devel] Request for review
Message-ID: <CY4PR11MB1751856322B51A0DC95662FCCBEA0@CY4PR11MB1751.namprd11.prod.outlook.com>

Developer types,


I've got an old patch out for LU-8703 (https://jira.hpdd.intel.com/browse/LU-8307), in need of review:
https://review.whamcloud.com/#/c/20888/


It's a pretty simple fix and still applicable now, but it needs reviewers.  So I'm looking for volunteers.  Details are in the ticket.

Any takers?

Thanks,

- Patrick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel_lists.lustre.org/attachments/20170504/7674d08e/attachment.html>

From joe at perches.com  Fri May  5 08:52:36 2017
From: joe at perches.com (Joe Perches)
Date: Fri, 05 May 2017 01:52:36 -0700
Subject: [lustre-devel] [PATCH] staging: lustre: llite: Fix variable
 length array warning
In-Reply-To: <1493966486-6143-1-git-send-email-gurooodas@gmail.com>
References: <1493966486-6143-1-git-send-email-gurooodas@gmail.com>
Message-ID: <1493974356.31950.13.camel@perches.com>

On Thu, 2017-05-04 at 23:41 -0700, Guru Das Srinagesh wrote:
> Fix sparse warning "warning: Variable length array is used." by using
> kmalloc_array to allocate the required amount of memory instead and
> kfree to deallocate memory after use.
[]
> diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c
[]
> @@ -86,7 +86,8 @@ ll_xattr_set_common(const struct xattr_handler *handler,
>  		    const char *name, const void *value, size_t size,
>  		    int flags)
>  {
> -	char fullname[strlen(handler->prefix) + strlen(name) + 1];
> +	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
> +	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_KERNEL);

What happens when this allocation fails?

From kedrot at gmail.com  Fri May  5 13:51:29 2017
From: kedrot at gmail.com (Guillermo O. Freschi)
Date: Fri,  5 May 2017 10:51:29 -0300
Subject: [lustre-devel] [PATCH] drivers: staging/lustre: conrpc.c - fix
	sparse error: incompatible types in comparison expression
	(different address spaces)
Message-ID: <20170505135129.14757-1-kedrot@gmail.com>

Signed-off-by: Guillermo O. Freschi <kedrot at gmail.com>
---
 drivers/staging/lustre/lnet/selftest/conrpc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lnet/selftest/conrpc.c b/drivers/staging/lustre/lnet/selftest/conrpc.c
index da36c55b86d3..f4578200994f 100644
--- a/drivers/staging/lustre/lnet/selftest/conrpc.c
+++ b/drivers/staging/lustre/lnet/selftest/conrpc.c
@@ -487,7 +487,7 @@ lstcon_rpc_trans_interpreter(struct lstcon_rpc_trans *trans,
 				   sizeof(struct list_head)))
 			return -EFAULT;
 
-		if (tmp.next == head_up)
+		if ((struct list_head __user *)tmp.next == head_up)
 			return 0;
 
 		next = tmp.next;
-- 
2.11.0

From kedrot at gmail.com  Fri May  5 13:53:11 2017
From: kedrot at gmail.com (Tordek)
Date: Fri, 5 May 2017 10:53:11 -0300
Subject: [lustre-devel] [PATCH] drivers: staging/lustre: conrpc.c - fix
 sparse error: incompatible types in comparison expression (different
 address spaces)
In-Reply-To: <20170505135129.14757-1-kedrot@gmail.com>
References: <20170505135129.14757-1-kedrot@gmail.com>
Message-ID: <CAKUXR6Mo-3QR0PQGf_7Otx2S3imowZzBD0Xs=xAY-m_sdHGNaw@mail.gmail.com>

This patch makes a lot of new warnings pop up, because the error is
blocking the rest of the file from being processed.

On 5 May 2017 at 10:51, Guillermo O. Freschi <kedrot at gmail.com> wrote:
> Signed-off-by: Guillermo O. Freschi <kedrot at gmail.com>
> ---
>  drivers/staging/lustre/lnet/selftest/conrpc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lnet/selftest/conrpc.c b/drivers/staging/lustre/lnet/selftest/conrpc.c
> index da36c55b86d3..f4578200994f 100644
> --- a/drivers/staging/lustre/lnet/selftest/conrpc.c
> +++ b/drivers/staging/lustre/lnet/selftest/conrpc.c
> @@ -487,7 +487,7 @@ lstcon_rpc_trans_interpreter(struct lstcon_rpc_trans *trans,
>                                    sizeof(struct list_head)))
>                         return -EFAULT;
>
> -               if (tmp.next == head_up)
> +               if ((struct list_head __user *)tmp.next == head_up)
>                         return 0;
>
>                 next = tmp.next;
> --
> 2.11.0
>

From mathiasrav at gmail.com  Thu May  4 16:13:38 2017
From: mathiasrav at gmail.com (Mathias Rav)
Date: Thu,  4 May 2017 12:13:38 -0400
Subject: [lustre-devel] [PATCH 1/2] staging: lustre: lprocfs: Use
	kstrtouint_from_user
In-Reply-To: <20170504161339.15901-1-mathiasrav@gmail.com>
References: <20170504161339.15901-1-mathiasrav@gmail.com>
Message-ID: <20170504161339.15901-2-mathiasrav@gmail.com>

Prefer kstrtouint_from_user to copy_from_user+simple_strtoul.

The helper function lprocfs_wr_uint() is only used to implement
"dump_granted_max" in debugfs.

Note the slight change in semantics: The previous implementation using
simple_strtoul allows garbage after the number, whereas kstrtox only allows
a trailing line break. The previous implementation allowed a write of zero
bytes whereas kstrtox will return -EINVAL. Since this only affects a single
debugfs endpoint, this should be a permissible slight change of semantics
in exchange for 18 fewer lines of code.

Signed-off-by: Mathias Rav <mathiasrav at gmail.com>
---
 .../lustre/lustre/obdclass/lprocfs_status.c        | 22 +---------------------
 1 file changed, 1 insertion(+), 21 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
index 1ec6e3767d81..338ce34d6514 100644
--- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
+++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
@@ -399,27 +399,7 @@ EXPORT_SYMBOL(lprocfs_rd_uint);
 int lprocfs_wr_uint(struct file *file, const char __user *buffer,
 		    unsigned long count, void *data)
 {
-	unsigned *p = data;
-	char dummy[MAX_STRING_SIZE + 1], *end;
-	unsigned long tmp;
-
-	if (count >= sizeof(dummy))
-		return -EINVAL;
-
-	if (count == 0)
-		return 0;
-
-	if (copy_from_user(dummy, buffer, count))
-		return -EFAULT;
-
-	dummy[count] = '\0';
-
-	tmp = simple_strtoul(dummy, &end, 0);
-	if (dummy == end)
-		return -EINVAL;
-
-	*p = (unsigned int)tmp;
-	return count;
+	return kstrtouint_from_user(buffer, count, 0, (unsigned int *)data);
 }
 EXPORT_SYMBOL(lprocfs_wr_uint);
 
-- 
2.12.2

From Valentin.Vidic at CARNet.hr  Fri May  5 05:27:41 2017
From: Valentin.Vidic at CARNet.hr (Valentin Vidic)
Date: Fri,  5 May 2017 07:27:41 +0200
Subject: [lustre-devel] [PATCH v2] staging: lustre: cleanup le32 assignment
	to ldp_flags
In-Reply-To: <20170429154900.25819-1-Valentin.Vidic@CARNet.hr>
References: <20170429154900.25819-1-Valentin.Vidic@CARNet.hr>
Message-ID: <20170505052741.5713-1-Valentin.Vidic@CARNet.hr>

Introduces a local var to collect flags and convert
them to le32.

Fixes the following sparse warnings:

drivers/staging/lustre/lustre/lmv/lmv_obd.c:2305:23: warning: invalid assignment: |=
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2305:23:    left side has type restricted __le32
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2305:23:    right side has type int
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2383:39: warning: invalid assignment: |=
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2383:39:    left side has type restricted __le32
drivers/staging/lustre/lustre/lmv/lmv_obd.c:2383:39:    right side has type int

Signed-off-by: Valentin Vidic <Valentin.Vidic at CARNet.hr>
---
Changes in v2: use a local var to collect flags

 drivers/staging/lustre/lustre/lmv/lmv_obd.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
index 09b469243d73..bec8c1948fa0 100644
--- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
+++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
@@ -2275,6 +2275,7 @@ static int lmv_read_striped_page(struct obd_export *exp,
 	struct lu_fid master_fid = op_data->op_fid1;
 	struct obd_device *obd = exp->exp_obd;
 	__u64 hash_offset = offset;
+	__u32 ldp_flags;
 	struct page *min_ent_page = NULL;
 	struct page *ent_page = NULL;
 	struct lu_dirent *min_ent = NULL;
@@ -2302,7 +2303,7 @@ static int lmv_read_striped_page(struct obd_export *exp,
 	dp = kmap(ent_page);
 	memset(dp, 0, sizeof(*dp));
 	dp->ldp_hash_start = cpu_to_le64(offset);
-	dp->ldp_flags |= LDF_COLLIDE;
+	ldp_flags = LDF_COLLIDE;
 
 	area = dp + 1;
 	left_bytes = PAGE_SIZE - sizeof(*dp);
@@ -2380,8 +2381,8 @@ static int lmv_read_striped_page(struct obd_export *exp,
 		ent_page = NULL;
 	} else {
 		if (ent == area)
-			dp->ldp_flags |= LDF_EMPTY;
-		dp->ldp_flags = cpu_to_le32(dp->ldp_flags);
+			ldp_flags |= LDF_EMPTY;
+		dp->ldp_flags |= cpu_to_le32(ldp_flags);
 		dp->ldp_hash_end = cpu_to_le64(hash_offset);
 	}
 
-- 
2.11.0

From gurooodas at gmail.com  Fri May  5 06:41:26 2017
From: gurooodas at gmail.com (Guru Das Srinagesh)
Date: Thu,  4 May 2017 23:41:26 -0700
Subject: [lustre-devel] [PATCH] staging: lustre: llite: Fix variable length
	array warning
Message-ID: <1493966486-6143-1-git-send-email-gurooodas@gmail.com>

Fix sparse warning "warning: Variable length array is used." by using
kmalloc_array to allocate the required amount of memory instead and
kfree to deallocate memory after use.

Signed-off-by: Guru Das Srinagesh <gurooodas at gmail.com>
---
 drivers/staging/lustre/lustre/llite/xattr.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c
index 6187bff..832ec6e 100644
--- a/drivers/staging/lustre/lustre/llite/xattr.c
+++ b/drivers/staging/lustre/lustre/llite/xattr.c
@@ -86,7 +86,8 @@ ll_xattr_set_common(const struct xattr_handler *handler,
 		    const char *name, const void *value, size_t size,
 		    int flags)
 {
-	char fullname[strlen(handler->prefix) + strlen(name) + 1];
+	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
+	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_KERNEL);
 	struct ll_sb_info *sbi = ll_i2sbi(inode);
 	struct ptlrpc_request *req = NULL;
 	const char *pv = value;
@@ -153,6 +154,9 @@ ll_xattr_set_common(const struct xattr_handler *handler,
 	}
 
 	ptlrpc_req_finished(req);
+
+	kfree(fullname);
+
 	return 0;
 }
 
@@ -363,7 +367,8 @@ static int ll_xattr_get_common(const struct xattr_handler *handler,
 			       struct dentry *dentry, struct inode *inode,
 			       const char *name, void *buffer, size_t size)
 {
-	char fullname[strlen(handler->prefix) + strlen(name) + 1];
+	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
+	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_KERNEL);
 	struct ll_sb_info *sbi = ll_i2sbi(inode);
 #ifdef CONFIG_FS_POSIX_ACL
 	struct ll_inode_info *lli = ll_i2info(inode);
@@ -411,8 +416,12 @@ static int ll_xattr_get_common(const struct xattr_handler *handler,
 		return -ENODATA;
 #endif
 	sprintf(fullname, "%s%s\n", handler->prefix, name);
-	return ll_xattr_list(inode, fullname, handler->flags, buffer, size,
-			     OBD_MD_FLXATTR);
+
+	rc = ll_xattr_list(inode, fullname, handler->flags, buffer, size,
+			   OBD_MD_FLXATTR);
+	kfree(fullname);
+
+	return rc;
 }
 
 static ssize_t ll_getxattr_lov(struct inode *inode, void *buf, size_t buf_size)
-- 
2.7.4

From mathiasrav at gmail.com  Thu May  4 16:13:37 2017
From: mathiasrav at gmail.com (Mathias Rav)
Date: Thu,  4 May 2017 12:13:37 -0400
Subject: [lustre-devel] [PATCH 0/2] staging: lustre: lprocfs: Fix coding
	style issues
Message-ID: <20170504161339.15901-1-mathiasrav@gmail.com>

This patchset fixes two style issues in lprocfs_status.c related to
simple_strtoul and seq_printf (reported by checkpatch).

There's a slight change in lustre debugfs write semantics: Using kstrtox causes
EINVAL when the written number is followed by other (garbage) characters,
whereas previously the garbage would be ignored and such a write would succeed.

Mathias Rav (2):
      staging: lustre: lprocfs: Use kstrtouint_from_user
      staging: lustre: lprocfs: Use seq_puts

 .../lustre/lustre/obdclass/lprocfs_status.c        | 42 ++++++---------------
 1 file changed, 11 insertions(+), 31 deletions(-)

From mathiasrav at gmail.com  Thu May  4 16:13:39 2017
From: mathiasrav at gmail.com (Mathias Rav)
Date: Thu,  4 May 2017 12:13:39 -0400
Subject: [lustre-devel] [PATCH 2/2] staging: lustre: lprocfs: Use seq_puts
In-Reply-To: <20170504161339.15901-2-mathiasrav@gmail.com>
References: <20170504161339.15901-1-mathiasrav@gmail.com>
	<20170504161339.15901-2-mathiasrav@gmail.com>
Message-ID: <20170504161339.15901-3-mathiasrav@gmail.com>

Replace all occurrences of seq_printf with no formatting directives
in lprocfs_status.c with seq_puts.

Reported by checkpatch.pl: "WARNING: Prefer seq_puts to seq_printf".

Signed-off-by: Mathias Rav <mathiasrav at gmail.com>
---
 .../staging/lustre/lustre/obdclass/lprocfs_status.c  | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
index 338ce34d6514..b5e0e46777ea 100644
--- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
+++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
@@ -716,7 +716,7 @@ static int obd_import_flags2str(struct obd_import *imp, struct seq_file *m)
 	bool first = true;
 
 	if (imp->imp_obd->obd_no_recov) {
-		seq_printf(m, "no_recov");
+		seq_puts(m, "no_recov");
 		first = false;
 	}
 
@@ -782,15 +782,15 @@ int lprocfs_rd_import(struct seq_file *m, void *data)
 		   imp->imp_connect_data.ocd_instance);
 	obd_connect_seq_flags2str(m, imp->imp_connect_data.ocd_connect_flags,
 				  ", ");
-	seq_printf(m, " ]\n");
+	seq_puts(m, " ]\n");
 	obd_connect_data_seqprint(m, ocd);
-	seq_printf(m, "    import_flags: [ ");
+	seq_puts(m, "    import_flags: [ ");
 	obd_import_flags2str(imp, m);
 
-	seq_printf(m,
-		   " ]\n"
-		   "    connection:\n"
-		   "       failover_nids: [ ");
+	seq_puts(m,
+		 " ]\n"
+		 "    connection:\n"
+		 "       failover_nids: [ ");
 	spin_lock(&imp->imp_lock);
 	j = 0;
 	list_for_each_entry(conn, &imp->imp_conn_list, oic_item) {
@@ -923,7 +923,7 @@ int lprocfs_rd_state(struct seq_file *m, void *data)
 
 	seq_printf(m, "current_state: %s\n",
 		   ptlrpc_import_state_name(imp->imp_state));
-	seq_printf(m, "state_history:\n");
+	seq_puts(m, "state_history:\n");
 	k = imp->imp_state_hist_idx;
 	for (j = 0; j < IMP_STATE_HIST_LEN; j++) {
 		struct import_state_hist *ish =
@@ -945,7 +945,7 @@ int lprocfs_at_hist_helper(struct seq_file *m, struct adaptive_timeout *at)
 
 	for (i = 0; i < AT_BINS; i++)
 		seq_printf(m, "%3u ", at->at_hist[i]);
-	seq_printf(m, "\n");
+	seq_puts(m, "\n");
 	return 0;
 }
 EXPORT_SYMBOL(lprocfs_at_hist_helper);
@@ -1013,7 +1013,7 @@ int lprocfs_rd_connect_flags(struct seq_file *m, void *data)
 	flags = obd->u.cli.cl_import->imp_connect_data.ocd_connect_flags;
 	seq_printf(m, "flags=%#llx\n", flags);
 	obd_connect_seq_flags2str(m, flags, "\n");
-	seq_printf(m, "\n");
+	seq_puts(m, "\n");
 	up_read(&obd->u.cli.cl_sem);
 	return 0;
 }
-- 
2.12.2

From joe at perches.com  Sun May  7 23:24:51 2017
From: joe at perches.com (Joe Perches)
Date: Sun, 07 May 2017 16:24:51 -0700
Subject: [lustre-devel] [PATCH v2] staging: lustre: llite: Fix variable
 length array warning
In-Reply-To: <1494149009-2121-1-git-send-email-gurooodas@gmail.com>
References: <1494149009-2121-1-git-send-email-gurooodas@gmail.com>
Message-ID: <1494199491.31950.52.camel@perches.com>

On Sun, 2017-05-07 at 02:23 -0700, Guru Das Srinagesh wrote:
> Fix sparse warning "warning: Variable length array is used." by using
> kmalloc_array to allocate the required amount of memory instead and
> kfree to deallocate memory after use.
[]
> diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c
[]
> @@ -86,13 +86,17 @@ ll_xattr_set_common(const struct xattr_handler *handler,
>  		    const char *name, const void *value, size_t size,
>  		    int flags)
>  {
> -	char fullname[strlen(handler->prefix) + strlen(name) + 1];
> +	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
> +	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_KERNEL);

Are you sure about using GFP_KERNEL and that sleeping is
allowed for this function allocation?

From mark.a.olson at intel.com  Mon May  8 22:32:00 2017
From: mark.a.olson at intel.com (Olson, Mark A)
Date: Mon, 8 May 2017 22:32:00 +0000
Subject: [lustre-devel] NOTIFICATION: Potential downtime for HPDD sites Sun
 May 14, 7:00am-4:00pm PDT
Message-ID: <A472DDB3E0A39046BCC3E1C47FFA8A983DB45144@fmsmsx116.amr.corp.intel.com>

NOTIFCATION

Intel IT will be doing maintenance on Sunday May 14, 2017  7:00am - 4:00pm Pacific.

The following sites may be unavailable for as long as 1 hour at some point during the maintenance window.

https://id.hpdd.intel.com
https://jira.hpdd.intel.com  
https://wiki.hpdd.intel.com
https://downloads.hpdd.intel.com/public/lustre/ 
https://review.whamcloud.com  
https://git.hpdd.intel.com 


Mark A. Olson
System Administrator
High Performance Data Division (HPDD)
Datacenter Operations (DCO)
Intel Corporation


From dan.carpenter at oracle.com  Tue May  9 08:31:36 2017
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Tue, 9 May 2017 11:31:36 +0300
Subject: [lustre-devel] [PATCH v4] staging: lustre: llite: Fix variable
 length array warning
In-Reply-To: <1494313036-15955-1-git-send-email-gurooodas@gmail.com>
References: <1494313036-15955-1-git-send-email-gurooodas@gmail.com>
Message-ID: <20170509083136.auumomyrgat4oc2k@mwanda>

This patch introduces tons of memory leaks so we can't apply it.

Just ignore the warning.  The size is small enough that it won't
overflow the stack.  The other reason to avoid these types of
declarations is that in olden times (5 years ago at least) there was a
GCC for an arch where if you declared the variable inside a loop it
would not free the memory until after the end of the loop.

	while ((foo = frob())) {
		int whatver[x + y];
	}

The memory would keep increasing until we broke from the loop or it
overflowed the stack and crashed.

On Mon, May 08, 2017 at 11:57:16PM -0700, Guru Das Srinagesh wrote:
> Fix sparse warning "warning: Variable length array is used." by using
> kmalloc_array to allocate the required amount of memory instead and
> kfree to deallocate memory after use.
> 
> Signed-off-by: Guru Das Srinagesh <gurooodas at gmail.com>
> ---
>  v4:
>    - Changed kmalloc_array flags from GFP_KERNEL to GFP_ATOMIC
> 
>  v3:
>    - Fixed checkpatch warning: Comparison to NULL could be written "!fullname"
> 
>  v2:
>    - Added missing check for NULL return value of kmalloc_array()
> 
>  drivers/staging/lustre/lustre/llite/xattr.c | 23 +++++++++++++++++++----
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c
> index 6187bff..ae2efd5 100644
> --- a/drivers/staging/lustre/lustre/llite/xattr.c
> +++ b/drivers/staging/lustre/lustre/llite/xattr.c
> @@ -86,13 +86,17 @@ ll_xattr_set_common(const struct xattr_handler *handler,
>  		    const char *name, const void *value, size_t size,
>  		    int flags)
>  {
> -	char fullname[strlen(handler->prefix) + strlen(name) + 1];
> +	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
> +	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_ATOMIC);

Using kmalloc_array() is pointless.  Everyone knows that sizeof(char) is
1 and also that 1 * x == x.  It just makes the code more confusing and
complicated for no reason.  Don't hide the allocation this declaration
block.  It should be next to the check for NULL.  But anyway, don't
bother resending, just ignore the warning.

regards,
dan carpenter

From gurooodas at gmail.com  Sat May  6 20:16:29 2017
From: gurooodas at gmail.com (Guru Das Srinagesh)
Date: Sat, 6 May 2017 13:16:29 -0700
Subject: [lustre-devel] [PATCH] staging: lustre: llite: Fix variable
	length array warning
In-Reply-To: <1493974356.31950.13.camel@perches.com>
References: <1493966486-6143-1-git-send-email-gurooodas@gmail.com>
	<1493974356.31950.13.camel@perches.com>
Message-ID: <20170506201629.GA14929@alpha>

On Fri, May 05, 2017 at 01:52:36AM -0700, Joe Perches wrote:
> On Thu, 2017-05-04 at 23:41 -0700, Guru Das Srinagesh wrote:
> > Fix sparse warning "warning: Variable length array is used." by using
> > kmalloc_array to allocate the required amount of memory instead and
> > kfree to deallocate memory after use.
> []
> > diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c
> []
> > @@ -86,7 +86,8 @@ ll_xattr_set_common(const struct xattr_handler *handler,
> >  		    const char *name, const void *value, size_t size,
> >  		    int flags)
> >  {
> > -	char fullname[strlen(handler->prefix) + strlen(name) + 1];
> > +	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
> > +	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_KERNEL);
> 
> What happens when this allocation fails?
> 
Thanks for rightly pointing out the omission of kmalloc_array failure case
handling code. I could check for fullname being NULL and then return -ENOMEM
right there in both functions. I'll go ahead and send a v2 of this patch, with
this modification incorporated, unless there are any more comments or concerns.
Could you please let me know? Thank you.

From gurooodas at gmail.com  Sun May  7 09:23:29 2017
From: gurooodas at gmail.com (Guru Das Srinagesh)
Date: Sun,  7 May 2017 02:23:29 -0700
Subject: [lustre-devel] [PATCH v2] staging: lustre: llite: Fix variable
	length array warning
Message-ID: <1494149009-2121-1-git-send-email-gurooodas@gmail.com>

Fix sparse warning "warning: Variable length array is used." by using
kmalloc_array to allocate the required amount of memory instead and
kfree to deallocate memory after use.

Signed-off-by: Guru Das Srinagesh <gurooodas at gmail.com>
---
 v2:
   - Added missing check for NULL return value of kmalloc_array()

 drivers/staging/lustre/lustre/llite/xattr.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c
index 6187bff..880eee9 100644
--- a/drivers/staging/lustre/lustre/llite/xattr.c
+++ b/drivers/staging/lustre/lustre/llite/xattr.c
@@ -86,13 +86,17 @@ ll_xattr_set_common(const struct xattr_handler *handler,
 		    const char *name, const void *value, size_t size,
 		    int flags)
 {
-	char fullname[strlen(handler->prefix) + strlen(name) + 1];
+	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
+	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_KERNEL);
 	struct ll_sb_info *sbi = ll_i2sbi(inode);
 	struct ptlrpc_request *req = NULL;
 	const char *pv = value;
 	__u64 valid;
 	int rc;
 
+	if (fullname == NULL)
+		return -ENOMEM;
+
 	if (flags == XATTR_REPLACE) {
 		ll_stats_ops_tally(ll_i2sbi(inode), LPROC_LL_REMOVEXATTR, 1);
 		valid = OBD_MD_FLXATTRRM;
@@ -153,6 +157,9 @@ ll_xattr_set_common(const struct xattr_handler *handler,
 	}
 
 	ptlrpc_req_finished(req);
+
+	kfree(fullname);
+
 	return 0;
 }
 
@@ -363,13 +370,17 @@ static int ll_xattr_get_common(const struct xattr_handler *handler,
 			       struct dentry *dentry, struct inode *inode,
 			       const char *name, void *buffer, size_t size)
 {
-	char fullname[strlen(handler->prefix) + strlen(name) + 1];
+	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
+	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_KERNEL);
 	struct ll_sb_info *sbi = ll_i2sbi(inode);
 #ifdef CONFIG_FS_POSIX_ACL
 	struct ll_inode_info *lli = ll_i2info(inode);
 #endif
 	int rc;
 
+	if (fullname == NULL)
+		return -ENOMEM;
+
 	CDEBUG(D_VFSTRACE, "VFS Op:inode="DFID"(%p)\n",
 	       PFID(ll_inode2fid(inode)), inode);
 
@@ -411,8 +422,12 @@ static int ll_xattr_get_common(const struct xattr_handler *handler,
 		return -ENODATA;
 #endif
 	sprintf(fullname, "%s%s\n", handler->prefix, name);
-	return ll_xattr_list(inode, fullname, handler->flags, buffer, size,
-			     OBD_MD_FLXATTR);
+
+	rc = ll_xattr_list(inode, fullname, handler->flags, buffer, size,
+			   OBD_MD_FLXATTR);
+	kfree(fullname);
+
+	return rc;
 }
 
 static ssize_t ll_getxattr_lov(struct inode *inode, void *buf, size_t buf_size)
-- 
2.7.4

From gurooodas at gmail.com  Sun May  7 23:59:46 2017
From: gurooodas at gmail.com (Guru Das Srinagesh)
Date: Sun, 7 May 2017 16:59:46 -0700
Subject: [lustre-devel] [PATCH v2] staging: lustre: llite: Fix variable
 length array warning
In-Reply-To: <1494199491.31950.52.camel@perches.com>
References: <1494149009-2121-1-git-send-email-gurooodas@gmail.com>
	<1494199491.31950.52.camel@perches.com>
Message-ID: <20170507235946.GA2898@alpha>

On Sun, May 07, 2017 at 04:24:51PM -0700, Joe Perches wrote:
> On Sun, 2017-05-07 at 02:23 -0700, Guru Das Srinagesh wrote:
> > Fix sparse warning "warning: Variable length array is used." by using
> > kmalloc_array to allocate the required amount of memory instead and
> > kfree to deallocate memory after use.
> []
> > diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c
> []
> > @@ -86,13 +86,17 @@ ll_xattr_set_common(const struct xattr_handler *handler,
> >  		    const char *name, const void *value, size_t size,
> >  		    int flags)
> >  {
> > -	char fullname[strlen(handler->prefix) + strlen(name) + 1];
> > +	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
> > +	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_KERNEL);
> 
> Are you sure about using GFP_KERNEL and that sleeping is
> allowed for this function allocation?
> 
I'm not sure about that. Would GFP_ATOMIC be a better flag to use?

From gurooodas at gmail.com  Tue May  9 09:10:34 2017
From: gurooodas at gmail.com (Guru Das Srinagesh)
Date: Tue, 9 May 2017 02:10:34 -0700
Subject: [lustre-devel] [PATCH v4] staging: lustre: llite: Fix variable
 length array warning
In-Reply-To: <20170509083136.auumomyrgat4oc2k@mwanda>
References: <1494313036-15955-1-git-send-email-gurooodas@gmail.com>
	<20170509083136.auumomyrgat4oc2k@mwanda>
Message-ID: <20170509091034.GA29060@alpha>

On Tue, May 09, 2017 at 11:31:36AM +0300, Dan Carpenter wrote:
> Just ignore the warning.
> 
Thank you for your comments on this patch.

From gurooodas at gmail.com  Tue May  9 06:57:16 2017
From: gurooodas at gmail.com (Guru Das Srinagesh)
Date: Mon,  8 May 2017 23:57:16 -0700
Subject: [lustre-devel] [PATCH v4] staging: lustre: llite: Fix variable
	length array warning
Message-ID: <1494313036-15955-1-git-send-email-gurooodas@gmail.com>

Fix sparse warning "warning: Variable length array is used." by using
kmalloc_array to allocate the required amount of memory instead and
kfree to deallocate memory after use.

Signed-off-by: Guru Das Srinagesh <gurooodas at gmail.com>
---
 v4:
   - Changed kmalloc_array flags from GFP_KERNEL to GFP_ATOMIC

 v3:
   - Fixed checkpatch warning: Comparison to NULL could be written "!fullname"

 v2:
   - Added missing check for NULL return value of kmalloc_array()

 drivers/staging/lustre/lustre/llite/xattr.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c
index 6187bff..ae2efd5 100644
--- a/drivers/staging/lustre/lustre/llite/xattr.c
+++ b/drivers/staging/lustre/lustre/llite/xattr.c
@@ -86,13 +86,17 @@ ll_xattr_set_common(const struct xattr_handler *handler,
 		    const char *name, const void *value, size_t size,
 		    int flags)
 {
-	char fullname[strlen(handler->prefix) + strlen(name) + 1];
+	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
+	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_ATOMIC);
 	struct ll_sb_info *sbi = ll_i2sbi(inode);
 	struct ptlrpc_request *req = NULL;
 	const char *pv = value;
 	__u64 valid;
 	int rc;
 
+	if (!fullname)
+		return -ENOMEM;
+
 	if (flags == XATTR_REPLACE) {
 		ll_stats_ops_tally(ll_i2sbi(inode), LPROC_LL_REMOVEXATTR, 1);
 		valid = OBD_MD_FLXATTRRM;
@@ -153,6 +157,9 @@ ll_xattr_set_common(const struct xattr_handler *handler,
 	}
 
 	ptlrpc_req_finished(req);
+
+	kfree(fullname);
+
 	return 0;
 }
 
@@ -363,13 +370,17 @@ static int ll_xattr_get_common(const struct xattr_handler *handler,
 			       struct dentry *dentry, struct inode *inode,
 			       const char *name, void *buffer, size_t size)
 {
-	char fullname[strlen(handler->prefix) + strlen(name) + 1];
+	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
+	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_ATOMIC);
 	struct ll_sb_info *sbi = ll_i2sbi(inode);
 #ifdef CONFIG_FS_POSIX_ACL
 	struct ll_inode_info *lli = ll_i2info(inode);
 #endif
 	int rc;
 
+	if (!fullname)
+		return -ENOMEM;
+
 	CDEBUG(D_VFSTRACE, "VFS Op:inode="DFID"(%p)\n",
 	       PFID(ll_inode2fid(inode)), inode);
 
@@ -411,8 +422,12 @@ static int ll_xattr_get_common(const struct xattr_handler *handler,
 		return -ENODATA;
 #endif
 	sprintf(fullname, "%s%s\n", handler->prefix, name);
-	return ll_xattr_list(inode, fullname, handler->flags, buffer, size,
-			     OBD_MD_FLXATTR);
+
+	rc = ll_xattr_list(inode, fullname, handler->flags, buffer, size,
+			   OBD_MD_FLXATTR);
+	kfree(fullname);
+
+	return rc;
 }
 
 static ssize_t ll_getxattr_lov(struct inode *inode, void *buf, size_t buf_size)
-- 
2.7.4

From gurooodas at gmail.com  Sun May  7 09:33:32 2017
From: gurooodas at gmail.com (Guru Das Srinagesh)
Date: Sun,  7 May 2017 02:33:32 -0700
Subject: [lustre-devel] [PATCH v3] staging: lustre: llite: Fix variable
	length array warning
Message-ID: <1494149612-2631-1-git-send-email-gurooodas@gmail.com>

Fix sparse warning "warning: Variable length array is used." by using
kmalloc_array to allocate the required amount of memory instead and
kfree to deallocate memory after use.

Signed-off-by: Guru Das Srinagesh <gurooodas at gmail.com>
---
 v3:
   - Fixed checkpatch warning: Comparison to NULL could be written "!fullname"

 v2:
   - Added missing check for NULL return value of kmalloc_array()

 drivers/staging/lustre/lustre/llite/xattr.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c
index 6187bff..35f38eb 100644
--- a/drivers/staging/lustre/lustre/llite/xattr.c
+++ b/drivers/staging/lustre/lustre/llite/xattr.c
@@ -86,13 +86,17 @@ ll_xattr_set_common(const struct xattr_handler *handler,
 		    const char *name, const void *value, size_t size,
 		    int flags)
 {
-	char fullname[strlen(handler->prefix) + strlen(name) + 1];
+	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
+	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_KERNEL);
 	struct ll_sb_info *sbi = ll_i2sbi(inode);
 	struct ptlrpc_request *req = NULL;
 	const char *pv = value;
 	__u64 valid;
 	int rc;
 
+	if (!fullname)
+		return -ENOMEM;
+
 	if (flags == XATTR_REPLACE) {
 		ll_stats_ops_tally(ll_i2sbi(inode), LPROC_LL_REMOVEXATTR, 1);
 		valid = OBD_MD_FLXATTRRM;
@@ -153,6 +157,9 @@ ll_xattr_set_common(const struct xattr_handler *handler,
 	}
 
 	ptlrpc_req_finished(req);
+
+	kfree(fullname);
+
 	return 0;
 }
 
@@ -363,13 +370,17 @@ static int ll_xattr_get_common(const struct xattr_handler *handler,
 			       struct dentry *dentry, struct inode *inode,
 			       const char *name, void *buffer, size_t size)
 {
-	char fullname[strlen(handler->prefix) + strlen(name) + 1];
+	int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
+	char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_KERNEL);
 	struct ll_sb_info *sbi = ll_i2sbi(inode);
 #ifdef CONFIG_FS_POSIX_ACL
 	struct ll_inode_info *lli = ll_i2info(inode);
 #endif
 	int rc;
 
+	if (!fullname)
+		return -ENOMEM;
+
 	CDEBUG(D_VFSTRACE, "VFS Op:inode="DFID"(%p)\n",
 	       PFID(ll_inode2fid(inode)), inode);
 
@@ -411,8 +422,12 @@ static int ll_xattr_get_common(const struct xattr_handler *handler,
 		return -ENODATA;
 #endif
 	sprintf(fullname, "%s%s\n", handler->prefix, name);
-	return ll_xattr_list(inode, fullname, handler->flags, buffer, size,
-			     OBD_MD_FLXATTR);
+
+	rc = ll_xattr_list(inode, fullname, handler->flags, buffer, size,
+			   OBD_MD_FLXATTR);
+	kfree(fullname);
+
+	return rc;
 }
 
 static ssize_t ll_getxattr_lov(struct inode *inode, void *buf, size_t buf_size)
-- 
2.7.4

From andreas.dilger at intel.com  Tue May 16 10:20:02 2017
From: andreas.dilger at intel.com (Dilger, Andreas)
Date: Tue, 16 May 2017 10:20:02 +0000
Subject: [lustre-devel] Request for review
In-Reply-To: <CY4PR11MB1751856322B51A0DC95662FCCBEA0@CY4PR11MB1751.namprd11.prod.outlook.com>
References: <CY4PR11MB1751856322B51A0DC95662FCCBEA0@CY4PR11MB1751.namprd11.prod.outlook.com>
Message-ID: <A9CE5A7F-3D47-4E03-9F8C-2EB15787F484@intel.com>

On May 4, 2017, at 20:24, Patrick Farrell <paf at cray.com> wrote:
> 
> Developer types,
> 
> I've got an old patch out for LU-8703 (https://jira.hpdd.intel.com/browse/LU-8307), in need of review:
> https://review.whamcloud.com/#/c/20888/
> 
> It's a pretty simple fix and still applicable now, but it needs reviewers.  So I'm looking for volunteers.  Details are in the ticket.
> 
> Any takers?

I just found this in my inbox.  Good to see that several people stepped up to do the inspection.

Now, only a few hundred other patches that need review... :-)  I definitely think that in case of patch review that the squeaky wheel gets the attention.  Posting to lustre-devel seems like a good way to get some wider attention onto patches?

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation







From faaland1 at llnl.gov  Tue May 16 18:03:32 2017
From: faaland1 at llnl.gov (Faaland, Olaf P.)
Date: Tue, 16 May 2017 18:03:32 +0000
Subject: [lustre-devel] lctl dl - different devices with same device name
Message-ID: <F46BAA88-7E46-4614-994A-01B5CE909CC1@llnl.gov>

Hi All,

This is regarding Lustre 2.8 FE – 2.8.0 + backported bug fixes.

Typically our MDS nodes run only a single MDT.  When this is the case, lctl dl produces 25 lines of output:

Osd
Mgc
Mds
Lod
Mdt
Mdd
Lwp
And 19 osp’s – one for each other lustre target in the file system.

Two of these devices listed, the mdt and the mdd, have the same name.  For example,

4 UP mdt lquake-MDT000f lquake-MDT000f-UUID 327
5 UP mdd lquake-MDT000f lquake-MDT000f-UUID 4

Is it correct that they have the same name?  I ask, because the functions jt_device() calls assume that they can uniquely map from a name to a device number, but in this case that’s not possible.

I could improve the utility code easily enough, but I don’t know if the device names are correct or not.  There’s no evidence the file system isn’t working correctly.

-Olaf


From dan.carpenter at oracle.com  Wed May 17 09:34:18 2017
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Wed, 17 May 2017 12:34:18 +0300
Subject: [lustre-devel] [PATCH] staging: lustre: lnet: specify address
	space
In-Reply-To: <20170516205610.21324-1-melko@frugalware.org>
References: <20170516205610.21324-1-melko@frugalware.org>
Message-ID: <20170517093418.pv4brp4imlebqt5i@mwanda>

On Tue, May 16, 2017 at 10:56:10PM +0200, Paolo Cretaro wrote:
> Fix warning issued by sparse:
> incorrect type in assignment (different address spaces).
> 
> Signed-off-by: Paolo Cretaro <melko at frugalware.org>
> ---
>  drivers/staging/lustre/lnet/lnet/lib-socket.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/lustre/lnet/lnet/lib-socket.c b/drivers/staging/lustre/lnet/lnet/lib-socket.c
> index 9fca8d225ee0..e5e5213b4da0 100644
> --- a/drivers/staging/lustre/lnet/lnet/lib-socket.c
> +++ b/drivers/staging/lustre/lnet/lnet/lib-socket.c
> @@ -181,7 +181,7 @@ lnet_ipif_enumerate(char ***namesp)
>  			goto out0;
>  		}
>  
> -		ifc.ifc_buf = (char *)ifr;
> +		ifc.ifc_buf = (char __user *)ifr;

But it's not a __user pointer so this is wrong.  You have deleted a
valuable warning message which is there to inform us about important
bugs.

regards,
dan carpenter

From quentin.bouget at cea.fr  Wed May 17 11:16:34 2017
From: quentin.bouget at cea.fr (quentin.bouget at cea.fr)
Date: Wed, 17 May 2017 13:16:34 +0200
Subject: [lustre-devel] have df report a more up-to-date view of the
 filesystem
Message-ID: <9e5f3b8d-b5f5-ce10-2b35-e6f13b7de532@cea.fr>

Hi everyone,

In LU-8940 <https://jira.hpdd.intel.com/browse/LU-8940> I describe an 
issue I am having with df in Lustre's tests. In short, df/statfs can 
report outdated information about a Lustre filesystem; given enough 
time, its output gets correct. From what I understand, statfs cannot 
report an "always up-to-date" view of the filesystem as this would cost 
too much time and resources.

I would like to know what you guys think of having Lustre's statfs 
operation report a view of the filesystem /at least as new as when the 
last sync operation completed/?

My point being that users (and tests) would be able to run df --sync to 
get up-to-date information (at the cost of a sync operation, and maybe 
some accounting for statfs).

Regards,
Quentin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel_lists.lustre.org/attachments/20170517/bb8336a2/attachment.html>

From rjh+lustre at cita.utoronto.ca  Wed May 17 14:17:11 2017
From: rjh+lustre at cita.utoronto.ca (Robin Humble)
Date: Wed, 17 May 2017 10:17:11 -0400
Subject: [lustre-devel] [PATCH] lustre: llite: Remove filtering of seclabel
	xattr
Message-ID: <20170517141711.GB1064@trinity.cita.utoronto.ca>

Signed-off-by: Robin Humble <plaguedbypenguins at gmail.com>
---
 lustre/llite/xattr.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/lustre/llite/xattr.c b/lustre/llite/xattr.c
index 4d42956..527ee40 100644
--- a/lustre/llite/xattr.c
+++ b/lustre/llite/xattr.c
@@ -147,11 +147,6 @@ int ll_setxattr_common(struct inode *inode, const char *name,
 		 strcmp(name, "lustre.lov") == 0))
 		RETURN(0);
 
-	/* b15587: ignore security.capability xattr for now */
-	if ((xattr_type == XATTR_SECURITY_T &&
-	    strcmp(name, "security.capability") == 0))
-		RETURN(0);
-
 	/* LU-549:  Disable security.selinux when selinux is disabled */
 	if (xattr_type == XATTR_SECURITY_T && !selinux_is_enabled() &&
 	    strcmp(name, "security.selinux") == 0)
@@ -343,11 +338,6 @@ int ll_getxattr_common(struct inode *inode, const char *name,
         if (rc)
                 RETURN(rc);
 
-        /* b15587: ignore security.capability xattr for now */
-        if ((xattr_type == XATTR_SECURITY_T &&
-            strcmp(name, "security.capability") == 0))
-                RETURN(-ENODATA);
-
         /* LU-549:  Disable security.selinux when selinux is disabled */
         if (xattr_type == XATTR_SECURITY_T && !selinux_is_enabled() &&
             strcmp(name, "security.selinux") == 0)
-- 
2.9.4

From simmonsja at ornl.gov  Wed May 17 17:58:47 2017
From: simmonsja at ornl.gov (Simmons, James A.)
Date: Wed, 17 May 2017 17:58:47 +0000
Subject: [lustre-devel] Request for review
In-Reply-To: <A9CE5A7F-3D47-4E03-9F8C-2EB15787F484@intel.com>
References: <CY4PR11MB1751856322B51A0DC95662FCCBEA0@CY4PR11MB1751.namprd11.prod.outlook.com>
	<A9CE5A7F-3D47-4E03-9F8C-2EB15787F484@intel.com>
Message-ID: <9b6143644c894de6b1c8caba04edc024@EXCHCS32.ornl.gov>

>I just found this in my inbox.  Good to see that several people stepped up to do the inspection.
>
>Now, only a few hundred other patches that need review... :-)  I definitely think that in case of patch review that the squeaky wheel gets the attention.  Posting to lustre-devel seems like a good way to get some >wider attention onto patches?

If this is the case I really like to see 

https://review.whamcloud.com/#/c/26966

reviewed. One more patch after that and the LU-6401 work will be completed.
Once done only one patch to finish off the libcfs header cleanup. So close!!!!

From andreas.dilger at intel.com  Thu May 18 08:30:36 2017
From: andreas.dilger at intel.com (Dilger, Andreas)
Date: Thu, 18 May 2017 08:30:36 +0000
Subject: [lustre-devel] [PATCH 6/6] staging/lustre: Use generic range
	rwlock
In-Reply-To: <20170515090725.27055-7-dave@stgolabs.net>
References: <20170515090725.27055-1-dave@stgolabs.net>
	<20170515090725.27055-7-dave@stgolabs.net>
Message-ID: <907C3F64-C3AF-4027-98F2-58877E650368@intel.com>

On May 15, 2017, at 11:07, Davidlohr Bueso <dave at stgolabs.net> wrote:
> 
> This replaces the in-house version, which is also derived
> from Jan's interval tree implementation.
> 
> Cc: oleg.drokin at intel.com
> Cc: andreas.dilger at intel.com
> Cc: jsimmons at infradead.org
> Cc: lustre-devel at lists.lustre.org
> Signed-off-by: Davidlohr Bueso <dbueso at suse.de>

Repeating my request that the whole patch series should be CC'd to the linux-fsdevel list,
since I only got this last patch and this makes it difficult to review the whole series.

> ---
> diff --git a/drivers/staging/lustre/lustre/llite/file.c b/drivers/staging/lustre/lustre/llite/file.c
> index 67c4b9cc6e75..bd020bdaf85d 100644
> --- a/drivers/staging/lustre/lustre/llite/file.c
> +++ b/drivers/staging/lustre/lustre/llite/file.c
> @@ -1083,10 +1083,10 @@ ll_file_io_generic(const struct lu_env *env, struct vvp_io_args *args,
> 		if (((iot == CIT_WRITE) ||
> 		     (iot == CIT_READ && (file->f_flags & O_DIRECT))) &&
> 		    !(vio->vui_fd->fd_flags & LL_FILE_GROUP_LOCKED)) {
> -			CDEBUG(D_VFSTRACE, "Range lock [%llu, %llu]\n",
> -			       range.rl_node.in_extent.start,
> -			       range.rl_node.in_extent.end);
> -			rc = range_lock(&lli->lli_write_tree, &range);
> +			CDEBUG(D_VFSTRACE, "Range lock [%lu, %lu]\n",
> +			       range.node.start,
> +			       range.node.last);
> +			rc = range_write_lock_interruptible(&lli->lli_write_tree, &range);
> 			if (rc < 0)
> 				goto out;
> 
> @@ -1096,10 +1096,10 @@ ll_file_io_generic(const struct lu_env *env, struct vvp_io_args *args,
> 		rc = cl_io_loop(env, io);
> 		ll_cl_remove(file, env);
> 		if (range_locked) {
> -			CDEBUG(D_VFSTRACE, "Range unlock [%llu, %llu]\n",
> -			       range.rl_node.in_extent.start,
> -			       range.rl_node.in_extent.end);
> -			range_unlock(&lli->lli_write_tree, &range);
> +			CDEBUG(D_VFSTRACE, "Range unlock [%lu, %lu]\n",
> +			       range.node.start,
> +			       range.node.last);
> +			range_write_unlock(&lli->lli_write_tree, &range);
> 		}
> 	} else {
> 		/* cl_io_rw_init() handled IO */

I'm not against this patch, but it does expose an implementation difference between the
Lustre version of this code and the in-tree version.  Preferred kernel coding style is to
have a struct-unique prefix for struct members (e.g. using "rl_" for struct range_lock,
using "in_" for struct interval_tree_node).  That allows tags to work properly, instead
of trying to locate generic struct names like "start", "node" etc.

In an unexpected twist of fate, the Lustre version of this code is following preferred
coding style and the in-tree (interval_tree) and submitted (range_rwlock) code does not.

Cheers, Andreas






From gregkh at linuxfoundation.org  Thu May 18 13:53:22 2017
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 18 May 2017 15:53:22 +0200
Subject: [lustre-devel] [PATCH 1/2] staging: lustre: lprocfs: Use
	kstrtouint_from_user
In-Reply-To: <20170504161339.15901-2-mathiasrav@gmail.com>
References: <20170504161339.15901-1-mathiasrav@gmail.com>
	<20170504161339.15901-2-mathiasrav@gmail.com>
Message-ID: <20170518135322.GA6772@kroah.com>

On Thu, May 04, 2017 at 12:13:38PM -0400, Mathias Rav wrote:
> Prefer kstrtouint_from_user to copy_from_user+simple_strtoul.
> 
> The helper function lprocfs_wr_uint() is only used to implement
> "dump_granted_max" in debugfs.
> 
> Note the slight change in semantics: The previous implementation using
> simple_strtoul allows garbage after the number, whereas kstrtox only allows
> a trailing line break. The previous implementation allowed a write of zero
> bytes whereas kstrtox will return -EINVAL. Since this only affects a single
> debugfs endpoint, this should be a permissible slight change of semantics
> in exchange for 18 fewer lines of code.
> 
> Signed-off-by: Mathias Rav <mathiasrav at gmail.com>
> ---
>  .../lustre/lustre/obdclass/lprocfs_status.c        | 22 +---------------------
>  1 file changed, 1 insertion(+), 21 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
> index 1ec6e3767d81..338ce34d6514 100644
> --- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
> +++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
> @@ -399,27 +399,7 @@ EXPORT_SYMBOL(lprocfs_rd_uint);
>  int lprocfs_wr_uint(struct file *file, const char __user *buffer,
>  		    unsigned long count, void *data)
>  {
> -	unsigned *p = data;
> -	char dummy[MAX_STRING_SIZE + 1], *end;
> -	unsigned long tmp;
> -
> -	if (count >= sizeof(dummy))
> -		return -EINVAL;
> -
> -	if (count == 0)
> -		return 0;
> -
> -	if (copy_from_user(dummy, buffer, count))
> -		return -EFAULT;
> -
> -	dummy[count] = '\0';
> -
> -	tmp = simple_strtoul(dummy, &end, 0);
> -	if (dummy == end)
> -		return -EINVAL;
> -
> -	*p = (unsigned int)tmp;
> -	return count;
> +	return kstrtouint_from_user(buffer, count, 0, (unsigned int *)data);

Why not just delete this whole function and have the callers make this
call instead?  No need for unneeded wrapper functions of core kernel
calls.

thanks,

greg k-h

From andreas.dilger at intel.com  Thu May 18 14:48:25 2017
From: andreas.dilger at intel.com (Dilger, Andreas)
Date: Thu, 18 May 2017 14:48:25 +0000
Subject: [lustre-devel] [PATCH 1/2] staging: lustre: lprocfs: Use
	kstrtouint_from_user
In-Reply-To: <20170518135322.GA6772@kroah.com>
References: <20170504161339.15901-1-mathiasrav@gmail.com>
	<20170504161339.15901-2-mathiasrav@gmail.com>
	<20170518135322.GA6772@kroah.com>
Message-ID: <9657977C-9620-4C31-9615-E4245482B5A7@intel.com>

On May 18, 2017, at 15:53, Greg Kroah-Hartman <gregkh at linuxfoundation.org> wrote:
> 
> On Thu, May 04, 2017 at 12:13:38PM -0400, Mathias Rav wrote:
>> Prefer kstrtouint_from_user to copy_from_user+simple_strtoul.
>> 
>> The helper function lprocfs_wr_uint() is only used to implement
>> "dump_granted_max" in debugfs.
>> 
>> Note the slight change in semantics: The previous implementation using
>> simple_strtoul allows garbage after the number, whereas kstrtox only allows
>> a trailing line break. The previous implementation allowed a write of zero
>> bytes whereas kstrtox will return -EINVAL. Since this only affects a single
>> debugfs endpoint, this should be a permissible slight change of semantics
>> in exchange for 18 fewer lines of code.
>> 
>> Signed-off-by: Mathias Rav <mathiasrav at gmail.com>
>> ---
>> .../lustre/lustre/obdclass/lprocfs_status.c        | 22 +---------------------
>> 1 file changed, 1 insertion(+), 21 deletions(-)
>> 
>> diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
>> index 1ec6e3767d81..338ce34d6514 100644
>> --- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
>> +++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
>> @@ -399,27 +399,7 @@ EXPORT_SYMBOL(lprocfs_rd_uint);
>> int lprocfs_wr_uint(struct file *file, const char __user *buffer,
>> 		    unsigned long count, void *data)
>> {
>> -	unsigned *p = data;
>> -	char dummy[MAX_STRING_SIZE + 1], *end;
>> -	unsigned long tmp;
>> -
>> -	if (count >= sizeof(dummy))
>> -		return -EINVAL;
>> -
>> -	if (count == 0)
>> -		return 0;
>> -
>> -	if (copy_from_user(dummy, buffer, count))
>> -		return -EFAULT;
>> -
>> -	dummy[count] = '\0';
>> -
>> -	tmp = simple_strtoul(dummy, &end, 0);
>> -	if (dummy == end)
>> -		return -EINVAL;
>> -
>> -	*p = (unsigned int)tmp;
>> -	return count;
>> +	return kstrtouint_from_user(buffer, count, 0, (unsigned int *)data);
> 
> Why not just delete this whole function and have the callers make this
> call instead?  No need for unneeded wrapper functions of core kernel
> calls.

Even better, it looks like this function has no callers on the client and could just
be deleted entirely.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation







From mathiasrav at gmail.com  Thu May 18 15:13:43 2017
From: mathiasrav at gmail.com (Mathias Rav)
Date: Thu, 18 May 2017 11:13:43 -0400
Subject: [lustre-devel] [PATCH 1/2] staging: lustre: lprocfs: Use
	kstrtouint_from_user
In-Reply-To: <9657977C-9620-4C31-9615-E4245482B5A7@intel.com>
References: <20170504161339.15901-1-mathiasrav@gmail.com>
	<20170504161339.15901-2-mathiasrav@gmail.com>
	<20170518135322.GA6772@kroah.com>
	<9657977C-9620-4C31-9615-E4245482B5A7@intel.com>
Message-ID: <20170518111343.15a263f1@alcyone.localdomain>

On Thu, 18 May 2017 14:48:25 +0000
"Dilger, Andreas" <andreas.dilger at intel.com> wrote:

> On May 18, 2017, at 15:53, Greg Kroah-Hartman <gregkh at linuxfoundation.org> wrote:
> > 
> > On Thu, May 04, 2017 at 12:13:38PM -0400, Mathias Rav wrote:  
> >> Prefer kstrtouint_from_user to copy_from_user+simple_strtoul.
> >> 
> >> The helper function lprocfs_wr_uint() is only used to implement
> >> "dump_granted_max" in debugfs.
> >> 
> >> Note the slight change in semantics: The previous implementation using
> >> simple_strtoul allows garbage after the number, whereas kstrtox only allows
> >> a trailing line break. The previous implementation allowed a write of zero
> >> bytes whereas kstrtox will return -EINVAL. Since this only affects a single
> >> debugfs endpoint, this should be a permissible slight change of semantics
> >> in exchange for 18 fewer lines of code.
> >> 
> >> Signed-off-by: Mathias Rav <mathiasrav at gmail.com>
> >> ---
> >> .../lustre/lustre/obdclass/lprocfs_status.c        | 22 +---------------------
> >> 1 file changed, 1 insertion(+), 21 deletions(-)
> >> 
> >> diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
> >> index 1ec6e3767d81..338ce34d6514 100644
> >> --- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
> >> +++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
> >> @@ -399,27 +399,7 @@ EXPORT_SYMBOL(lprocfs_rd_uint);
> >> int lprocfs_wr_uint(struct file *file, const char __user *buffer,
> >> 		    unsigned long count, void *data)
> >> {
> >> -	unsigned *p = data;
> >> -	char dummy[MAX_STRING_SIZE + 1], *end;
> >> -	unsigned long tmp;
> >> -
> >> -	if (count >= sizeof(dummy))
> >> -		return -EINVAL;
> >> -
> >> -	if (count == 0)
> >> -		return 0;
> >> -
> >> -	if (copy_from_user(dummy, buffer, count))
> >> -		return -EFAULT;
> >> -
> >> -	dummy[count] = '\0';
> >> -
> >> -	tmp = simple_strtoul(dummy, &end, 0);
> >> -	if (dummy == end)
> >> -		return -EINVAL;
> >> -
> >> -	*p = (unsigned int)tmp;
> >> -	return count;
> >> +	return kstrtouint_from_user(buffer, count, 0, (unsigned int *)data);  
> > 
> > Why not just delete this whole function and have the callers make this
> > call instead?  No need for unneeded wrapper functions of core kernel
> > calls.  
> 
> Even better, it looks like this function has no callers on the client and could just
> be deleted entirely.

No, the functions lprocfs_{rd,wr}_uint are used once through a macro:
ldlm/ldlm_resource.c calls LPROC_SEQ_FOPS_RW_TYPE(ldlm_rw, uint)
to define ldlm_rw_uint_seq_{show,write}, which then calls
lprocfs_{rd,wr}_uint which in turn call seq_printf/kstrtouint_from_user.

It seems like much indirection for almost no gain besides hiding
access to ((seq_file *) file->private_data)->private in a macro.

If you agree, I will prepare a patch that switches ldlm_resource to
using the LPROC_SEQ_FOPS macro directly, which allows us to remove two
trivial wrappers.

/Mathias

From melko at frugalware.org  Tue May 16 20:56:10 2017
From: melko at frugalware.org (Paolo Cretaro)
Date: Tue, 16 May 2017 22:56:10 +0200
Subject: [lustre-devel] [PATCH] staging: lustre: lnet: specify address space
Message-ID: <20170516205610.21324-1-melko@frugalware.org>

Fix warning issued by sparse:
incorrect type in assignment (different address spaces).

Signed-off-by: Paolo Cretaro <melko at frugalware.org>
---
 drivers/staging/lustre/lnet/lnet/lib-socket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lnet/lnet/lib-socket.c b/drivers/staging/lustre/lnet/lnet/lib-socket.c
index 9fca8d225ee0..e5e5213b4da0 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-socket.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-socket.c
@@ -181,7 +181,7 @@ lnet_ipif_enumerate(char ***namesp)
 			goto out0;
 		}
 
-		ifc.ifc_buf = (char *)ifr;
+		ifc.ifc_buf = (char __user *)ifr;
 		ifc.ifc_len = nalloc * sizeof(*ifr);
 
 		rc = lnet_sock_ioctl(SIOCGIFCONF, (unsigned long)&ifc);
-- 
2.13.0

From andreas.dilger at intel.com  Fri May 19 02:14:42 2017
From: andreas.dilger at intel.com (Dilger, Andreas)
Date: Fri, 19 May 2017 02:14:42 +0000
Subject: [lustre-devel] have df report a more up-to-date view of the
 filesystem
In-Reply-To: <9e5f3b8d-b5f5-ce10-2b35-e6f13b7de532@cea.fr>
References: <9e5f3b8d-b5f5-ce10-2b35-e6f13b7de532@cea.fr>
Message-ID: <A5B44F72-4853-44F6-B453-E919F303AA95@intel.com>

On May 17, 2017, at 13:16, quentin.bouget at cea.fr wrote:
> 
> Hi everyone,
> 
> In LU-8940 I describe an issue I am having with df in Lustre's tests. In short, df/statfs can report outdated information about a Lustre filesystem; given enough time, its output gets correct. From what I understand, statfs cannot report an "always up-to-date" view of the filesystem as this would cost too much time and resources.
> 
> I would like to know what you guys think of having Lustre's statfs operation report a view of the filesystem at least as new as when the last sync operation completed?
> 
> My point being that users (and tests) would be able to run df --sync to get up-to-date information (at the cost of a sync operation, and maybe some accounting for statfs).

This isn't really a problem with "df".  The client will cache the statfs information for at most 1s until it refreshes it again.

What it appears is happening (from LU-8940) is that unlinking a bunch of files doesn't delete the files and destroy the objects fast enough for the small test filesystem.  If there is a real system being used then it would likely not have any significant problems seen on these small filesystems.

There are methods in test-framework.sh (e.g. wait_delete_completed()) to handle the free space reporting when the filesystem is full.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation







From andreas.dilger at intel.com  Fri May 19 03:02:58 2017
From: andreas.dilger at intel.com (Dilger, Andreas)
Date: Fri, 19 May 2017 03:02:58 +0000
Subject: [lustre-devel] [PATCH 1/2] staging: lustre: lprocfs: Use
	kstrtouint_from_user
In-Reply-To: <20170518111343.15a263f1@alcyone.localdomain>
References: <20170504161339.15901-1-mathiasrav@gmail.com>
	<20170504161339.15901-2-mathiasrav@gmail.com>
	<20170518135322.GA6772@kroah.com>
	<9657977C-9620-4C31-9615-E4245482B5A7@intel.com>
	<20170518111343.15a263f1@alcyone.localdomain>
Message-ID: <C724B088-EDD5-4214-BF83-DDF31B93A238@intel.com>

On May 18, 2017, at 17:13, Mathias Rav <mathiasrav at gmail.com> wrote:
> 
> On Thu, 18 May 2017 14:48:25 +0000
> "Dilger, Andreas" <andreas.dilger at intel.com> wrote:
> 
>> On May 18, 2017, at 15:53, Greg Kroah-Hartman <gregkh at linuxfoundation.org> wrote:
>>> 
>>> On Thu, May 04, 2017 at 12:13:38PM -0400, Mathias Rav wrote:  
>>>> Prefer kstrtouint_from_user to copy_from_user+simple_strtoul.
>>>> 
>>>> The helper function lprocfs_wr_uint() is only used to implement
>>>> "dump_granted_max" in debugfs.
>>>> 
>>>> Note the slight change in semantics: The previous implementation using
>>>> simple_strtoul allows garbage after the number, whereas kstrtox only allows
>>>> a trailing line break. The previous implementation allowed a write of zero
>>>> bytes whereas kstrtox will return -EINVAL. Since this only affects a single
>>>> debugfs endpoint, this should be a permissible slight change of semantics
>>>> in exchange for 18 fewer lines of code.
>>>> 
>>>> Signed-off-by: Mathias Rav <mathiasrav at gmail.com>
>>>> ---
>>>> .../lustre/lustre/obdclass/lprocfs_status.c        | 22 +---------------------
>>>> 1 file changed, 1 insertion(+), 21 deletions(-)
>>>> 
>>>> diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
>>>> index 1ec6e3767d81..338ce34d6514 100644
>>>> --- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
>>>> +++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
>>>> @@ -399,27 +399,7 @@ EXPORT_SYMBOL(lprocfs_rd_uint);
>>>> int lprocfs_wr_uint(struct file *file, const char __user *buffer,
>>>> 		    unsigned long count, void *data)
>>>> {
>>>> -	unsigned *p = data;
>>>> -	char dummy[MAX_STRING_SIZE + 1], *end;
>>>> -	unsigned long tmp;
>>>> -
>>>> -	if (count >= sizeof(dummy))
>>>> -		return -EINVAL;
>>>> -
>>>> -	if (count == 0)
>>>> -		return 0;
>>>> -
>>>> -	if (copy_from_user(dummy, buffer, count))
>>>> -		return -EFAULT;
>>>> -
>>>> -	dummy[count] = '\0';
>>>> -
>>>> -	tmp = simple_strtoul(dummy, &end, 0);
>>>> -	if (dummy == end)
>>>> -		return -EINVAL;
>>>> -
>>>> -	*p = (unsigned int)tmp;
>>>> -	return count;
>>>> +	return kstrtouint_from_user(buffer, count, 0, (unsigned int *)data);  
>>> 
>>> Why not just delete this whole function and have the callers make this
>>> call instead?  No need for unneeded wrapper functions of core kernel
>>> calls.  
>> 
>> Even better, it looks like this function has no callers on the client and could just
>> be deleted entirely.
> 
> No, the functions lprocfs_{rd,wr}_uint are used once through a macro:
> ldlm/ldlm_resource.c calls LPROC_SEQ_FOPS_RW_TYPE(ldlm_rw, uint)
> to define ldlm_rw_uint_seq_{show,write}, which then calls
> lprocfs_{rd,wr}_uint which in turn call seq_printf/kstrtouint_from_user.
> 
> It seems like much indirection for almost no gain besides hiding
> access to ((seq_file *) file->private_data)->private in a macro.
> 
> If you agree, I will prepare a patch that switches ldlm_resource to
> using the LPROC_SEQ_FOPS macro directly, which allows us to remove two
> trivial wrappers.

Please do.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation







From mathiasrav at gmail.com  Fri May 19 02:49:20 2017
From: mathiasrav at gmail.com (Mathias Rav)
Date: Thu, 18 May 2017 22:49:20 -0400
Subject: [lustre-devel] [PATCH v2 0/2] staging: lustre: lprocfs: Fix coding
	style issues
Message-ID: <20170519024922.15222-1-mathiasrav@gmail.com>

This patchset fixes two style issues in lprocfs_status.c related to
simple_strtoul and seq_printf (reported by checkpatch).

v1->v2:
  - Patch 1/2 now completely removes lprocfs_{rd,wr}_uint
  - Patch 2/2 unchanged

Mathias Rav (2):
      staging: lustre: Use kstrtouint_from_user in ldlm_rw_uint
      staging: lustre: lprocfs: Use seq_puts instead of seq_printf

 .../staging/lustre/lustre/ldlm/ldlm_resource.c    | 20 +++++++-
 .../lustre/lustre/obdclass/lprocfs_status.c       | 54 ++++-----------------
 2 files changed, 29 insertions(+), 45 deletions(-)

From mathiasrav at gmail.com  Fri May 19 02:49:22 2017
From: mathiasrav at gmail.com (Mathias Rav)
Date: Thu, 18 May 2017 22:49:22 -0400
Subject: [lustre-devel] [PATCH v2 2/2] staging: lustre: lprocfs: Use
	seq_puts instead of seq_printf
In-Reply-To: <20170519024922.15222-1-mathiasrav@gmail.com>
References: <20170519024922.15222-1-mathiasrav@gmail.com>
Message-ID: <20170519024922.15222-3-mathiasrav@gmail.com>

Reported by checkpatch.pl: "WARNING: Prefer seq_puts to seq_printf".

Signed-off-by: Mathias Rav <mathiasrav at gmail.com>
---
 .../staging/lustre/lustre/obdclass/lprocfs_status.c  | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
index b42c4092bf22..6d1caed02733 100644
--- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
+++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
@@ -702,7 +702,7 @@ static int obd_import_flags2str(struct obd_import *imp, struct seq_file *m)
 	bool first = true;
 
 	if (imp->imp_obd->obd_no_recov) {
-		seq_printf(m, "no_recov");
+		seq_puts(m, "no_recov");
 		first = false;
 	}
 
@@ -768,15 +768,15 @@ int lprocfs_rd_import(struct seq_file *m, void *data)
 		   imp->imp_connect_data.ocd_instance);
 	obd_connect_seq_flags2str(m, imp->imp_connect_data.ocd_connect_flags,
 				  ", ");
-	seq_printf(m, " ]\n");
+	seq_puts(m, " ]\n");
 	obd_connect_data_seqprint(m, ocd);
-	seq_printf(m, "    import_flags: [ ");
+	seq_puts(m, "    import_flags: [ ");
 	obd_import_flags2str(imp, m);
 
-	seq_printf(m,
-		   " ]\n"
-		   "    connection:\n"
-		   "       failover_nids: [ ");
+	seq_puts(m,
+		 " ]\n"
+		 "    connection:\n"
+		 "       failover_nids: [ ");
 	spin_lock(&imp->imp_lock);
 	j = 0;
 	list_for_each_entry(conn, &imp->imp_conn_list, oic_item) {
@@ -909,7 +909,7 @@ int lprocfs_rd_state(struct seq_file *m, void *data)
 
 	seq_printf(m, "current_state: %s\n",
 		   ptlrpc_import_state_name(imp->imp_state));
-	seq_printf(m, "state_history:\n");
+	seq_puts(m, "state_history:\n");
 	k = imp->imp_state_hist_idx;
 	for (j = 0; j < IMP_STATE_HIST_LEN; j++) {
 		struct import_state_hist *ish =
@@ -931,7 +931,7 @@ int lprocfs_at_hist_helper(struct seq_file *m, struct adaptive_timeout *at)
 
 	for (i = 0; i < AT_BINS; i++)
 		seq_printf(m, "%3u ", at->at_hist[i]);
-	seq_printf(m, "\n");
+	seq_puts(m, "\n");
 	return 0;
 }
 EXPORT_SYMBOL(lprocfs_at_hist_helper);
@@ -999,7 +999,7 @@ int lprocfs_rd_connect_flags(struct seq_file *m, void *data)
 	flags = obd->u.cli.cl_import->imp_connect_data.ocd_connect_flags;
 	seq_printf(m, "flags=%#llx\n", flags);
 	obd_connect_seq_flags2str(m, flags, "\n");
-	seq_printf(m, "\n");
+	seq_puts(m, "\n");
 	up_read(&obd->u.cli.cl_sem);
 	return 0;
 }
-- 
2.13.0

From mathiasrav at gmail.com  Fri May 19 02:49:21 2017
From: mathiasrav at gmail.com (Mathias Rav)
Date: Thu, 18 May 2017 22:49:21 -0400
Subject: [lustre-devel] [PATCH v2 1/2] staging: lustre: Use
	kstrtouint_from_user in ldlm_rw_uint
In-Reply-To: <20170519024922.15222-1-mathiasrav@gmail.com>
References: <20170519024922.15222-1-mathiasrav@gmail.com>
Message-ID: <20170519024922.15222-2-mathiasrav@gmail.com>

Clean up the helper functions used to implement "dump_granted_max" in
debugfs.

Replace the lprocfs_rd_uint() and lprocfs_wr_uint() generic callbacks
with a simpler, more direct implementation of ldlm_rw_uint_fops.

There's a slight change in lustre debugfs write semantics: Using kstrtox
causes EINVAL when the written number is followed by other (garbage)
characters, whereas previously the garbage would be ignored and such a
write would succeed.

Signed-off-by: Mathias Rav <mathiasrav at gmail.com>
---
 drivers/staging/lustre/lustre/ldlm/ldlm_resource.c | 20 ++++++++++++-
 .../lustre/lustre/obdclass/lprocfs_status.c        | 34 ----------------------
 2 files changed, 19 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_resource.c b/drivers/staging/lustre/lustre/ldlm/ldlm_resource.c
index 633f65b078eb..1c8b0ea10c32 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_resource.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_resource.c
@@ -78,7 +78,25 @@ lprocfs_wr_dump_ns(struct file *file, const char __user *buffer,
 
 LPROC_SEQ_FOPS_WR_ONLY(ldlm, dump_ns);
 
-LPROC_SEQ_FOPS_RW_TYPE(ldlm_rw, uint);
+static int ldlm_rw_uint_seq_show(struct seq_file *m, void *v)
+{
+	seq_printf(m, "%u\n", *(unsigned int *)m->private);
+	return 0;
+}
+
+static ssize_t
+ldlm_rw_uint_seq_write(struct file *file, const char __user *buffer,
+		       size_t count, loff_t *off)
+{
+	struct seq_file *seq = file->private_data;
+
+	if (count == 0)
+		return 0;
+	return kstrtouint_from_user(buffer, count, 0,
+				    (unsigned int *)seq->private);
+}
+
+LPROC_SEQ_FOPS(ldlm_rw_uint);
 
 static struct lprocfs_vars ldlm_debugfs_list[] = {
 	{ "dump_namespaces", &ldlm_dump_ns_fops, NULL, 0222 },
diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
index 1ec6e3767d81..b42c4092bf22 100644
--- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
+++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
@@ -389,40 +389,6 @@ struct dentry *ldebugfs_register(const char *name,
 EXPORT_SYMBOL_GPL(ldebugfs_register);
 
 /* Generic callbacks */
-int lprocfs_rd_uint(struct seq_file *m, void *data)
-{
-	seq_printf(m, "%u\n", *(unsigned int *)data);
-	return 0;
-}
-EXPORT_SYMBOL(lprocfs_rd_uint);
-
-int lprocfs_wr_uint(struct file *file, const char __user *buffer,
-		    unsigned long count, void *data)
-{
-	unsigned *p = data;
-	char dummy[MAX_STRING_SIZE + 1], *end;
-	unsigned long tmp;
-
-	if (count >= sizeof(dummy))
-		return -EINVAL;
-
-	if (count == 0)
-		return 0;
-
-	if (copy_from_user(dummy, buffer, count))
-		return -EFAULT;
-
-	dummy[count] = '\0';
-
-	tmp = simple_strtoul(dummy, &end, 0);
-	if (dummy == end)
-		return -EINVAL;
-
-	*p = (unsigned int)tmp;
-	return count;
-}
-EXPORT_SYMBOL(lprocfs_wr_uint);
-
 static ssize_t uuid_show(struct kobject *kobj, struct attribute *attr,
 			 char *buf)
 {
-- 
2.13.0

From nikola.jelic83 at gmail.com  Fri May 19 18:48:07 2017
From: nikola.jelic83 at gmail.com (Nikola Jelic)
Date: Fri, 19 May 2017 20:48:07 +0200
Subject: [lustre-devel] [PATCH] lustre: ko2iblnd: removed forced u32 casts
	after htonl
Message-ID: <20170519184807.9783-1-nikola.jelic83@gmail.com>

sockaddr_in.sin_addr.s_addr is __be32 integral type, so the (__force u32)
cast after the htonl call is unnecessary, and also detected by sparse:
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2309:33: warning: incorrect type in assignment (different base types)
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2381:30: warning: incorrect type in assignment (different base types)

Signed-off-by: Nikola Jelic <nikola.jelic83 at gmail.com>
---
 drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 79321e4aaf30..0520f02f670d 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -2306,7 +2306,7 @@ static int kiblnd_dev_need_failover(struct kib_dev *dev)
 
 	memset(&srcaddr, 0, sizeof(srcaddr));
 	srcaddr.sin_family = AF_INET;
-	srcaddr.sin_addr.s_addr = (__force u32)htonl(dev->ibd_ifip);
+	srcaddr.sin_addr.s_addr = htonl(dev->ibd_ifip);
 
 	memset(&dstaddr, 0, sizeof(dstaddr));
 	dstaddr.sin_family = AF_INET;
@@ -2378,7 +2378,7 @@ int kiblnd_dev_failover(struct kib_dev *dev)
 
 	memset(&addr, 0, sizeof(addr));
 	addr.sin_family      = AF_INET;
-	addr.sin_addr.s_addr = (__force u32)htonl(dev->ibd_ifip);
+	addr.sin_addr.s_addr = htonl(dev->ibd_ifip);
 	addr.sin_port	= htons(*kiblnd_tunables.kib_service);
 
 	/* Bind to failover device or port */
-- 
2.11.0

From oleg.drokin at intel.com  Tue May 23 05:48:53 2017
From: oleg.drokin at intel.com (Oleg Drokin)
Date: Tue, 23 May 2017 01:48:53 -0400
Subject: [lustre-devel] new tag 2.9.58
Message-ID: <3C6162D1-5FE5-4EFC-9D31-D2A7CE83F5B8@intel.com>

Hello!

   I just tagged 2.9.58 tag in the lustre development master tree.

   Here's the changelog:
Alex Zhuravlev (3):
      LU-9285 osp: revert patches LU-8367 and LU-8973
      LU-8367 osp: orphan cleanup do not wait for reserved
      LU-9394 osd: __osd_obj2dnode() to return negative errors

Amir Shehata (1):
      LU-9119 lnet: selftest MR fix

Andreas Dilger (9):
      LU-9201 test: avoid long sleeps in mount_facet()
      LU-8998 llapi: add LLAPI_LAYOUT_COMP_USE_PREV
      LU-9411 tests: skip llapi_layout_test 30, 31 for interop
      LU-7567 utils: fix timestamp printing in lfs_changelog()
      LU-8998 tests: improve sanity.sh::check_seq_oid()
      LU-7584 tests: clean up sanity test_129
      LU-8589 osd: remove "object" from method function names
      LU-9415 lfsck: quiet noisy console message
      LU-9330 osp: make variables match proc tunables

Andriy Skulysh (3):
      LU-7062 ldlm: GPF in _ldlm_lock_debug()
      LU-8359 ldlm: Wrong evict during failover
      LU-9241 llite: ASSERTION( de->d_op == &ll_d_ops ) failed

Arnd Bergmann (2):
      LU-4423 ptlrpc: use 64-bit times for request times
      LU-4423 selftest: use jiffies_to_*() instead of cfs_duration_usec

Arshad Hussain (1):
      LU-8670 tests: test_115 Fixes & Improvements

Bob Glossman (1):
      LU-9458 ptlrpc: handle case of epp_free_pages <= PTLRPC_MAX_BRW_PAGES

Bobi Jam (6):
      LU-9324 lfs: output stripe info in YAML format
      LU-9357 pfl: should inherit pool from previous layout comp
      LU-9324 lnet: move cyaml.h under lnet/include/
      LU-9362 lfs: getstripe print last init-ed component info
      LU-9315 pfl: static analysis issues
      LU-9412 lfs: A invalid memory write in llapi_layout_to_lum

Bruno Faccini (3):
      LU-8376 ost: enhance end to end bulk cksum error report
      LU-9372 ptlrpc: drain "ptlrpc_request_buffer_desc" objects
      LU-9477 tests: check correct handling of dead object

Chris Hanna (1):
      LU-9430 utils: fix logic errors and putchar in sk_name2hmac()

Chris Horn (1):
      LU-9447 o2iblnd: Check for 2 arg ib_alloc_pd

Dmitry Eremin (5):
      LU-9183 llite: handle make the string hashes salt the hash
      LU-9183 llite: handle removal the pos argument of generic_write_sync
      LU-9205 tests: fix failures in CLIENTONLY mode
      LU-9183 ptlrpc: handle changes in struct group_info
      LU-9183 llite: remove struct file on stack in ll_setxattr()

Doug Oucharek (4):
      LU-8943 lnd: Enable Multiple OPA Endpoints between Nodes
      LU-9456 lnd: Change sock_create() to sock_create_kern()
      LU-9425 lnd: Turn on 2 sges by default
      LU-9472 lnd: Fix FastReg map/unmap for MLX5

Emoly Liu (1):
      LU-9369 lfs: make lfs find work correctly

Fan Yong (4):
      LU-9040 scrub: detect dead loop scanning
      LU-7473 acl: increase ACL entries limitation
      LU-9202 lfsck: skip unavailable targets when sync failures
      LU-9303 doc: man pages for snapshot components

Frank Zago (1):
      LU-7988 hsm: change coordinator start/stop mechanisms

Giuseppe Di Natale (1):
      LU-9439 scripts: lnet systemd service

Hongchao Zhang (3):
      LU-5788 test: fix the cmd to getfree space
      LU-8346 obdclass: guarantee all keys filled
      LU-6952 mount: Mount options parsing problem

James Nunez (4):
      LU-9125 test: Update setstripe options
      LU-9096 test: add sanity 253 to ALWAYS_EXCEPT
      LU-9514 test: sanity 51f add to ALWAYS_EXCEPT
      LU-9522 test: sanity 27z fix update local variable

James Simmons (2):
      LU-9019 libcfs: migrate watchdog to 64 bit time
      LU-6401 uapi: turn lustre_param.h into a proper UAPI header

Jinshan Xiong (3):
      LU-9305 osd-zfs: arc_buf could be non-pagesize aligned
      LU-9340 lov: Initialize component extents unconditionally
      LU-9491 llite: Handle multi-vec append write correctly

John L. Hammond (8):
      LU-9312 hsm: fix error handling around mdt_hsm_get_md_hsm()
      LU-9312 hsm: add a cookie indexed request hash
      LU-9403 mdt: prevent HSM leak on re-archive
      LU-9404 mdt: set HSM xattr only when needed
      LU-9385 mdt: remove XATTR locking from mdt_add_dirty_flag()
      LU-9443 mdd: omit changelog records for volatile files
      LU-9312 hsm: release restore lock without object
      LU-9464 hsm: use OBD_ALLOC_LARGE() for hsm_scan_data array

Kit Westneat (1):
      LU-8294 gss: quiet cache_check return ENOENT warning

Lai Siyao (1):
      LU-8650 mdt: enable REP-ACK for DNE

Niu Yawei (1):
      LU-8998 tools: support negative flags

Oleg Drokin (2):
      Revert "LU-9439 scripts: Change behavior of lustre_rmmod"
      New tag 2.9.58

Patrick Farrell (1):
      LU-8307 ldlm: cond_resched in ldlm_bl_thread_main

Prakash Surya (1):
      LU-9439 scripts: Change behavior of lustre_rmmod

Qian Yingjin (1):
      LU-9140 nrs: add some debug log for NRS TBF

Saurabh Tandan (1):
      LU-7108 test: Remove sanityn tests from ALWAYS_EXCEPT list

Sebastien Buisson (1):
      LU-8659 tests: use runcon in sanity-selinux

Sushant Mane (1):
      LU-8730 test: Remove duplicate $dev from conf-sanity test_83

Wang Shilong (1):
      LU-4017 quota: cleanup to improve quota codes

Yang Sheng (2):
      LU-8364 ldiskfs: fixes for failover mode
      LU-9384 ldiskfs: port upstream patches for changing extra isize

sharmaso (1):
      LU-9119 lnet: Fix deleting peers from YAML

wangdi (1):
      LU-8746 update: restore tdtd_refcount during failure

From quentin.bouget at cea.fr  Tue May 23 13:34:04 2017
From: quentin.bouget at cea.fr (quentin.bouget at cea.fr)
Date: Tue, 23 May 2017 15:34:04 +0200
Subject: [lustre-devel] have df report a more up-to-date view of the
 filesystem
In-Reply-To: <A5B44F72-4853-44F6-B453-E919F303AA95@intel.com>
References: <9e5f3b8d-b5f5-ce10-2b35-e6f13b7de532@cea.fr>
	<A5B44F72-4853-44F6-B453-E919F303AA95@intel.com>
Message-ID: <6a0002bd-b70f-9672-0529-46038b1be5e8@cea.fr>

Le 19/05/2017 à 04:14, Dilger, Andreas a écrit :
> On May 17, 2017, at 13:16, quentin.bouget at cea.fr wrote:
>> Hi everyone,
>>
>> In LU-8940 I describe an issue I am having with df in Lustre's tests. In short, df/statfs can report outdated information about a Lustre filesystem; given enough time, its output gets correct. From what I understand, statfs cannot report an "always up-to-date" view of the filesystem as this would cost too much time and resources.
>>
>> I would like to know what you guys think of having Lustre's statfs operation report a view of the filesystem at least as new as when the last sync operation completed?
>>
>> My point being that users (and tests) would be able to run df --sync to get up-to-date information (at the cost of a sync operation, and maybe some accounting for statfs).
> This isn't really a problem with "df".  The client will cache the statfs information for at most 1s until it refreshes it again.
>
> What it appears is happening (from LU-8940) is that unlinking a bunch of files doesn't delete the files and destroy the objects fast enough for the small test filesystem.  If there is a real system being used then it would likely not have any significant problems seen on these small filesystems.
>
> There are methods in test-framework.sh (e.g. wait_delete_completed()) to handle the free space reporting when the filesystem is full.
>
> Cheers, Andreas
> --
> Andreas Dilger
> Lustre Principal Architect
> Intel Corporation

It would seem wait_delete_completed() is exactly what we were looking 
for to solve LU-8940.

Thanks!
Quentin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel_lists.lustre.org/attachments/20170523/1ec01bd2/attachment.html>

From gregkh at linuxfoundation.org  Tue May 23 19:38:55 2017
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 23 May 2017 21:38:55 +0200
Subject: [lustre-devel] [PATCH] drivers: staging: lustre: replace
 variable length array by dynamic allocation
In-Reply-To: <8c04ebb67ffbc9482cc6170e9bd29ec513766218.1495567933.git.raphael.beamonte@gmail.com>
References: <8c04ebb67ffbc9482cc6170e9bd29ec513766218.1495567933.git.raphael.beamonte@gmail.com>
Message-ID: <20170523193855.GA11862@kroah.com>

On Tue, May 23, 2017 at 09:32:13PM +0200, Raphaël Beamonte wrote:
> Fixes the following sparse warnings:
> 
> drivers/staging/lustre/lustre/llite/xattr.c:89:62: warning: Variable
> length array is used.
> drivers/staging/lustre/lustre/llite/xattr.c:366:62: warning: Variable
> length array is used.
> 
> Signed-off-by: Raphaël Beamonte <raphael.beamonte at gmail.com>
> ---
>  drivers/staging/lustre/lustre/llite/xattr.c | 24 ++++++++++++++++++++----
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c
> index 6187bffec8c4..ccfc728d8ec0 100644
> --- a/drivers/staging/lustre/lustre/llite/xattr.c
> +++ b/drivers/staging/lustre/lustre/llite/xattr.c
> @@ -86,7 +86,7 @@ ll_xattr_set_common(const struct xattr_handler *handler,
>  		    const char *name, const void *value, size_t size,
>  		    int flags)
>  {
> -	char fullname[strlen(handler->prefix) + strlen(name) + 1];
> +	char *fullname;
>  	struct ll_sb_info *sbi = ll_i2sbi(inode);
>  	struct ptlrpc_request *req = NULL;
>  	const char *pv = value;
> @@ -140,10 +140,18 @@ ll_xattr_set_common(const struct xattr_handler *handler,
>  			return -EPERM;
>  	}
>  
> +	fullname = kmalloc(strlen(handler->prefix) + strlen(name) + 1,
> +			   GFP_KERNEL);
> +	if (!fullname)
> +		return -ENOMEM;
> +
>  	sprintf(fullname, "%s%s\n", handler->prefix, name);
>  	rc = md_setxattr(sbi->ll_md_exp, ll_inode2fid(inode),
>  			 valid, fullname, pv, size, 0, flags,
>  			 ll_i2suppgid(inode), &req);
> +
> +	kfree(fullname);

Didn't we reject much this same patch last week?

thanks,

greg k-h

From green at linuxhacker.ru  Sat May 27 03:40:33 2017
From: green at linuxhacker.ru (Oleg Drokin)
Date: Fri, 26 May 2017 23:40:33 -0400
Subject: [lustre-devel] [PATCH] staging/lustre/lov: remove set_fs() call
	from lov_getstripe()
Message-ID: <20170527034033.223677-1-green@linuxhacker.ru>

lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct
lov_user_md pointer from user- or kernel-space.  This changes the
behavior of copy_from_user() on SPARC and may result in a misaligned
access exception which in turn oopses the kernel.  In fact the
relevant argument to lov_getstripe() is never called with a
kernel-space pointer and so changing the address limits is unnecessary
and so we remove the calls to save, set, and restore the address
limits.

Signed-off-by: John L. Hammond <john.hammond at intel.com>
Reviewed-on: http://review.whamcloud.com/6150
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221
Reviewed-by: Andreas Dilger <andreas.dilger at intel.com>
Reviewed-by: Li Wei <wei.g.li at intel.com>
Signed-off-by: Oleg Drokin <green at linuxhacker.ru>
---
 drivers/staging/lustre/lustre/lov/lov_pack.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lov/lov_pack.c b/drivers/staging/lustre/lustre/lov/lov_pack.c
index 2e1bd47..e6727ce 100644
--- a/drivers/staging/lustre/lustre/lov/lov_pack.c
+++ b/drivers/staging/lustre/lustre/lov/lov_pack.c
@@ -293,18 +293,10 @@ int lov_getstripe(struct lov_object *obj, struct lov_stripe_md *lsm,
 	size_t lmmk_size;
 	size_t lum_size;
 	int rc;
-	mm_segment_t seg;
 
 	if (!lsm)
 		return -ENODATA;
 
-	/*
-	 * "Switch to kernel segment" to allow copying from kernel space by
-	 * copy_{to,from}_user().
-	 */
-	seg = get_fs();
-	set_fs(KERNEL_DS);
-
 	if (lsm->lsm_magic != LOV_MAGIC_V1 && lsm->lsm_magic != LOV_MAGIC_V3) {
 		CERROR("bad LSM MAGIC: 0x%08X != 0x%08X nor 0x%08X\n",
 		       lsm->lsm_magic, LOV_MAGIC_V1, LOV_MAGIC_V3);
@@ -406,6 +398,5 @@ int lov_getstripe(struct lov_object *obj, struct lov_stripe_md *lsm,
 out_free:
 	kvfree(lmmk);
 out:
-	set_fs(seg);
 	return rc;
 }
-- 
2.9.3

From nikola.jelic83 at gmail.com  Sat May 27 21:37:28 2017
From: nikola.jelic83 at gmail.com (Nikola Jelic)
Date: Sat, 27 May 2017 23:37:28 +0200
Subject: [lustre-devel] [PATCH] staging: lustre: changed __u32 to __be32
Message-ID: <20170527213728.19297-1-nikola.jelic83@gmail.com>

Temporary variable is used only as __be32, for both assignments and reads,
but the type is inconsistent (__u32).

Signed-off-by: Nikola Jelic <nikola.jelic83 at gmail.com>
---
 drivers/staging/lustre/lnet/lnet/lib-socket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lnet/lnet/lib-socket.c b/drivers/staging/lustre/lnet/lnet/lib-socket.c
index 9fca8d225ee0..776f3c2fa486 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-socket.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-socket.c
@@ -89,7 +89,7 @@ lnet_ipif_query(char *name, int *up, __u32 *ip, __u32 *mask)
 	struct ifreq ifr;
 	int nob;
 	int rc;
-	__u32 val;
+	__be32 val;
 
 	nob = strnlen(name, IFNAMSIZ);
 	if (nob == IFNAMSIZ) {
-- 
2.11.0

From nikola.jelic83 at gmail.com  Sat May 27 22:14:11 2017
From: nikola.jelic83 at gmail.com (Nikola Jelic)
Date: Sun, 28 May 2017 00:14:11 +0200
Subject: [lustre-devel] [PATCH] staging: lustre: in-place endianness
	functions
Message-ID: <20170527221411.23772-1-nikola.jelic83@gmail.com>

lib-move.c file has a lot of expressions in the form of:
v = le[32|64]_to_cpu(v);
This caused a lot of sparse warnings.
Replaced with:
le[32|64]_to_cpus(&v);

Signed-off-by: Nikola Jelic <nikola.jelic83 at gmail.com>
---
 drivers/staging/lustre/lnet/lnet/lib-move.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c b/drivers/staging/lustre/lnet/lnet/lib-move.c
index a99c5c0aa672..20ebe247071f 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-move.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
@@ -1274,9 +1274,9 @@ lnet_parse_put(struct lnet_ni *ni, struct lnet_msg *msg)
 	int rc;
 
 	/* Convert put fields to host byte order */
-	hdr->msg.put.match_bits	= le64_to_cpu(hdr->msg.put.match_bits);
-	hdr->msg.put.ptl_index	= le32_to_cpu(hdr->msg.put.ptl_index);
-	hdr->msg.put.offset	= le32_to_cpu(hdr->msg.put.offset);
+	le64_to_cpus(&hdr->msg.put.match_bits);
+	le32_to_cpus(&hdr->msg.put.ptl_index);
+	le32_to_cpus(&hdr->msg.put.offset);
 
 	info.mi_id.nid	= hdr->src_nid;
 	info.mi_id.pid	= hdr->src_pid;
@@ -1332,10 +1332,10 @@ lnet_parse_get(struct lnet_ni *ni, struct lnet_msg *msg, int rdma_get)
 	int rc;
 
 	/* Convert get fields to host byte order */
-	hdr->msg.get.match_bits  = le64_to_cpu(hdr->msg.get.match_bits);
-	hdr->msg.get.ptl_index   = le32_to_cpu(hdr->msg.get.ptl_index);
-	hdr->msg.get.sink_length = le32_to_cpu(hdr->msg.get.sink_length);
-	hdr->msg.get.src_offset  = le32_to_cpu(hdr->msg.get.src_offset);
+	le64_to_cpus(&hdr->msg.get.match_bits);
+	le32_to_cpus(&hdr->msg.get.ptl_index);
+	le32_to_cpus(&hdr->msg.get.sink_length);
+	le32_to_cpus(&hdr->msg.get.src_offset);
 
 	info.mi_id.nid  = hdr->src_nid;
 	info.mi_id.pid  = hdr->src_pid;
@@ -1464,8 +1464,8 @@ lnet_parse_ack(struct lnet_ni *ni, struct lnet_msg *msg)
 	src.pid = hdr->src_pid;
 
 	/* Convert ack fields to host byte order */
-	hdr->msg.ack.match_bits = le64_to_cpu(hdr->msg.ack.match_bits);
-	hdr->msg.ack.mlength = le32_to_cpu(hdr->msg.ack.mlength);
+	le64_to_cpus(&hdr->msg.ack.match_bits);
+	le32_to_cpus(&hdr->msg.ack.mlength);
 
 	cpt = lnet_cpt_of_cookie(hdr->msg.ack.dst_wmd.wh_object_cookie);
 	lnet_res_lock(cpt);
@@ -1798,7 +1798,7 @@ lnet_parse(struct lnet_ni *ni, struct lnet_hdr *hdr, lnet_nid_t from_nid,
 		/* convert common msg->hdr fields to host byteorder */
 		msg->msg_hdr.type	= type;
 		msg->msg_hdr.src_nid	= src_nid;
-		msg->msg_hdr.src_pid	= le32_to_cpu(msg->msg_hdr.src_pid);
+		le32_to_cpus(&msg->msg_hdr.src_pid);
 		msg->msg_hdr.dest_nid	= dest_nid;
 		msg->msg_hdr.dest_pid	= dest_pid;
 		msg->msg_hdr.payload_length = payload_length;
-- 
2.11.0

From gregkh at linuxfoundation.org  Mon May 29 14:28:44 2017
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 29 May 2017 16:28:44 +0200
Subject: [lustre-devel] [PATCH] staging/lustre/lov: remove set_fs() call
 from lov_getstripe()
In-Reply-To: <20170527034033.223677-1-green@linuxhacker.ru>
References: <20170527034033.223677-1-green@linuxhacker.ru>
Message-ID: <20170529142843.GA11952@kroah.com>

On Fri, May 26, 2017 at 11:40:33PM -0400, Oleg Drokin wrote:
> lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct
> lov_user_md pointer from user- or kernel-space.  This changes the
> behavior of copy_from_user() on SPARC and may result in a misaligned
> access exception which in turn oopses the kernel.  In fact the
> relevant argument to lov_getstripe() is never called with a
> kernel-space pointer and so changing the address limits is unnecessary
> and so we remove the calls to save, set, and restore the address
> limits.
> 
> Signed-off-by: John L. Hammond <john.hammond at intel.com>
> Reviewed-on: http://review.whamcloud.com/6150
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221
> Reviewed-by: Andreas Dilger <andreas.dilger at intel.com>
> Reviewed-by: Li Wei <wei.g.li at intel.com>
> Signed-off-by: Oleg Drokin <green at linuxhacker.ru>
> ---
>  drivers/staging/lustre/lustre/lov/lov_pack.c | 9 ---------
>  1 file changed, 9 deletions(-)

So is this the patch that you want applied to the staging tree(s) as
well?  If so, please let me know, otherwise I have no clue...

Come on, you know better than this...

greg k-h

From green at linuxhacker.ru  Mon May 29 15:55:53 2017
From: green at linuxhacker.ru (Oleg Drokin)
Date: Mon, 29 May 2017 11:55:53 -0400
Subject: [lustre-devel] [PATCH] staging/lustre/lov: remove set_fs() call
	from lov_getstripe()
In-Reply-To: <20170529142843.GA11952@kroah.com>
References: <20170527034033.223677-1-green@linuxhacker.ru>
	<20170529142843.GA11952@kroah.com>
Message-ID: <BB2BB1AB-2956-4977-8244-9ACEAB57C033@linuxhacker.ru>


On May 29, 2017, at 10:28 AM, Greg Kroah-Hartman wrote:

> On Fri, May 26, 2017 at 11:40:33PM -0400, Oleg Drokin wrote:
>> lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct
>> lov_user_md pointer from user- or kernel-space.  This changes the
>> behavior of copy_from_user() on SPARC and may result in a misaligned
>> access exception which in turn oopses the kernel.  In fact the
>> relevant argument to lov_getstripe() is never called with a
>> kernel-space pointer and so changing the address limits is unnecessary
>> and so we remove the calls to save, set, and restore the address
>> limits.
>> 
>> Signed-off-by: John L. Hammond <john.hammond at intel.com>
>> Reviewed-on: http://review.whamcloud.com/6150
>> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221
>> Reviewed-by: Andreas Dilger <andreas.dilger at intel.com>
>> Reviewed-by: Li Wei <wei.g.li at intel.com>
>> Signed-off-by: Oleg Drokin <green at linuxhacker.ru>
>> ---
>> drivers/staging/lustre/lustre/lov/lov_pack.c | 9 ---------
>> 1 file changed, 9 deletions(-)
> 
> So is this the patch that you want applied to the staging tree(s) as
> well?  If so, please let me know, otherwise I have no clue…

Yes, this is it.
Thanks!

From oleg.drokin at intel.com  Wed May 31 13:36:56 2017
From: oleg.drokin at intel.com (Oleg Drokin)
Date: Wed, 31 May 2017 09:36:56 -0400
Subject: [lustre-devel] [PATCH V2] libcfs: Fix a sleep-in-atomic bug in
	cfs_wi_deschedule
In-Reply-To: <1496217420-16868-1-git-send-email-baijiaju1990@163.com>
References: <1496217420-16868-1-git-send-email-baijiaju1990@163.com>
Message-ID: <C018CB68-5485-4EC7-ABE1-B15D5DD7DE64@intel.com>

Hello!

On May 31, 2017, at 3:57 AM, Jia-Ju Bai wrote:

> The driver may sleep under a spin lock, and the function call path is:
> cfs_wi_deschedule (acquire the lock by spin_lock)
>  LASSERT
>    lbug_with_loc
>      libcfs_debug_dumplog
>        schedule and kthread_run --> may sleep
> 
> To fix it, all "LASSERT" is placed out of the spin_lock and spin_unlock.
> 
> Signed-off-by: Jia-Ju Bai <baijiaju1990 at 163.com>
> ---
> drivers/staging/lustre/lnet/libcfs/workitem.c |   12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lnet/libcfs/workitem.c b/drivers/staging/lustre/lnet/libcfs/workitem.c
> index dbc2a9b..9c530cf 100644
> --- a/drivers/staging/lustre/lnet/libcfs/workitem.c
> +++ b/drivers/staging/lustre/lnet/libcfs/workitem.c
> @@ -140,6 +140,10 @@ struct cfs_wi_sched {
> 
> 	LASSERT(!in_interrupt()); /* because we use plain spinlock */
> 	LASSERT(!sched->ws_stopping);
> +	if (wi->wi_scheduled) {
> +		LASSERT(!list_empty(&wi->wi_list));
> +		LASSERT(sched->ws_nscheduled > 0);
> +	}

I don't think you can do this,
this was under spinlock because those values could change from a different thread
and we do need to look at them all together.

You are correct that LASSET/LBUG might schedule to dump a debug log
into a file and even if not it does sleep indefinitely after that.
But in reality the default option is "panic_on_lbug=1" which simply converts
LASSERT() into panic().

This is certainly not a normal condition and as such I think we can leave the code
as is.

Thanks.


> 
> 	/*
> 	 * return 0 if it's running already, otherwise return 1, which
> @@ -151,18 +155,14 @@ struct cfs_wi_sched {
> 	rc = !(wi->wi_running);
> 
> 	if (wi->wi_scheduled) { /* cancel pending schedules */
> -		LASSERT(!list_empty(&wi->wi_list));
> 		list_del_init(&wi->wi_list);
> -
> -		LASSERT(sched->ws_nscheduled > 0);
> 		sched->ws_nscheduled--;
> -
> 		wi->wi_scheduled = 0;
> 	}
> 
> -	LASSERT(list_empty(&wi->wi_list));
> -
> 	spin_unlock(&sched->ws_lock);
> +
> +	LASSERT(list_empty(&wi->wi_list));
> 	return rc;
> }
> EXPORT_SYMBOL(cfs_wi_deschedule);
> -- 
> 1.7.9.5
> 

From oleg.drokin at intel.com  Wed May 31 13:39:51 2017
From: oleg.drokin at intel.com (Oleg Drokin)
Date: Wed, 31 May 2017 09:39:51 -0400
Subject: [lustre-devel] [PATCH V2] libcfs: Fix a sleep-in-atomic bug in
	cfs_wi_exit
In-Reply-To: <1496217641-17002-1-git-send-email-baijiaju1990@163.com>
References: <1496217641-17002-1-git-send-email-baijiaju1990@163.com>
Message-ID: <440F74B1-2F94-4C08-A9F9-EDF039BE6565@intel.com>

Hello!

On May 31, 2017, at 4:00 AM, Jia-Ju Bai wrote:

> The driver may sleep under a spin lock, and the function call path is:
> cfs_wi_exit (acquire the lock by spin_lock)
>  LASSERT
>    lbug_with_loc
>      libcfs_debug_dumplog
>        schedule and kthread_run --> may sleep
> 
> To fix it, all "LASSERT" is placed out of the spin_lock and spin_unlock.
> 
> Signed-off-by: Jia-Ju Bai <baijiaju1990 at 163.com>
> ---
> drivers/staging/lustre/lnet/libcfs/workitem.c |   13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lnet/libcfs/workitem.c b/drivers/staging/lustre/lnet/libcfs/workitem.c
> index dbc2a9b..928d06d 100644
> --- a/drivers/staging/lustre/lnet/libcfs/workitem.c
> +++ b/drivers/staging/lustre/lnet/libcfs/workitem.c
> @@ -111,22 +111,23 @@ struct cfs_wi_sched {
> {
> 	LASSERT(!in_interrupt()); /* because we use plain spinlock */
> 	LASSERT(!sched->ws_stopping);
> +	LASSERT(wi->wi_running);
> +	if (wi->wi_scheduled) {
> +		LASSERT(!list_empty(&wi->wi_list));
> +		LASSERT(sched->ws_nscheduled > 0);
> +	}

Similarly here and in all other patches about LASSERT calls under spinlocks() from you,
just think of them as a panic() call, no operations are expected to continue
after it triggers.

Thanks.

> 
> 	spin_lock(&sched->ws_lock);
> 
> -	LASSERT(wi->wi_running);
> 	if (wi->wi_scheduled) { /* cancel pending schedules */
> -		LASSERT(!list_empty(&wi->wi_list));
> 		list_del_init(&wi->wi_list);
> -
> -		LASSERT(sched->ws_nscheduled > 0);
> 		sched->ws_nscheduled--;
> 	}
> 
> -	LASSERT(list_empty(&wi->wi_list));
> -
> 	wi->wi_scheduled = 1; /* LBUG future schedule attempts */
> 	spin_unlock(&sched->ws_lock);
> +
> +	LASSERT(list_empty(&wi->wi_list));
> }
> EXPORT_SYMBOL(cfs_wi_exit);
> 
> -- 
> 1.7.9.5
>