All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Rakesh Pandit <rakesh@tuxera.com>
Cc: ebiederm@xmission.com, keescook@chromium.org,
	serge.hallyn@canonical.com, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] befs: iget_locked() doesn't return an ERR_PTR
Date: Thu, 16 Jan 2014 05:53:57 +0000	[thread overview]
Message-ID: <20140116055357.GW10323@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20140115175828.GA3514@localhost.localdomain>

On Wed, Jan 15, 2014 at 07:58:28PM +0200, Rakesh Pandit wrote:
> Also fix befs_iget return value if iget_locked fails.

Applied, but I really wonder if we'd made a mistake with iget{5}_locked()
API - perhaps the calling conventions returning ERR_PTR(-ENOMEM) would've
been better...  Most of the callers are immediately followed by
	if (!inode)
		return ERR_PTR(-ENOMEM);
and in fact something like
inode_is_new(inode) = !ERR_PTR(inode) && (inode->i_flags & I_NEW)
might've killed even more boilerplate in callers, so it might make
sense to introduce a new variants of iget{,5}_locked that would
return ERR_PTR(-ENOMEM) on out-of-memory and mark the original variants
obsolete after a while...

Anyway, for now your patch is obviously the right fix.

BTW, the callers of iget{,5}_locked() that do not do that return
ERR_PTR(-ENOMEM) on NULL thing are worth looking into:
	* sysfs_get_inode() - callers of _that_ do the same thing; might
as well have done it there.
	* nilfs_iget_locked() - ditto.
	* fuse_iget() - ditto.
	* btrfs_iget_locked() - ditto.
	* udf_iget() - callers galore, with very inconsistent error values
propagated on that failure (EACCES, EIO, etc.); quite a few of those would
be better off with ENOMEM (e.g. ->lookup() failing with EACCES on oom isn't
right).
	* __ecryptfs_get_inode() - EACCES instead of ENOMEM, for no good
reason I can see...
	* gfs2_iget() - ENOBUFS instead of ENOMEM.  ENOBUFS is 
"No buffer space available (POSIX.1 (XSI STREAMS option))" and since
we don't support STREAMS it's probably fair game, but... what the hell?
	* ll_iget() - this one definitely ought to return ERR_PTR(), since
it does that on other errors; callers check for both.  One of them converts
NULL to ERR_PTR(-ENOMEM), another (in mount guts) treats it as EBADF (again,
very odd return value when there's no file descriptors in sight).
	* befs_iget() - the one you'd caught.
	* hfs_iget() - one caller treats it as EACCES, another - as EINVAL.
To make things more complicated, there's another failure exit, which probably
should be EINVAL.  Overall, I'd make it return ERR_PTR()...
	* cifs_iget() - probably would be better off with ERR_PTR(); most
of the callers treat NULL as ENOMEM, but cifs_posix_mkdir() is really
odd in that respect...  No sure what's going on there.
	* hfs_btree_open() - callers end up treating that as EIO (and do that
to kmalloc() failures right in there)
	* hpfs_lookup() - treats all errors as ENOENT, that one included...
	* hpfs_fill_super() - same, but treats everything as EINVAL
	* bdget() and bdget_disk() - a bunch of callers forget to check for
allocation failures at all; some are doing that legitimately, some are
probably oopsable...

      reply	other threads:[~2014-01-16  5:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-15 17:58 [PATCH] befs: iget_locked() doesn't return an ERR_PTR Rakesh Pandit
2014-01-16  5:53 ` Al Viro [this message]

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=20140116055357.GW10323@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rakesh@tuxera.com \
    --cc=serge.hallyn@canonical.com \
    /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.