[Gluster-devel] Testcase broken due to posix iatt commit

[Vijaikumar Mallikarjuna]

Previously function 'posix_acl_ctx_get' was creating inode_ctx if it is not
present. So if sometime lookup does not come for root inode, then inode-ctx
was created here without any perm set.
Now inode-ctx is created only in lookup_cbk and setattr_cbk to populate the
ctx with valid perm from statbuf, so I think we need to send lookup for
root-inode.

Thanks,
Vijay


On Mon, Mar 28, 2016 at 8:40 PM, FNU Raghavendra Manjunath <
rabhat at redhat.com> wrote:

> Root inode gets linked during mount itselsf.
>
> We get lookups on root. But since root inode is always present in the
> inode table, after the mount if there is a fop on an entry whose parent is
> root, then that fop will be able to find the parent in the inode table as
> part of resolve. So it need not explicitly send a hard resolution for
> resolving parent inode.
>
> Du? Did I miss anything?
>
> Regards,
> Raghavendra
> On Mar 28, 2016 11:02 AM, "Vijaikumar Mallikarjuna" <vmallika at redhat.com>
> wrote:
>
>> Hi Du/Johny,
>>
>> Don't we get a lookup on root inode? Please confirm.
>>
>> If we don't get lookup on root inode, then we need to create inode-ctx in
>> a posix_acl_ctx_get() function.
>>
>> Thanks,
>> Vijay
>> On 28-Mar-2016 7:37 PM, "FNU Raghavendra Manjunath" <rabhat at redhat.com>
>> wrote:
>>
>>> CCing Vijay Kumar who made the acl related changes in that patch.
>>>
>>> Vijay? Can you please look into it?
>>>
>>> Regards,
>>> Raghavendra
>>>
>>> On Mon, Mar 28, 2016 at 9:57 AM, Avra Sengupta <asengupt at redhat.com>
>>> wrote:
>>>
>>>> Hi Raghavendra,
>>>>
>>>> As part of the patch (http://review.gluster.org/#/c/13730/16), the
>>>> inode_ctx is not created in posix_acl_ctx_get(). Because of this the
>>>> testcase in http://review.gluster.org/#/c/13623/ breaks. It fails with
>>>> the following logs:
>>>>
>>>> [2016-03-28 13:43:39.216168] D [MSGID: 0]
>>>> [io-threads.c:346:iot_schedule] 0-patchy-io-threads: CREATE scheduled as
>>>> normal fop
>>>> [2016-03-28 13:43:39.216495] E [posix-acl.c:199:acl_permits] (-->
>>>> /usr/local/lib/libglusterfs.so.0(_gf_log_callingfn+0x1ba)[0x7f6fea72780a]
>>>> (-->
>>>> /usr/local/lib/glusterfs/3.8dev/xlator/features/access-control.so(+0x49c4)[0x7f6fde5499c4]
>>>> (-->
>>>> /usr/local/lib/glusterfs/3.8dev/xlator/features/access-control.so(+0xa855)[0x7f6fde54f855]
>>>> (-->
>>>> /usr/local/lib/glusterfs/3.8dev/xlator/features/locks.so(+0xd37e)[0x7f6fde33837e]
>>>> (-->
>>>> /usr/local/lib/glusterfs/3.8dev/xlator/features/upcall.so(+0x640f)[0x7f6fde12040f]
>>>> ))))) 0-patchy-access-control: inode ctx is NULL for
>>>> 00000000-0000-0000-0000-000000000001
>>>> [2016-03-28 13:43:39.216544] I [MSGID: 115071]
>>>> [server-rpc-fops.c:1612:server_create_cbk] 0-patchy-server: 8: CREATE
>>>> /file1 (00000000-0000-0000-0000-000000000001/file1) ==> (Permission denied)
>>>> [Permission denied]
>>>>
>>>> Is it because we missed the inode_ctx creation that was being done by
>>>> posix_acl_ctx_get() previously? Can you please shed some light on this
>>>>
>>>> Regards,
>>>> Avra
>>>>
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160329/d6e2d8ca/attachment-0001.html>