Re: DHT NULL pointer usage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Shyam,

On 11/17/2014 03:50 PM, Shyam wrote:
On 11/17/2014 07:20 AM, Emmanuel Dreyfus wrote:
Hello

I have an almost reliable test that fails on NetBSD:

./tests/basic/ec/quota.t                 (Wstat: 0 Tests: 22 Failed: 3)
   Failed tests:  19-21

This one is a real bug: glusterfsd crashed because of a NULL pointer. I
am going to submit a change to avoid touhcing postbuf is op_ret = -1 but
if someone has a better idea, please let me know.

This should be fine from a DHT perspective. The current tests check if
the file is under migration, using the postbuf attrs sticky and SGID
(for the file). If the FOP errore'd out then the code should look to
check if this is a dht_inode_missing error and then do a phase2 check to
see if the file migrated to a new target (based on a good/bad op_ret).

Looking at the test, it seems that we hit a quota error on the write. In
which case following the file even if it migrated does not make sense.
We should have received an EDQUOT error as the op_errno (if I am not
mistaken) and exited this function at the check below,

dht_writev_cbk:
35:       if (op_ret == -1 && !dht_inode_missing(op_errno)) {
36:                goto out;
37:        }

It's very strange. The failing test tries to write a file. There should be enough quota for the file to be written and it's not being migrated, but it seems that the brick is returning ENOENT (at least this is what ec_writev_cbk() is receiving). However all other tests writing to files seems to work ok, so I'm not sure what is special with this particular test.


Are we not sending an EDQUOT upwards in this case?

Validating assumptions:
- As this is an fd based operation, the fd should have been open, and so
why did the writev fail exactly? EDQUOT?

The op_errno is 2 (ENOENT)

- Was this an NFS based test, which could explain the use of anon-fds
which would return an error if the file is no longer on the backend. Is
this a test run from an NFS mount point?

It's a normal FUSE mount.

Xavi
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux