summaryrefslogtreecommitdiffstats
path: root/rpc
diff options
context:
space:
mode:
authorShehjar Tikoo <shehjart@gluster.com>2010-07-28 03:51:18 +0000
committerAnand V. Avati <avati@dev.gluster.com>2010-07-28 03:10:02 -0700
commitb2b6281e3487d3d797ab7974df69790a28c443c9 (patch)
tree9382156d76ff3fffe82f700e1f550da56e410908 /rpc
parent46037573958dbb3a99283ed22862e62f60f526ad (diff)
nfs3: NULL fdentry check before removing from fdcache
Suppose a file name 1 is created and some data is written to it. After this another 512 files are newly created and written to. When the the 513th file is created and an fd_t opened for it, it results in 1's fd_t being replaced in the fd-lru with 513th file's fd_t. This is the correct behaviour resulting in all refs getting unref from the fd_t of 1 and the fd and all related state being freed. But, in some workloads, some refs are still pending even after the fd_t is removed from LRU, resulting in the fd still being bound to the inode. In nfs3svc_remove_cbk, while removing the inode state, we also ensure that any fd_ts in the cache for this inode are also removed. While removing the fd_t, this situation where the fd_t has replaced with another, even while a ref remains on the fd_t, results in a crash in the fdcache_remove path in nfs3svc_remove_cbk. This happens because the fd_ctx_get results in a NULL value because the ctx was already deleted when this fd_t was removed from fd-lru earlier. This patch fixes the crash by introducing a NULL check. Signed-off-by: Shehjar Tikoo <shehjart@gluster.com> Signed-off-by: Anand V. Avati <avati@dev.gluster.com> BUG: 885 ([NFS Xlator] Crash in nfs3_fdcache_update) URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=885
Diffstat (limited to 'rpc')
0 files changed, 0 insertions, 0 deletions