Re: [PATCH] staging: wilc1000: rework comments in wilc_sdio.c

2016-04-10 Thread Julian Calaby 
Hi Mohammed,

On Sun, Apr 10, 2016 at 5:11 AM,   wrote:
> From: Mohammed Billoo 
>
> Remove unnecessary comments (highlighting sections of functions), make
> multiline comments into single line comments, and ensure that multiline
> comments adhere to coding style.

You need to add a signed-off-by line here.

> ---
>  drivers/staging/wilc1000/wilc_sdio.c | 136 
> ---
>  1 file changed, 31 insertions(+), 105 deletions(-)
>

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 00/17] staging : lustre : rest of missing patches from 2.5.0 release

2016-04-10 Thread James Simmons 
This is the last collection of missing fixes present in the
Lustre 2.5.0 release. Once these are merged the upstream
client will be equal to the pre-2.6 lustre version since the
major of clio cleanups from that time frame have already
landed.

Andrew Perepechko (3):
  staging: lustre: llite: variable rename in namei.c
  staging: lustre: llite: speedup in unlink/rmdir
  staging: lustre: lprocfs: implement log2 using bitops

Andriy Skulysh (1):
  staging: lustre: lov: Don't wait for active target with OBD_STATFS_NODELAY

Bobi Jam (1):
  staging: lustre: obd: MDT mount fails on MDS w/o MGS on it

Bruno Faccini (3):
  staging: lustre: ldlm: Fix a race during FLock handling
  staging: lustre: ldlm: refine LU-2665 patch for POSIX compliance
  staging: lustre: lov: return minimal FIEMAP for released files

Jeff Mahoney (1):
  staging: lustre: lloop: Fix build failure on ppc64

Jinshan Xiong (3):
  staging: lustre: llite: error setting max_cache_mb at mount time
  staging: lustre: llite: Truncate to restore file
  staging: lustre: osc: osc_extent_wait() shouldn't be interruptible

John L. Hammond (2):
  staging: lustre: hsm: permission checks for HSM ioctl operations
  staging: lustre: hsm: don't use real suppgid

Niu Yawei (1):
  staging: lustre: clio: incorrect assertions in 'enable-invariants'

Sebastien Buisson (1):
  staging: lustre: osc: fix race issues thanks to oap_lock

Swapnil Pimpale (1):
  staging: lustre: ptlrpc: return a meaningful status from ptlrpcd_init()

 drivers/staging/lustre/lustre/ldlm/ldlm_flock.c|   15 +++--
 drivers/staging/lustre/lustre/llite/dir.c  |3 +
 drivers/staging/lustre/lustre/llite/file.c |5 +-
 .../staging/lustre/lustre/llite/llite_internal.h   |2 +-
 drivers/staging/lustre/lustre/llite/llite_lib.c|   60 +--
 drivers/staging/lustre/lustre/llite/lloop.c|3 -
 drivers/staging/lustre/lustre/llite/lproc_llite.c  |4 +-
 drivers/staging/lustre/lustre/llite/namei.c|   65 ++--
 drivers/staging/lustre/lustre/llite/vvp_io.c   |5 +-
 drivers/staging/lustre/lustre/lov/lov_obd.c|   21 ++
 drivers/staging/lustre/lustre/lov/lov_request.c|7 ++-
 drivers/staging/lustre/lustre/mdc/mdc_locks.c  |4 +-
 drivers/staging/lustre/lustre/mdc/mdc_request.c|   17 +++--
 drivers/staging/lustre/lustre/mgc/mgc_request.c|5 +-
 drivers/staging/lustre/lustre/obdclass/cl_page.c   |5 +-
 .../lustre/lustre/obdclass/lprocfs_status.c|6 +-
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |   13 +++--
 drivers/staging/lustre/lustre/osc/osc_cache.c  |   10 +++-
 drivers/staging/lustre/lustre/osc/osc_io.c |2 +
 drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c |5 +-
 20 files changed, 155 insertions(+), 102 deletions(-)

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 05/17] staging: lustre: llite: variable rename in namei.c

2016-04-10 Thread James Simmons 
From: Andrew Perepechko 

With the patch 6648 a fee variables were renamed. We do these
renames in broken out patch to the fix obvious.

Signed-off-by: Andrew Perepechko 
Reviewed-by: Alexander Boyko 
Reviewed-by: Vitaly Fertman 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3473
Xyratex-bug-id: MRP-1027
Reviewed-on: http://review.whamcloud.com/6648
Reviewed-by: Fan Yong 
Reviewed-by: Andreas Dilger 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/llite/namei.c |   52 +-
 1 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
b/drivers/staging/lustre/lustre/llite/namei.c
index f8f98e4..6445bc1 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -927,23 +927,23 @@ out:
  * is any lock existing. They will recycle dentries and inodes based upon locks
  * too. b=20433
  */
-static int ll_unlink(struct inode *dir, struct dentry *dentry)
+static int ll_unlink(struct inode *dir, struct dentry *dchild)
 {
struct ptlrpc_request *request = NULL;
struct md_op_data *op_data;
int rc;
 
CDEBUG(D_VFSTRACE, "VFS Op:name=%pd,dir=%lu/%u(%p)\n",
-  dentry, dir->i_ino, dir->i_generation, dir);
+  dchild, dir->i_ino, dir->i_generation, dir);
 
op_data = ll_prep_md_op_data(NULL, dir, NULL,
-dentry->d_name.name,
-dentry->d_name.len,
+dchild->d_name.name,
+dchild->d_name.len,
 0, LUSTRE_OPC_ANY, NULL);
if (IS_ERR(op_data))
return PTR_ERR(op_data);
 
-   ll_get_child_fid(dentry, &op_data->op_fid3);
+   ll_get_child_fid(dchild, &op_data->op_fid3);
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request);
ll_finish_md_op_data(op_data);
@@ -977,23 +977,23 @@ static int ll_mkdir(struct inode *dir, struct dentry 
*dentry, umode_t mode)
return err;
 }
 
-static int ll_rmdir(struct inode *dir, struct dentry *dentry)
+static int ll_rmdir(struct inode *dir, struct dentry *dchild)
 {
struct ptlrpc_request *request = NULL;
struct md_op_data *op_data;
int rc;
 
CDEBUG(D_VFSTRACE, "VFS Op:name=%pd,dir=%lu/%u(%p)\n",
-  dentry, dir->i_ino, dir->i_generation, dir);
+  dchild, dir->i_ino, dir->i_generation, dir);
 
op_data = ll_prep_md_op_data(NULL, dir, NULL,
-dentry->d_name.name,
-dentry->d_name.len,
+dchild->d_name.name,
+dchild->d_name.len,
 S_IFDIR, LUSTRE_OPC_ANY, NULL);
if (IS_ERR(op_data))
return PTR_ERR(op_data);
 
-   ll_get_child_fid(dentry, &op_data->op_fid3);
+   ll_get_child_fid(dchild, &op_data->op_fid3);
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request);
ll_finish_md_op_data(op_data);
@@ -1056,42 +1056,42 @@ out:
return err;
 }
 
-static int ll_rename(struct inode *old_dir, struct dentry *old_dentry,
-struct inode *new_dir, struct dentry *new_dentry)
+static int ll_rename(struct inode *src, struct dentry *src_dchild,
+struct inode *tgt, struct dentry *tgt_dchild)
 {
struct ptlrpc_request *request = NULL;
-   struct ll_sb_info *sbi = ll_i2sbi(old_dir);
+   struct ll_sb_info *sbi = ll_i2sbi(src);
struct md_op_data *op_data;
int err;
 
CDEBUG(D_VFSTRACE,
   "VFS 
Op:oldname=%pd,src_dir=%lu/%u(%p),newname=%pd,tgt_dir=%lu/%u(%p)\n",
-  old_dentry, old_dir->i_ino, old_dir->i_generation, old_dir,
-  new_dentry, new_dir->i_ino, new_dir->i_generation, new_dir);
+  src_dchild, src->i_ino, src->i_generation, src,
+  tgt_dchild, tgt->i_ino, tgt->i_generation, tgt);
 
