[LU-3228] fc18: sanity test_183: @@@@@@ FAIL: test_183 failed with 1 Created: 25/Apr/13 Updated: 01/Jul/14 Resolved: 25/Jan/14 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.4.0, Lustre 2.4.1 |
| Fix Version/s: | Lustre 2.4.0 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Minh Diep | Assignee: | Jian Yu |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | yuc2 | ||
| Issue Links: |
|
||||||||||||||||
| Severity: | 3 | ||||||||||||||||
| Rank (Obsolete): | 7889 | ||||||||||||||||
| Description |
|
== sanity test 183: No crash or request leak in case of strange dispositions ========================= 20:23:20 (1366860200) https://maloo.whamcloud.com/test_sets/83b66856-ad8e-11e2-bbea-52540035b04c |
| Comments |
| Comment by Peter Jones [ 25/Apr/13 ] |
|
Yu, Jian Could you please look into this one? Thanks Peter |
| Comment by Jian Yu [ 22/May/13 ] |
|
Lustre Branch: master (tag 2.4.50) The sanity test 183 was added for It passed on RHEL6.4 client: but failed on FC18 client: After fail_loc was set to 0 on MDS, the touch operation failed on client node: fail_loc=0 touch: cannot touch '/mnt/lustre/d0.sanity/d183/f.sanity.183': No such file or directory Debug log on client node showed that: 00000001:00000001:0.0:1369222356.453337:0:8789:0:(debug.c:444:libcfs_debug_mark_buffer()) *************************************************** The ll_atomic_open() failed with 1, which was returned from finish_no_open(). I'm still digging. |
| Comment by Jian Yu [ 09/Aug/13 ] |
|
Lustre Branch: b2_4 The failure occurred regularly on Lustre b2_4 branch on FC18 client: |
| Comment by Jian Yu [ 04/Sep/13 ] |
|
Lustre build: http://build.whamcloud.com/job/lustre-b2_4/44/ (2.4.1 RC1) sanity test 183 hit the same failure: |
| Comment by Oleg Drokin [ 24/Jan/14 ] |
|
After failing like this, next unmount, that happens to be in test 223 crashes with reference count assertion. This bug is also observed in mainline kernel. |
| Comment by Oleg Drokin [ 25/Jan/14 ] |
|
Apparently this bug was introduced by commit 784cd144103871bd421c139c09bfbf4d5d29ca08 coming from patch http://review.whamcloud.com/4387 to support atomic_open. The problematic hunk is this: @@ -438,13 +443,21 @@ int ll_lookup_it_finish(struct ptlrpc_request *request,
Also see bug 7198. */
}
- *de = ll_splice_alias(inode, *de);
+ /* Only hash *de if it is unhashed (new dentry).
+ * Atoimc_open may passin hashed dentries for open.
+ */
+ if (d_unhashed(*de))
+ *de = ll_splice_alias(inode, *de);
When this hits (as in, dentry IS hashed), two things happen: |
| Comment by Oleg Drokin [ 25/Jan/14 ] |
|
Apparently this was fixed by http://review.whamcloud.com/8110 |
| Comment by Oleg Drokin [ 25/Jan/14 ] |
|
I verified that the patch in http://review.whamcloud.com/8110 fixes the issue. |