[Bugs] [Bug 1630804] libgfapi-python: test_listdir_with_stat and test_scandir failure on release 5 branch

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1630804

Shyamsundar <srangana at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kdhananj at redhat.com
              Flags|                            |needinfo?(kdhananj at redhat.c
                   |                            |om)



--- Comment #5 from Shyamsundar <srangana at redhat.com> ---
Using the C based reproducer in comment #4 bisected the code to determine that
the failure is from the following patch:

commit c9bde3021202f1d5c5a2d19ac05a510fc1f788ac
https://review.gluster.org/c/glusterfs/+/20639

The commit message for the above patch does call out a race of the nature
observed as follows,

<commit message>
Some fops don't have valid iatts in their responses. For eg., write
  response whose data is still cached in write-behind will have zeroed
  out stat. In this case keep only ia_type and ia_gfid and reset rest
  of the iatt members to zero.
  - fuse-bridge in this case just sends "entry" information back to
    kernel and attr is not sent.
  - gfapi sets entry->inode to NULL and zeroes out the entire stat
* There is one tiny race between the entry creation and a readdirp on
  its parent dir, which could cause the inode-ctx setting and inode
  ctx reading to happen on two different inode objects. To prevent
  this, when entry->inode doesn't eqaul to linked_inode,
  - fuse-bridge is made to send only "entry" information without
    attributes
  - gfapi sets entry->inode to NULL and zeroes out the entire stat.

The bug in this case seems to stem from one of the above (or maybe a pattern
that is new) but looks simple enough that it needs to work as intended.

Requesting @krutika or @du to take a look and see how best to address the
problem.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.