-   op_data = ll_prep_md_op_data(NULL, old_dir, new_dir, NULL, 0, 0,
+   op_data = ll_prep_md_op_data(NULL, src, tgt, NULL, 0, 0,
 LUSTRE_OPC_ANY, NULL);
if (IS_ERR(op_data))
return PTR_ERR(op_data);
 
-   ll_get_child_fid(old_dentry, &op_data->op_fid3);
-   ll_get_child_fid(new_dentry, &op_data->op_fid4);
+   ll_get_child_fid(src_dchild, &op_data->op_fid3);
+   ll_get_child_fid(tgt_dchild, &op_data->op_fid4);
err = md_rename(sbi->ll_md_exp, op_data,
-   old_dentry->d_name.name,
-   old_dentry->d_name.len,
-   new_dentry->d_name.name,
-   new_dentry->d_name.len, &request);
+   src_d

[PATCH 07/17] staging: lustre: llite: error setting max_cache_mb at mount time

2016-04-10 Thread James Simmons 
From: Jinshan Xiong 

The root cause is that when max_cache_mb conf parameter is applied,
the client isn't connected to the OST yet so that sbi->ll_dt_exp is
NULL. However, it's not necessary to shrink the cache memory in this
case so success should be returned.

Signed-off-by: Jinshan Xiong 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3676
Reviewed-on: http://review.whamcloud.com/7194
Reviewed-by: Andreas Dilger 
Reviewed-by: Bobi Jam 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/llite/lproc_llite.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/lproc_llite.c 
b/drivers/staging/lustre/lustre/llite/lproc_llite.c
index 091144f..6947913 100644
--- a/drivers/staging/lustre/lustre/llite/lproc_llite.c
+++ b/drivers/staging/lustre/lustre/llite/lproc_llite.c
@@ -461,8 +461,8 @@ static ssize_t ll_max_cached_mb_seq_write(struct file *file,
break;
 
if (!sbi->ll_dt_exp) { /* being initialized */
-   rc = -ENODEV;
-   break;
+   rc = 0;
+   goto out;
}
 
/* difficult - have to ask OSCs to drop LRU slots. */
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 03/17] staging: lustre: ldlm: Fix a race during FLock handling

2016-04-10 Thread James Simmons 
From: Bruno Faccini 

Protect against race where lock could have been just destroyed
due to overlap, in ldlm_process_flock_lock().
Easy reproducer is BULL's NFS Locktests in pthread mode.
(http://nfsv4.bullopensource.org/tools/tests/locktest.php)

Signed-off-by: Bruno Faccini 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1126
Reviewed-on: http://review.whamcloud.com/7134
Reviewed-by: Oleg Drokin 
Reviewed-by: John L. Hammond 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/ldlm/ldlm_flock.c |   15 ++-
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c 
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index 3f97e1c..5102d78 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -520,11 +520,6 @@ ldlm_flock_completion_ast(struct ldlm_lock *lock, __u64 
flags, void *data)
 granted:
OBD_FAIL_TIMEOUT(OBD_FAIL_LDLM_CP_CB_WAIT, 10);
 
-   if (lock->l_flags & LDLM_FL_DESTROYED) {
-   LDLM_DEBUG(lock, "client-side enqueue waking up: destroyed");
-   return 0;
-   }
-
if (lock->l_flags & LDLM_FL_FAILED) {
LDLM_DEBUG(lock, "client-side enqueue waking up: failed");
return -EIO;
@@ -534,6 +529,16 @@ granted:
 
lock_res_and_lock(lock);
 
+   /*
+* Protect against race where lock could have been just destroyed
+* due to overlap in ldlm_process_flock_lock().
+*/
+   if (lock->l_flags & LDLM_FL_DESTROYED) {
+   unlock_res_and_lock(lock);
+   LDLM_DEBUG(lock, "client-side enqueue waking up: destroyed");
+   return 0;
+   }
+
/* ldlm_lock_enqueue() has already placed lock on the granted list. */
list_del_init(&lock->l_res_link);
 
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 01/17] staging: lustre: osc: fix race issues thanks to oap_lock

2016-04-10 Thread James Simmons 
From: Sebastien Buisson 

Fix 'data race condition' defects found by Coverity version 6.5.0:

Data race condition (MISSING_LOCK)

Accessing variable without holding lock. Elsewhere,
this variable is accessed with lock held.

This patch is dedicated to code fragments involving oap_lock.

Signed-off-by: Sebastien Buisson 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2744
Reviewed-on: http://review.whamcloud.com/6572
Reviewed-by: Oleg Drokin 
Reviewed-by: Andreas Dilger 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/osc/osc_cache.c |8 
 drivers/staging/lustre/lustre/osc/osc_io.c|2 ++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c 
b/drivers/staging/lustre/lustre/osc/osc_cache.c
index 956d57b..846be76 100644
--- a/drivers/staging/lustre/lustre/osc/osc_cache.c
+++ b/drivers/staging/lustre/lustre/osc/osc_cache.c
@@ -1147,7 +1147,9 @@ static int osc_extent_make_ready(const struct lu_env *env,
last->oap_count = osc_refresh_count(env, last, OBD_BRW_WRITE);
LASSERT(last->oap_count > 0);
LASSERT(last->oap_page_off + last->oap_count <= 
PAGE_CACHE_SIZE);
+   spin_lock(&last->oap_lock);
last->oap_async_flags |= ASYNC_COUNT_STABLE;
+   spin_unlock(&last->oap_lock);
}
 
/* for the rest of pages, we don't need to call osf_refresh_count()
@@ -1156,7 +1158,9 @@ static int osc_extent_make_ready(const struct lu_env *env,
list_for_each_entry(oap, &ext->oe_pages, oap_pending_item) {
if (!(oap->oap_async_flags & ASYNC_COUNT_STABLE)) {
oap->oap_count = PAGE_CACHE_SIZE - oap->oap_page_off;
+   spin_lock(&last->oap_lock);
oap->oap_async_flags |= ASYNC_COUNT_STABLE;
+   spin_unlock(&last->oap_lock);
}
}
 
@@ -2350,6 +2354,10 @@ int osc_queue_async_io(const struct lu_env *env, struct 
cl_io *io,
oap->oap_cmd = cmd;
oap->oap_page_off = ops->ops_from;
oap->oap_count = ops->ops_to - ops->ops_from;
+   /*
+* No need to hold a lock here,
+* since this page is not in any list yet.
+*/
oap->oap_async_flags = 0;
oap->oap_brw_flags = brw_flags;
 
diff --git a/drivers/staging/lustre/lustre/osc/osc_io.c 
b/drivers/staging/lustre/lustre/osc/osc_io.c
index cf7743d..0f50465 100644
--- a/drivers/staging/lustre/lustre/osc/osc_io.c
+++ b/drivers/staging/lustre/lustre/osc/osc_io.c
@@ -168,8 +168,10 @@ static int osc_io_submit(const struct lu_env *env,
}
 
cl_page_list_move(qout, qin, page);
+   spin_lock(&oap->oap_lock);
oap->oap_async_flags = ASYNC_URGENT|ASYNC_READY;
oap->oap_async_flags |= ASYNC_COUNT_STABLE;
+   spin_unlock(&oap->oap_lock);
 
osc_page_submit(env, opg, crt, brw_flags);
list_add_tail(&oap->oap_pending_item, &list);
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 02/17] staging: lustre: clio: incorrect assertions in 'enable-invariants'

2016-04-10 Thread James Simmons 
From: Niu Yawei 

Fixed several incorrect assumptions in 'enable-invariants'.

Signed-off-by: Niu Yawei 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3521
Reviewed-on: http://review.whamcloud.com/6832
Reviewed-by: Bobi Jam 
Reviewed-by: Jinshan Xiong 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/obdclass/cl_page.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/cl_page.c 
b/drivers/staging/lustre/lustre/obdclass/cl_page.c
index 8df39ce..03aab85 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_page.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_page.c
@@ -498,7 +498,7 @@ void cl_page_disown0(const struct lu_env *env,
 
state = pg->cp_state;
PINVRNT(env, pg, state == CPS_OWNED || state == CPS_FREEING);
-   PINVRNT(env, pg, cl_page_invariant(pg));
+   PINVRNT(env, pg, cl_page_invariant(pg) || state == CPS_FREEING);
cl_page_owner_clear(pg);
 
if (state == CPS_OWNED)
@@ -670,7 +670,8 @@ EXPORT_SYMBOL(cl_page_unassume);
 void cl_page_disown(const struct lu_env *env,
struct cl_io *io, struct cl_page *pg)
 {
-   PINVRNT(env, pg, cl_page_is_owned(pg, io));
+   PINVRNT(env, pg, cl_page_is_owned(pg, io) ||
+   pg->cp_state == CPS_FREEING);
 
io = cl_io_top(io);
cl_page_disown0(env, io, pg);
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64

2016-04-10 Thread James Simmons 
From: Jeff Mahoney 

On ppc64 with 64k pages, we get a build failure in lloop:

drivers/staging/lustre/lustre/llite/lloop.c:527:2:
note: in expansion of macro 'CLASSERT'
CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));

There's no need to change the queue's logical block size. Even if it could
accept a 64k value, that would result in any file system on top of it
needing to also use 64k blocks. It'd be safe to set it to 4k, but there's
no actual need for it. It's not used to split requests except for WRITE_SAME,
which lloop doesn't implement anyway.

Signed-off-by: Jeff Mahoney 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000
Reviewed-on: http://review.whamcloud.com/7745
Reviewed-by: Jinshan Xiong 
Reviewed-by: Minh Diep 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/llite/lloop.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/lloop.c 
b/drivers/staging/lustre/lustre/llite/lloop.c
index b725fc1..f396753 100644
--- a/drivers/staging/lustre/lustre/llite/lloop.c
+++ b/drivers/staging/lustre/lustre/llite/lloop.c
@@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct file 
*unused,
lo->lo_queue->queuedata = lo;
 
/* queue parameters */
-   CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));
-   blk_queue_logical_block_size(lo->lo_queue,
-(unsigned short)PAGE_CACHE_SIZE);
blk_queue_max_hw_sectors(lo->lo_queue,
 LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9));
blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS);
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 09/17] staging: lustre: ptlrpc: return a meaningful status from ptlrpcd_init()

2016-04-10 Thread James Simmons 
From: Swapnil Pimpale 

This patch has the following:
1) Fix for the return value from ptlrpcd_init(). It will now return a
   correct status instead of returning zero always.
2) ptlrpcd_addref() should not increment ptlrpcd_users on error.
3) Added code in a mdc_setup() and mgc_setup() to test the return
   value of ptlrpcd_addref() and return on error.

Signed-off-by: Swapnil Pimpale 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3808
Reviewed-on: http://review.whamcloud.com/7522
Reviewed-by: John L. Hammond 
Reviewed-by: Andreas Dilger 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/mdc/mdc_request.c |9 ++---
 drivers/staging/lustre/lustre/mgc/mgc_request.c |5 -
 drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c  |5 -
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c 
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index a089237..97f8669 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -2314,12 +2314,14 @@ static int mdc_setup(struct obd_device *obd, struct 
lustre_cfg *cfg)
return -ENOMEM;
mdc_init_rpc_lock(cli->cl_rpc_lock);
 
-   ptlrpcd_addref();
+   rc = ptlrpcd_addref();
+   if (rc < 0)
+   goto err_rpc_lock;
 
cli->cl_close_lock = kzalloc(sizeof(*cli->cl_close_lock), GFP_NOFS);
if (!cli->cl_close_lock) {
rc = -ENOMEM;
-   goto err_rpc_lock;
+   goto err_ptlrpcd_decref;
}
mdc_init_rpc_lock(cli->cl_close_lock);
 
@@ -2345,9 +2347,10 @@ static int mdc_setup(struct obd_device *obd, struct 
lustre_cfg *cfg)
 
 err_close_lock:
kfree(cli->cl_close_lock);
+err_ptlrpcd_decref:
+   ptlrpcd_decref();
 err_rpc_lock:
kfree(cli->cl_rpc_lock);
-   ptlrpcd_decref();
return rc;
 }
 
diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c 
b/drivers/staging/lustre/lustre/mgc/mgc_request.c
index b7dc872..3f5f884 100644
--- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
+++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
@@ -734,7 +734,9 @@ static int mgc_setup(struct obd_device *obd, struct 
lustre_cfg *lcfg)
struct task_struct *task;
int rc;
 
-   ptlrpcd_addref();
+   rc = ptlrpcd_addref();
+   if (rc < 0)
+   goto err_noref;
 
rc = client_obd_setup(obd, lcfg);
if (rc)
@@ -773,6 +775,7 @@ err_cleanup:
client_obd_cleanup(obd);
 err_decref:
ptlrpcd_decref();
+err_noref:
return rc;
 }
 
diff --git a/drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c 
b/drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c
index dbc3376..76a355a 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c
@@ -909,8 +909,11 @@ int ptlrpcd_addref(void)
int rc = 0;
 
mutex_lock(&ptlrpcd_mutex);
-   if (++ptlrpcd_users == 1)
+   if (++ptlrpcd_users == 1) {
rc = ptlrpcd_init();
+   if (rc < 0)
+   ptlrpcd_users--;
+   }
mutex_unlock(&ptlrpcd_mutex);
return rc;
 }
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 17/17] staging: lustre: hsm: don't use real suppgid

2016-04-10 Thread James Simmons 
From: John L. Hammond 

In the MDC HSM handlers that do not pack a real suppgid, use -1 rather
than 0 for the suppgid in mdt_body.

Signed-off-by: John L. Hammond 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3866
Reviewed-on: http://review.whamcloud.com/7565
Reviewed-by: Aurelien Degremont 
Reviewed-by: Faccini Bruno 
Reviewed-by: Jinshan Xiong 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/mdc/mdc_request.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c 
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index 97f8669..513290f 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -1169,7 +1169,7 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp,
goto out;
}
 
-   mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0);
+   mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, -1, 0);
 
/* Copy hsm_progress struct */
req_hpk = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_PROGRESS);
@@ -1203,7 +1203,7 @@ static int mdc_ioc_hsm_ct_register(struct obd_import 
*imp, __u32 archives)
goto out;
}
 
-   mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0);
+   mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, -1, 0);
 
/* Copy hsm_progress struct */
archive_mask = req_capsule_client_get(&req->rq_pill,
@@ -1278,7 +1278,7 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import 
*imp)
goto out;
}
 
-   mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0);
+   mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, -1, 0);
 
ptlrpc_request_set_replen(req);
 
@@ -1395,7 +1395,7 @@ static int mdc_ioc_hsm_request(struct obd_export *exp,
return rc;
}
 
-   mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0);
+   mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, -1, 0);
 
/* Copy hsm_request struct */
req_hr = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_REQUEST);
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 06/17] staging: lustre: llite: speedup in unlink/rmdir

2016-04-10 Thread James Simmons 
From: Andrew Perepechko 

Assume dchild argument is fully initialized in ->unlink and
->rmdir callbacks, so additional lookup for ELC is not needed.

Signed-off-by: Andrew Perepechko 
Reviewed-by: Alexander Boyko 
Reviewed-by: Vitaly Fertman 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3473
Xyratex-bug-id: MRP-1027
Reviewed-on: http://review.whamcloud.com/6648
Reviewed-by: Fan Yong 
Reviewed-by: Andreas Dilger 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/llite/namei.c |   21 +++--
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
b/drivers/staging/lustre/lustre/llite/namei.c
index 6445bc1..7e4247a 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -845,12 +845,6 @@ static int ll_create_nd(struct inode *dir, struct dentry 
*dentry,
return rc;
 }
 
-static inline void ll_get_child_fid(struct dentry *child, struct lu_fid *fid)
-{
-   if (d_really_is_positive(child))
-   *fid = *ll_inode2fid(d_inode(child));
-}
-
 int ll_objects_destroy(struct ptlrpc_request *request, struct inode *dir)
 {
struct mdt_body *body;
@@ -943,7 +937,9 @@ static int ll_unlink(struct inode *dir, struct dentry 
*dchild)
if (IS_ERR(op_data))
return PTR_ERR(op_data);
 
-   ll_get_child_fid(dchild, &op_data->op_fid3);
+   if (dchild && dchild->d_inode)
+   op_data->op_fid3 = *ll_inode2fid(dchild->d_inode);
+
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request);
ll_finish_md_op_data(op_data);
@@ -993,7 +989,9 @@ static int ll_rmdir(struct inode *dir, struct dentry 
*dchild)
if (IS_ERR(op_data))
return PTR_ERR(op_data);
 
-   ll_get_child_fid(dchild, &op_data->op_fid3);
+   if (dchild && dchild->d_inode)
+   op_data->op_fid3 = *ll_inode2fid(dchild->d_inode);
+
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request);
ll_finish_md_op_data(op_data);
@@ -1074,8 +1072,11 @@ static int ll_rename(struct inode *src, struct dentry 
*src_dchild,
if (IS_ERR(op_data))
return PTR_ERR(op_data);
 
-   ll_get_child_fid(src_dchild, &op_data->op_fid3);
-   ll_get_child_fid(tgt_dchild, &op_data->op_fid4);
+   if (src_dchild && src_dchild->d_inode)
+   op_data->op_fid3 = *ll_inode2fid(src_dchild->d_inode);
+   if (tgt_dchild && tgt_dchild->d_inode)
+   op_data->op_fid4 = *ll_inode2fid(tgt_dchild->d_inode);
+
err = md_rename(sbi->ll_md_exp, op_data,
src_dchild->d_name.name,
src_dchild->d_name.len,
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 16/17] staging: lustre: hsm: permission checks for HSM ioctl operations

2016-04-10 Thread James Simmons 
From: John L. Hammond 

In the LL_IOC_HSM_CT_START case of ll_dir_ioctl() require
CAP_SYS_ADMIN, since the local handler for this ioctl may modify the
global KUC table.

Signed-off-by: John L. Hammond 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3866
Reviewed-on: http://review.whamcloud.com/7565
Reviewed-by: Aurelien Degremont 
Reviewed-by: Faccini Bruno 
Reviewed-by: Jinshan Xiong 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/llite/dir.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/dir.c 
b/drivers/staging/lustre/lustre/llite/dir.c
index 45bdf8f..94f3800 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -1844,6 +1844,9 @@ out_quotactl:
return rc;
}
case LL_IOC_HSM_CT_START:
+   if (!capable(CFS_CAP_SYS_ADMIN))
+   return -EPERM;
+
rc = copy_and_ioctl(cmd, sbi->ll_md_exp, (void __user *)arg,
sizeof(struct lustre_kernelcomm));
return rc;
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 11/17] staging: lustre: osc: osc_extent_wait() shouldn't be interruptible

