linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Liu <jeff.liu@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Christoph Lameter <cl@gentwo.org>,
	David Rientjes <rientjes@google.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	Pekka Enberg <penberg@kernel.org>,
	akpm@linuxfoundation.org
Subject: Re: [PATCH RESEND] slub: return correct error on slab_sysfs_init
Date: Fri, 20 Jun 2014 21:51:16 +0800	[thread overview]
Message-ID: <53A43C54.3090402@oracle.com> (raw)
In-Reply-To: <20140619133201.7f84ae4acbc1b9d8f65e2b4f@linux-foundation.org>


On 06/20/2014 04:32 AM, Andrew Morton wrote:
> On Thu, 19 Jun 2014 09:39:54 -0500 (CDT) Christoph Lameter <cl@gentwo.org> wrote:
> 
>> On Wed, 18 Jun 2014, David Rientjes wrote:
>>
>>> Why?  kset_create_and_add() can fail for a few other reasons other than
>>> memory constraints and given that this is only done at bootstrap, it
>>> actually seems like a duplicate name would be a bigger concern than low on
>>> memory if another init call actually registered it.
>>
>> Greg said that the only reason for failure would be out of memory.
> 
> The kset_create_and_add interface is busted - it should return an
> ERR_PTR on error, not NULL.  This seems to be a common gregkh failing :(
> 
> It's plausible that out-of-memory is the most common reason for
> kset_create_and_add() failure, dunno.
> 
> Jeff, the changelog wasn't a good one - it failed to describe the
> reasons for the change.  What was wrong with ENOSYS and why is ENOMEM
> more appropriate?  If Greg told us that out-of-memory is the only
> possible reason for the failure then it would be useful to capture the
> reasoning behind this within this changelog.
> 
> Also let's describe the effects of this patch.  It looks like it's just
> cosmetic - if kset_create_and_add() fails, the kernel behavior will be
> the same either way.

I admit that the current changelog is indistinct :)

At that time, I thought it would be ENOMEM because I was review another patch
for adding sysfs support to XFS where we return ENOMEM in this case:
http://www.spinics.net/lists/xfs/msg28343.html

This drives to me to think why it should be ENOMEM rather than ERR_PTR since
it seems most likely kset_create_and_add() would fails due to other reasons.
Hence I looked through kernel sources and figured out most subsystems are return
ENOMEM, maybe those subsystems are refers to the kset example code at:
samples/kobject/kset-example.c

So my original motivation is just to make the slub sysfs init error handling in
accordance to other subsystems(nitpick) and it does not affect the kernel behaviour.

Combine with Greg's comments, as such, maybe the changelog would looks like
the following?

GregKH: the only reason for failure would be out of memory on kset_create_and_add().
return -ENOMEM than -ENOSYS if the call is failed which is consistent with other
subsystems in this situation.


Cheers,
-Jeff





  

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2014-06-20 13:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18  1:29 [PATCH RESEND] slub: return correct error on slab_sysfs_init Jeff Liu
2014-06-18 20:16 ` David Rientjes
2014-06-19 14:39   ` Christoph Lameter
2014-06-19 20:32     ` Andrew Morton
2014-06-19 21:34       ` David Rientjes
2014-06-20 13:51       ` Jeff Liu [this message]
2014-06-20 22:30         ` David Rientjes
2014-06-21  8:49           ` Jeff Liu
2014-06-23 13:59             ` Christoph Lameter

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=53A43C54.3090402@oracle.com \
    --to=jeff.liu@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=akpm@linuxfoundation.org \
    --cc=cl@gentwo.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).