aboutsummaryrefslogtreecommitdiffstats
path: root/fs/cramfs
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2011-04-21 09:34:27 +0000
committerAlex Elder <aelder@sgi.com>2011-05-19 12:03:45 -0500
commit44396476a0f24e5174768d3732f1958857c26d22 (patch)
tree2581ab960427ac915ad0684a7d921476097b1d0d /fs/cramfs
parentee58abdfcc8201f500107c7ba03f738af8b49b85 (diff)
downloadkernel_samsung_tuna-44396476a0f24e5174768d3732f1958857c26d22.zip
kernel_samsung_tuna-44396476a0f24e5174768d3732f1958857c26d22.tar.gz
kernel_samsung_tuna-44396476a0f24e5174768d3732f1958857c26d22.tar.bz2
xfs: reset buffer pointers before freeing them
When we free a vmapped buffer, we need to ensure the vmap address and length we free is the same as when it was allocated. In various places in the log code we change the memory the buffer is pointing to before issuing IO, but we never reset the buffer to point back to it's original memory (or no memory, if that is the case for the buffer). As a result, when we free the buffer it points to memory that is owned by something else and attempts to unmap and free it. Because the range does not match any known mapped range, it can trigger BUG_ON() traps in the vmap code, and potentially corrupt the vmap area tracking. Fix this by always resetting these buffers to their original state before freeing them. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Alex Elder <aelder@sgi.com>
Diffstat (limited to 'fs/cramfs')
0 files changed, 0 insertions, 0 deletions