2016-04-10 Thread James Simmons 
From: Jinshan Xiong 

Otherwise it will hit the assertion at cl_lock.c:

 cl_lock.c:1967:discard_cb())
  ASSERTION( (!(page->cp_type == CPT_CACHEABLE) ||
  (!PageWriteback(cl_page_vmpage(env, page ) failed:

This is because in osc_lock_flush() we have to make sure the IO
is finished before discarding the pages.

Signed-off-by: Jinshan Xiong 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2779
Reviewed-on: http://review.whamcloud.com/5419
Reviewed-by: Bobi Jam 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/osc/osc_cache.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c 
b/drivers/staging/lustre/lustre/osc/osc_cache.c
index 846be76..a341160 100644
--- a/drivers/staging/lustre/lustre/osc/osc_cache.c
+++ b/drivers/staging/lustre/lustre/osc/osc_cache.c
@@ -965,7 +965,7 @@ static int osc_extent_wait(const struct lu_env *env, struct 
osc_extent *ext,
"%s: wait ext to %d timedout, recovery in progress?\n",
osc_export(obj)->exp_obd->obd_name, state);
 
-   lwi = LWI_INTR(LWI_ON_SIGNAL_NOOP, NULL);
+   lwi = LWI_INTR(NULL, NULL);
rc = l_wait_event(ext->oe_waitq, extent_wait_cb(ext, state),
  &lwi);
}
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 04/17] staging: lustre: ldlm: refine LU-2665 patch for POSIX compliance

2016-04-10 Thread James Simmons 
From: Bruno Faccini 

Follow-on to patch introduced to fix LU-2665 ticket (Gerrit
Change at http://review.whamcloud.com/6415 with Change-Id:
I8faa331712abeadee46eabe111ee1c23a05840d5).
Original patch introduced regressions against POSIX test suite
(fcntl.18/fcntl.35 tests in LSB-VSX POSIX test suite at
http://www.opengroup.org/testing/linux-test/lsb-vsx.html),
so the idea is to only resend F_UNLCKs to have both LU-2665 bug
and POSIX test suite happy.

Signed-off-by: Bruno Faccini 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3701
Reviewed-on: http://review.whamcloud.com/7453
Reviewed-by: Bobi Jam 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/mdc/mdc_locks.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/lustre/lustre/mdc/mdc_locks.c 
b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
index 958a164..01b6d77 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
@@ -869,7 +869,9 @@ resend:
 * (explicits or automatically generated by Kernel to clean
 * current FLocks upon exit) that can't be trashed
 */
-   if ((rc == -EINTR) || (rc == -ETIMEDOUT))
+   if (((rc == -EINTR) || (rc == -ETIMEDOUT)) &&
+   (einfo->ei_type == LDLM_FLOCK) &&
+   (einfo->ei_mode == LCK_NL))
goto resend;
return rc;
}
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 10/17] staging: lustre: llite: Truncate to restore file

2016-04-10 Thread James Simmons 
From: Jinshan Xiong 

Truncate up is safe so it won't trigger restore.

Copy optimization for truncate down - only copy the part under
truncate length. If a file is truncated to zero usually it'll be
followed by write so I choose to restore the file and set correct
stripe information.

Signed-off-by: Jinshan Xiong 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3817
Reviewed-on: http://review.whamcloud.com/7505
Reviewed-by: jacques-Charles Lafoucriere 
Reviewed-by: Henri Doreau 
Reviewed-by: Aurelien Degremont 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/llite/file.c |5 +-
 .../staging/lustre/lustre/llite/llite_internal.h   |2 +-
 drivers/staging/lustre/lustre/llite/llite_lib.c|   60 +--
 drivers/staging/lustre/lustre/llite/vvp_io.c   |5 +-
 4 files changed, 35 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/file.c 
b/drivers/staging/lustre/lustre/llite/file.c
index 9b553d2..24fa24b 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -3621,7 +3621,7 @@ again:
 /**
  *  This function send a restore request to the MDT
  */
-int ll_layout_restore(struct inode *inode)
+int ll_layout_restore(struct inode *inode, loff_t offset, __u64 length)
 {
struct hsm_user_request *hur;
int  len, rc;
@@ -3637,7 +3637,8 @@ int ll_layout_restore(struct inode *inode)
hur->hur_request.hr_flags = 0;
memcpy(&hur->hur_user_item[0].hui_fid, &ll_i2info(inode)->lli_fid,
   sizeof(hur->hur_user_item[0].hui_fid));
-   hur->hur_user_item[0].hui_extent.length = -1;
+   hur->hur_user_item[0].hui_extent.offset = offset;
+   hur->hur_user_item[0].hui_extent.length = length;
hur->hur_request.hr_itemcount = 1;
rc = obd_iocontrol(LL_IOC_HSM_REQUEST, ll_i2sbi(inode)->ll_md_exp,
   len, hur, NULL);
diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h 
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index d67c8c0..bb582f1 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -1377,7 +1377,7 @@ enum {
 
 int ll_layout_conf(struct inode *inode, const struct cl_object_conf *conf);
 int ll_layout_refresh(struct inode *inode, __u32 *gen);
-int ll_layout_restore(struct inode *inode);
+int ll_layout_restore(struct inode *inode, loff_t start, __u64 length);
 
 int ll_xattr_init(void);
 void ll_xattr_fini(void);
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c 
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index 9571742..49bfbbd 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -1266,14 +1266,6 @@ int ll_setattr_raw(struct dentry *dentry, struct iattr 
*attr, bool hsm_import)
   LTIME_S(attr->ia_mtime), LTIME_S(attr->ia_ctime),
   (s64)ktime_get_real_seconds());
 
-   /* If we are changing file size, file content is modified, flag it. */
-   if (attr->ia_valid & ATTR_SIZE) {
-   attr->ia_valid |= MDS_OPEN_OWNEROVERRIDE;
-   spin_lock(&lli->lli_lock);
-   lli->lli_flags |= LLIF_DATA_MODIFIED;
-   spin_unlock(&lli->lli_lock);
-   }
-
/* We always do an MDS RPC, even if we're only changing the size;
 * only the MDS knows whether truncate() should fail with -ETXTBUSY
 */
@@ -1285,13 +1277,6 @@ int ll_setattr_raw(struct dentry *dentry, struct iattr 
*attr, bool hsm_import)
if (!S_ISDIR(inode->i_mode))
inode_unlock(inode);
 
-   memcpy(&op_data->op_attr, attr, sizeof(*attr));
-
-   /* Open epoch for truncate. */
-   if (exp_connect_som(ll_i2mdexp(inode)) &&
-   (attr->ia_valid & (ATTR_SIZE | ATTR_MTIME | ATTR_MTIME_SET)))
-   op_data->op_flags = MF_EPOCH_OPEN;
-
/* truncate on a released file must failed with -ENODATA,
 * so size must not be set on MDS for released file
 * but other attributes must be set
@@ -1305,29 +1290,40 @@ int ll_setattr_raw(struct dentry *dentry, struct iattr 
*attr, bool hsm_import)
if (lsm && lsm->lsm_pattern & LOV_PATTERN_F_RELEASED)
file_is_released = true;
ccc_inode_lsm_put(inode, lsm);
+
+   if (!hsm_import && attr->ia_valid & ATTR_SIZE) {
+   if (file_is_released) {
+   rc = ll_layout_restore(inode, 0, attr->ia_size);
+   if (rc < 0)
+   goto out;
+
+   file_is_released = false;
+   ll_layout_refresh(inode, &gen);
+   }
+
+   /*
+* If we are changing file size, file c

[PATCH 15/17] staging: lustre: lov: Don't wait for active target with OBD_STATFS_NODELAY

2016-04-10 Thread James Simmons 
From: Andriy Skulysh 

Patch for LU-631 which was landed before the upstream merge broke
OBD_STATFS_NODELAY behaviour. It adds unnecessary delay while
running df command with inactive OSTs. We shouldn't try to recover
connection to OST in this case.

Signed-off-by: Andriy Skulysh 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4010
Reviewed-on: http://review.whamcloud.com/7762
Reviewed-by: Andreas Dilger 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/lov/lov_request.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lov/lov_request.c 
b/drivers/staging/lustre/lustre/lov/lov_request.c
index 7178a02..475ca2f 100644
--- a/drivers/staging/lustre/lustre/lov/lov_request.c
+++ b/drivers/staging/lustre/lustre/lov/lov_request.c
@@ -716,12 +716,15 @@ int lov_prep_statfs_set(struct obd_device *obd, struct 
obd_info *oinfo,
struct lov_request *req;
 
if (!lov->lov_tgts[i] ||
-   (!lov_check_and_wait_active(lov, i) &&
-(oinfo->oi_flags & OBD_STATFS_NODELAY))) {
+   (oinfo->oi_flags & OBD_STATFS_NODELAY &&
+!lov->lov_tgts[i]->ltd_active)) {
CDEBUG(D_HA, "lov idx %d inactive\n", i);
continue;
}
 
+   if (!lov->lov_tgts[i]->ltd_active)
+   lov_check_and_wait_active(lov, i);
+
/* skip targets that have been explicitly disabled by the
 * administrator
 */
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 08/17] staging: lustre: obd: MDT mount fails on MDS w/o MGS on it

2016-04-10 Thread James Simmons 
From: Bobi Jam 

If we specify multiple --mgsnode for a MDT, when we start MDS upon
it while MGS is no the other node, the MGC import connection will
always select the local nid (which is one of the candidate mgsnode)
since it think its the closest connection.

This patch treats further --mgsnode nids as failover nids, so that
multiple import connections are added for the MGC import.

Signed-off-by: Bobi Jam 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3829
Reviewed-on: http://review.whamcloud.com/7509
Reviewed-by: Liang Zhen 
Reviewed-by: Lai Siyao 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |   13 -
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/obd_mount.c 
b/drivers/staging/lustre/lustre/obdclass/obd_mount.c
index d3e28a3..9474aa9 100644
--- a/drivers/staging/lustre/lustre/obdclass/obd_mount.c
+++ b/drivers/staging/lustre/lustre/obdclass/obd_mount.c
@@ -307,7 +307,8 @@ int lustre_start_mgc(struct super_block *sb)
while (class_parse_nid(ptr, &nid, &ptr) == 0) {
rc = do_lcfg(mgcname, nid,
 LCFG_ADD_UUID, niduuid, NULL, NULL, NULL);
-   i++;
+   if (!rc)
+   i++;
/* Stop at the first failover nid */
if (*ptr == ':')
break;
@@ -345,16 +346,18 @@ int lustre_start_mgc(struct super_block *sb)
sprintf(niduuid, "%s_%x", mgcname, i);
j = 0;
while (class_parse_nid_quiet(ptr, &nid, &ptr) == 0) {
-   j++;
-   rc = do_lcfg(mgcname, nid,
-LCFG_ADD_UUID, niduuid, NULL, NULL, NULL);
+   rc = do_lcfg(mgcname, nid, LCFG_ADD_UUID, niduuid,
+NULL, NULL, NULL);
+   if (!rc)
+   ++j;
if (*ptr == ':')
break;
}
if (j > 0) {
rc = do_lcfg(mgcname, 0, LCFG_ADD_CONN,
 niduuid, NULL, NULL, NULL);
-   i++;
+   if (!rc)
+   i++;
} else {
/* at ":/fsname" */
break;
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 14/17] staging: lustre: lov: return minimal FIEMAP for released files

2016-04-10 Thread James Simmons 
From: Bruno Faccini 

Since st_blocks = NULL is returned for released files, FIEMAP
should at least return a minimal mapping to make users aware
that file contains data but it is not immediately available.
This will make coreutils and tools such tar happy and have
them presume file is sparse.

Also, add a new test_228 in sanity-hsm to verify it works
for "[cp,tar] --sparse" commands.

Also fix a LBUG ("lov_fiemap()) ASSERTION( fm_local ) failed")
likely to occur when no-object/ENOMEM conditions and also now
when released.

Signed-off-by: Bruno Faccini 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3864
Reviewed-on: http://review.whamcloud.com/7584
Reviewed-by: Andreas Dilger 
Reviewed-by: Aurelien Degremont 
Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/lov/lov_obd.c |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c 
b/drivers/staging/lustre/lustre/lov/lov_obd.c
index 1a9e3e8..9b72671 100644
--- a/drivers/staging/lustre/lustre/lov/lov_obd.c
+++ b/drivers/staging/lustre/lustre/lov/lov_obd.c
@@ -1733,6 +1733,27 @@ static int lov_fiemap(struct lov_obd *lov, __u32 keylen, 
void *key,
unsigned int buffer_size = FIEMAP_BUFFER_SIZE;
 
if (!lsm_has_objects(lsm)) {
+   if (lsm && lsm_is_released(lsm) && (fm_key->fiemap.fm_start <
+   fm_key->oa.o_size)) {
+   /*
+* released file, return a minimal FIEMAP if
+* request fits in file-size.
+*/
+   fiemap->fm_mapped_extents = 1;
+   fiemap->fm_extents[0].fe_logical =
+   fm_key->fiemap.fm_start;
+   if (fm_key->fiemap.fm_start + fm_key->fiemap.fm_length <
+   fm_key->oa.o_size) {
+   fiemap->fm_extents[0].fe_length =
+   fm_key->fiemap.fm_length;
+   } else {
+   fiemap->fm_extents[0].fe_length =
+   fm_key->oa.o_size - 
fm_key->fiemap.fm_start;
+   fiemap->fm_extents[0].fe_flags |=
+   (FIEMAP_EXTENT_UNKNOWN |
+FIEMAP_EXTENT_LAST);
+   }
+   }
rc = 0;
goto out;
}
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 12/17] staging: lustre: lprocfs: implement log2 using bitops

2016-04-10 Thread James Simmons 
From: Andrew Perepechko 

This patch implements log2 using fls.

Signed-off-by: Andrew Perepechko 
Reviewed-by: Alexander Boyko 
Reviewed-by: alexander_zarochent...@xyratex.com
Reviewed-by: Vitaly Fertman 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3496
Xyratex-bug-id: MRP-999
Reviewed-on: http://review.whamcloud.com/6757
Reviewed-by: John L. Hammond 
Reviewed-by: Bob Glossman 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 .../lustre/lustre/obdclass/lprocfs_status.c|6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c 
b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
index d93f42f..172fc91 100644
--- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
+++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
@@ -1471,10 +1471,10 @@ EXPORT_SYMBOL(lprocfs_oh_tally);
 
 void lprocfs_oh_tally_log2(struct obd_histogram *oh, unsigned int value)
 {
-   unsigned int val;
+   unsigned int val = 0;
 
-   for (val = 0; ((1 << val) < value) && (val <= OBD_HIST_MAX); val++)
-   ;
+   if (likely(value != 0))
+   val = min(fls(value - 1), OBD_HIST_MAX);
 
lprocfs_oh_tally(oh, val);
 }
-- 
1.7.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64

2016-04-10 Thread Jeff Mahoney 
This patch was shown not to work. I just haven't removed it from opensuse yet.

-Jeff

--
Jeff Mahoney
(apologies for the top post -- from my mobile)

> On Apr 10, 2016, at 9:13 AM, James Simmons  wrote:
> 
> From: Jeff Mahoney 
> 
> On ppc64 with 64k pages, we get a build failure in lloop:
> 
> drivers/staging/lustre/lustre/llite/lloop.c:527:2:
> note: in expansion of macro 'CLASSERT'
> CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));
> 
> There's no need to change the queue's logical block size. Even if it could
> accept a 64k value, that would result in any file system on top of it
> needing to also use 64k blocks. It'd be safe to set it to 4k, but there's
> no actual need for it. It's not used to split requests except for WRITE_SAME,
> which lloop doesn't implement anyway.
> 
> Signed-off-by: Jeff Mahoney 
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000
> Reviewed-on: http://review.whamcloud.com/7745
> Reviewed-by: Jinshan Xiong 
> Reviewed-by: Minh Diep 
> Reviewed-by: Oleg Drokin 
> Signed-off-by: James Simmons 
> ---
> drivers/staging/lustre/lustre/llite/lloop.c |3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/llite/lloop.c 
> b/drivers/staging/lustre/lustre/llite/lloop.c
> index b725fc1..f396753 100644
> --- a/drivers/staging/lustre/lustre/llite/lloop.c
> +++ b/drivers/staging/lustre/lustre/llite/lloop.c
> @@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct 
> file *unused,
>lo->lo_queue->queuedata = lo;
> 
>/* queue parameters */
> -CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));
> -blk_queue_logical_block_size(lo->lo_queue,
> - (unsigned short)PAGE_CACHE_SIZE);
>blk_queue_max_hw_sectors(lo->lo_queue,
> LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9));
>blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS);
> -- 
> 1.7.1
> 
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()

