Sage Weil <sage@xxxxxxxxxxx> writes:
> On Thu, 16 Aug 2012, Miklos Szeredi wrote:
>> Miklos Szeredi <miklos@xxxxxxxxxx> writes:
>>
>> > Sage Weil <sage@xxxxxxxxxxx> writes:
>> >
>> >> Hi Miklos,
>> >>
>> >> I found some time to track down the O_CREAT error code issue. Patch is
>> >> below. Does this look correct?
>> >>
>> >> I was reproducing with
>> >>
>> >> ceph-fuse mnt
>> >> mkdir -p mnt/a
>> >> cd mnt
>> >> .../pjd-fstest-20080816/fstest -u 65534 -g 65534 open a/foo O_RDONLY,O_CREAT 0644
>> >>
>> >> EACCES is expected, ENOENT was returned instead.
>> >
>> > I don't quite undersdand what is happending here.
>> >
>> > Why does ceph-fuse return ENOENT here? Returning ENOENT for O_CREAT
>> > only makes sense if the parent directory doesn't exist, but that's not
>> > the case here.
>>
>> More specifically, the initial lookup will return ENOENT, that's fine.
>>
>> But in that case fuse_atomic_open() will do a FUSE_CREATE for which
>> ENOENT is not the right answer.
>
> I didn't dig deeply into what fuse_lookup() itself was doing, but the
> short version is:
>
> - namei.c's atomic_open() gets -EACCES from the may_o_create() check, sets
> create_error, and clears O_CREAT from the flags
>
> - fuse_atomic_open() calls fuse_lookup(), which returns NULL and leaves
> entry->d_inode == NULL. ceph-fuse's lookup method returned -ENOENT.
> fuse_lookup() is just hashing the negative dentry instead of returning
> ENOENT.
>
> - fuse_atomic_open() sees O_CREAT is not set and calls finish_no_open().
>
> - the existing ENOENT -> EACCES check in atomic_open() (below) fails
> because fuse_atomic_open() returned 1:
>
> if (error < 0) {
> if (create_error && error == -ENOENT)
> error = create_error;
> goto out;
> }
>
> This patch just applies the same ENOENT->EACCES logic to the equivalent
> negative/null dentry case.
Okay, I get it now.
Yes, your patch looks correct. I'll queue it up with the other
atomic-open fixes.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
