[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