2016-04-10 Thread Jonathan Cameron 
On 06/04/16 22:06, Lars-Peter Clausen wrote:
> On 04/06/2016 06:11 AM, Alison Schofield wrote:
>> Replace the code that guarantees the device stays in direct mode with
>> iio_device_{claim|release}_direct_mode() which does same.
>>
>> Signed-off-by: Alison Schofield 
> 
> Looks good, thanks.
> 
> Acked-by: Lars-Peter Clausen 
> 
Applied to the togreg branch of iio.git - thanks.

Jonathan
>> ---
>> Changed in v2:
>>  - removed improper application of claim/release from intr handler
>>  - updated changelog
>>
>>  drivers/staging/iio/adc/ad7606_core.c | 12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/iio/adc/ad7606_core.c 
>> b/drivers/staging/iio/adc/ad7606_core.c
>> index 6dbc811..f79ee61 100644
>> --- a/drivers/staging/iio/adc/ad7606_core.c
>> +++ b/drivers/staging/iio/adc/ad7606_core.c
>> @@ -88,12 +88,12 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
>>  
>>  switch (m) {
>>  case IIO_CHAN_INFO_RAW:
>> -mutex_lock(&indio_dev->mlock);
>> -if (iio_buffer_enabled(indio_dev))
>> -ret = -EBUSY;
>> -else
>> -ret = ad7606_scan_direct(indio_dev, chan->address);
>> -mutex_unlock(&indio_dev->mlock);
>> +ret = iio_device_claim_direct_mode(indio_dev);
>> +if (ret)
>> +return ret;
>> +
>> +ret = ad7606_scan_direct(indio_dev, chan->address);
>> +iio_device_release_direct_mode(indio_dev);
>>  
>>  if (ret < 0)
>>  return ret;
>>
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()

2016-04-10 Thread Jonathan Cameron 
On 06/04/16 19:06, Lars-Peter Clausen wrote:
> On 04/03/2016 11:09 AM, Jonathan Cameron wrote:
>> On 01/04/16 17:53, Alison Schofield wrote:
>>> Two instances are moved to the new claim/release API:
>>>
>>> In the first instance, the driver was using mlock followed by
>>> iio_buffer_enabled(). Replace that code with the new API to guarantee
>>> the device stays in direct mode. There is no change in driver behavior.
>>>
>>> In the second instance, the driver was not using mlock to hold the
>>> device in direct mode, but should have been.  Here we introduce the
>>> new API to guarantee direct mode. This is a change in driver behavior.
>>>
>>> Signed-off-by: Alison Schofield 
>>> ---
>>>  drivers/staging/iio/adc/ad7606_core.c | 15 ---
>>>  1 file changed, 8 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/staging/iio/adc/ad7606_core.c
> b/drivers/staging/iio/adc/ad7606_core.c
>>> index 6dbc811..f914b8d 100644
>>> --- a/drivers/staging/iio/adc/ad7606_core.c
>>> +++ b/drivers/staging/iio/adc/ad7606_core.c
>>> @@ -88,12 +88,12 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
>>>
>>> switch (m) {
>>> case IIO_CHAN_INFO_RAW:
>>> -   mutex_lock(&indio_dev->mlock);
>>> -   if (iio_buffer_enabled(indio_dev))
>>> -   ret = -EBUSY;
>>> -   else
>>> -   ret = ad7606_scan_direct(indio_dev, chan->address);
>>> -   mutex_unlock(&indio_dev->mlock);
>>> +   ret = iio_device_claim_direct_mode(indio_dev);
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> +   ret = ad7606_scan_direct(indio_dev, chan->address);
>>> +   iio_device_release_direct_mode(indio_dev);
>>>
>>> if (ret < 0)
>>> return ret;
>>> @@ -411,8 +411,9 @@ static irqreturn_t ad7606_interrupt(int irq, void
> *dev_id)
>>> struct iio_dev *indio_dev = dev_id;
>>> struct ad7606_state *st = iio_priv(indio_dev);
>>>
>>> -   if (iio_buffer_enabled(indio_dev)) {
>>> +   if (!iio_device_claim_direct_mode(indio_dev))  {
>>> schedule_work(&st->poll_work);
>>> +   iio_device_release_direct_mode(indio_dev);
>> Unfortunately this won't work.  That interrupt is still in traditional non
>> threaded form.  This will take a mutex in a top half interrupt handler
>> where a sleep cannot occur.
>>
>> I'm just wondering how expensive it would be to fix this by moving that over
>> to a threaded handler.  In the poll_work case (buffer) it would be cleaner
> to do
>> so. I'm really confused what the intended interrupt handler
>> is in here.  I 'think' the sequence is:
>>
>> Trigger fires the convst pin whether in top half or the bottom half of
>> a threaded interrupt, but not both - I guess this works, if it is rather
>> 'unusual'.
>>
>> We then get a interrupt to indicate that it has finished conversion and that
>> filters through to actually fill the buffer via a traditional top half /
>> bottom half interrupt handler.
>>
>> So if we were to convert that to a threaded interrupt (with no top half / non
>> threaded part), we could drop the schedule_work and just call
>> ad7606_poll_bh_to_ring from the thread handler.
>>
>> In the direct read case I doubt we care about the delay in dropping to a
>> thread prior to signalling the data is ready.
>>
>> Can't think why this driver is still in staging :)
> 
> Yeah, we should leave this driver out from the conversion for now. The whole
> convst pin handling need a major rework. It shouldn't really be in the
> driver and usually you wouldn't want to use to use a GPIO and software timer
> since that gives you way to much jitter for good results. You'd probably use
> something like a PWM.
Agreed, you would normally move this into hardware, but we'd still need to allow
for the possibility of it being software triggered - even if ugly.

Anyhow, lets park this for now.

J
> 
>>
>> Lars, any interest from Analog in getting this one cleaned up?  Also
>> do you have any test hardware, if we mess around with this interrupt 
>> handling?
> 
> I have the hardware somewhere in some storage bay, but just converting this
> over to threaded interrupt handling is not really a solution. So, if you
> want to get rid of the iio_buffer_enabled() in the interrupt handler a
> simple solution is to register preenable and postdisable callbacks where you
> set a flag in the driver struct to indicate that it is in buffered mode or 
> not.
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64

2016-04-10 Thread James Simmons 

> This patch was shown not to work. I just haven't removed it from opensuse yet.

Its been running in our production tree as well for some time. Guess that 
change is a noop. In any case we have been discussing redoing the lloop 
driver anyways. Just need to find the cycles.

> --
> Jeff Mahoney
> (apologies for the top post -- from my mobile)
> 
> > On Apr 10, 2016, at 9:13 AM, James Simmons  wrote:
> > 
> > From: Jeff Mahoney 
> > 
> > On ppc64 with 64k pages, we get a build failure in lloop:
> > 
> > drivers/staging/lustre/lustre/llite/lloop.c:527:2:
> > note: in expansion of macro 'CLASSERT'
> > CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));
> > 
> > There's no need to change the queue's logical block size. Even if it could
> > accept a 64k value, that would result in any file system on top of it
> > needing to also use 64k blocks. It'd be safe to set it to 4k, but there's
> > no actual need for it. It's not used to split requests except for 
> > WRITE_SAME,
> > which lloop doesn't implement anyway.
> > 
> > Signed-off-by: Jeff Mahoney 
> > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000
> > Reviewed-on: http://review.whamcloud.com/7745
> > Reviewed-by: Jinshan Xiong 
> > Reviewed-by: Minh Diep 
> > Reviewed-by: Oleg Drokin 
> > Signed-off-by: James Simmons 
> > ---
> > drivers/staging/lustre/lustre/llite/lloop.c |3 ---
> > 1 files changed, 0 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/staging/lustre/lustre/llite/lloop.c 
> > b/drivers/staging/lustre/lustre/llite/lloop.c
> > index b725fc1..f396753 100644
> > --- a/drivers/staging/lustre/lustre/llite/lloop.c
> > +++ b/drivers/staging/lustre/lustre/llite/lloop.c
> > @@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct 
> > file *unused,
> >lo->lo_queue->queuedata = lo;
> > 
> >/* queue parameters */
> > -CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));
> > -blk_queue_logical_block_size(lo->lo_queue,
> > - (unsigned short)PAGE_CACHE_SIZE);
> >blk_queue_max_hw_sectors(lo->lo_queue,
> > LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9));
> >blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS);
> > -- 
> > 1.7.1
> > 
> > 
> 
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 08/27] staging: lustre: avoid to use bio->bi_vcnt directly

