[LU-12755] CPU soft lockup on mkfs.lustre

• Status: Resolved
• Project: Lustre
• Affects Version/s: Upstream
• Fix Version/s: Lustre 2.13.0, Lustre 2.12.3
• Type: Bug
• Priority: Blocker
• Reporter: Tamas Kazinczy
• Assignee: Jian Yu
• Resolution: Fixed
• Labels: hang, mkfs.lustre

Environment

Red Hat 7.7 on VMware
Red Hat 7.7 on HPE ProLiant DL380 Gen10
Red Hat 7.7 on HPE Synergy 480 Gen10

• Epic/Theme: Lustre-2.12.57
• Severity: 3
• Epic: hang, server

Description

After successfully creating packages for Red Hat 7.7

(e.g. lustre-2.12.57_35_g55a7e2d-1.el7.x86_64.rpm)

I get CPU soft lockups when trying to create an MGS with LDISKFS backend.

NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [mkfs.lustre:31220]

More details from log:

Sep  6 10:41:00 mgs1 kernel: Call Trace:Sep  6 10:41:00 mgs1 kernel: [<ffffffff9bd73365>] queued_spin_lock_slowpath+0xb/0xf
Sep  6 10:41:00 mgs1 kernel: [<ffffffff9bd81ad0>] _raw_spin_lock+0x20/0x30
Sep  6 10:41:00 mgs1 kernel: [<ffffffff9b865e2e>] igrab+0x1e/0x60
Sep  6 10:41:00 mgs1 kernel: [<ffffffffc06bd88b>] ldiskfs_quota_off+0x3b/0x130 [ldiskfs]
Sep  6 10:41:00 mgs1 kernel: [<ffffffffc06c091d>] ldiskfs_put_super+0x4d/0x400 [ldiskfs]
Sep  6 10:41:00 mgs1 kernel: [<ffffffff9b84b13d>] generic_shutdown_super+0x6d/0x100
Sep  6 10:41:00 mgs1 kernel: [<ffffffff9b84b5b7>] kill_block_super+0x27/0x70
Sep  6 10:41:00 mgs1 kernel: [<ffffffff9b84b91e>] deactivate_locked_super+0x4e/0x70
Sep  6 10:41:00 mgs1 kernel: [<ffffffff9b84c0a6>] deactivate_super+0x46/0x60
Sep  6 10:41:00 mgs1 kernel: [<ffffffff9b86abff>] cleanup_mnt+0x3f/0x80
Sep  6 10:41:00 mgs1 kernel: [<ffffffff9b86ac92>] __cleanup_mnt+0x12/0x20
Sep  6 10:41:00 mgs1 kernel: [<ffffffff9b6c1c0b>] task_work_run+0xbb/0xe0
Sep  6 10:41:00 mgs1 kernel: [<ffffffff9b62cc65>] do_notify_resume+0xa5/0xc0
Sep  6 10:41:00 mgs1 kernel: [<ffffffff9bd8c23b>] int_signal+0x12/0x17
Sep  6 10:41:00 mgs1 kernel: Code: 47 fe ff ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 66 90 b9 01 00 00 00 8b 17 85 d2 74 0d 83 fa 03 74 08 f3 90 <8b> 17 85 d2 75 f3 89 d0 f0 0f b1 0f 39 c2 75 e3 5d 66 90 c3 0f

I also tried to go for an MDS/MGS pair on the DL380 but mkfs.lustre got stuck the same way 

as seen on VMware.

Comments

[Patrick Farrell (Inactive)]

Tamas,

Are you able to provide dmesg from your node?  (You can attach a file here)

Also, what version of e2fsprogs are you using?  (output of rpm -qa | grep e2fsprogs would work for this)

If possible, it would also be nice to get this:

After gathering dmesg, if you can also (while the mkfs is hung) do:

echo t > /proc/sysrq-trigger 

Then gather dmesg again and attach that as well. (Gathering dmesg twice is necessary because this can produce so much output that it will overwrite your existing dmesg.)

[Peter Jones]

Furthermore, I would suggest that you focus on the tip of b2_12 rather than using master in your tests. The intention is to add support for RHEL 7.7 with the upcoming 2.12.3 release and the current b2_12 is close to the release version.

[Tamas Kazinczy]

We have:

e2fsprogs.x86_64                 1.45.2.wc1-0.el7                  @e2fsprogs-wc

 

