I found a bug with 32-bIt ARM client at mount due to the last patch landed before 2.12.0. Will submit a fix, but I don't think it relates to this.
Can people try https://review.whamcloud.com/#/c/34714. This seems to resolve these problems.
After some input from Neil Brown I have gotten patch https://review.whamcloud.com/#/c/34714. ARM ldiskfs servers should mount with new issues.
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/34714/
Subject: LU-11832 ldiskfs: properly handle VFS parallel locking
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 41dd393ffbd94877dad411cfd66105379258b579
Landed for 2.14
After this patch Lustre build is broken for me. I don't know why defines HAVE_DIR_CONTEXT were removed in such way, These kind of kernel differences were handled at a configure way usually.
/home/test/lustre-release/lustre/osd-ldiskfs/osd_handler.c:859:21: error: field ‘ctx’ has incomplete type
struct dir_context ctx;
^
/home/test/lustre-release/lustre/osd-ldiskfs/osd_handler.c: In function ‘osd_check_lmv’:
/home/test/lustre-release/lustre/osd-ldiskfs/osd_handler.c:965:3: error: field name not in record or union initializer
.ctx.actor = osd_stripe_dir_filldir,
^
/home/test/lustre-release/lustre/osd-ldiskfs/osd_handler.c:965:3: error: (near initialization for ‘oclb’)
/home/test/lustre-release/lustre/osd-ldiskfs/osd_handler.c:1024:3: error: implicit declaration of function ‘iterate_dir’ [-Werror=implicit-function-declaration]
rc = iterate_dir(filp, &oclb.ctx);
^
/home/test/lustre-release/lustre/osd-ldiskfs/osd_handler.c: At top level:
/home/test/lustre-release/lustre/osd-ldiskfs/osd_handler.c:6520:21: error: field ‘ctx’ has incomplete type
struct dir_context ctx;
^
/home/test/lustre-release/lustre/osd-ldiskfs/osd_handler.c: In function ‘osd_ldiskfs_it_fill’:
/home/test/lustre-release/lustre/osd-ldiskfs/osd_handler.c:6610:3: error: field name not in record or union initializer
.ctx.actor = osd_ldiskfs_filldir,
^
/home/test/lustre-release/lustre/osd-ldiskfs/osd_handler.c:6610:3: error: (near initialization for ‘buf’)
@James A Simmons could you clarify this dirty hack ?
@Peter Jones, why building didn't find this error during gerrit integration process?
If you look at commit 41dd393ffbd94877dad411cfd66105379258b579 it explains in detail why this was done. What kernel are you using? Can you point me to the source. interate_dir() / struct dir_context is used everywhere in the kernel so this shouldn't be broken.
aboyko you must be building in a different way than we do in the standard CI system - builds have been continuing to build ok over the past couple of weeks. Once the difference is understood, it would be possible for you to setup build slaves matching your desired configuration in a manner that passes results back into Gerrit - that way situations like this can be avoided.
Well, I have a slightly older kernel than which_patch has, 3.10-693.21, and Lustre works perfect until this fix. configure process allows to support a wide range of kernel version and I'm a bit surprised that this strict dependence was made.
Went to RHEL web site to down the source and now it redirects you to their latest RHEL7 kernels 
I suspect this is a older kernel issue. Currently I see in lustre/Changelog that the oldest kernel officially supported is RHEL7.5. Also for the optional kernel patches they only go back to RHEL7.5. I have a local patch that removes all pre-RHEL7.5 ldiskfs patches but haven't pushed it yet since its unclear if we need to support all RHEL7 versions.
Personally I'm not a fan of support older than RHEL7.5 kernels for several reasons. First is the any kernels before RHEL7.4 don't support the spectra fixes for sites concerned about security. I also remember issues with a broken mlx stack and another issue with the rw_sem being broken in an earlier RHEL version. Its up to Peter what is supported.
From the discussions in the LWG to date, the plan for 2.14 is for RHEL8.1 to be the primary distro and I would expect only the latest RHEL7 kernel to also be tested. Anything older is exposed to these kind of failures cropping up from time to time. There are definitely options as a community to expand what is being tested but I think that it would be better to continue any such discussions in the LWG forum to allow broader participation.