2016-04-10 Thread James Simmons 

> The lloop driver should be removed entirely - use the loop driver
> instead.

I talked with Andreas last week at our annual Lustre users group meeting 
about this. The reason I was told for existance is that some users were
using files on a Lustre file system with the loop back device. The 
performance was really bad at the time so a lloop was developed to 
overcome those limitations. Its been a long time so perhaps its time
to look at the default loop driver again to see if can perform now. If
it doesn't we will go the route of reworking the lloop driver in the
spirit of the cryptoloop device.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 08/27] staging: lustre: avoid to use bio->bi_vcnt directly

2016-04-10 Thread Christoph Hellwig 
On Sun, Apr 10, 2016 at 03:37:42PM +0100, James Simmons wrote:
> 
> > The lloop driver should be removed entirely - use the loop driver
> > instead.
> 
> I talked with Andreas last week at our annual Lustre users group meeting 
> about this. The reason I was told for existance is that some users were
> using files on a Lustre file system with the loop back device. The 
> performance was really bad at the time so a lloop was developed to 
> overcome those limitations. Its been a long time so perhaps its time
> to look at the default loop driver again to see if can perform now. If
> it doesn't we will go the route of reworking the lloop driver in the
> spirit of the cryptoloop device.

The loop driver now supports using AIO/DIO on any file systems that
implements ->read_iter and ->write_iter. If lustre doesn't support
those or doesn't have proper performance using them it should be
addressed in the file system.

