Bug 762745 (GLUSTER-1013)

Summary: gen_seq is not really thread safe
Product: [Community] GlusterFS Reporter: zls <zls0424>
Component: posixAssignee: Pranith Kumar K <pkarampu>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 3.0.4CC: amarts, gluster-bugs, vijay
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
a possible patch none

Description zls 2010-06-19 08:09:42 UTC 
Think we have two threads (A and B) that are calling posix_fstat_with_gen/posix_lstat_with_gen for the same path. If "trusted.brick00-posix.gen" for the path is not set before, sys_lgetxattr returns -1 for both threads. Then gen_val will be calculated for each thread under the protection of lock. But the write back action and inode_link action in later server_lookup_cbk are not protected.

For example, thread A got 0x1 and thread B got 0x2, then the "trusted.brick00-posix.gen" written back to file system by sys_fsetxattr may be any one of them. Here we get 0x1. But the first call of inode_link for this path may be with value 0x2. Then later requests from client for this directory will get gen 0x1 from the file system, while the cached inode information has value 0x2 (which will only be updated if new read value larger than cached one). Then if client try to create file in this directory, it will fail with error ENOENT because of generation dismatch. In this case we can only restart the server, which will read the value from file system.

Is that true?
Comment 1 zls 2010-07-01 07:52:45 UTC 
Created attachment 245 [details]
Patch for three different Xaw memory bugs

a possible patch
Comment 2 Amar Tumballi 2010-10-05 08:35:20 UTC 
Hi <zls>,

Thanks for the patches, but with 3.1.x branch, we moved out of 'gen' and came out with better approach of gfid, which is uniq across the mount point. Hence will be closing it. Can you please test the new 3.1 (currently @ beta) releases?

We will currently mark this bug as INVALID (as this part of the codebase is no more existing). Please open new bugs for new issues.

Thanks and Regards,
Gluster Team