Bug 762745 (GLUSTER-1013) - gen_seq is not really thread safe
Summary: gen_seq is not really thread safe
Keywords:
Status: CLOSED NOTABUG
Alias: GLUSTER-1013
Product: GlusterFS
Classification: Community
Component: posix
Version: 3.0.4
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
Assignee: Pranith Kumar K
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-19 08:09 UTC by zls
Modified: 2015-12-01 16:45 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)
a possible patch (2.30 KB, patch)
2010-07-01 07:52 UTC, zls
no flags Details | Diff

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


Note You need to log in before you can comment on or make changes to this bug.