Note that the dio mode in the loop device is not the default and you
need to manually enabled it, keep that in mind when testing.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [lustre-devel] [PATCH] staging: lustre: split error handling code into multiple labels

2016-04-10 Thread James Simmons 

> Instead of using a switch-case statement to find out what kind of error
> has just happened, split error handling logic into multiple labels and
> jump right into the appropriate label to do the error handling. This way
> it is easier to follow different code paths. It also looks easy on the
> eyes.
> 
> Additionally silences the following coccinelle warning:
> 
> drivers/staging/lustre/lustre/obdecho/echo_client.c:762:22-27: ERROR: ed
> is NULL but dereferenced.
> 
> Signed-off-by: Cihangir Akturk 

Acked-by: James Simmons 

I also tested it and saw no regressions.

> ---
>  .../staging/lustre/lustre/obdecho/echo_client.c| 54 
> --
>  1 file changed, 20 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/obdecho/echo_client.c 
> b/drivers/staging/lustre/lustre/obdecho/echo_client.c
> index a752bb4..f143f7a 100644
> --- a/drivers/staging/lustre/lustre/obdecho/echo_client.c
> +++ b/drivers/staging/lustre/lustre/obdecho/echo_client.c
> @@ -668,8 +668,7 @@ static struct lu_device *echo_device_alloc(const struct 
> lu_env *env,
>   struct obd_device  *obd = NULL; /* to keep compiler happy */
>   struct obd_device  *tgt;
>   const char *tgt_type_name;
> - int rc;
> - int cleanup = 0;
> + int rc, err;
>  
>   ed = kzalloc(sizeof(*ed), GFP_NOFS);
>   if (!ed) {
> @@ -677,16 +676,14 @@ static struct lu_device *echo_device_alloc(const struct 
> lu_env *env,
>   goto out;
>   }
>  
> - cleanup = 1;
>   cd = &ed->ed_cl;
>   rc = cl_device_init(cd, t);
>   if (rc)
> - goto out;
> + goto out_free;
>  
>   cd->cd_lu_dev.ld_ops = &echo_device_lu_ops;
>   cd->cd_ops = &echo_device_cl_ops;
>  
> - cleanup = 2;
>   obd = class_name2obd(lustre_cfg_string(cfg, 0));
>   LASSERT(obd);
>   LASSERT(env);
> @@ -696,28 +693,25 @@ static struct lu_device *echo_device_alloc(const struct 
> lu_env *env,
>   CERROR("Can not find tgt device %s\n",
>  lustre_cfg_string(cfg, 1));
>   rc = -ENODEV;
> - goto out;
> + goto out_device_fini;
>   }
>  
>   next = tgt->obd_lu_dev;
>   if (!strcmp(tgt->obd_type->typ_name, LUSTRE_MDT_NAME)) {
>   CERROR("echo MDT client must be run on server\n");
>   rc = -EOPNOTSUPP;
> - goto out;
> + goto out_device_fini;
>   }
>  
>   rc = echo_site_init(env, ed);
>   if (rc)
> - goto out;
> -
> - cleanup = 3;
> + goto out_device_fini;
>  
>   rc = echo_client_setup(env, obd, cfg);
>   if (rc)
> - goto out;
> + goto out_site_fini;
>  
>   ed->ed_ec = &obd->u.echo_client;
> - cleanup = 4;
>  
>   /* if echo client is to be stacked upon ost device, the next is
>* NULL since ost is not a clio device so far
> @@ -729,7 +723,7 @@ static struct lu_device *echo_device_alloc(const struct 
> lu_env *env,
>   if (next) {
>   if (next->ld_site) {
>   rc = -EBUSY;
> - goto out;
> + goto out_cleanup;
>   }
>  
>   next->ld_site = &ed->ed_site->cs_lu;
> @@ -737,7 +731,7 @@ static struct lu_device *echo_device_alloc(const struct 
> lu_env *env,
>   next->ld_type->ldt_name,
> NULL);
>   if (rc)
> - goto out;
> + goto out_cleanup;
>  
>   } else {
>   LASSERT(strcmp(tgt_type_name, LUSTRE_OST_NAME) == 0);
> @@ -745,27 +739,19 @@ static struct lu_device *echo_device_alloc(const struct 
> lu_env *env,
>  
>   ed->ed_next = next;
>   return &cd->cd_lu_dev;
> -out:
> - switch (cleanup) {
> - case 4: {
> - int rc2;
> -
> - rc2 = echo_client_cleanup(obd);
> - if (rc2)
> - CERROR("Cleanup obd device %s error(%d)\n",
> -obd->obd_name, rc2);
> - }
>  
> - case 3:
> - echo_site_fini(env, ed);
> - case 2:
> - cl_device_fini(&ed->ed_cl);
> - case 1:
> - kfree(ed);
> - case 0:
> - default:
> - break;
> - }
> +out_cleanup:
> + err = echo_client_cleanup(obd);
> + if (err)
> + CERROR("Cleanup obd device %s error(%d)\n",
> +obd->obd_name, err);
> +out_site_fini:
> + echo_site_fini(env, ed);
> +out_device_fini:
> + cl_device_fini(&ed->ed_cl);
> +out_free:
> + kfree(ed);
> +out:
>   return ERR_PTR(rc);
>  }
>  
> -- 
> 2.1.4
> 
> ___
> lustre-devel mailing list
> lustre-de...@lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> 
___
devel mailing list
de...@li

Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64

2016-04-10 Thread Greg Kroah-Hartman 
On Sun, Apr 10, 2016 at 03:04:51PM +0100, James Simmons wrote:
> 
> > This patch was shown not to work. I just haven't removed it from opensuse 
> > yet.
> 
> Its been running in our production tree as well for some time. Guess that 
> change is a noop. In any case we have been discussing redoing the lloop 
> driver anyways. Just need to find the cycles.

Why do you need this driver?  I know Christoph has pointed out many
times that it should just be dropped as it's not needed.

And should I drop this patch from the series?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64

2016-04-10 Thread James Simmons 

> > > This patch was shown not to work. I just haven't removed it from opensuse 
> > > yet.
> > 
> > Its been running in our production tree as well for some time. Guess that 
> > change is a noop. In any case we have been discussing redoing the lloop 
> > driver anyways. Just need to find the cycles.
> 
> Why do you need this driver?  I know Christoph has pointed out many
> times that it should just be dropped as it's not needed.

Please don't drop this driver just yet. The reason we kept it was for the DIO 
support that the loop back device lacked earlier. We need to do some 
testing to make sure the loop can completely replace this driver.

> And should I drop this patch from the series?

Yes since it is a noop. No other patches are dependent on it.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 08/27] staging: lustre: avoid to use bio->bi_vcnt directly

2016-04-10 Thread James Simmons 

> On Sun, Apr 10, 2016 at 03:37:42PM +0100, James Simmons wrote:
> > 
> > > The lloop driver should be removed entirely - use the loop driver
> > > instead.
> > 
> > I talked with Andreas last week at our annual Lustre users group meeting 
> > about this. The reason I was told for existance is that some users were
> > using files on a Lustre file system with the loop back device. The 
> > performance was really bad at the time so a lloop was developed to 
> > overcome those limitations. Its been a long time so perhaps its time
> > to look at the default loop driver again to see if can perform now. If
> > it doesn't we will go the route of reworking the lloop driver in the
> > spirit of the cryptoloop device.
> 
> The loop driver now supports using AIO/DIO on any file systems that
> implements ->read_iter and ->write_iter. If lustre doesn't support
> those or doesn't have proper performance using them it should be
> addressed in the file system.
> 
> Note that the dio mode in the loop device is not the default and you
> need to manually enabled it, keep that in mind when testing.

This is excellent news. The only sad thing is that most lustre users
are running distros that use kernels before the AIO/DIO enhancements
were landed :-( We will have to keep a copy around for those guys. But
first I need to test the performance of the loop back driver this
week before this can be dropped.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: wilc1000: rework comments in wilc_sdio.c

2016-04-10 Thread mohammed . billoo 
From: Mohammed Billoo 

Remove unnecessary comments (highlighting sections of functions), make
multiline comments into single line comments, and ensure that multiline
comments adhere to coding style.

Signed-off-by: Mohammed Billoo 
---
 drivers/staging/wilc1000/wilc_sdio.c | 136 ---
 1 file changed, 31 insertions(+), 105 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_sdio.c 
b/drivers/staging/wilc1000/wilc_sdio.c
index a839a79..a082e12 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -1,11 +1,7 @@
-/* // 
*/
-/*  */
-/* Copyright (c) Atmel Corporation.  All rights reserved. */
-/*  */
-/* Module Name:  wilc_sdio.c */
-/*  */
-/*  */
-/* 
 */
+/* Copyright (c) Atmel Corporation.  All rights reserved.
+ *
+ * Module Name:  wilc_sdio.c
+ */
 
 #include 
 #include "wilc_wlan_if.h"
@@ -257,11 +253,6 @@ static void wilc_sdio_disable_interrupt(struct wilc *dev)
dev_info(&func->dev, "wilc_sdio_disable_interrupt OUT\n");
 }
 
-/
- *
- *  Function 0
- *
- /
 
 static int sdio_set_func0_csa_address(struct wilc *wilc, u32 adr)
 {
@@ -269,9 +260,7 @@ static int sdio_set_func0_csa_address(struct wilc *wilc, 
u32 adr)
struct sdio_cmd52 cmd;
int ret;
 
-   /**
-*  Review: BIG ENDIAN
-**/
+   /* Review: BIG ENDIAN */
cmd.read_write = 1;
cmd.function = 0;
cmd.raw = 0;
@@ -334,11 +323,6 @@ _fail_:
return 0;
 }
 
-/
- *
- *  Function 1
- *
- /
 
 static int sdio_set_func1_block_size(struct wilc *wilc, u32 block_size)
 {
@@ -369,11 +353,7 @@ _fail_:
return 0;
 }
 
-/
- *
- *  Sdio interfaces
- *
- /
+
 static int sdio_write_reg(struct wilc *wilc, u32 addr, u32 data)
 {
struct sdio_func *func = dev_to_sdio_func(wilc->dev);
@@ -398,9 +378,7 @@ static int sdio_write_reg(struct wilc *wilc, u32 addr, u32 
data)
} else {
struct sdio_cmd53 cmd;
 
-   /**
-*  set the AHB address
-**/
+   /* set the AHB address */
if (!sdio_set_func0_csa_address(wilc, addr))
goto _fail_;
 
@@ -436,31 +414,23 @@ static int sdio_write(struct wilc *wilc, u32 addr, u8 
*buf, u32 size)
 
cmd.read_write = 1;
if (addr > 0) {
-   /**
-*  has to be word aligned...
-**/
+   /* has to be word aligned... */
if (size & 0x3) {
size += 4;
size &= ~0x3;
}
 
-   /**
-*  func 0 access
-**/
+   /* func 0 access */
cmd.function = 0;
cmd.address = 0x10f;
} else {
-   /**
-*  has to be word aligned...
-**/
+   /* has to be word aligned... */
if (size & 0x3) {
size += 4;
size &= ~0x3;
}
 
-   /**
-*  func 1 access
-**/
+   /* func 1 access */
cmd.function = 1;
cmd.address = 0;
}
@@ -576,31 +546,23 @@ static int sdio_read(struct wilc *wilc, u32 addr, u8 
*buf, u32 size)
 
cmd.read_write = 0;
if (addr > 0) {
-   /**
-*  has to be word aligned...
-**/
+   /* has to be word aligned... */
if (size & 0x3) {
size += 4;
size &= ~0x3;
}
 
-   /**
-*  func 0 access
-**/
+   /* func 0 access */
cmd.function = 0;
cmd.address = 0x10f;
} else {
-   /**
-*  has to be word aligned...
-**/
+   /* has to be word aligned... */
if (size & 0x3) {
size += 4;
size &= ~0x3;
}
 
-   /**
-*  func 1 access
-**/
+   /* func 1 access */
cmd.function = 1;
cmd.address = 0;
}
@@ -627,7 +589,7 @@ static int sdio_read(struct wilc *wilc, u32 addr, u8 *buf, 
u32 size)
if (addr > 0)
addr += nblk * block_size;
buf += nblk * block_size;
-   }   /* if (nb

Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64

2016-04-10 Thread Jeff Mahoney 
On 4/10/16 10:04 AM, James Simmons wrote:
> 
>> This patch was shown not to work. I just haven't removed it from opensuse 
>> yet.
> 
> Its been running in our production tree as well for some time. Guess that 
> change is a noop. In any case we have been discussing redoing the lloop 
> driver anyways. Just need to find the cycles.

I guess my memory was flakey and I was recalling the first comments in
LU-4000.  The updated version should be ok.

-Jeff

>> --
>> Jeff Mahoney
>> (apologies for the top post -- from my mobile)
>>
>>> On Apr 10, 2016, at 9:13 AM, James Simmons  wrote:
>>>
>>> From: Jeff Mahoney 
>>>
>>> On ppc64 with 64k pages, we get a build failure in lloop:
>>>
>>> drivers/staging/lustre/lustre/llite/lloop.c:527:2:
>>> note: in expansion of macro 'CLASSERT'
>>> CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));
>>>
>>> There's no need to change the queue's logical block size. Even if it could
>>> accept a 64k value, that would result in any file system on top of it
>>> needing to also use 64k blocks. It'd be safe to set it to 4k, but there's
>>> no actual need for it. It's not used to split requests except for 
>>> WRITE_SAME,
>>> which lloop doesn't implement anyway.
>>>
>>> Signed-off-by: Jeff Mahoney 
>>> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000
>>> Reviewed-on: http://review.whamcloud.com/7745
>>> Reviewed-by: Jinshan Xiong 
>>> Reviewed-by: Minh Diep 
>>> Reviewed-by: Oleg Drokin 
>>> Signed-off-by: James Simmons 
>>> ---
>>> drivers/staging/lustre/lustre/llite/lloop.c |3 ---
>>> 1 files changed, 0 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/staging/lustre/lustre/llite/lloop.c 
>>> b/drivers/staging/lustre/lustre/llite/lloop.c
>>> index b725fc1..f396753 100644
>>> --- a/drivers/staging/lustre/lustre/llite/lloop.c
>>> +++ b/drivers/staging/lustre/lustre/llite/lloop.c
>>> @@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct 
>>> file *unused,
>>>lo->lo_queue->queuedata = lo;
>>>
>>>/* queue parameters */
>>> -CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8)));
>>> -blk_queue_logical_block_size(lo->lo_queue,
>>> - (unsigned short)PAGE_CACHE_SIZE);
>>>blk_queue_max_hw_sectors(lo->lo_queue,
>>> LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9));
>>>blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS);
>>> -- 
>>> 1.7.1
>>>
>>>
>>
>>
> 


