[Gluster-devel] regarding special treatment of ENOTSUP for setxattr

[Harshavardhana]

Here are the important locations in the XFS tree coming from 2.6.32 branch

STATIC int
xfs_set_acl(struct inode *inode, int type, struct posix_acl *acl)
{
        struct xfs_inode *ip = XFS_I(inode);
        unsigned char *ea_name;
        int error;

        if (S_ISLNK(inode->i_mode)) ----------------> I would
generally think this is the issue.
                return -EOPNOTSUPP;

STATIC long
xfs_vn_fallocate(
        struct inode    *inode,
        int             mode,
        loff_t          offset,
        loff_t          len)
{
        long            error;
        loff_t          new_size = 0;
        xfs_flock64_t   bf;
        xfs_inode_t     *ip = XFS_I(inode);
        int             cmd = XFS_IOC_RESVSP;
        int             attr_flags = XFS_ATTR_NOLOCK;

        if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
                return -EOPNOTSUPP;

STATIC int
xfs_ioc_setxflags(
        xfs_inode_t             *ip,
        struct file             *filp,
        void                    __user *arg)
{
        struct fsxattr          fa;
        unsigned int            flags;
        unsigned int            mask;
        int error;

        if (copy_from_user(&flags, arg, sizeof(flags)))
                return -EFAULT;

        if (flags & ~(FS_IMMUTABLE_FL | FS_APPEND_FL | \
                      FS_NOATIME_FL | FS_NODUMP_FL | \
                      FS_SYNC_FL))
                return -EOPNOTSUPP;

Perhaps some sort of system level acl's are being propagated by us
over symlinks() ? - perhaps this is the related to the same issue of
following symlinks?

On Sun, May 18, 2014 at 10:48 AM, Pranith Kumar Karampuri
<pkarampu at redhat.com> wrote:
> Sent the following patch to remove the special treatment of ENOTSUP here: http://review.gluster.org/7788
>
> Pranith
> ----- Original Message -----
>> From: "Kaleb KEITHLEY" <kkeithle at redhat.com>
>> To: gluster-devel at gluster.org
>> Sent: Tuesday, May 13, 2014 8:01:53 PM
>> Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for       setxattr
>>
>> On 05/13/2014 08:00 AM, Nagaprasad Sathyanarayana wrote:
>> > On 05/07/2014 03:44 PM, Pranith Kumar Karampuri wrote:
>> >>
>> >> ----- Original Message -----
>> >>> From: "Raghavendra Gowdappa" <rgowdapp at redhat.com>
>> >>> To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
>> >>> Cc: "Vijay Bellur" <vbellur at redhat.com>, gluster-devel at gluster.org,
>> >>> "Anand Avati" <aavati at redhat.com>
>> >>> Sent: Wednesday, May 7, 2014 3:42:16 PM
>> >>> Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP
>> >>> for setxattr
>> >>>
>> >>> I think with "repetitive log message suppression" patch being merged, we
>> >>> don't really need gf_log_occasionally (except if they are logged in
>> >>> DEBUG or
>> >>> TRACE levels).
>> >> That definitely helps. But still, setxattr calls are not supposed to
>> >> fail with ENOTSUP on FS where we support gluster. If there are special
>> >> keys which fail with ENOTSUPP, we can conditionally log setxattr
>> >> failures only when the key is something new?
>>
>> I know this is about EOPNOTSUPP (a.k.a. ENOTSUPP) returned by
>> setxattr(2) for legitimate attrs.
>>
>> But I can't help but wondering if this isn't related to other bugs we've
>> had with, e.g., lgetxattr(2) called on invalid xattrs?
>>
>> E.g. see https://bugzilla.redhat.com/show_bug.cgi?id=765202. We have a
>> hack where xlators communicate with each other by getting (and setting?)
>> invalid xattrs; the posix xlator has logic to filter out  invalid
>> xattrs, but due to bugs this hasn't always worked perfectly.
>>
>> It would be interesting to know which xattrs are getting errors and on
>> which fs types.
>>
>> FWIW, in a quick perusal of a fairly recent (3.14.3) kernel, in xfs
>> there are only six places where EOPNOTSUPP is returned, none of them
>> related to xattrs. In ext[34] EOPNOTSUPP can be returned if the
>> user_xattr option is not enabled (enabled by default in ext4.) And in
>> the higher level vfs xattr code there are many places where EOPNOTSUPP
>> _might_ be returned, primarily only if subordinate function calls aren't
>> invoked which would clear the default or return a different error.
>>
>> --
>>
>> Kaleb
>>
>>
>>
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel



-- 
Religious confuse piety with mere ritual, the virtuous confuse
regulation with outcomes