This patch adds support for the ultrasonic ranger srf04 of devantech.

This device is measuring the distance of objects in a range between 1 cm
and 3 meters and a theoretical resolution of 3 mm.

There are two GPIOs used:
  - trigger: set as output to the device when the measurement should start
  - echo: set by the device when the ultrasonic wave is sent out and reset
    when the echo is recognized; this needs to be an interrupt input

The time between setting and resetting the echo pin is the time the
waveform needed for one round trip. This time is recorded in the interrupt
handler.

The distance is calculated in the read function by using the ultrasonic
speed at 20 degrees celsius which is about 343 m/s.
Signed-off-by: NAndreas Klinger <ak@it-klinger.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This patch adds dt binding for devantech ultrasonic ranger srf04.

The vendor "devantech" was already added to the vendor list with
        "[PATCH v4 1/3] iio: distance: srf08: add trivial DT binding"
Signed-off-by: NAndreas Klinger <ak@it-klinger.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Changed symbolic permissions to octal permissions.
Found using checkpatch
Signed-off-by: NDerek Robson <robsonde@gmail.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Signed-off-by: NMatt Ranostay <matt@ranostay.consulting>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This replaces the last occurrence of the deprecated <asm/uaccess.h> include
in the staging directory with the newer <linux/uaccess.h>
Signed-off-by: NSeraphime Kirkovski <kirkseraph@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The problem is that we copy hdr.ioc_len, we verify it, then we copy it
again without checking to see if it has changed in between the two
copies.

This could result in an information leak.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is a patch to fix "WARNING: line over 80 characters" found by
checkpatch.pl in vvp_page.c.
Signed-off-by: NZhengyi Shen <shenzhengyi@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The reason for __REQ_LAYOUT_USER__ was to expose a
section of code in layout.c to userland for a utility
similar to wireshark. This was done before wireshark
existed but now that it does we no longer need to do
this type of hack. This also reduces lustre_acl.h to
strictly a kernel header now.
Signed-off-by: NJames Simmons <uja.ornl@yahoo.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8945
Reviewed-on: https://review.whamcloud.com/24396Reviewed-by: NDmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The use of 64 bit time introduces an expensive 64 bit
division operation. Since the time lapse being calculated
in osc_cache_too_much will never be more than seventy years
we can cast the time lapse to an long and perform a normal
32 bit divison operation instead.
Signed-off-by: NJames Simmons <uja.ornl@yahoo.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8835
Reviewed-on: https://review.whamcloud.com/23814Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Reviewed-by: NDmitry Eremin <dmitry.eremin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If an application attempts to remove millions of files in a
single directory it will fail. This failure was tracked down to
the nlink < 2 check in lmv_revalidate_slaves, because after
nlink reaches to maximum value of LDISKFS_LINK_MAX (65000),
the nlink broadcast back from the server will be reported as
one. The return value of 1 is not invalid so lets remove
the check.
Signed-off-by: Nwang di <di.wang@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6984
Reviewed-on: http://review.whamcloud.com/16490Reviewed-by: NJames Simmons <uja.ornl@yahoo.com>
Reviewed-by: NJian Yu <jian.yu@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The function generic_file_read_iter() does not check EOF
before invoke direct_IO callback. So we have to check it
ourselves.
Signed-off-by: NYang Sheng <yang.sheng@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8969
Reviewed-on: https://review.whamcloud.com/24552Reviewed-by: NBob Glossman <bob.glossman@intel.com>
Reviewed-by: NBobi Jam <bobijam@hotmail.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Building the lustre client with W=1 reports the following
error:

obdclass/obd_mount.c: In function lmd_parse:
obdclass/obd_mount.c:880: warning: variable set but not used

The solution is to move s3 to the inner loop
where it is only used.
Signed-off-by: NJames Simmons <uja.ornl@yahoo.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8378
Reviewed-on: https://review.whamcloud.com/23820Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Reviewed-by: NJinshan Xiong <jinshan.xiong@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch makes no functional changes.  Struct initializers in the
fid directory that use C89 or GCC-only syntax are updated to C99
syntax.

The C99 syntax prevents incorrect initialization if values are
accidently placed in the wrong position, allows changes in the struct
definition, and clears any members that are not given an explicit
value.

The following struct initializers have been updated:

lustre/fid/fid_lib.c:
        const struct lu_seq_range LUSTRE_SEQ_SPACE_RANGE
        const struct lu_seq_range LUSTRE_SEQ_ZERO_RANGE
lustre/fid/lproc_fid.c:
        struct lprocfs_vars seq_client_debugfs_list
Signed-off-by: NSteve Guminski <stephenx.guminski@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6210
Reviewed-on: https://review.whamcloud.com/23789Reviewed-by: NNathaniel Clark <nathaniel.l.clark@intel.com>
Reviewed-by: NJames Simmons <uja.ornl@yahoo.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The replay cursor should be updated properly when close happened
during replay, otherwise, ptlrpc_replay_next() could run into a
dead loop due to an invalid replay cursor:

- replay cursor is moved to an open request during replay;
- application close that open file, so the rq_replay of the open
  request is cleared;
- ptlrpc_replay_next() calls ptlrpc_free_committed() to free
  committed/closed requests, the open request is removed from
  the committed list, so the replay cursor is changed to an
  empty list_head now. The open request won't be freed now since
  it's still held by the pending close request;
- ptlrpc_replay_next() continue to move the replay cursor to
  next and run into a dead loop at the end;

Another change in this patch is to remove the out of date comments
in ptlrpc_replay_next() and cover the whole process of finding
replay request within imp_lock, because:

1. With two separated replay lists and replay cursor introduced,
   finding replay request won't take much time as before, it's
   not necessary to do this "lock -> unlock -> lock -> unlock"
   trick anymore;

2. Nowadays there are various kind of non-replay requests are
   allowed during recovery, so ptlrpc_free_committed() may run in
   parallel to remove an open request while ptlrpc_replay_next()
   is iterating the open requests list;
Signed-off-by: NNiu Yawei <yawei.niu@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8765
Reviewed-on: https://review.whamcloud.com/23418Reviewed-by: NYang Sheng <yang.sheng@intel.com>
Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Update max_ptlrpcds module parameter descriptions to let
users know its obsolete. Change cpt to CPT for the module
parameter description ptlrpcd_per_cpt_max so it matches
documentation.
Signed-off-by: NDmitry Eremin <dmitry.eremin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8890
Reviewed-on: https://review.whamcloud.com/24065Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Environment for request interpreters is not used any more.
Signed-off-by: NDmitry Eremin <dmitry.eremin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8887
Reviewed-on: https://review.whamcloud.com/24061Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NBob Glossman <bob.glossman@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove the inline function socklnd_init_msg.
Its only used by the kernel code so no point
keeping it in an UAPI header.
Signed-off-by: NJames Simmons <uja.ornl@yahoo.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6142
Reviewed-on: https://review.whamcloud.com/18506Reviewed-by: NDmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: NDoug Oucharek <doug.s.oucharek@intel.com>
Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

ksocklnd reaper thread always tries to close the connection for the
first timedout zero-copy TX. This is wrong if this connection is
already being closed, because the reaper will see the same TX again
and again and cannot find out other timedout zero-copy TXs and close
connections for them.
Signed-off-by: NLiang Zhen <liang.zhen@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8867
Reviewed-on: https://review.whamcloud.com/23973Reviewed-by: NDoug Oucharek <doug.s.oucharek@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In mdc_close() if ptlrpc_request_pack() fails then set req to NULL so
that an already freed request is not returned in *request.
Signed-off-by: NJohn L. Hammond <john.hammond@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8811
Reviewed-on: https://review.whamcloud.com/23843Reviewed-by: NPatrick Farrell <paf@cray.com>
Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