I've just attached dmesg outputs.

[Aurelien Degremont (Inactive)]

Just to confirm I also hit the same issue using the usual Lustre development environment.

$ git reflog
219c519 HEAD@{0}: clone: from https://review.whamcloud.com/fs/lustre-release
$ rpm -q e2fsprogs
e2fsprogs-1.45.2.wc1-0.el7.x86_64
$ uname -r
3.10.0-1062.el7.x86_64

 I'm just using RHEL 7.7

git cloned lustre master branch
sh ./autogen.sh
./configure
make
REFORMAT=: ./lustre/tests/llmount.sh

[Jian Yu]

Hi Tamas and Aurelien,

I didn't hit the above issue after building Lustre 2.12.57 from source codes on a VirtualBox RHEL 7.7 vm against kernel 3.10.0-1062.el7.

Before compiling Lustre codes, did you patch the kernel?

[Jian Yu]

FYI, here are the steps I performed on a RHEL 7.7 vm:
Build kernel:

git clone git://git.whamcloud.com/fs/lustre-release.git
cd lustre-release/
sh ./autogen.sh

cd
mkdir -p kernel/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
cd kernel
echo '%_topdir %(echo $HOME)/kernel/rpmbuild' > ~/.rpmmacros
rpm -ivh /root/kernelrpm/kernel-3.10.0-1062.el7.src.rpm
cd /root/kernel/rpmbuild/
rpmbuild -bp --target=`uname -m` ./SPECS/kernel.spec

cd /root/lustre-release/lustre/kernel_patches/series/
for patch in $(<"3.10-rhel7.7.series"); do patch_file="$HOME/lustre-release/lustre/kernel_patches/patches/${patch}"; cat "${patch_file}" >> "$HOME/lustre-kernel-x86_64-lustre.patch"; done
cp ~/lustre-kernel-x86_64-lustre.patch ~/kernel/rpmbuild/SOURCES/patch-3.10.0-lustre.patch

sed -i.inst -e '/find $RPM_BUILD_ROOT\/lib\/modules\/$KernelVer/a\
    cp -a fs/ext3/* $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/fs/ext3 \
    cp -a fs/ext4/* $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/fs/ext4' \
-e '/^# empty final patch to facilitate testing of kernel patches/i\
Patch99995: patch-%{version}-lustre.patch' \
-e '/^ApplyOptionalPatch linux-kernel-test.patch/i\
ApplyOptionalPatch patch-%{version}-lustre.patch' \
-e '/^%define listnewconfig_fail 1/s/1/0/' \
~/kernel/rpmbuild/SPECS/kernel.spec

cd
echo '# x86_64' > ~/kernel/rpmbuild/SOURCES/kernel-3.10.0-x86_64.config
cat ~/lustre-release/lustre/kernel_patches/kernel_configs/kernel-3.10.0-3.10-rhel7.7-x86_64.config >> ~/kernel/rpmbuild/SOURCES/kernel-3.10.0-x86_64.config

cd ~/kernel/rpmbuild
buildid="_lustre"
rpmbuild -ba --with firmware --target x86_64 --with baseonly --without kabichk --define "buildid ${buildid}" ~/kernel/rpmbuild/SPECS/kernel.spec

cd /root/kernel/rpmbuild/RPMS/x86_64/
rpm -ivh kernel-3.10.0-1062.el7_lustre.x86_64.rpm kernel-devel-3.10.0-1062.el7_lustre.x86_64.rpm kernel-headers-3.10.0-1062.el7_lustre.x86_64.rpm kernel-tools-3.10.0-1062.el7_lustre.x86_64.rpm kernel-tools-libs-3.10.0-1062.el7_lustre.x86_64.rpm --force
sync
shutdown -r 0

Build Lustre:

cd lustre-release/
./configure --with-linux=/root/kernel/rpmbuild/BUILD/kernel-3.10.0-1062.el7/linux-3.10.0-1062.el7_lustre.x86_64/
make

Here is the wiki page for compiling Lustre: http://wiki.lustre.org/Compiling_Lustre.

[Aurelien Degremont (Inactive)]

Hi Jian,

No, I did not patched the kernel but I though this is needed only when using project quota feature?

I just realized I downgraded my kernel to 3.10.0-957.10.1.el7_lustre, which is the patched version from Whamcloud. So it seems really related to the kernel patches.

