summaryrefslogtreecommitdiffstats
path: root/security/keys
diff options
context:
space:
mode:
authorDavid Chinner <dgc@sgi.com>2007-06-18 16:49:44 +1000
committerTim Shimmin <tes@chook.melbourne.sgi.com>2007-07-14 15:32:09 +1000
commit45c34141126a89da07197d5b89c04c6847f1171a (patch)
treeb5418b397602fc0ab131ed4a56a90f215628d776 /security/keys
parentb2826136a1fc3ea451bcbb73a75ca50b3231aa8f (diff)
downloadlinux-45c34141126a89da07197d5b89c04c6847f1171a.tar.bz2
[XFS] Apply transaction delta counts atomically to incore counters
With the per-cpu superblock counters, batch updates are no longer atomic across the entire batch of changes. This is not an issue if each individual change in the batch is applied atomically. Unfortunately, free block count changes are not applied atomically, and they are applied in a manner guaranteed to cause problems. Essentially, the free block count reservation that the transaction took initially is returned to the in core counters before a second delta takes away what is used. because these two operations are not atomic, we can race with another thread that can use the returned transaction reservation before the transaction takes the space away again and we can then get ENOSPC being reported in a spot where we don't have an ENOSPC condition, nor should we ever see one there. Fix it up by rolling the two deltas into the one so it can be applied safely (i.e. atomically) to the incore counters. SGI-PV: 964465 SGI-Modid: xfs-linux-melb:xfs-kern:28796a Signed-off-by: David Chinner <dgc@sgi.com> Signed-off-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Tim Shimmin <tes@sgi.com>
Diffstat (limited to 'security/keys')
0 files changed, 0 insertions, 0 deletions