WARNING: Symbolic permissions 'S_IRUGO' are not preferred.
Consider using octal permissions '0444'.
This warning was detected by checkpatch.pl for hdm_i2c.c.
Signed-off-by: Zhengyi Shen <shenzhengyi@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fix the line over 80 characters warning that was detected
using checkpatch.pl script.
Fixes: 6fe5efa141 ('staging: octeon: Convert create_singlethread_workqueue()')
Cc: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: Seraphime Kirkovski <kirkseraph@gmail.com>
Signed-off-by: Greg 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: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg 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: Zhengyi Shen <shenzhengyi@gmail.com>
Signed-off-by: Greg 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: Steve Guminski <stephenx.guminski@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6210
Reviewed-on: https://review.whamcloud.com/23789
Reviewed-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Reviewed-by: James Simmons <uja.ornl@yahoo.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>
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>
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: Steve Guminski <stephenx.guminski@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6210
Reviewed-on: https://review.whamcloud.com/23332
Reviewed-by: Frank Zago <fzago@cray.com>
Reviewed-by: Dmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Reviewed-by: Nathaniel Clark <nathaniel.l.clark@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>
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: Steve Guminski <stephenx.guminski@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8189
Reviewed-on: http://review.whamcloud.com/23167
Reviewed-by: Frank Zago <fzago@cray.com>
Reviewed-by: Bob Glossman <bob.glossman@intel.com>
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Dmitry Eremin <dmitry.eremin@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>
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>
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>
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>
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>
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>
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>
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>