[Tamas Kazinczy]

Hey Jian,

I forgot to tell that I'd like to have patchless servers.

[Jian Yu]

Thank you Aurelien and Tamas for the info.
I can reproduce the issue with patchless server build. With vfs-project-quotas-rhel7.patch applied to kernel, the issue disappeared. I'm looking into the related ldiskfs patches.

[Andreas Dilger]

degremoa, are you also seeing the hang with the same stack trace (stuck on a spinlock in the quota inode during unmount)? While it is a bit confusing, mkfs.lustre is mounting the filesystem internally to create Lustre configuration files.

I'd guess that there is something wrong with the quota inodes stored in the superblock, like they are not initialized, or the spinlock is not initialized, which only shows up because we are formatting then mounting and unmounting the filesystem so quickly.

[Jian Yu]

Hi Andreas,
While running mkfs.lustre, ldiskfs_write_ldd() mounted the device temporarily to write CONFIGS/mountdata. The hang occurred while unmounting the device.
I compared ldiskfs patch ext4-projid-ignore-maxquotas.patch and kernels for RHEL 7.7 and 7.6, and found the following ext4_quota_off_umount() was added into ext4_put_super() for RHEL 7.7 kernel 3.10.0-1062.el7:

ext4_quota_off_umount() and ext4_put_super()

#ifdef CONFIG_QUOTA
static int ext4_quota_off(struct super_block *sb, int type);

static inline void ext4_quota_off_umount(struct super_block *sb)
{
        int type;

        /* Use our quota_off function to clear inode flags etc. */
        for (type = 0; type < MAXQUOTAS; type++)
                ext4_quota_off(sb, type);
}
#else
static inline void ext4_quota_off_umount(struct super_block *sb)
{
}
#endif

static void ext4_put_super(struct super_block *sb)
{
        struct ext4_sb_info *sbi = EXT4_SB(sb);
        struct ext4_super_block *es = sbi->s_es;
        int aborted = 0;
        int i, err;

        ext4_unregister_li_request(sb);
        ext4_quota_off_umount(sb);
        <~snip~>
}

inode_lock(inode) and inode_unlock(inode) were also added into ext4_quota_off() for RHEL 7.7 kernel.

[Andreas Dilger]

Can you please check the upstream kernel to see if there is some additional fix to this code? If yes, then it should be backported tinour ldiskfs series, and also reported to RH.

[Jian Yu]

Sure, Andreas. Let me do this.

[Jian Yu]

Hi Andreas,
The ext4_quota_off_umount() function and ext4_quota_on/off() changes were added by the following Linux kernel commit:

commit 957153fce8d226612de05938ca18101b7d608328
Author: Jan Kara <[e-mail]>
Date:   Thu Apr 6 15:40:06 2017 +0200

    ext4: Set flags on quota files directly
    
    Currently immutable and noatime flags on quota files are set by quota
    code which requires us to copy inode->i_flags to our on disk version of
    quota flags in GETFLAGS ioctl and ext4_do_update_inode(). Move to
    setting / clearing these on-disk flags directly to save that copying.
    
    Signed-off-by: Jan Kara <[e-mail]>

However after that, there is no additional fix related to the issue in this ticket.

I'm wondering why after applying vfs-project-quotas-rhel7.patch, the issue disappeared.

[Aurelien Degremont (Inactive)]

Andreas, for some unknown reason my system keeps crashing when I try to reproduce this issue. Kernel crashes instead of hitting this during MDT formatting.

But I think you got everything you need for this problem anyway, no?

[Andreas Dilger]

yujian, it looks like this may indeed be related to the project quota patch.

With vfs-project-quotas-rhel7.patch applied the kernel properly handles the project quota type (index 2, i.e. the 3rd quota type), and without it, the RHEL7 kernel doesn't handle this quota type. In ldiskfs, we need to make sure that the loop in ext4_quota_off_umount() is limiting the LDISKFS_MAXQUOTAS loop to the kernel MAXQUOTAS. Otherwise, it is trying to dereference sb->s_inode[2] which is not an inode at all, just random memory.

degremoa, I think we are good. It shouldn't be too hard to make a patch now that we (likely) know what the problem is.

[Andreas Dilger]

It looks like in ldiskfs/kernel_patches/patches/rhel7/ext4-projid-feature-support.patch it should check how many quotas that the kernel supports:

 /* Number of quota types we support */