An earlier commit accidentally changed handling of IT_OPEN,
making it take the MDS_INODELOCK_UPDATE bits lock instead of
MDS_INODELOCK_LOOKUP. This does not cause any known bugs.
Signed-off-by: NPatrick Farrell <paf@cray.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8842
Reviewed-on: https://review.whamcloud.com/23797
Fixes: 70a251f6 ("staging: lustre: obd: decruft md_enqueue() and md_intent_lock()"
Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NLai Siyao <lai.siyao@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch makes no functional changes. Struct initializers in the
libcfs directory that use C89 or GCC-only syntax are updated to C99
syntax.

The C99 syntax prevents incorrect initialization if values are
accidently placed in the wrong position, allows changes in the struct
definition, and clears any members that are not given an explicit
value.

The following struct initializers have been updated:

libcfs/include/libcfs/libcfs_crypto.h:
        static struct cfs_crypto_hash_type hash_types[]
Signed-off-by: NSteve Guminski <stephenx.guminski@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6210
Reviewed-on: https://review.whamcloud.com/23332Reviewed-by: NFrank Zago <fzago@cray.com>
Reviewed-by: NDmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: NJames Simmons <uja.ornl@yahoo.com>
Reviewed-by: NNathaniel Clark <nathaniel.l.clark@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Don't treat unability to set CPU partition affinity as error.
Improve those warning messages.
Signed-off-by: NDmitry Eremin <dmitry.eremin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8703
Reviewed-on: https://review.whamcloud.com/23307Reviewed-by: NPatrick Farrell <paf@cray.com>
Reviewed-by: NDoug Oucharek <doug.s.oucharek@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

None of the obd_notify() handlers listen for the OBD_NOTIFY_CREATE
event, so remove it and its sole use in lov_add_target().
Signed-off-by: NJohn L. Hammond <john.hammond@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8403
Reviewed-on: https://review.whamcloud.com/21420Reviewed-by: NBen Evans <bevans@cray.com>
Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

ptlrpc_import_delay_req() refuses to delay blocking asts when import
is not in LUSTRE_IMP_FULL yet. That leads to client eviction assuming
that it failed to respond.

Allow delays for blocking asts being resent.
Signed-off-by: NVladimir Saveliev <vladimir.saveliev@seagate.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8351
Seagate-bug-id: MRP-3500
Reviewed-on: https://review.whamcloud.com/21065Reviewed-by: NBobi Jam <bobijam@hotmail.com>
Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The patch updates the prototype in osc_internal.h to match the
enums used in the declaration.

The osc_match_base declaration in lustre/osc/osc_request.c uses
enums for stricter checking on the type and mode parameters:

int osc_match_base(struct obd_export *exp,
                   ...
-->                enum ldlm_type type,
                   union ldlm_policy_data *policy,
-->                enum ldlm_mode mode,
                   ...  int unref)

The prototype in lustre/osc/osc_internal.h instead used unsigned ints:

int osc_match_base(struct obd_export *exp,
                   ...
-->                __u32 type,
                       union ldlm_policy_data *policy,
-->                __u32 mode,
                   ...  int unref);
Signed-off-by: NSteve Guminski <stephenx.guminski@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8189
Reviewed-on: http://review.whamcloud.com/23167Reviewed-by: NFrank Zago <fzago@cray.com>
Reviewed-by: NBob Glossman <bob.glossman@intel.com>
Reviewed-by: NJames Simmons <uja.ornl@yahoo.com>
Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NDmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

reply_out_callback() should call ptlrpc_schedule_difficult_reply()
to finalize the rs if it's already not on uncommitted list, otherwise,
the rs and the export held by rs could be leaked:

- target_send_reply() sends a difficult reply before the transaction
  committed, the reply is linked to scp_rep_active;

- export gets disconnected by umount or whatever reason,
  server_disconnect_export() is called to complete all outstanding
  replies, which will calls into ptlrpc_handle_rs() to dispose of
  the rs, so the rs is removed from the uncommitted list and
  LNetMDUnlink() is called to unlink the reply buffer and generate
  an unlink event;

- reply_out_callback() is called to process above unlink event,
  ptlrpc_schedule_difficult_reply() is supposed to be called to
  dispose of the rs finally. However, it could be skipped because of
  following flawed code snippet:

  if (!rs->rs_no_ack ||
      rs->rs_transno <= rs->rs_export->exp_obd->obd_last_committed)
        ptlrpc_schedule_difficult_reply(rs);

The intention of above code is: if rs_no_ack is true (COS enabled),
and transaction is not committed, we should rely on commit callback
to release the rs. However, it overlooked the situation that rs
could have been removed from the uncommitted list by disconnecting
export.
Signed-off-by: NNiu Yawei <yawei.niu@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7903
Reviewed-on: http://review.whamcloud.com/22696Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Reviewed-by: NLai Siyao <lai.siyao@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Replace the ulong_ptr_t and long_ptr_t with standard
kernel types.
Signed-off-by: NJames Simmons <uja.ornl@yahoo.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6245
Reviewed-on: http://review.whamcloud.com/20204Reviewed-by: NFrank Zago <fzago@cray.com>
Reviewed-by: NDmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There exists timing race between umount and other
thread which will increment the reference count on
mnt e.g. getattr. If umount thread lose the race
then umount fails with EBUSY error. To avoid this
timed wait is added so that umount thread will wait
for user to decrement the mnt reference count.
Signed-off-by: NRahul Deshmukh <rahul.deshmukh@seagate.com>
Signed-off-by: NLokesh Nagappa Jaliminche <lokesh.jaliminche@seagate.com>
Signed-off-by: NJian Yu <jian.yu@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1882
Seagate-bug-id: MRP-1192
Reviewed-on: http://review.whamcloud.com/20061Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Reviewed-by: NLai Siyao <lai.siyao@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

So that debug log only contains relevant messages for debugging
purpose.
Signed-off-by: NBobi Jam <bobijam.xu@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8413
Reviewed-on: http://review.whamcloud.com/22753Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Reviewed-by: NFan Yong <fan.yong@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the case of interval_tree.h only interval_set()
uses LASSERT which is removed in this patch and
interval_set() instead reports a real error. The
header libcfs.h for interval_tree.h is not needed
anymore so we can just use the standard linux
kernel headers instead.h
Signed-off-by: NJames Simmons <uja.ornl@yahoo.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6401
Reviewed-on: https://review.whamcloud.com/22522
Reviewed-on: https://review.whamcloud.com/24323Reviewed-by: NFrank Zago <fzago@cray.com>
Reviewed-by: NDmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

lov_device::ld_target[ost_idx] could be NULL if the OST target is
not filled in lov_device::ld_lov::lov_tgt_desc[ost_idx] yet.
Signed-off-by: NBobi Jam <bobijam.xu@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8018
Reviewed-on: http://review.whamcloud.com/21411Reviewed-by: NJinshan Xiong <jinshan.xiong@intel.com>
Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Change default value of CPT pattern and make it match NUMA topology
Signed-off-by: NLiang Zhen <liang.zhen@intel.com>
Signed-off-by: NDmitry Eremin <dmitry.eremin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5050
Reviewed-on: http://review.whamcloud.com/22377Reviewed-by: NJames Simmons <uja.ornl@yahoo.com>
Reviewed-by: NOlaf Weber <olaf@sgi.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The function cfs_cpt_table_create_pattern() alters the string
passed to it. Currently we are passing in the module parameter
string cpu_pattern which is incorrect. Instead lets duplicate
the module parameter string and pass that to the function
cfs_cpt_table_create_pattern().
Signed-off-by: NLiang Zhen <liang.zhen@intel.com>
Signed-off-by: NDmitry Eremin <dmitry.eremin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5050
Reviewed-on: http://review.whamcloud.com/22377Reviewed-by: NJames Simmons <uja.ornl@yahoo.com>
Reviewed-by: NOlaf Weber <olaf@sgi.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

OSC has to make sure that it won't issue write RPCs with too many
chunks otherwise it will casue ZFS to create transactions much
bigger than DMU_MAX_ACCESS in size, which will end up with write
failure.
Signed-off-by: NJinshan Xiong <jinshan.xiong@intel.com>
Signed-off-by: NDmitry Eremin <dmitry.eremin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8135
Reviewed-on: http://review.whamcloud.com/22369
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8632
Reviewed-on: http://review.whamcloud.com/22654Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Reviewed-by: NPatrick Farrell <paf@cray.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Sync write should update m/ctime promptly, otherwise, stale m/ctime
could be updated on the OST object by the sync write RPC.
Signed-off-by: NNiu Yawei <yawei.niu@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7310
Reviewed-on: http://review.whamcloud.com/21063Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NBobi Jam <bobijam@hotmail.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The 'fld_read_server' uses 'RMF_GENERIC_DATA' to hold the 'FLD_QUERY'
RPC reply that is composed of 'struct lu_seq_range_array'. But there
is not registered swabber function for 'RMF_GENERIC_DATA'. So the RPC
peers need to handle the RPC reply with fixed little-endian format.

In theory, we can define new structure with some swabber registered
to handle the 'FLD_QUERY' RPC reply result automatically. But from
the implementation view, it is not easy to be done within current
'struct req_msg_field' framework. Because the sequence range array
in the RPC reply is not fixed length, instead, its length depends
on 'lu_seq_range' count, that is unknown when prepare the RPC buffer.
Generally, for such flexible length RPC usage, there will be a field
in the RPC layout to indicate the data length. But for the 'FLD_READ'
RPC, we have no way to do that unless we add new length filed that
will broken the on-wire RPC protocol and cause interoperability
trouble with old peer.
Signed-off-by: NFan Yong <fan.yong@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6284
Reviewed-on: http://review.whamcloud.com/22309Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Reviewed-by: NJames Simmons <uja.ornl@yahoo.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Setting extended attributes permissions are properly checked with and
without ACLs. In user.* namespace, only regular files and directories
can have extended attributes. For sticky directories, only the owner
and privileged user can write attributes.
Signed-off-by: NDmitry Eremin <dmitry.eremin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1482
Reviewed-on: http://review.whamcloud.com/21496Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NAlex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Whole policy structure was zeroed twice. Once during enqueue
and second time during resend or replay. Policy structure
should be initialized with default values only in ldlm_lock_new().
Signed-off-by: NAndriy Skulysh <andriy.skulysh@seagate.com>
Signed-off-by: NBen Evans <bevans@cray.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8349
Seagate-bug-id: MRP-2536, MRP-2909
Reviewed-on: http://review.whamcloud.com/21061Reviewed-by: NAlexander Boyko <alexander.boyko@seagate.com>
Reviewed-by: NVitaly Fertman <vitaly.fertman@seagate.com>
Reviewed-by: NMike Pershin <mike.pershin@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Originally, the logic of handling config_llog_data::cld_refcount
is some confusing, it may cause the cld_refcount to be leaked or
trigger "LASSERT(atomic_read(&cld->cld_refcount) > 0);" when put
the reference. This patch clean related logic as following:

1) When the 'cld' is created, its reference is set as 1.

2) No need additional reference when add the 'cld' into the list
   'config_llog_list'.

3) Inrease 'cld_refcount' when set lock data after mgc_enqueue()
   done successfully by mgc_process_log().

4) When mgc_requeue_thread() traversals the 'config_llog_list',
   it needs to take additional reference on each 'cld' to avoid
   being freed during subsequent processing. The reference also
   prevents the 'cld' to be dropped from the 'config_llog_list',
   then the mgc_requeue_thread() can safely locate next 'cld',
   and then decrease the 'cld_refcount' for previous one.

5) mgc_blocking_ast() will drop the reference of 'cld_refcount'
   that is taken in mgc_process_log().

6) The others need to call config_log_find() to find the 'cld'
   if want to access related config log data. That will increase
   the 'cld_refcount' to avoid being freed during accessing. The
   sponsor needs to call config_log_put() after using the 'cld'.

7) Other confused or redundant logic are dropped.

   On the other hand, the patch also enhances the protection for
   'config_llog_data' flags, such as 'cld_stopping'/'cld_lostlock'
   as following.

a) Use 'config_list_lock' (spinlock) to handle the possible
   parallel accessing of these flags among mgc_requeue_thread()
   and others config llog data visitors, such as mount/umount,
   blocking_ast, and so on.

b) Use 'config_llog_data::cld_lock' (mutex) to pretect other
   parallel accessing of these flags among kinds of blockable
   operations, such as mount, umount, and blocking ast.

