[Cluster-devel] [GFS2 PATCH] GFS2: attempt to access beyond end of device creating file
Bob Peterson
rpeterso at redhat.com
Thu Mar 15 12:19:52 UTC 2012
----- Original Message -----
| | The question is how does this pointer land up being not NULL to
| | start
| | with... I thought that you were looking into that from your earlier
| | comment in the bug,
| |
| | Steve.
| Hi,
|
| My belief is that the i_hash_cache pointer was non-NULL because of
| a code path in the RHEL6 kernel that does not exist in the upstream
| kernel. (RHEL6 function gfs2_clear_inode was not invalidating the
| hash
| table cache like it should, but it doesn't exist in upstream GFS2).
|
| If my suspicion is correct, setting the i_hash_cache pointer to NULL
| from gfs2_alloc_inode is unnecessary and purely precautionary.
| I'm running some tests on the RHEL6 kernel to help prove that theory,
| but the test will probably take all day (it's a long-running test).
|
| I can't reproduce the original problem with the upstream kernel
| because I can't run that test on my upstream box (it requires a
| special RHEL6 environment set up by a third party).
|
| Regards,
|
| Bob Peterson
| Red Hat File Systems
|
Hi,
I confirmed my suspicion above. The non-NULL pointer was caused by
bug in a code path that does not apply to the upstream kernel.
Therefore, I self-NAK and withdraw this patch.
Regards,
Bob Peterson
Red Hat File Systems
More information about the Cluster-devel
mailing list