[LU-5178] object leak in mdt_rename_sanity()

• Status: Closed
• Project: Lustre
• Affects Version/s: Lustre 2.6.0
• Fix Version/s: Lustre 2.6.0
• Type: Bug
• Priority: Minor
• Reporter: John Hammond
• Assignee: WC Triage
• Resolution: Fixed
• Labels: mdt
• Severity: 3

Description

This would be addressed by Vitaly's http://review.whamcloud.com/#/c/10484/

static int mdt_rename_sanity(struct mdt_thread_info *info,
                             const struct lu_fid *dir_fid,
                             const struct lu_fid *fid)
{
        struct mdt_object *dst;
        struct lu_fid dst_fid = *dir_fid;
        int rc = 0;
        ENTRY;

        /* If the source and target are in the same directory, they can not               
         * be parent/child relationship, so subdir check is not needed */
        if (lu_fid_eq(dir_fid, fid))
                return 0;

        do {
                LASSERT(fid_is_sane(&dst_fid));
                dst = mdt_object_find(info->mti_env, info->mti_mdt, &dst_fid);
                if (!IS_ERR(dst)) {
                        /* XXX: this object might not be protected by LDLM lock
                         * here, (see mdt_rename_parents_lock), but LOHA_EXISTS
                         * will not change once it is being set, but LFSCK might
                         * change this later.(LU-5069) */
                        if (!mdt_object_exists(dst))
                                RETURN(-ESTALE);

Issue Links

• is duplicated by: LU-4725 wrong lock ordering in rename leads t...
• is related to: LU-4725 wrong lock ordering in rename leads t...
• is related to: LU-5177 object leak in mdt_open_by_fid_lock()

Comments

[John Hammond]

This is not a duplicate of LU-4725. The two issues have completely different descriptions. If the patch from LU-4725 lands and fixes this issue then fine close this as fixed. If that patch doesn't land then we still have this issue.

[John Hammond]

Fixed by http://review.whamcloud.com/#/c/10484/.