+#if MAXQUOTAS > 2
+#define EXT4_MAXQUOTAS 3
+#else
 #define EXT4_MAXQUOTAS 2
+#endif

or something similar, so that it doesn't try to use project quotas on an unpatched RHEL7 kernel.

[Jian Yu]

Thank you very much, Andreas. Let me push a patch and verify it.

[Andreas Dilger]

Looking into this a bit more (c.f. LU-20), it seems that we may want the same code to module with both a patched and unpatched kernel, so it is probably better to keep EXT4_MAXQUOTAS=3 and decide whether to disable the project quota at unmount during runtime rather than at compile time. Something similar to how quota is enabled for the various types:

@@ -819,7 +819,7 @@ static inline void ext4_quota_off_umount
        int type;
 
        /* Use our quota_off function to clear inode flags etc. */
-       for (type = 0; type < MAXQUOTAS; type++)
-                ext4_quota_off(sb, type);
+       for (type = 0; type < EXT4_MAXQUOTAS; type++)
+               if (EXT4_SB(sb)->s_qf_names[i])
+                       ext4_quota_off(sb, type);
 }

The existing check "if (!inode0" inside ext4_quota_off() is incorrect in this case because sb_dqopt(sb)->files[type] is located in the kernel superblock, which was not compiled to have enough space for the project quota. It may be that ext4_orphan_cleanup() needs a similar change to check EXT4_SB(sb)->s_qf_names[i] instead, since that is located inside the ext4/ldiskfs module and will be self-consistent.

[Gerrit Updater]

Jian Yu ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36203
Subject: LU-12755 ldiskfs: check s_qf_names in ext4_quota_off_umount()
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: fff55938f6266cdd9d201dae950079371a6fde3b

[Peter Jones]

kazinczy and/or degremoa can you verify whether this fix works for you?

[Jian Yu]

I just got the test result that the patch fixed the spinlock issue but hit another issue:

Kernel error detected: [   64.991808] VFS: Busy inodes after unmount of dm-0. Self-destruct in 5 seconds.  Have a nice day...

[Wang Shilong (Inactive)]

Apologies, I missed this important ticket.

Jian Yu,

Would you collect dumpe2fs -h /dev/dm-0 output?

I guess we might load project inode but the logic is we did not iput it caused the problem, would you try following parts to see if it could fix above buys inode problem:

