summaryrefslogtreecommitdiff
path: root/fs/gfs2/main.c
diff options
context:
space:
mode:
authorBob Peterson <rpeterso@redhat.com>2016-06-09 22:24:07 +0300
committerBob Peterson <rpeterso@redhat.com>2016-06-10 15:01:58 +0300
commit36e4ad0316c017d5b271378ed9a1c9a4b77fab5f (patch)
tree4a23a5f7ef511ce6b366c98cc0605bcb91985cb6 /fs/gfs2/main.c
parent29567292c0b5b2fb484125c280a2175141fe2205 (diff)
downloadlinux-36e4ad0316c017d5b271378ed9a1c9a4b77fab5f.tar.xz
GFS2: don't set rgrp gl_object until it's inserted into rgrp tree
Before this patch, function read_rindex_entry would set a rgrp glock's gl_object pointer to itself before inserting the rgrp into the rgrp rbtree. The problem is: if another process was also reading the rgrp in, and had already inserted its newly created rgrp, then the second call to read_rindex_entry would overwrite that value, then return a bad return code to the caller. Later, other functions would reference the now-freed rgrp memory by way of gl_object. In some cases, that could result in gfs2_rgrp_brelse being called twice for the same rgrp: once for the failed attempt and once for the "real" rgrp release. Eventually the kernel would panic. There are also a number of other things that could go wrong when a kernel module is accessing freed storage. For example, this could result in rgrp corruption because the fake rgrp would point to a fake bitmap in memory too, causing gfs2_inplace_reserve to search some random memory for free blocks, and find some, since we were never setting rgd->rd_bits to NULL before freeing it. This patch fixes the problem by not setting gl_object until we have successfully inserted the rgrp into the rbtree. Also, it sets rd_bits to NULL as it frees them, which will ensure any accidental access to the wrong rgrp will result in a kernel panic rather than file system corruption, which is preferred. Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Diffstat (limited to 'fs/gfs2/main.c')
0 files changed, 0 insertions, 0 deletions