[LU-7026] Suspicious condition in lfsck_layout_slave_exec_oit

• Status: Resolved
• Project: Lustre
• Type: Bug
• Priority: Minor
• Reporter: Oleg Drokin
• Assignee: nasf (Inactive)
• Resolution: Not a Bug
• Severity: 3

Description

In the master code we have this snippet in lfsck_layout_slave_exec_oit:

        if (oid > lls->lls_lastid) {
                if (!(lo->ll_flags & LF_CRASHED_LASTID)) {
                        /* OFD may create new objects during LFSCK scanning. */
                        rc = lfsck_layout_lastid_reload(env, com, lls);
                        if (unlikely(rc != 0)) {
                                CDEBUG(D_LFSCK, "%s: layout LFSCK failed to "
                                      "reload LAST_ID for "LPX64": rc = %d\n",
                                      lfsck_lfsck2name(com->lc_lfsck),
                                      lls->lls_seq, rc);

                                GOTO(unlock, rc);
                        }

                        if (oid <= lls->lls_lastid ||
                            lo->ll_flags & LF_CRASHED_LASTID)
                                GOTO(unlock, rc = 0);

Note that we are still in the !(lo->ll_flags & LF_CRASHED_LASTID) branch, so why test for it one more time? Was there something else in mind?
I don't see any locking implying a parallel thread set it or any function calls in between that might have changed it too.

Comments

[nasf (Inactive)]

The lfsck_layout_lastid_reload() will be called inside the branch "if (!(lo->ll_flags & LF_CRASHED_LASTID)) {", and may set LF_CRASHED_LASTID.

[Joseph Gmitter (Inactive)]

Fan Yong,
Can you take a look at this issue?
Thanks.
Joe

[Oleg Drokin]

But I do not see lo to be passed into lfsck_layout_lastid_reload(), does it get to it in some other way?

[nasf (Inactive)]

"lo" is one of the member of "com" that is the parameter of lfsck_layout_lastid_reload().