With certain version of gcc lov_obd.c failes to compile
with the following warning.
In function copy_to_user,
inlined from lov_iocontrol at
lustre/lustre/lov/lov_obd.c:1168:
./arch/x86/include/asm/uaccess.h:735: error: call to
__copy_to_user_overflow declared with attribute warning:
copy_to_user() buffer size is not probably correct
In lov_iocontrol the data was being casted to int instead
of the required unsigned long. This patch changes the cast
to what is needed for copy_to_user.
Signed-off-by: James Simmons <uja.ornl@yahoo.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6302
Reviewed-on: http://review.whamcloud.com/14613
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>
Add cl_object_layout_get() to return the layout and generation of an
object. Replace some direct accesses to object LSM with calls to this
function.
In ll_getxattr() factor out the LOV xattr specific handling into a new
function ll_getxattr_lov() which calls cl_object_layout_get(). In
ll_listxattr() call ll_getxattr_lov() to determine if a lustre.lov
xattr should be emitted. Add lov_lsm_pack() to generate LOV xattrs
from a LSM.
Remove the unused functions ccc_inode_lsm_{get,put}() and
lov_lsm_get().
Signed-off-by: John L. Hammond <john.hammond@intel.com>
Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5814
Reviewed-on: http://review.whamcloud.com/13680
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>
Some old protocol compatibility workarounds are still present in
master that should have been removed when LUSTRE_MSG_MAGIC_V1 was.
In particular, the process for upgrading LUSTRE_MSG_MAGIC_V1 to
LUSTRE_MSG_MAGIC_V2 had the client to connect to the server with the
V1 protocol with op_flag=MSG_CONNECT_NEXT_VER set, and if the server
supported the V2 protocol it would reply with LUSTRE_MSG_MAGIC_V2.
This ensured that if the new client connected to an old server the
connection would be allowed. However, even with V1 protocol support
removed, the 2.x clients are still connecting with NEXT_VER set.
In b1_8 this flag was contingent on LUSTRE_MSG_MAGIC_V1 being used,
which is how it should have been in 2.x as well.
A few other cleanups are be done at the same time:
- disallow 1.8 clients (or at least those that don't understand
OBD_CONNECT_FULL20) so we can remove workarounds for 1.8 clients
- remove support for pre-2.1 DLM flock lock handling
- don't workaround the lack of MDS_ATTR_xTIME_SET flags in setattr
- always set MSGHDR_CKSUM_INCOMPAT18 (it can eventually be removed)
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6349
Reviewed-on: http://review.whamcloud.com/14006
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Reviewed-by: Dmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Liang Zhen <liang.zhen@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>
Currently, the CBPENDING flag is set on group locks when
the osc lock above them is released (osc_cancel_base).
This results in a situation where a new group lock request
on a resource does not match an existing group lock because
LDLM_FL_CBPENDING is set on the existing lock.
So two group locks are granted on the same resource, which
is not valid, since a given client can only have one group
lock on a particular resource.
Since group locks are manually released and not called back
like other LDLM locks, the CBPENDING flag doesn't make
sense. Since they must be manually released, they also
cannot go in the LDLM LRU cache and must be fully released
immediately once they are no longer in use.
This was previously accomplished by setting CBPENDING when
the corresponding osc lock is released, but as noted above,
this prevents the group lock matching some future lock
requests.
This patch uses the fact that group locks have an l_writers
reference which they keep until they are manually released,
so we remove them when they have no more reader or writer
references, without checking cbpending.
Signed-off-by: Patrick Farrell <paf@cray.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6368
Reviewed-on: http://review.whamcloud.com/14093
Reviewed-by: frank zago <fzago@cray.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@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 new tag field is used as a virtual index for multiple modifying
RPCs management. It is set by the client and allows the target to
release in-memory reply data when the tag is reused by a new RPC.
The tag field replaces the unused last_seen field of ptlrpcd_body
structure.
Additionally, the last_xid field is used to transfer the highest XID
for which a reply has been received and does not have an unreplied
lower-numbered XID.
Signed-off-by: Gregoire Pichon <gregoire.pichon@bull.net>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5319
Reviewed-on: http://review.whamcloud.com/14095
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The new OBD_CONNECT_MULTIMODRPCS connection flag indicates the support
of multiple modify RPCs in parallel. It can be specified by the client
within the connection request and by the server within the connection
reply. The new ocd_maxmodrpcs connection data specifies the maximum modify
RPCs in parallel supported by the server.
To allow the MDS to send the new ocd_maxmodrpcs field, it has been
required to modify RMF_CONNECT_DATA so that its size includes the new
field. This change leads to remove the ocd_connect_data_v1 structure.
Note that the client has been allocating an extra 16*sizeof(__u64) for
the obd_connect_data reply since 2.0 and even in later versions of 1.8)
so there is no problem for the MDS to just send the full reply size.
This patch fixes a bug in __req_capsule_get() since it wasn't checking
RMF_F_NO_SIZE_CHECK when receiving the message. This allows legacy
clients (with version lower that this commit) to send connection
request with ocd_connect_data structure size smaller (actually size is
ocd_connect_data_v1 structure size) than new server ocd_connect_data
structure size.
This patch also fixes a bug in the routine that displays the import's
connect data.
Signed-off-by: Gregoire Pichon <gregoire.pichon@bull.net>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5319
Reviewed-on: http://review.whamcloud.com/#/c/13960
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In this implementation, read ahead will hold the underlying DLM lock
to add read ahead pages. A new cl_io operation cio_read_ahead() is
added for this purpose. It takes parameter cl_read_ahead{} so that
each layer can adjust it by their own requirements. For example, at
OSC layer, it will make sure the read ahead region is covered by a
LDLM lock; at the LOV layer, it will make sure that the region won't
cross stripe boundary.
Legacy callback cpo_is_under_lock() is removed.
Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3259
Reviewed-on: http://review.whamcloud.com/10859
Reviewed-by: John L. Hammond <john.hammond@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>
When unloading a module, it may happen that lu_context_key_degister()
removes a key while a thread is either registering it in a new
context (lu_context_init(), lu_context_refill()), or using it when
exiting from a context (lu_context__exit(), lu_context__fini()).
In these cases, we reference a key which no longer exists, and
the system crashes either because we use a *POISON'ed* pointer
in key_fini() -> key->lct_fini(), or because one of the following
assertions fails:
- lu_context_key_degister():
ASSERTION(cfs_atomic_read(&key->lct_used) == 1)
failed: key has instances: 2
- lu_context_exit():
ASSERTION(key != NULL)
- key_fini():
ASSERTION(atomic_read(&key->lct_used) > 1)
This can also leads to SLAB objects which are not freed:
slab error in kmem_cache_destroy(): cache `echo_thread_kmem':
Can't free all objects
Note: ptlrpc service threads need to call lu_context_init/fini in
each loop (for each RPC), and this could be a big performance issue
on fat SMP machines if we add serialization by a spinlock and need
to lock/unlock it for multiple times for each RPC.
So the aim of this patch, which only impacts some low frequently used
functions, is:
1) to add a synchronization in lu_context_key_quiesce(), also called
by lu_context_key_degister(), to wait until all key::lct_init()
methods have completed, by serializing with keys_fill()
2) to add a synchronization in lu_context_key_degister(), to wait
until all transient contexts referencing this key have run
key::lct_fini() method
Signed-off-by: Patrick Valentin <patrick.valentin@bull.net>
Signed-off-by: Gregoire Pichon <gregoire.pichon@bull.net>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6049
Reviewed-on: http://review.whamcloud.com/13164
Reviewed-by: Fan Yong <fan.yong@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>
Remove function remote_event_destroy as it is not used anywhere in the
kernel. Function detected using Coccinelle but changes done by hand.
Script:
@initialize:python@
@@
def display(name,p):
print(name,p[0].file)
@r1@
identifier func;
type T;
position p;
@@
static T func@p(...)
{
...
}
@r@
identifier r1.func;
@@
func
@script:python depends on !r@
func << r1.func;
p << r1.p;
@@
display(func,p)
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fix the coding style problem of block comment detected by the
checkpatch.pl.
WARNING: Block comments use a trailing */ on a separate line
Signed-off-by: Hisao Tanabe <xtanabe@gmail.com>
Acked-by: Johan Hovold <johan@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes a WARNING: Prefer 'unsigned int' to bare use of
'unsigned', found by checkpatch.pl. By fixing this the types of the parameters of the function become more explicit.
Signed-off-by: Muraru Mihaela <mihaela.muraru21@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes the checkpatch.pl warning: "WARNING: do not add new
typedefs". Hiding a variables of type 'struct' is not always a good
idea,because when we passing them as parameters we tempt to forget that
in this proces we work with stack memory and allocatting struct on
stack is something that we should manage carefuly.
It is also delete the '_t' from the name of the structs and treat a line
over 80 character issue in ddk750_mode.c, that appear after my modification.
Signed-off-by: Mihaela Muraru <mihaela.muraru21@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This comes from the downstream tree and is needed for the new VCHIQ
driver in staging.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
