LU-4209 utils: fix O_TMPFILE/O_LOV_DELAY_CREATE conflict

In kernel 3.11 O_TMPFILE was introduced, but the open flag value
conflicts with the O_LOV_DELAY_CREATE flag 020000000 added to fix
LU-812 in Lustre 2.4.  O_LOV_DELAY_CREATE allows applications
to defer file layout and object creation from open time (the default)
until it can instead be specified by the application using an ioctl.

Instead of trying to find a non-conflicting O_LOV_DELAY_CREATE flag
or define a Lustre-specific flag that isn't of use to most/any other
filesystems, use (O_NOCTTY|FASYNC) as the new value.  These flags
are not meaningful for newly-created regular files and should be
ok since O_LOV_DELAY_CREATE is only meaningful for new files.

I looked into using O_ACCMODE/FMODE_WRITE_IOCTL, which allows calling
ioctl() on the minimally-opened fd and is close to what is needed,
but that doesn't allow specifying the actual read or write mode for
the file, and fcntl(F_SETFL) doesn't allow O_RDONLY/O_WRONLY/O_RDWR
to be set after the file is opened.

We will keep the 0100000000 flag for backward compatibility until
3.13 is the oldest client kernel that is supported, but drop the
conflicting __O_TMPFILE value of 02000000 since that will cause an
error when running on newer kernels.  The 020000000 has only been
used since Lustre 2.4.0 and always in conjunction with 0100000000,
so any apps that used O_LOV_DELAY_CREATE directly instead of calling
llapi_file_create*() will still work until Linux 3.13 is used.

Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Change-Id: I565f3454616edc60c6acee01034aa5d773500c1e
Reviewed-on: http://review.whamcloud.com/8312
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Bob Glossman <bob.glossman@intel.com>
Reviewed-by: Peng Tao <bergwolf@gmail.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-1267 lfsck: enhance API for MDT-OST consistency

Introduce new dt_object method ::do_declare_attr_get(). The caller
can use such method to notify low layer that "It will need the OST
object attribute very soon, please help to prepare in advance". For
the LFSCK layout consistency verification, the osp_declare_attr_get()
will use UPDATE_OBJ RPC with sub_opcode OBJ_ATTR_GET.

Similarly, another new new dt_object method ::do_declare_xattr_get()
is used to notify low layer that "It will need the OST object xattr
very soon, please help to prepare in advance", which uses UPDATE_OBJ
RPC with sub_opcode OBJ_XATTR_GET.

These idempotent requests can be batched together during the phase
of declaration and sent out via single OUT RPC. It can be shared by
any thread that wants to send idempotent requests to the same OST.

Introduce cache in OSP for remote object's attribute and extended
attribute. Currently, it is mainly used to hold those pre-fetched
OST-objects' kinds of attr/parent FID. But it also can be used by
DNE for other purposes in the future.

For performance, the batched idempotent OUT RPC uses asynchronous
mode. Every sub operation needs to register its own interpterer.
These interpterers will be called one by one after the batched OUT
RPC is replied by the OST.

Implement do_attr_get() against OSP-object for the MDT to get OST
object attribute.

Implement do_xattr_get() against OSP-object for the MDT to get OST
object parent FID attribute.

Implement do_xattr_set() against OSP-object for the MDT to set OST
object parent FID extended attribute.

Some code cleanup and re-organization, such as moving transaction
related code from osp/osp_md_object.c to osp/osp_trans.c, moving
common OUT code from osp/osp_md_object.c to target/out_lib.c.

Originally, only DNE operations will use OUT RPCs, so they use sync
mode transaction. But with LFSCK phase II introduced, sync mode OUT
RPC processing is bad performance. The patch improves related funcs
to allow LFSCK to use async mode transaction for OUT RPC processing,
and DNE related operations still use sync mode transaction.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I4fe99f96ad24d43c1edea3a4a16b7ed206c38c4f
Reviewed-on: http://review.whamcloud.com/7156
Tested-by: Jenkins
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-3289 gss: Shared key mechanism & flavors

Implement security flavors and GSSAPI mechanism to perform shared key
authentication (ski) and encryption (skpi).

Signed-off-by: Andrew Korty <ajk@iu.edu>
Change-Id: I48855c098965fcf527b3949c6dfb181d457b4ca5
Reviewed-on: http://review.whamcloud.com/8629
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Jenkins
Reviewed-by: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Tested-by: Maloo <hpdd-maloo@intel.com>
LU-3373 osd-ldiskfs: export ext4_truncate

The latest kernel removes inode_operations::truncate member, while
SLES11 kernel still keep the member but does not fill that member
for regular file.

This patch exports symbol for ext4_truncate, and calls it directly
in osd_punch() if the regular file inode operation does not fill its
truncate function.

Signed-off-by: Bobi Jam <bobijam.xu@intel.com>
Change-Id: I42477ca3f1a56e9c0870a641431936298f6d71b5
Reviewed-on: http://review.whamcloud.com/9174
Tested-by: Jenkins
Reviewed-by: Bob Glossman <bob.glossman@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Yang Sheng <yang.sheng@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-4612 lvfs: correct call to pop_ctxt

Earlier commit 3e7573cc14a331f01150814495e2345793e22f06 that converted
a call of osd_pop_ctxt() to pop_ctxt() ignored the fact the argument
order of these routines were different. This led to panics.

This patch fixes the pop_ctxt() call by putting the arguments
in the correct order.

Signed-off-by: Bob Glossman <bob.glossman@intel.com>
Change-Id: I352250fe3ed91cb8a23a5b8e88b944dc8309b481
Reviewed-on: http://review.whamcloud.com/9224
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Minh Diep <minh.diep@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>