All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] [RFC] zram01: Fix on ppc64le
Date: Thu, 9 Feb 2017 09:48:08 -0500 (EST)	[thread overview]
Message-ID: <116936368.2235095.1486651688068.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20170209140042.GE12673@rei.lan>



----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Thursday, 9 February, 2017 3:00:42 PM
> Subject: Re: [LTP] [PATCH] [RFC] zram01: Fix on ppc64le
> 
> Hi!
> > > > There is still one unsolved problem since the TWARN messages from the
> > > > tst_device.c will trigger TBROK in tst_test.c since the IPC is not
> > > > initialized. I'm still unsure how to fix that, maybe we should allow to
> > > > allocate non-shared structure for the results in the special case that
> > > > the library code is being reused in shell helpers.
> > > 
> > > Maybe we should just add an API to redirect tst_brk() and tst_res() so
> > > that we could use library code in the various non-test utilities.
> > 
> > Or drop that TBROK?
> 
> It's especially there for code that defines TST_NO_DEFAULT_MAIN but one
> can argue that this is special case and if you define that macro you
> should know what you are doing anyway...
> 
> But still I prefer to throw error message instead of segfaulting while
> trying to deference NULL pointer.

I was suggesting we skip update_results(), not to let it segfault.

> 
> > > Maybe
> > > we could patch things up so that we could use SAFE_MACROS() in cleanup
> > > as well...
> > 
> > This should be doable with some flag we set in do_test_cleanup(), to skip
> > further calls.
> 
> I'm nearly finished with RFC patch. The main problem is the
> __attribute__((noreturn)) that has been added for various tst_brk*
> variants. So in the end it looks like only solution is to do the
> tst_brk_() redirection in the safe_macros.c, since we cannot return from
> tst_brkm_() since the return address is not stored on stack because it
> has noreturn attribute. And dropping the noreturn attribute from
> tst_brkm_() is not an option either, since that generates a ton of
> "control reaches end of non-void function" warnings.

Vast majority is from single header file:

$ grep "reaches end of non-void" log.txt | sort | uniq | wc -l
328

$ grep "reaches end of non-void" log.txt | sort | uniq | grep compat_16.h | wc -l
289

> 
> But it's quite easy to define a macro or two that does the same
> redirection as we do in tst_brkm_() so that we never reach the oldlib
> code from safe_macros.c if newlib test is running.
> 
> --
> Cyril Hrubis
> chrubis@suse.cz
> 

  reply	other threads:[~2017-02-09 14:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-31 13:44 [LTP] [PATCH] [RFC] zram01: Fix on ppc64le Cyril Hrubis
2017-01-31 16:14 ` Jan Stancek
2017-02-01  9:45   ` Cyril Hrubis
2017-02-01 10:59     ` Jan Stancek
2017-02-02 15:22       ` Cyril Hrubis
2017-02-08 11:10         ` Cyril Hrubis
2017-02-09 12:02           ` Cyril Hrubis
2017-02-09 13:24             ` Jan Stancek
2017-02-09 14:00               ` Cyril Hrubis
2017-02-09 14:48                 ` Jan Stancek [this message]
2017-02-09 14:56                   ` Cyril Hrubis
2017-08-15  9:23 ` Cyril Hrubis
2017-08-15 11:44   ` Jan Stancek
2017-08-15 12:38     ` Cyril Hrubis
2017-08-15 12:48       ` Jan Stancek
2017-08-15 12:57         ` Cyril Hrubis

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=116936368.2235095.1486651688068.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --cc=ltp@lists.linux.it \
    /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.