linux-kernel - Re: [Ocfs2-devel] [PATCH 13/39] ocfs2: Add extended attribute support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081008133453.GH25392@lst.de>
Date:	Wed, 8 Oct 2008 15:34:53 +0200
From:	Christoph Hellwig <hch@....de>
To:	Tiger Yang <tiger.yang@...cle.com>
Cc:	Mark Fasheh <mfasheh@...e.com>, Christoph Hellwig <hch@....de>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	ocfs2-devel@....oracle.com
Subject: Re: [Ocfs2-devel] [PATCH 13/39] ocfs2: Add extended attribute support

On Wed, Oct 08, 2008 at 09:56:41AM +0800, Tiger Yang wrote:
> I have looked the patch for btrfs about this. We are different.
> Btrfs store the whole xattr name including the prefix "user." 
> "trusted.", we store index number instead of it.

I looked at the git tree and there are two users of
ocfs2_xattr_handler().

 (1) for using the ->list handler in listattr.  That's something I fixed
     in btrfs that I wanted to point you to.  The whole concept of a
     ->list handler is stupid, and it was only added as a hack for
     the tmpfs "generic" xattr support which is a mess.  Instead of
     looking up a handler that would only do the same thing anyway
     for all on-disk attributes just call the code directly and
     have a map from index to prefix (look at
     fs/xfs/linux-2.6/xfs_xattr.c for an example).  You
     also have a check for OCFS2_MOUNT_NOUSERXATTR for the user
     attributes, but that's much easier done by just checking the
     index in an if (and I'd personally just kill it completely, the
     options doesn't seem useful - but that's an unrelated bit)
 
 (2) For generating the hash.  I don't quite understand why you want to
     also hash the prefix if it's not store on disk anyway but sorted
     into the numeric buckets.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/