We used to access layout version under the protection of ldlm
lock, this introduces extra overhead for dlm lock matching.
In this patch, lli_layout_lock is introduced to access the layout
version. Also, when a layout lock is losing, we should tear down
mmap of the correspoding inode to avoid stale data accessing in the
future.
This is part of technical verification of replication.
Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com>
Reviewed-on: http://review.whamcloud.com/8689
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3254
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Bobi Jam <bobijam@gmail.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The statahead debug messages include the pid of the current
process in their body. This is both redudant (because all
lustre log messages contain the pid), and sometimes downright
misleading. For instance the messages would say something like
"stopping statahead thread 3446". One would probably think
that 3446 is the pid of the process that is being stopped,
but in fact it was the pid of the caller issuing the stop signal.
We remove all superfluous pids from the messages.
Next we have the ll_statahead_thread() and the ll_agl_thread() record
their respective pids in their respective ptlrpc_thread structures.
This allows to print the pid of the thread that we are trying to
stop (which is actually useful info) from other threads, such as those
calling ll_stop_statahead().
Signed-off-by: Christopher J. Morrone <morrone2@llnl.gov>
Reviewed-on: http://review.whamcloud.com/9360
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4624
Reviewed-by: Fan Yong <fan.yong@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The statahead and statahead agl threads blindly set their
thread state to SVC_RUNNING without checking the state first. If, for
instance, another thread sets the state to SVC_STOPPING that
stop signal will now have been lost. Deadlock ensues.
We also partly improve the sai reference counting, because a race exists
where the ll_stop_statahead thread can drop the default reference, and
the statahead thread can exit and drop its reference as well. With no
references on the sai, the final put will poison and free the buffer. The
original do_statahead_enter() function may then continue to access
the buffer after it is freed because it did not take a reference of its
own. We add a local reference to address that.
Signed-off-by: Christopher J. Morrone <morrone2@llnl.gov>
Reviewed-on: http://review.whamcloud.com/9358
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4624
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Fan Yong <fan.yong@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When allocating a reply buffer for the striping information don't
assume the unlikely worst case. Instead, assume the common case
and size the buffer based on the observed default ea/cookie size.
The default size is initialized to a single stripe and allowed to
grow up to an entire page if needed. This means that for smallish
filesystems (less than ~21 OSTs) where the worst case striping
information can fit in a single page there is effectively no
change. Only for larger filesystem will the default be less than
the maximum. This has a number of advantages.
* By limiting the default reply buffer size we avoid always
vmalloc()'ing the buffer because it exceeds four pages in size
and instead kmalloc() it. This prevents the client from
thrashing on the global vmalloc() spin lock.
* A reply buffer of exactly the right size (no larger) is allocated
in the overflow case. These larger reply buffers are still
unlikely to exceed the 16k limit where a vmalloc() will occur.
* Saves memory in the common case. Wide striped files exceeded
the default are expected to be the exception.
The reason this patch works is because the ptlrpc layer is smart
enough to reallocate the reply buffer when an overflow occurs.
Therefore the client doesn't have to drop the incoming reply and
send a new request with a larger reply buffer.
It's also worth mentioning that the reply buffer always contains
a significant amount of extra padding because they are rounded up
to the nearest power of two. This means that even files striped
wider than the default have a good chance of fitting in the
allocated reply buffer.
Also remove client eadatasize check in mdt xattr packing because
as said above client can handle -EOVERFLOW.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-on: http://review.whamcloud.com/6339
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3338
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Bob Glossman <bob.glossman@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
File write before io loop will take lli_trun_sem read semaphore to
protect osc_extent, while after generic_file_aio_write() done, it
could possible need to kill suid or sgid, which will call
ll_setattr_raw() to change the inode's attribute, and it does not
involve size.
So the ll_truc_sem write semaphore should be constrained
around ll_setattr_ost() to not come across the lli_trunc_sem read
semaphore get from the normal file write path.
Signed-off-by: Bobi Jam <bobijam.xu@intel.com>
Reviewed-on: http://review.whamcloud.com/9267
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4627
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The last parameter @datasync of fsync() has following indication:
* if datasync=0, we'd always flush data and metadata
* if datasync=1, we'd always flush data while does not flush modifed
metadata unless that metadata is needed in order to allow a
subsequent data retrieval to be correctly handled. For example, a
change to the file size would require a metadata flush.
Lustre client can not tell the difference easily, and would issue
MDS_SYNC and OST_SYNC in all cases.
Signed-off-by: Bobi Jam <bobijam.xu@intel.com>
Reviewed-on: http://review.whamcloud.com/8684
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4388
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The total size of an HSM archive request may exceed the
desired (LNET) message. When this happens, it can hang
the client and not allow the archive request to succeed.
Before we know the total size of the hsm_action_items, we
need to limit the size of the reguest. Doing this limits
the number of items that can be sent in one archive request.
We'e reduced the size allowed for the user archive request
to MDS_MAXREQSIZE/3.
Signed-off-by: James Nunez <james.a.nunez@intel.com>
Reviewed-on: http://review.whamcloud.com/9393
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4639
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In Lustre 2.4, the flags passed to the memory allocation functions are
translated from CFS enumeration values types to the kernel GFP
values by calling cfs_alloc_flags_to_gfp(). This function adds
__GFP_WAIT to all flags except CFS_ALLOC_ATOMIC. In 2.5, when
the cfs wrappers were dropped, cfs_alloc_flags_to_gfp() was
removed and the CFS_ALLOC_xxxx was simply replaced with __GFP_xxxx.
This means that most memory allocation calls are missing the
__GFP_WAIT flag. The result is that Lustre experiences more ENOMEM
errors, many of which the higher levels of Lustre do not handle
robustly.
Notes GFP_NOFS = __GFP_WAIT | __GFP_IO. So the patch replaces
__GFP_IO with GFP_NOFS.
Patch does not add __GFP_WAIT to GFP_IOFS. GFP_IOFS was not used in
Lustre 2.4 so it has never been used with __GFP_WAIT.
Signed-off-by: Ann Koehler <amk@cray.com>
Signed-off-by: Emoly Liu <emoly.liu@intel.com>
Reviewed-on: http://review.whamcloud.com/9223
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4357
Reviewed-by: Liang Zhen <liang.zhen@intel.com>
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Array 'message_buf' of size 500 may use index value(s) -1
Object 'enc_key.data' was freed at line 164 after being freed
by calling 'free' at line 150. Also there are 3 similar errors
on line(s) 164.
Suspicious dereference of pointer 'vmsg' before NULL check at
line 187. Also there are 2 similar errors on line(s) 196, 205.
Suspicious dereference of pointer 'rmsg' before NULL check at
line 191. Also there are 2 similar errors on line(s) 200, 209.
Signed-off-by: Dmitry Eremin <dmitry.eremin@intel.com>
Reviewed-on: http://review.whamcloud.com/9274
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4629
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If a connection has been stopped with ptlrpc_pinger_del_import() and
marked obd_no_recov, don't reconnect in ptlrpc_disconnect_import() if
the import is already disconnected. Otherwise, without the pinger it
will just wait there indefinitely for the reconnection that will never
happen.
Put the obd_no_recov check inside ptlrpc_import_in_recovery() so that
any threads waiting on the connection to recover would also be broken
out of their sleep if obd_no_recov is set.
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-on: http://review.whamcloud.com/8996
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4413
Reviewed-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Reviewed-by: wangdi <di.wang@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_rtw_free_network23a() and _rtw_free_network23a_nolock23a() are now
identical - one copy should do.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All callers get here by searching for the WPA OUI first, so no point
checking for it once we get here.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The following locations in the code treat the frame control as u16 rather than
the correct __le16:
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:2471:15: expected unsigned short *fctrl
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:2644:15: expected unsigned short *fctrl
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:2849:15: expected unsigned short *fctrl
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:2994:15: expected unsigned short *fctrl
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3308:15: expected unsigned short *fctrl
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3578:15: expected unsigned short *fctrl
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3699:15: expected unsigned short *fctrl
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3821:15: expected unsigned short *fctrl
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3932:15: expected unsigned short *fctrl
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:4004:15: expected unsigned short [usertype] *fctrl
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:4194:15: expected unsigned short *fctrl
drivers/staging/rtl8723au/core/rtw_xmit.c:911:23: expected unsigned short [usertype] *fctrl
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:216:15: expected unsigned short [usertype] *fctrl
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:313:15: expected unsigned short [usertype] *fctrl
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:350:15: expected unsigned short [usertype] *fctrl
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:419:15: expected unsigned short [usertype] *fctrl
drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c:314:15: expected unsigned short *fctrl
drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c:2357:15: expected unsigned short *fctrl
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
struct intf_hdl is now purely a wrapper around struct _io_ops, so we
can get rid of it in the next patch.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This lowers the dependency on struct intf_hdl so we can start getting
rid of if.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
