[LU-216] Fix fiemap locking issue in 2.6.32 kernels Created: 15/Apr/11 Updated: 10/Apr/12 Resolved: 10/Apr/12 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.1.0, Lustre 1.8.6 |
| Fix Version/s: | Lustre 2.2.0, Lustre 1.8.6 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Cory Spitz | Assignee: | Zhenyu Xu |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Severity: | 3 |
| Bugzilla ID: | 23,780 |
| Rank (Obsolete): | 5009 |
| Description |
|
The patch from Lustre Bugzilla 23780 attachment 31890 was added for RHEL6 support with git commit e550abd05cf7ffddaedbef996be1baaae0912b4a, but a better long term fix is needed. Johann L. writes in Lustre Bugzilla 23780 comment #28: and follows up in Lustre Bugzilla 23780 comment #34: b1_8 also still requires the fix for SLES 11 SP1. Info required for matching: sanity-benchmark test_fsx fsx |
| Comments |
| Comment by Zhenyu Xu [ 15/Apr/11 ] |
|
master branch patch at http://review.whamcloud.com/491 For ext4 based ldiskfs module, ldiskfs_ext_new_extent_cb() get called w/o extent tree protection which opens extent change race window, this patch is to make sure the extent tree is not changed during the race window. |
| Comment by Zhenyu Xu [ 20/Apr/11 ] |
|
b1_8 only need get rid of ext4-bug23780-remove-i_data_sem-from-walk_space.patch in sles11 series. |
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Build Master (Inactive) [ 20/Apr/11 ] |
|
Integrated in Oleg Drokin : 0fc3c3d84b08a48e2eac04785bd3b3ac1f1ad8eb
|
| Comment by Jian Yu [ 11/May/11 ] |
|
Since |
| Comment by Zhenyu Xu [ 11/May/11 ] |
|
http://review.whamcloud.com/447 is for b1_8 branch. |
| Comment by Build Master (Inactive) [ 17/May/11 ] |
|
Integrated in Johann Lombardi : de95114f8b9f04ef713020b60bfee802316701af
|
| Comment by Build Master (Inactive) [ 17/May/11 ] |
|
Integrated in Johann Lombardi : de95114f8b9f04ef713020b60bfee802316701af
|
| Comment by Build Master (Inactive) [ 17/May/11 ] |
|
Integrated in Johann Lombardi : de95114f8b9f04ef713020b60bfee802316701af
|
| Comment by Build Master (Inactive) [ 17/May/11 ] |
|
Integrated in Johann Lombardi : de95114f8b9f04ef713020b60bfee802316701af
|
| Comment by Build Master (Inactive) [ 17/May/11 ] |
|
Integrated in Johann Lombardi : de95114f8b9f04ef713020b60bfee802316701af
|
| Comment by Build Master (Inactive) [ 17/May/11 ] |
|
Integrated in Johann Lombardi : de95114f8b9f04ef713020b60bfee802316701af
|
| Comment by Build Master (Inactive) [ 17/May/11 ] |
|
Integrated in Johann Lombardi : de95114f8b9f04ef713020b60bfee802316701af
|
| Comment by Build Master (Inactive) [ 17/May/11 ] |
|
Integrated in Johann Lombardi : de95114f8b9f04ef713020b60bfee802316701af
|
| Comment by Build Master (Inactive) [ 17/May/11 ] |
|
Integrated in Johann Lombardi : de95114f8b9f04ef713020b60bfee802316701af
|
| Comment by Build Master (Inactive) [ 17/May/11 ] |
|
Integrated in Johann Lombardi : de95114f8b9f04ef713020b60bfee802316701af
|
| Comment by Build Master (Inactive) [ 17/May/11 ] |
|
Integrated in Johann Lombardi : de95114f8b9f04ef713020b60bfee802316701af
|
| Comment by Build Master (Inactive) [ 20/May/11 ] |
|
Integrated in Johann Lombardi : 4c2ea168bb65cb0abe1182e319e650ea3a58da10
|
| Comment by Build Master (Inactive) [ 20/May/11 ] |
|
Integrated in Johann Lombardi : 4c2ea168bb65cb0abe1182e319e650ea3a58da10
|
| Comment by Build Master (Inactive) [ 20/May/11 ] |
|
Integrated in Johann Lombardi : 4c2ea168bb65cb0abe1182e319e650ea3a58da10
|
| Comment by Build Master (Inactive) [ 20/May/11 ] |
|
Integrated in Johann Lombardi : 4c2ea168bb65cb0abe1182e319e650ea3a58da10
|
| Comment by Build Master (Inactive) [ 20/May/11 ] |
|
Integrated in Johann Lombardi : 4c2ea168bb65cb0abe1182e319e650ea3a58da10
|
| Comment by Build Master (Inactive) [ 20/May/11 ] |
|
Integrated in Johann Lombardi : 4c2ea168bb65cb0abe1182e319e650ea3a58da10
|
| Comment by Build Master (Inactive) [ 20/May/11 ] |
|
Integrated in Johann Lombardi : 4c2ea168bb65cb0abe1182e319e650ea3a58da10
|
| Comment by Build Master (Inactive) [ 20/May/11 ] |
|
Integrated in Johann Lombardi : 4c2ea168bb65cb0abe1182e319e650ea3a58da10
|
| Comment by Build Master (Inactive) [ 20/May/11 ] |
|
Integrated in Johann Lombardi : 4c2ea168bb65cb0abe1182e319e650ea3a58da10
|
| Comment by Build Master (Inactive) [ 20/May/11 ] |
|
Integrated in Johann Lombardi : 4c2ea168bb65cb0abe1182e319e650ea3a58da10
|
| Comment by Build Master (Inactive) [ 20/May/11 ] |
|
Integrated in Johann Lombardi : 4c2ea168bb65cb0abe1182e319e650ea3a58da10
|
| Comment by Peter Jones [ 31/May/11 ] |
|
Patch for master being worked as http://review.whamcloud.com/#change,491 |
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Build Master (Inactive) [ 02/Jun/11 ] |
|
Integrated in Oleg Drokin : dea0c1f27c0eb53d4738a70241ff2bcc47201862
|
| Comment by Alex Zhuravlev [ 06/Sep/11 ] |
|
I tend to think ldiskfs_ext_next_allocated_block() should be called under i_data_sem together with ldiskfs_ext_find_extent(), otherwise ldiskfs_ext_next_allocated_block() is working on data being modified |
| Comment by Andrew Perepechko [ 11/Oct/11 ] |
|
Zhenyu Xu, why isn't a hypothetical allocation race in ext3_ext_new_extent_cb() addressed by your patch avoided by means of i_mutex which is taken whenever Lustre calls fsfilt_map_inode_pages(create=1)? Thanks. |
| Comment by Zhenyu Xu [ 11/Oct/11 ] |
|
Panda, I don't quite get you, i_mutex is always hold during the map block process, it is i_data_sem that be used to protect extent block usage. I don't know what "allocation race" you are referring to, would you mind elaborating it? |
| Comment by Andrew Perepechko [ 12/Oct/11 ] |
|
Zhenyu Xu, I was referring to your patch. > static int ext3_ext_new_extent_cb() > > tmpex = tmppath[depth].p_ext; > if (tmpex != ex) {>...> } This patch seems to be expecting that the extent map may have changed during write (which I called allocation race earlier) . However, obdfilter takes i_mutex on writes and truncates and serializes extent map updates with it. Which case/race is expected to be handled with your code that I quoted above? Thanks. |
| Comment by Zhenyu Xu [ 14/Oct/11 ] |
|
Panda, I think you are right, I also couldn't find where the extent tree got changed w/o i_mutex hold, but the in the 1st place, in walk_space, ext4_ext_find_extent is called with i_data_sem protection, then there should exist case where extent got change w/o i_mutex protection, so the issue should be what Bzzz mentioned, we'd protect extent access, i.e. put ldiskfs_ext_next_allocated_block() under i_data_sem lock hold. |