All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Srikanth Korangala Hari <srikanth.h@samsung.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"adobriyan@gmail.com" <adobriyan@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: Re: [PATCH 1/1] Preventive patch in the proc file-system to handle NULL check.
Date: Fri, 17 Aug 2018 04:36:06 +0100	[thread overview]
Message-ID: <20180817033606.GB6515@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180817032142epcms5p875c72643ea624e3b2d8f10e4abaf5182@epcms5p8>

On Fri, Aug 17, 2018 at 08:51:42AM +0530, Srikanth Korangala Hari wrote:
> > Thanks�for�the�patch!�Do�you�have�a�reproducer�or�is�this�theoretical?
> > This�will�affect�if�it�should�go�to�stable�or�not.
> 
> Dear Luis, this is theoretical as I observed in most of the call's to api - "proc_mkdir" the NULL check is being done. Hence I thought of adding one here.

Realistically, if you get allocation failures that early in the boot,
oops is the least of your problems - it won't get through mounting
the root or lauching init (or unpacking initramfs, etc.)

Sure, might as well check it there - nothing wrong with that, but do
keep in mind that
	* it's very certain to end up in panic() very shortly afterwards,
no matter what
	* the odds of exhausting memory (and that would be extremely
low-memory setup) precisely at that point (i.e. even getting to
proc_root_init()) are not high.

Might be interesting to try lower and lower mem=... values passed to the
kernel in attempt to step into this one; I wouldn't put large odds on
being able to hit precisely that place, but it would be educational anyway.

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Srikanth Korangala Hari <srikanth.h@samsung.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"adobriyan@gmail.com" <adobriyan@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: Re: [PATCH 1/1] Preventive patch in the proc file-system to handle NULL check.
Date: Fri, 17 Aug 2018 04:36:06 +0100	[thread overview]
Message-ID: <20180817033606.GB6515@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180817032142epcms5p875c72643ea624e3b2d8f10e4abaf5182@epcms5p8>

On Fri, Aug 17, 2018 at 08:51:42AM +0530, Srikanth Korangala Hari wrote:
> > Thanks for the patch! Do you have a reproducer or is this theoretical?
> > This will affect if it should go to stable or not.
> 
> Dear Luis, this is theoretical as I observed in most of the call's to api - "proc_mkdir" the NULL check is being done. Hence I thought of adding one here.

Realistically, if you get allocation failures that early in the boot,
oops is the least of your problems - it won't get through mounting
the root or lauching init (or unpacking initramfs, etc.)

Sure, might as well check it there - nothing wrong with that, but do
keep in mind that
	* it's very certain to end up in panic() very shortly afterwards,
no matter what
	* the odds of exhausting memory (and that would be extremely
low-memory setup) precisely at that point (i.e. even getting to
proc_root_init()) are not high.

Might be interesting to try lower and lower mem=... values passed to the
kernel in attempt to step into this one; I wouldn't put large odds on
being able to hit precisely that place, but it would be educational anyway.

  reply	other threads:[~2018-08-17  6:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180816093424epcas2p25ede075fec715ad31108360ddca9cce8@epcas2p2.samsung.com>
2018-08-16  9:34 ` [PATCH 1/1] Preventive patch in the proc file-system to handle NULL check Srikanth K H
2018-08-16 12:32   ` Alexey Dobriyan
2018-08-17  3:27     ` Srikanth Korangala Hari
2018-08-16 13:17   ` Luis Chamberlain
2018-08-17  3:21     ` Srikanth Korangala Hari
2018-08-17  3:36       ` Al Viro [this message]
2018-08-17  3:36         ` Al Viro

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=20180817033606.GB6515@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=adobriyan@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=srikanth.h@samsung.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.