diff options
| author | Sage Weil <sage@newdream.net> | 2010-10-27 20:59:49 -0700 |
|---|---|---|
| committer | Sage Weil <sage@newdream.net> | 2010-10-27 21:05:54 -0700 |
| commit | 2f56f56ad991edd51ffd0baf1182245ee1277a04 (patch) | |
| tree | e4062e2bb1a92b487609cded256d5ede1a6eda90 /lib/iomap.c | |
| parent | efa4c1206eaff047c474af2136748a58eb8cc33b (diff) | |
| download | kernel_samsung_smdk4412-2f56f56ad991edd51ffd0baf1182245ee1277a04.tar.gz kernel_samsung_smdk4412-2f56f56ad991edd51ffd0baf1182245ee1277a04.tar.bz2 kernel_samsung_smdk4412-2f56f56ad991edd51ffd0baf1182245ee1277a04.zip | |
Revert "ceph: update issue_seq on cap grant"
This reverts commit d91f2438d881514e4a923fd786dbd94b764a9440.
The intent of issue_seq is to distinguish between mds->client messages that
(re)create the cap and those that do not, which means we should _only_ be
updating that value in the create paths. By updating it in handle_cap_grant,
we reset it to zero, which then breaks release.
The larger question is what workload/problem made me think it should be
updated here...
Signed-off-by: Sage Weil <sage@newdream.net>
Diffstat (limited to 'lib/iomap.c')
0 files changed, 0 insertions, 0 deletions