[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gluster-devel] metadata race confition (was: ename(2) race condition)
From: |
Emmanuel Dreyfus |
Subject: |
[Gluster-devel] metadata race confition (was: ename(2) race condition) |
Date: |
Tue, 22 May 2012 07:33:37 +0200 |
User-agent: |
MacSOUP/2.7 (unregistered for 1949 days) |
Anand Avati <address@hidden> wrote:
> Is the FUSE SETATTR implementation in NetBSD synchronous? i.e, does the
> chown() or chmod() syscall issued by the application strictly block till
> GlusterFS's fuse_setattr_cbk() is called?
I have been able to narrow the test down to the code below, which does not even
call chown().
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <err.h>
#include <sysexits.h>
int
main(void)
{
int fd;
(void)mkdir("subdir", 0755);
do {
if ((fd = open("subdir/bugc1.txt", O_CREAT|O_RDWR, 0644)) == -1)
err(EX_OSERR, "open failed");
if (close(fd) == -1)
err(EX_OSERR, "close failed");
if (unlink("subdir/bugc1.txt") == -1)
err(EX_OSERR, "unlink failed");
} while (1 /*CONSTCOND */);
/* NOTREACHED */
return EX_OK;
}
It produces a FUSE trace without SETATTR:
> unique = 393, nodeid = 3098542496, opcode = LOOKUP (1)
< unique = 393, nodeid = 3098542496, opcode = LOOKUP (1), error = -2
> unique = 394, nodeid = 3098542496, opcode = CREATE (35)
< unique = 394, nodeid = 3098542496, opcode = CREATE (35), error = 0
-> I suspect (not yet checked) this is the place where I get fuse_entry_out
with attr.uid = 0. This will be cached since attr_valid tells us to do so.
> unique = 395, nodeid = 3098542396, opcode = RELEASE (18)
< unique = 395, nodeid = 3098542396, opcode = RELEASE (18), error = 0
> unique = 396, nodeid = 3098542296, opcode = LOOKUP (1)
< unique = 396, nodeid = 3098542296, opcode = LOOKUP (1), error = 0
>From other traces, I can tell that this last lookup is for the parent directory
(subdir). The FUSE request for looking up bugc1.txt with the intent of deleting
is not even sent: from cached uid we obtained from fuse_entry_out, we know that
permissions shall be denied (I had a debug printf to check that). We do not even
ask.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
address@hidden
- [Gluster-devel] rename(2) race condition, Emmanuel Dreyfus, 2012/05/20
- Re: [Gluster-devel] rename(2) race condition, Emmanuel Dreyfus, 2012/05/20
- Re: [Gluster-devel] rename(2) race condition, Emmanuel Dreyfus, 2012/05/21
- Re: [Gluster-devel] rename(2) race condition, Anand Avati, 2012/05/21
- [Gluster-devel] metadata race confition (was: ename(2) race condition),
Emmanuel Dreyfus <=
- Re: [Gluster-devel] metadata race confition (was: ename(2) race condition), Anand Avati, 2012/05/22
- Re: [Gluster-devel] metadata race confition (was: ename(2) race condition), Emmanuel Dreyfus, 2012/05/22
- Re: [Gluster-devel] metadata race confition (was: ename(2) race condition), Emmanuel Dreyfus, 2012/05/22
- Re: [Gluster-devel] metadata race confition (was: ename(2) race condition), Anand Avati, 2012/05/22
- Re: [Gluster-devel] metadata race confition (was: ename(2) race condition), Emmanuel Dreyfus, 2012/05/22