Initialize the parent of the IIO device to the device that registered it.
This makes sure that the IIO device appears the right level in the device
hierarchy.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Initialize the parent of the IIO device to the device that registered it.
This makes sure that the IIO device appears the right level in the device
hierarchy.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <jic23@kernel.org>
There are a few more little cleanups that could be done on this driver, but
I don't think any are sufficient to justify not moving it out of staging.
It's a very simple driver (presumably for a simple part) so not much that can
go wrong. I think it was only ever in staging because that's where IIO was
as a whole at the time and then we forgot about it!
Signed-off-by: Jonathan Cameron <jic23@kernel.org> Cc: Roland Stigge <stigge@antcom.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
There are some unanswered questions due to disagreements between the code
and various datasheets (including between different datasheets for the same
part).
I don't think that is necessarily a reason to keep it in staging however.
I'm partly posting this patch inorder to reignite debate and with a bit
of luck find someone who has one of these to test!
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Documentation: iio: 104-quad-8: Fix KernelVersion in sysfs ABI documentation
The ACCES 104-QUAD-8 IIO driver did not appear in the 4.9 version of the
Linux kernel. This patch fixes the KernelVersion lines of the 104-QUAD-8
sysfs ABI documentation.
Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8") Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Documentation: iio: Fix KernelVersion in counter sysfs ABI documentation
The IIO counter driver support did not appear in the 4.9 version of the
Linux kernel. This patch fixes the KernelVersion lines of the relevant
IIO counter sysfs ABI documentation.
Fixes: 1a8f324aa1f2 ("iio: Implement counter channel type and info constants") Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Brian Masney [Thu, 9 Feb 2017 01:54:28 +0000 (20:54 -0500)]
staging: iio: isl29028: use the runtime power management for system sleep
With the introduction of runtime power management in commit 2db5054ac28d
("staging: iio: isl29028: add runtime power management support"), the
system could go to sleep and turn off the device without notifying the
runtime power management code. This patch changes the system suspend
and resume to go through the runtime power management.
Signed-off-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Brian Masney [Thu, 9 Feb 2017 01:54:26 +0000 (20:54 -0500)]
staging: iio: isl29028: fix incorrect sleep time when taking initial proximity reading
When proximity is enabled in isl29028_enable_proximity(), the function
msleep() is called with the sampling frequency, which is not correct.
This patch changes the code to sleep the specified amount of time listed
in the datasheet instead.
Signed-off-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Brian Masney [Thu, 9 Feb 2017 01:54:25 +0000 (20:54 -0500)]
staging: iio: isl29028: change mdelay() to msleep()
This driver in some cases can busy wait for upwards of 100 ms. Since the
kernel at this point is not running in atomic context, and is running in
process context, we can safely use msleep() instead. This patch changes
the two occurrences of mdelay() to msleep().
Signed-off-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Matt Ranostay [Sat, 4 Feb 2017 10:22:51 +0000 (02:22 -0800)]
iio: health: add MAX30102 oximeter driver support
MAX30102 is an heart rate and pulse oximeter sensor that works using
two LEDS of different wavelengths, and detecting the light reflected
back.
This patchset adds support for both IR and RED LED channels which can
be processed in userspace to determine heart rate and blood oxygen
levels. The MAX30102 part isn't completely register and functional
compatible with the existing MAX30100 driver.
Signed-off-by: Matt Ranostay <matt@ranostay.consulting> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio: accel: Add driver for the Analog Devices ADXL345 3-axis accelerometer
Add basic IIO support for the Analog Devices ADXL345 3-axis accelerometer.
The datasheet can be found here:
http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf
Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Cc: Daniel Baluta <daniel.baluta@gmail.com> Cc: Alison Schofield <amsfield22@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Lorenzo Bianconi [Sun, 29 Jan 2017 10:49:27 +0000 (11:49 +0100)]
iio: imu: st_lsm6dsx: add support to lsm6ds3h
Add support to STM LSM6DS3H 6-axis (acc + gyro) Mems sensor
http://www.st.com/resource/en/datasheet/lsm6ds3h.pdf Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Lorenzo Bianconi [Sun, 29 Jan 2017 10:49:25 +0000 (11:49 +0100)]
iio: imu: st_lsm6dsx: add support to lsm6dsl
Add support to STM LSM6DSL 6-axis (acc + gyro) Mems sensor
http://www.st.com/resource/en/datasheet/lsm6dsl.pdf Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Andreas Klinger [Tue, 31 Jan 2017 18:03:45 +0000 (19:03 +0100)]
iio: distance: add devantech us ranger srf04
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: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
James Simmons [Sun, 29 Jan 2017 00:05:27 +0000 (19:05 -0500)]
staging: lustre: ptlrpc : remove userland usage from ptlrpc
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: James Simmons <uja.ornl@yahoo.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8945
Reviewed-on: https://review.whamcloud.com/24396 Reviewed-by: Dmitry Eremin <dmitry.eremin@intel.com> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Simmons [Sun, 29 Jan 2017 00:05:26 +0000 (19:05 -0500)]
staging: lustre: osc: avoid 64 divide in osc_cache_too_much
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: James Simmons <uja.ornl@yahoo.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8835
Reviewed-on: https://review.whamcloud.com/23814 Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: Dmitry Eremin <dmitry.eremin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
wang di [Sun, 29 Jan 2017 00:05:25 +0000 (19:05 -0500)]
staging: lustre: lmv: remove nlink check in lmv_revalidate_slaves
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: wang di <di.wang@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6984
Reviewed-on: http://review.whamcloud.com/16490 Reviewed-by: James Simmons <uja.ornl@yahoo.com> Reviewed-by: Jian Yu <jian.yu@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steve Guminski [Sun, 29 Jan 2017 00:05:22 +0000 (19:05 -0500)]
staging: lustre: fid: Change positional struct initializers to C99
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:
Niu Yawei [Sun, 29 Jan 2017 00:05:21 +0000 (19:05 -0500)]
staging: lustre: ptlrpc: update replay cursor when close during replay
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: Niu Yawei <yawei.niu@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8765
Reviewed-on: https://review.whamcloud.com/23418 Reviewed-by: Yang Sheng <yang.sheng@intel.com> Reviewed-by: John L. Hammond <john.hammond@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Eremin [Sun, 29 Jan 2017 00:05:19 +0000 (19:05 -0500)]
staging: lustre: ptlrpc: update MODULE_PARAM_DESC in ptlrpcd.c
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: Dmitry Eremin <dmitry.eremin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8890
Reviewed-on: https://review.whamcloud.com/24065 Reviewed-by: John L. Hammond <john.hammond@intel.com> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liang Zhen [Sun, 29 Jan 2017 00:05:16 +0000 (19:05 -0500)]
staging: lustre: ksocklnd: ignore timedout TX on closing connection
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.
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: John L. Hammond <john.hammond@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8811
Reviewed-on: https://review.whamcloud.com/23843 Reviewed-by: Patrick Farrell <paf@cray.com> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Patrick Farrell [Sun, 29 Jan 2017 00:05:14 +0000 (19:05 -0500)]
staging: lustre: mdc: Make IT_OPEN take lookup bits lock
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: Patrick Farrell <paf@cray.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8842
Reviewed-on: https://review.whamcloud.com/23797 Fixes: 70a251f68dea ("staging: lustre: obd: decruft md_enqueue() and md_intent_lock()" Reviewed-by: John L. Hammond <john.hammond@intel.com> Reviewed-by: Lai Siyao <lai.siyao@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steve Guminski [Sun, 29 Jan 2017 00:05:13 +0000 (19:05 -0500)]
staging: lustre: libcfs: Change positional struct initializers to C99
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:
John L. Hammond [Sun, 29 Jan 2017 00:05:11 +0000 (19:05 -0500)]
staging: lustre: obd: remove OBD_NOTIFY_CREATE
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: John L. Hammond <john.hammond@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8403
Reviewed-on: https://review.whamcloud.com/21420 Reviewed-by: Ben Evans <bevans@cray.com> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: lustre: ptlrpc: allow blocking asts to be delayed
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: Vladimir 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/21065 Reviewed-by: Bobi Jam <bobijam@hotmail.com> Reviewed-by: John L. Hammond <john.hammond@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Niu Yawei [Sun, 29 Jan 2017 00:05:08 +0000 (19:05 -0500)]
staging: ptlrpc: leaked rs on difficult reply
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: Niu Yawei <yawei.niu@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7903
Reviewed-on: http://review.whamcloud.com/22696 Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: Lai Siyao <lai.siyao@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rahul Deshmukh [Sun, 29 Jan 2017 00:05:06 +0000 (19:05 -0500)]
staging: lustre: llite: Adding timed wait in ll_umount_begin
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.
James Simmons [Sun, 29 Jan 2017 00:05:04 +0000 (19:05 -0500)]
staging: lustre: header: remove assert from interval_set()
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: James 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/24323 Reviewed-by: Frank Zago <fzago@cray.com> Reviewed-by: Dmitry Eremin <dmitry.eremin@intel.com> Reviewed-by: John L. Hammond <john.hammond@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Eremin [Sun, 29 Jan 2017 00:05:01 +0000 (19:05 -0500)]
staging: lustre: libcfs: avoid stomping on module param cpu_pattern
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().
Jinshan Xiong [Sun, 29 Jan 2017 00:05:00 +0000 (19:05 -0500)]
staging: lustre: osc: limits the number of chunks in write RPC
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.
Fan Yong [Sun, 29 Jan 2017 00:04:58 +0000 (19:04 -0500)]
staging: lustre: ptlrpc: comment for FLD_QUERY RPC reply swab
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: Fan Yong <fan.yong@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6284
Reviewed-on: http://review.whamcloud.com/22309 Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: James Simmons <uja.ornl@yahoo.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Eremin [Sun, 29 Jan 2017 00:04:57 +0000 (19:04 -0500)]
staging: lustre: llite: Setting xattr are properly checked with and without ACLs
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: Dmitry Eremin <dmitry.eremin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1482
Reviewed-on: http://review.whamcloud.com/21496 Reviewed-by: John L. Hammond <john.hammond@intel.com> Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg 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: Andriy Skulysh <andriy.skulysh@seagate.com> Signed-off-by: Ben 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/21061 Reviewed-by: Alexander Boyko <alexander.boyko@seagate.com> Reviewed-by: Vitaly Fertman <vitaly.fertman@seagate.com> Reviewed-by: Mike Pershin <mike.pershin@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg 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: Fan Yong <fan.yong@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8408
Reviewed-on: http://review.whamcloud.com/21616 Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com> Reviewed-by: Hongchao Zhang <hongchao.zhang@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Drokin [Sun, 29 Jan 2017 00:04:54 +0000 (19:04 -0500)]
staging: lustre: llite: Trust creates in revalidate too.
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: Oleg Drokin <oleg.drokin@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8371
Reviewed-on: http://review.whamcloud.com/21168 Reviewed-by: James Simmons <uja.ornl@yahoo.com> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lai Siyao [Sun, 29 Jan 2017 00:04:53 +0000 (19:04 -0500)]
staging: lustre: llite: normal user can't set FS default stripe
Current client doesn't check permission before updating filesystem
default stripe on MGS, which isn't secure and obvious.
Since we setattr on MDS first, and then set default stripe on MGS,
we can just return error upon setattr failure.
Now filesystem default stripe is stored in ROOT in MDT, so saving
it in system config is for compatibility with old servers, this
will be removed in the future.
Signed-off-by: Lai Siyao <lai.siyao@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8454
Reviewed-on: http://review.whamcloud.com/21612
Reviewed-on: http://review.whamcloud.com/22580 Reviewed-by: Jian Yu <jian.yu@intel.com> Reviewed-by: Bobi Jam <bobijam@hotmail.com> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andreas Dilger [Sun, 29 Jan 2017 00:04:47 +0000 (19:04 -0500)]
staging: lustre: llite: handle inactive OSTs better in statfs
Change the order of checks for inactive OSCs in lov_prep_statfs_set()
so that administratively disabled OSTs do not generate any output in
"lfs df" at all, to avoid needlessly cluttering the output.
Enable the lazystatfs mount option by default, so that "df" does not
hang when an OST is temporarily offline.
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7759
Reviewed-on: http://review.whamcloud.com/19195 Reviewed-by: John L. Hammond <john.hammond@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Boyko [Sun, 29 Jan 2017 00:04:46 +0000 (19:04 -0500)]
staging: lustre: ptlrpc: skip lock if export failed
This patch resolves IO vs eviction race.
After eviction failed export stayed at stale list,
a client had IO processing and reconnected during it.
A client sent brw rpc with last lock cookie and new connection.
The lock with failed export was found and assert was happened.
(ost_handler.c:1812:ost_prolong_lock_one())
ASSERTION( lock->l_export == opd->opd_exp ) failed:
1. Skip the lock at ldlm_handle2lock if lock export failed.
2. Validation of lock for IO was added at hpreq_check(). The lock
searching is based on granted interval tree. If server doesn`t
have a valid lock, it reply to client with ESTALE.
Signed-off-by: Alexander Boyko <alexander.boyko@seagate.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7702
Seagate-bug-id: MRP-2787
Reviewed-on: http://review.whamcloud.com/18120 Reviewed-by: Fan Yong <fan.yong@intel.com> Reviewed-by: Vitaly Fertman <vitaly.fertman@seagate.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Zhuravlev [Sun, 29 Jan 2017 00:04:45 +0000 (19:04 -0500)]
staging: lustre: obdclass: do not call lu_site_purge() for single object exceed
First of all, this is expensive procedure including a global
mutex and per-bucket spinlocks. also, all the threads observed
exceed will be calling lu_site_purge() and essentially serialized
on that. instead we can let other threads to skip the whole
procedure.
Signed-off-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7896
Reviewed-on: http://review.whamcloud.com/19082 Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: Mike Pershin <mike.pershin@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jinshan Xiong [Sun, 29 Jan 2017 00:04:44 +0000 (19:04 -0500)]
staging: lustre: llite: don't ignore layout for group lock request
ignore_layout can be set for operations that layout won't be changed,
typically page operations. Ignoring layout change in group lock
request will confuse layout change code at LOV layer and hit
assertion.
Signed-off-by: Henri Doreau <henri.doreau@cea.fr> Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com> Signed-off-by: Bobi Jam <bobijam.xu@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2766
Reviewed-on: http://review.whamcloud.com/6828 Reviewed-by: John L. Hammond <john.hammond@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
frank zago [Sun, 29 Jan 2017 00:04:43 +0000 (19:04 -0500)]
staging: lustre: hsm: stack overrun in hai_dump_data_field
The function hai_dump_data_field will do a stack buffer
overrun when cat'ing /sys/fs/lustre/.../hsm/actions if an action has
some data in it.
hai_dump_data_field uses snprintf. But there is no check for
truncation, and the value returned by snprintf is used as-is. The
coordinator code calls hai_dump_data_field with 12 bytes in the
buffer. The 6th byte of data is printed incompletely to make room for
the terminating NUL. However snprintf still returns 2, so when
hai_dump_data_field writes the final NUL, it does it outside the
reserved buffer, in the 13th byte of the buffer. This stack buffer
overrun hangs my VM.
Fix by checking that there is enough room for the next 2 characters
plus the NUL terminator. Don't print half bytes. Change the format to
02X instead of .2X, which makes more sense.
Signed-off-by: frank zago <fzago@cray.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8171
Reviewed-on: http://review.whamcloud.com/20338 Reviewed-by: John L. Hammond <john.hammond@intel.com> Reviewed-by: Jean-Baptiste Riaux <riaux.jb@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ulka Vaze [Sun, 29 Jan 2017 00:04:40 +0000 (19:04 -0500)]
staging: lustre: lmv: Error not handled for lmv_find_target
This issue is found by smatch; has been reported as-
Unchecked usage of potential ERR_PTR result in lmv_hsm_req_count
and lmv_hsm_req_build. Added ERR_PTR in both functions and also
return value check added.
Ann Koehler [Sun, 29 Jan 2017 00:04:39 +0000 (19:04 -0500)]
staging: lustre: obd: RCU stalls in lu_cache_shrink_count()
The algorithm for counting freeable objects in the lu_cache shrinker
does not scale with the number of cpus. The LU_SS_LRU_LEN counter
for each cpu is read and summed at shrink time while holding the
lu_sites_guard mutex. With a large number of cpus and low memory
conditions, processes bottleneck on the mutex.
This mod reduces the time spent counting by using the kernel's percpu
counter functions to maintain the length of a site's lru. The summing
occurs when a percpu value is incremented or decremented and a
threshold is exceeded. lu_cache_shrink_count() simply returns the
last such computed sum.
This mod also replaces the lu_sites_guard mutex with a rw semaphore.
The lock protects the lu_site list, which is modified when a file
system is mounted/umounted or when the lu_site is purged.
lu_cache_shrink_count simply reads data so it does not need to wait
for other readers. lu_cache_shrink_scan, which actually frees the
unused objects, is still serialized.
Signed-off-by: Ann Koehler <amk@cray.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7997
Reviewed-on: http://review.whamcloud.com/19390 Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: Bobi Jam <bobijam@hotmail.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jinshan Xiong [Sun, 29 Jan 2017 00:04:34 +0000 (19:04 -0500)]
staging: lustre: clio: revise readahead to support 16MB IO
Read ahead currently doesn't handle 16MB RPC packets correctly
by assuming the packets are a default size instead of querying
the size. This work adjust the read ahead policy to issue
read ahead RPC by the underlying RPC size.
Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com> Signed-off-by: Gu Zheng <gzheng@ddn.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7990
Reviewed-on: http://review.whamcloud.com/19368 Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: Li Xi <lixi@ddn.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andreas Dilger [Sun, 29 Jan 2017 00:04:32 +0000 (19:04 -0500)]
staging: lustre: mdc: quiet console message for known -EINTR
If a user process is waiting for MDS recovery during close, but the
process is interrupted, the file is still closed but it prints a
message on the console. Quiet the console message for -EINTR, since
this is expected behaviour.
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6627
Reviewed-on: http://review.whamcloud.com/14911 Reviewed-by: Frank Zago <fzago@cray.com> Reviewed-by: Emoly Liu <emoly.liu@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lai Siyao [Sun, 29 Jan 2017 00:04:30 +0000 (19:04 -0500)]
staging: lustre: statahead: drop support for remote entry
This patch dropped support for remote entry statahead, because it
needs 2 async RPCs to fetch both LOOKUP lock from parent MDT and
UPDATE lock from client MDT, which is complicated. Plus not
supporting remote entry statahead won't cause any issue.
* pack child fid in statahead request.
* lmv_intent_getattr_async() will compare parent and child MDT,
if child is remote, return -ENOTSUPP.
Signed-off-by: Lai Siyao <lai.siyao@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6578
Reviewed-on: http://review.whamcloud.com/15767 Reviewed-by: Fan Yong <fan.yong@intel.com> Reviewed-by: wangdi <di.wang@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jinshan Xiong [Sun, 29 Jan 2017 00:04:29 +0000 (19:04 -0500)]
staging: lustre: llite: Remove access of stripe in ll_setattr_raw
In ll_setattr_raw(), it needs to know if a file is released
when the file is being truncated. It used to get this information
by accessing lov_stripe_md. This turns out not necessary. This
patch removes the access of lov_stripe_md and solves the problem
in lov_io_init_released().
Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5823
Reviewed-on: http://review.whamcloud.com/13514 Reviewed-by: James Simmons <uja.ornl@yahoo.com> Reviewed-by: Henri Doreau <henri.doreau@cea.fr> Reviewed-by: John L. Hammond <john.hammond@intel.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Thu, 2 Feb 2017 12:12:01 +0000 (12:12 +0000)]
staging: rts5208: remove redundant retval status check
The retval status checks in the proceeding do loop return out
of function ms_read_attritbute_info if there is an error
condition, thus we never reach the end of the loop with
retval failed status. Therefore, the retval status check
at end of the do loop is redundant and can be removed.
Detected with CoverityScan, CID#143000 ("Logically dead code")
Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Thu, 2 Feb 2017 14:43:42 +0000 (15:43 +0100)]
staging: fbtft: change 'gamma' array to u32
Having a local variable of 1024 bytes on 64-bit architectures is a bit
too much, and I ran into this warning while trying to see what functions
use the largest stack:
drivers/staging/fbtft/fbtft-sysfs.c: In function 'store_gamma_curve':
drivers/staging/fbtft/fbtft-sysfs.c:132:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
As there is no need for 64-bit gamma values (on 32-bit architectures,
we don't use those either), I'm changing the type from 'unsigned long'
to 'u32' here, which cuts the required space in half everywhere.
Arnd Bergmann [Thu, 2 Feb 2017 14:38:24 +0000 (15:38 +0100)]
staging: rtl8192u: move stats_IndicateArray off stack
Putting 128 pointers on the stack is rather wasteful, in particular
on 64-bit architectures:
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c: In function 'RxPktPendingTimeout':
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:92:1: warning: the frame size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=]
The rtl8192e driver has the exact same function, except that stores the
array in its 'ieee' structure. Let's do it the same way here for consistency.
David Kershner [Wed, 1 Feb 2017 22:39:00 +0000 (17:39 -0500)]
staging: unisys: visorbus: get rid of unused payload info
We no longer send payloads back to the s-Par firmware, we can get rid of
the initialize and destroy functions since they weren't actually being
used just created and destroyed.
Signed-off-by: David Kershner <david.kershner@unisys.com> Reviewed-by: David Binder <david.binder@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Sell [Wed, 1 Feb 2017 22:38:58 +0000 (17:38 -0500)]
staging: unisys: visornic: prevent hang doing 'modprobe -r visornic'
A stray+extraneous 'netif_napi_add()' that we were doing in
visornic_probe() was causing havoc when we got into visornic_remove(),
called during 'modprobe -r visornic'. The symptom was a processor busy-wait
loop on the modprobe process, which '/proc/<pid>/stack' would show looping
doing napi things.
Presumably the stray line got there as a result of some merging snafoo, and
has been deleted to fix the problem. With this patch 'modprobe -r visornic'
and a subsequent 'modprobe visornic' both complete successfully, and result
in an operational network.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: David Kershner <david.kershner@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / karo-tx-linux.git / log