diff options
| author | Paul Cassella <cassella@cray.com> | 2014-08-15 12:48:08 -0400 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2014-08-17 09:38:42 -0700 |
| commit | 6aa5107281ea065b9a7818a1c640e022d41a421b (patch) | |
| tree | 1a07f0b28a60e52d4c22a267db09d7dac55c362d /include/linux/dynamic_queue_limits.h | |
| parent | 7591805af511b7f71fec87c69a539d1d0cfb93a1 (diff) | |
staging/lustre/llite: Make sure ft_flags is valid
In ll_fault0, the 'fault' struct is mostly cleared before the call to
cl_io_loop, but ft_flags is not reset. It is ordinarily set by
the call to filemap_fault in vvp_io_kernel_fault, but if Lustre
returns before calling filemap_fault, it still has the old value of
ft_flags.
ll_fault0 will then consume the ft_flags field. If it has the
VM_FAULT_RETRY bit set, it will be used as ll_fault0() and
ll_fault()'s return value.
This is a problem when VM_FAULT_RETRY is in ft_flags:
When fault/filemap_fault return with that flag set, they have already
released the mmap semaphore, and do_page_fault does not need to
release it.
Incorrectly returning this flag from ll_fault means mmap_sem
is not upped in the kernel's do_page_fault().
In addition to clearing ft_flags, this patch does not use it unless
it is valid. It's potentially misleading to return ft_flags in
"fault_ret" if ft_flags has not been set by filemap_fault.
This adds clarity, but does not change the current behavior:
When not valid, ft_flags is replaced by fault_ret, which is zero,
as is ft_flags when not set by filemap_fault.
Signed-off-by: Patrick Farrell <paf@cray.com>
Reviewed-on: http://review.whamcloud.com/10956
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5291
Reviewed-by: Bobi Jam <bobijam@gmail.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>
Diffstat (limited to 'include/linux/dynamic_queue_limits.h')
0 files changed, 0 insertions, 0 deletions
