From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] [RFC] zram01: Fix on ppc64le
Date: Thu, 9 Feb 2017 15:00:42 +0100 [thread overview]
Message-ID: <20170209140042.GE12673@rei.lan> (raw)
In-Reply-To: <1788271290.2108729.1486646650050.JavaMail.zimbra@redhat.com>
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.
> > 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.
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
next prev parent reply other threads:[~2017-02-09 14:00 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 [this message]
2017-02-09 14:48 ` Jan Stancek
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=20170209140042.GE12673@rei.lan \
--to=chrubis@suse.cz \
--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.