The 'config_llog_data::cld_lock' is also used for protecting
the sub-cld members, such as 'cld_sptlrpc'/'cld_params', and
so on.
Signed-off-by: NFan Yong <fan.yong@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8408
Reviewed-on: http://review.whamcloud.com/21616Reviewed-by: NAlex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: NHongchao Zhang <hongchao.zhang@intel.com>
Reviewed-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

By forcing creates to always go via lookup we lose some
important caching benefits too.
Instead let's trust creates with positive cached entries.

Then we have 3 possible outcomes:
1. Negative dentry - we go via atomic_open and do the create
   by name there.
2. Positive dentry, no contention - we just go straight to
   ll_intent_file_open and open by fid.
3. positive dentry, contention - by the time we reach the server,
   the inode is gone. We get ENOENT which is unacceptable to return
   from create. But since we know it's a create, we substitute it
   with ESTALE and VFS retries again with LOOKUP_REVAL set, we catch
   that in revalidate and force a lookup (same path as before this
   patch).
Signed-off-by: NOleg Drokin <oleg.drokin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8371
Reviewed-on: http://review.whamcloud.com/21168Reviewed-by: NJames Simmons <uja.ornl@yahoo.com>
Reviewed-by: NAndreas Dilger <andreas.dilger@intel.com>
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>