diff options
author | Bob Peterson <rpeterso@redhat.com> | 2020-01-20 15:49:28 +0100 |
---|---|---|
committer | Andreas Gruenbacher <agruenba@redhat.com> | 2020-01-28 15:04:53 +0100 |
commit | a31b4ec539e966515f1f97f4000d0e2a399930ce (patch) | |
tree | 2dbc373f2a272a5b72f8fd910f9df352f7deebc1 /drivers/pci/controller/vmd.c | |
parent | c04f2e0dd5309607dbc425f02b5ac076b395f19d (diff) | |
download | linux-a31b4ec539e966515f1f97f4000d0e2a399930ce.tar.bz2 |
Revert "gfs2: eliminate tr_num_revoke_rm"
This reverts commit e955537e3262de8e56f070b13817f525f472fa00.
Before patch e955537e32, tr_num_revoke tracked the number of revokes
added to the transaction, and tr_num_revoke_rm tracked how many
revokes were removed. But since revokes are queued off the sdp
(superblock) pointer, some transactions could remove more revokes
than they added. (e.g. revokes added by a different process).
Commit e955537e32 eliminated transaction variable tr_num_revoke_rm,
but in order to do so, it changed the accounting to always use
tr_num_revoke for its math. Since you can remove more revokes than
you add, tr_num_revoke could now become a negative value.
This negative value broke the assert in function gfs2_trans_end:
if (gfs2_assert_withdraw(sdp, (nbuf <=3D tr->tr_blocks) &&
(tr->tr_num_revoke <=3D tr->tr_revokes)))
One way to fix this is to simply remove the tr_num_revoke clause
from the assert and allow the value to become negative. Andreas
didn't like that idea, so instead, we decided to revert e955537e32.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Diffstat (limited to 'drivers/pci/controller/vmd.c')
0 files changed, 0 insertions, 0 deletions