All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Kleikamp <dave.kleikamp@oracle.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-fsdevel@vger.kernel.org, Jeff Mahoney <jeffm@suse.com>,
	Dave Kleikamp <shaggy@kernel.org>
Subject: Re: [RFC] setxattr bugs
Date: Sun, 03 Feb 2013 07:59:27 -0600	[thread overview]
Message-ID: <510E6D3F.2060200@oracle.com> (raw)
In-Reply-To: <20130203043046.GR4503@ZenIV.linux.org.uk>

On 02/02/2013 10:30 PM, Al Viro wrote:
> 	* JFS, since 2005: setxattr(name, "system.posix_acl_access", NULL, 0, 0)
> succeeds, creating an empty EA with "system.posix_acl_access" as name.
> Validity checks should apply _after_
>         if (value == NULL) {    /* empty EA, do not remove */
>                 value = "";
>                 value_len = 0;
>         }
> and not before it.

This is probably a hold-over from weird OS/2 behavior that we really
don't need to keep.

> 	* reiserfs, since 2009: setxattr(name, attr_name, NULL, 0, 0) is
> treated as removexattr(name, attr_name), not as emptying given xattr.
> 
> 	The question is, does either of those cross into "established
> weirdness in ABI" or are they still at the "bugs to be fixed" stage?
> 
> 	FWIW, I'm seriously tempted to stop passing NULL as the
> third argument of ->setxattr(), essentially taking all those
> if (!value) value = ""; pieces from individual ->setxattr() instances
> to __vfs_setxattr_noperm() (all other callers of ->setxattr() never
> pass NULL data or 0 size, so it's irrelevant for them).  Would fix
> both jfs and reiserfs weirdness....
> 
> 	Objections?

no objection from me. I can clean up the jfs code so that it no longer
saves empty xattrs.

Thanks,
Shaggy

  reply	other threads:[~2013-02-03 13:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-03  4:30 [RFC] setxattr bugs Al Viro
2013-02-03 13:59 ` Dave Kleikamp [this message]
2013-02-05  2:14 ` Jeff Mahoney
2013-02-05 17:14   ` Casey Schaufler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=510E6D3F.2060200@oracle.com \
    --to=dave.kleikamp@oracle.com \
    --cc=jeffm@suse.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaggy@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.