[root@server ext4]# git diff super.c
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index ca8b50c8..e3fccb79 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -5624,7 +5624,7 @@ static int ext4_enable_quotas(struct super_block *sb)
 
        sb_dqopt(sb)->flags |= DQUOT_QUOTA_SYS_FILE;
        for (type = 0; type < EXT4_MAXQUOTAS; type++) {
-               if (qf_inums[type]) {
+               if (qf_inums[type] && type < MAXQUOTAS) {
                        err = ext4_quota_enable(sb, type, QFMT_VFS_V1,
                                                DQUOT_USAGE_ENABLED);
                        if (err) {

Andreas, any reasons that why we did not use first suggested way:

 /* Number of quota types we support */
+#if MAXQUOTAS > 2
+#define EXT4_MAXQUOTAS 3
+#else
 #define EXT4_MAXQUOTAS 2
+#endif

This looks much safe fix.

[Jian Yu]

Thank you, Shilong. Let me try the above changes.

[Andreas Dilger]

Shilong, the reason we don't use the static MAXQUOTAS limit at compile time is to allow using the same ldiskfs and osd-ldiskfs module on both patched and unpatched kernels.

[Jian Yu]

With the "qf_inums[type] && type < MAXQUOTAS" change applied, the following failure still occurred:

Kernel error detected: [   67.386709] VFS: Busy inodes after unmount of dm-0. Self-destruct in 5 seconds.  Have a nice day...

[Wang Shilong (Inactive)]

Let me setup an environment and try locally.

[Andreas Dilger]

Jian, can you please push a separate patch with the "simple" version of the patch, which limits EXT4_MAX_QUOTAS to the kernel MAXQUOTAS value, if smaller. That will at least tell us if this is the source of the problem.

[Jian Yu]

Sure, Andreas.

[Gerrit Updater]

Jian Yu ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36241
Subject: LU-12755 ldiskfs: limit EXT4_MAXQUOTAS to MAXQUOTAS
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: b0965235b20ff03c55eaeae6d917d6e3f11968f7

[Wang Shilong (Inactive)]

OK, the problem is that we leaked USR and Group inode, comments on first patch, I agreed we'd better use first patch.

[Wang Shilong (Inactive)]

Also it will be interesting that with project quota enabled but unpatched kernel used, I just tested it will fail:

  642.115121]  [<ffffffff93379262>] dump_stack+0x19/0x1b
[  642.115888]  [<ffffffffc091606a>] ldiskfs_quota_enable+0x10a/0x120 [ldiskfs]
[  642.116934]  [<ffffffffc091807b>] ldiskfs_enable_quotas+0x9b/0x110 [ldiskfs]
[  642.117962]  [<ffffffffc091c490>] ldiskfs_fill_super+0x2e60/0x2e80 [ldiskfs]
[  642.118993]  [<ffffffff92e4c893>] mount_bdev+0x1b3/0x1f0
[  642.119790]  [<ffffffffc0919630>] ? ldiskfs_calculate_overhead+0x430/0x430 [ldiskfs]
[  642.120951]  [<ffffffffc0913605>] ldiskfs_mount+0x15/0x20 [ldiskfs]
[  642.121874]  [<ffffffff92e4d1fe>] mount_fs+0x3e/0x1b0
[  642.122624]  [<ffffffff92de1035>] ? __alloc_percpu+0x15/0x20
[  642.123409]  [<ffffffff92e6b377>] vfs_kern_mount+0x67/0x110
[  642.124225]  [<ffffffff92e6dacf>] do_mount+0x1ef/0xce0
[  642.124983]  [<ffffffff92e4521a>] ? __check_object_size+0x1ca/0x250
[  642.125919]  [<ffffffff92ddbe7f>] ? memdup_user+0x4f/0x80
[  642.126723]  [<ffffffff92e6e903>] SyS_mount+0x83/0xd0
[  642.127521]  [<ffffffff9338bede>] system_call_fastpath+0x25/0x2a

I think we also need this extra fix for that:

[root@server ext4]# git diff super.c
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index ca8b50c8..e3fccb79 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -5624,7 +5624,7 @@ static int ext4_enable_quotas(struct super_block *sb)
 
        sb_dqopt(sb)->flags |= DQUOT_QUOTA_SYS_FILE;
        for (type = 0; type < EXT4_MAXQUOTAS; type++) {
-               if (qf_inums[type]) {
+               if (qf_inums[type] && type < MAXQUOTAS) {
                        err = ext4_quota_enable(sb, type, QFMT_VFS_V1,
                                                DQUOT_USAGE_ENABLED);
                        if (err) {

[Andreas Dilger]

I think we also need this extra fix for that:

[root@server ext4]# git diff super.c

@@ -5624,7 +5624,7 @@ static int ext4_enable_quotas(struct super_block *sb)
 
        sb_dqopt(sb)->flags |= DQUOT_QUOTA_SYS_FILE;
        for (type = 0; type < EXT4_MAXQUOTAS; type++) {
-               if (qf_inums[type]) {
+               if (qf_inums[type] && type < MAXQUOTAS) {
                        err = ext4_quota_enable(sb, type, QFMT_VFS_V1,
                                                DQUOT_USAGE_ENABLED);
                        if (err) {

It isn't clear if this will fix all of the problems, since it is taking the MAXQUOTAS value from the kernel at build time, not at runtime. Since we always build against a patched kernel with MAXQUOTAS=3, it wouldn't restrict the code. It probably would help for the case of building against a patched kernel.

[Wang Shilong (Inactive)]

Yup, I was thinking that to make us ldiskfs.ko module works for both patched and unpatched kernel:

using following way to check:

bool is_proj_supported_by_kernel(struct super_block *sb)
{
    return (sizeof(sb_dqopt(sb)->info) / sizeof(struct mem_dqinfo)) > PRJQUOTA;
}

[Andreas Dilger]

This will still return the size of the structures matching the kernel that ldiskfs was built against, not necessarily the kernel that the module is loaded with.

We would need that function to be exported by the running kernel, which would mean to patch the kernel (obviously not possible for the unpatched kernel, and very unlikely to get upstream).

Instead, we need to find something that is exported from the running kernel that gives us information about whether it supports project quotas.

[Wang Shilong (Inactive)]

Hmm, you are right..

But haven't found a way to do that since Kernel mostly use static value MAXQUOTAS..

[Li Xi]

I am wondering whether the following way would help use to get the MAXQUOTAS of the running kernel (using a tricky way):

1) We call dquot_initialize(inode) in OSD/ldiskfs.
2) __dquot_initialize() calls inode->i_sb->dq_op->get_projid()
3) We patch ldiskfs to change ext4_get_projid(). In ext4_get_projid(), it set a static flag to show that the kernel actually supports PRJQUOTA.

However, dquot_initialize() depends on ext4_enable_quotas? So might not be workable...

[Wang Shilong (Inactive)]

In the mount phase, ROOT inode will call dquot_initialize() first time but at that time ext4_enable_quotas() haven't been called, and unfortunately we also need check whether kernel support PRJQUOTA inside ext4_enable_quotas().....

So this way won't work..

[Wang Shilong (Inactive)]

unfortunately it looks hard to make it work ideally, we coud not be blocked at this, at least we need fix common case, how about
we add some warning messages during mount time?

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index ca8b50c8..cddf6595 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4489,6 +4489,13 @@ no_journal:
        ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10);
 
        kfree(orig_data);
+#ifdef  HAVE_PROJECT_QUOTA
+       ext4_msg(sb, KERN_WARNING, 
+               "ext4 module compiled with patched kernel won't work on unpatched kernel");
+#else
+       ext4_msg(sb, KERN_WARNING, 
+               "ext4 module compiled with unpatched kernel won't work on patched kernel");
+#endif
        return 0;

Mark it as a known issue, at least Administrator knows this issue.

[Wang Shilong (Inactive)]

The good new is this issue won't exist for RHEL8 and later kernels though..

[Li Xi]

Instead of printing an error, returning error seems better. It will prevent any future problem.

[Li Xi]

In the mount phase, ROOT inode will call dquot_initialize() first time but at that time ext4_enable_quotas() haven't been called, and unfortunately we also need check whether kernel support PRJQUOTA inside ext4_enable_quotas().....

I think we can ext4_enable_quotas() first on group quota and user quota. And then set the flag of sb_has_quota_active(PROJQUOTA) temporarily. And then call dquot_initialize() to check whether MAXQUOTAS == 3.

[Wang Shilong (Inactive)]

The tricky way seems work with limited testing, Yu Jian could you continue some testing on refreshed patch:

1) Built and installed. ldiskfs on patched kernel and then switch it to unpatched kernel.
2) Built and installed ldiskfs on unpatched kernel and then switch it to patched kernel.

To make sure mount and umount Lustre works.

[Jian Yu]

Sure, Shilong.

[Li Xi]

Shilong, I assume you mean the updated patch https://review.whamcloud.com/#/c/36203/

Any reason why ext4_get_projid() is called before ext4_enable_quotas()? I thought ext4_enable_quotas() is always called before any one calls ext4_get_projid().

[Wang Shilong (Inactive)]

Li Xi,

I walkrounded that issue by set PROJ active flag temporariy, and then call dquot_initialize() to call ext4_get_projid().
I just tested fixed version, it seems work:

+	sb_dqopt(sb)->flags |= dquot_state_flag(DQUOT_USAGE_ENABLED, PRJQUOTA);
+	dquot_initialize(root);
+	sb_dqopt(sb)->flags &= ~dquot_state_flag(DQUOT_USAGE_ENABLED, PRJQUOTA);

By adding some printk debug, it seems detection works.

[Gerrit Updater]

Jian Yu ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36270
Subject: LU-12755 ldiskfs: fix project quota unpon unpatched kernel
Project: fs/lustre-release
Branch: b2_12
Current Patch Set: 1
Commit: e56b4bc0970275ce6413883794bd52d2dfa7b164

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/36203/
Subject: LU-12755 ldiskfs: fix project quota unpon unpatched kernel
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: d780f15a2d63c8bde5ae6345aed85b4b44904fb5

[Peter Jones]

Landed for 2.13

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/36270/
Subject: LU-12755 ldiskfs: fix project quota unpon unpatched kernel
Project: fs/lustre-release
Branch: b2_12
Current Patch Set:
Commit: 820e374624a584ec0c0a326ec96bf0abeb50cf40

[Tamas Kazinczy]

I can confirm that mkfs.lustre for patchless LDISKFS from b2_12 works fine for me now.

[Peter Jones]

Great. Thanks for confirming kazinczy