-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 08/27] staging: lustre: avoid to use bio->bi_vcnt directly

2016-04-10 Thread Ming Lei 
On Mon, Apr 11, 2016 at 12:02 AM, James Simmons  wrote:
>
>> On Sun, Apr 10, 2016 at 03:37:42PM +0100, James Simmons wrote:
>> >
>> > > The lloop driver should be removed entirely - use the loop driver
>> > > instead.
>> >
>> > I talked with Andreas last week at our annual Lustre users group meeting
>> > about this. The reason I was told for existance is that some users were
>> > using files on a Lustre file system with the loop back device. The
>> > performance was really bad at the time so a lloop was developed to
>> > overcome those limitations. Its been a long time so perhaps its time
>> > to look at the default loop driver again to see if can perform now. If
>> > it doesn't we will go the route of reworking the lloop driver in the
>> > spirit of the cryptoloop device.
>>
>> The loop driver now supports using AIO/DIO on any file systems that
>> implements ->read_iter and ->write_iter. If lustre doesn't support
>> those or doesn't have proper performance using them it should be
>> addressed in the file system.
>>
>> Note that the dio mode in the loop device is not the default and you
>> need to manually enabled it, keep that in mind when testing.
>
> This is excellent news. The only sad thing is that most lustre users
> are running distros that use kernels before the AIO/DIO enhancements
> were landed :-( We will have to keep a copy around for those guys. But
> first I need to test the performance of the loop back driver this
> week before this can be dropped.

Considered that this cleanup patch for lustre loop is quite simple and
straightforward, I suggest to keep this cleanup patch as so and do the
dropping in another patchset. Christoph, are you OK with that?

Thanks,
Ming Lei
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC][PATCH] MAINTAINERS: Add Android Ion as a separate entry

2016-04-10 Thread Dan Carpenter 
No one objects to this.

Resend it, but without the RFC in the subject.  Greg has a no RFC rule,
probably he has to edit the subject.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel