All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: Petr Mladek <pmladek@suse.com>
Cc: Jiri Kosina <jikos@kernel.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Jason Baron <jbaron@akamai.com>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	Evgenii Shatokhin <eshatokhin@virtuozzo.com>,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] livepatch: Handle failing allocation of shadow variables in the selftest
Date: Thu, 31 Jan 2019 09:40:25 +0100 (CET)	[thread overview]
Message-ID: <alpine.LSU.2.21.1901310936510.26726@pobox.suse.cz> (raw)
In-Reply-To: <20190130084603.bxm57h6wf47b45fs@pathway.suse.cz>

On Wed, 30 Jan 2019, Petr Mladek wrote:

> On Mon 2019-01-21 13:14:38, Miroslav Benes wrote:
> > Hi,
> > 
> > On Wed, 16 Jan 2019, Petr Mladek wrote:
> > 
> > > Do not dereference pointers to the shadow variables when either
> > > klp_shadow_alloc() or klp_shadow_get() fail.
> > 
> > I may misunderstand the patch, so bear with me, please. Is this because of 
> > a possible null pointer dereference? If yes, shouldn't this say rather 
> > "when both klp_shadow_alloc() and klp_shadow_get() fail"?
> 
> Well, klp_shadow_get() could fail also from other reasons if there is
> a bug in the implementation.

Yes, but I meant that if only klp_shadow_alloc() or klp_shadow_get() 
failed, it would be caught by ret == sv1 comparison and you would not need 
to add checking of ret at the beginning.
 
> > > There is no need to check the other locations explicitly. The test
> > > would fail if any allocation fails. And the existing messages, printed
> > > during the test, provide enough information to debug eventual problems.
> 
> Heh, this is actually the reason why I did not add the check
> for shadow_alloc(). Any error would be detected later
> with klp_shadow_get() calls that should get tested anyway.
> 
> Hmm, when I think about it. A good practice is to handle
> klp_shadow_allow() or klp_shadow_get() failures immediately.
> After all, it is the sample code that people might follow.

I think so. 

> > > Signed-off-by: Petr Mladek <pmladek@suse.com>
> > > ---
> > >  lib/livepatch/test_klp_shadow_vars.c | 8 ++++----
> > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/lib/livepatch/test_klp_shadow_vars.c b/lib/livepatch/test_klp_shadow_vars.c
> > > index 02f892f941dc..55e6820430dc 100644
> > > --- a/lib/livepatch/test_klp_shadow_vars.c
> > > +++ b/lib/livepatch/test_klp_shadow_vars.c
> > > @@ -162,15 +162,15 @@ static int test_klp_shadow_vars_init(void)
> > >  	 * to expected data.
> > >  	 */
> > >  	ret = shadow_get(obj, id);
> > > -	if (ret == sv1 && *sv1 == &var1)
> > > +	if (ret && ret == sv1 && *sv1 == &var1)
> > >  		pr_info("  got expected PTR%d -> PTR%d result\n",
> > >  			ptr_id(sv1), ptr_id(*sv1));
> > >  	ret = shadow_get(obj + 1, id);
> > > -	if (ret == sv2 && *sv2 == &var2)
> > > +	if (ret && ret == sv2 && *sv2 == &var2)
> > >  		pr_info("  got expected PTR%d -> PTR%d result\n",
> > >  			ptr_id(sv2), ptr_id(*sv2));
> > >  	ret = shadow_get(obj, id + 1);
> > > -	if (ret == sv3 && *sv3 == &var3)
> > > +	if (ret && ret == sv3 && *sv3 == &var3)
> > >  		pr_info("  got expected PTR%d -> PTR%d result\n",
> > >  			ptr_id(sv3), ptr_id(*sv3));
> > 
> > There is one more similar site calling shadow_get(obj, id + 1) which is 
> > fixed.
> 
> Heh, I think that I did not add the check there on purpose.
> If we are here, shadow_get(obj, id + 1) must have already succeeded
> above.

Yes, but if it failed, you would not notice. The message would not be 
printed and that's all. So it is possible to run into the same problematic 
error condition here.

> But it is a bad practice. We should always check the output.
> I'll do so in v2.

Agreed.

Miroslav

  reply	other threads:[~2019-01-31  8:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 16:17 [PATCH 0/4] livepatch: Followup changes for the atomic replace patchset Petr Mladek
2019-01-16 16:17 ` [PATCH 1/4] livepatch: Introduce klp_for_each_patch macro Petr Mladek
2019-01-21 12:10   ` Miroslav Benes
2019-01-21 22:34   ` Joe Lawrence
2019-01-16 16:17 ` [PATCH 2/4] livepatch: Handle failing allocation of shadow variables in the selftest Petr Mladek
2019-01-21 12:14   ` Miroslav Benes
2019-01-30  8:46     ` Petr Mladek
2019-01-31  8:40       ` Miroslav Benes [this message]
2019-01-21 22:40   ` Joe Lawrence
2019-01-30  8:56     ` Petr Mladek
2019-01-16 16:17 ` [PATCH 3/4] livepatch: Module coming and going callbacks can proceed all listed patches Petr Mladek
2019-01-21 14:45   ` Miroslav Benes
2019-01-21 22:47   ` Joe Lawrence
2019-01-16 16:17 ` [PATCH 4/4] livepatch: Remove the redundant enabled flag in struct klp_patch Petr Mladek
2019-01-21 22:50   ` Joe Lawrence
2019-01-22 10:06   ` Miroslav Benes
2019-01-23 18:27     ` Joe Lawrence
2019-01-29 20:00       ` Josh Poimboeuf
2019-01-30  9:44         ` Petr Mladek
2019-02-01 16:03 ` [PATCH 0/4] livepatch: Followup changes for the atomic replace patchset Joe Lawrence
2019-02-04  9:40   ` Petr Mladek

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=alpine.LSU.2.21.1901310936510.26726@pobox.suse.cz \
    --to=mbenes@suse.cz \
    --cc=eshatokhin@virtuozzo.com \
    --cc=jbaron@akamai.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=pmladek@suse.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.