[LU-287] race in glimpse size

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 1.8.6
• Fix Version/s: Lustre 1.8.6
• Type: Bug
• Priority: Minor
• Reporter: Niu Yawei (Inactive)
• Assignee: Niu Yawei (Inactive)
• Resolution: Won't Fix
• Severity: 3

Description

It looks to me there is a race in the size glimpse:

When a client received glimpse callback, it get the lock by ldlm_handle2lock_ns() in ldlm_callback_handler(), and just before calling the ll_glimpse_callback(), this lock is happen to be canceled locally, and the kms is shrinked on cancel, then ll_glimpse_callback() will tell server a wrong size (less than actual size).

Actually, we already have a flag (i.e. LDLM_FL_KMS_IGNORE) to notify that kms is being updated because the lock is being cancelled. We could just check for this flag in ll_glimpse_callback()and return EINVAL to the glimpse. The server should then update the LVB from disk and get the right object size since kms is updated on the client once all dirty data has been pushed to the server already.

Comments

[Jinshan Xiong (Inactive)]

I tend to think this should be a safe race because anyway ldlm_server_glimpse_ast() will update lvb size by calling filter_lvbo_update() with @increase_only setting to 1. That means at the end of filter_intent_policy() the uptodate size will be returned to client eventually. Am I missed anything?

[Niu Yawei (Inactive)]

Hi, Xiong

In such race, glimpse callback will success and the wrong size (less than actual size) will be sent back to server, and on server, ldlm_server_glimpse_ast() calls ldlm_res_lvbo_update(res, req, 1) to update LVB by this wrong size. Please note that the inode size on server hasn't been updated to LVB yet.

[Niu Yawei (Inactive)]

2.x (master code) doesn't have this race, because the kms is always shrinked after ldlm_lock->l_ast_data detached.

[Peter Jones]

As per last comment, not an issue

[Niu Yawei (Inactive)]

It's not an issue for 2.x, the patch for b1_8 is at http://review.whamcloud.com/#change,512 . It's not landed yet.

[Cory Spitz]

Is http://review.whamcloud.com/#change,512 intended to land on b1_8?