linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	"Paul E. McKenney" <paulmck@kernel.org>
Subject: Re: linux-next: Tree for Nov 20 (kcsan + objtool)
Date: Wed, 20 Nov 2019 20:48:41 +0100	[thread overview]
Message-ID: <CANpmjNOHTyTRCeo3oxEPTY__TCjAQ8nMvcqDSZ6Otfs7vVESSA@mail.gmail.com> (raw)
In-Reply-To: <58708908-84a0-0a81-a836-ad97e33dbb62@infradead.org>

On Wed, 20 Nov 2019 at 17:18, Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 11/20/19 1:34 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20191119:
> >
>
> on x86_64:
>
> kernel/kcsan/core.o: warning: objtool: kcsan_found_watchpoint()+0xa: call to kcsan_is_enabled() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_read1()+0x13: call to find_watchpoint() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_write1()+0x10: call to find_watchpoint() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_read2()+0x13: call to find_watchpoint() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_write2()+0x10: call to find_watchpoint() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_read4()+0x13: call to find_watchpoint() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_write4()+0x10: call to find_watchpoint() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_read8()+0x13: call to find_watchpoint() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_write8()+0x10: call to find_watchpoint() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_read16()+0x13: call to find_watchpoint() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_write16()+0x10: call to find_watchpoint() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_read_range()+0x13: call to find_watchpoint() with UACCESS enabled
> kernel/kcsan/core.o: warning: objtool: __tsan_write_range()+0x10: call to find_watchpoint() with UACCESS enabled
>
> kernel/trace/trace_branch.o: warning: objtool: ftrace_likely_update()+0x361: call to __stack_chk_fail() with UACCESS enabled
>
>
> Full randconfig file is attached.

Thanks.

This is due to CONFIG_CC_OPTIMIZE_FOR_SIZE=y. It seems the compiler
decides to not even inline small static inline functions. I tried to
make this go away by adding __always_inline, but then we're also left
with atomic64_try_cmpxchg which never gets inlined.

The optimized build simply inlines the small static inline functions.
We certainly do not want to add more functions to the objtool
whitelist, especially those that are private to KCSAN.

We could fix it by either:

1. Adding __always_inline to every function used by the KCSAN runtime
outside user_access_save + also fix atomic64_try_cmpxchg
(atomic-instrumented.h).

2. Just not compile KCSAN with -Os, i.e. have the Makefile strip -Os
and replace it with -O2 for kcsan/core.c. #2 is the simpler option,
and would probably make KCSAN more effective even with -Os. Although
it might violate the assumption of whoever decided they want both
CC_OPTIMIZE_FOR_SIZE and KCSAN. It might also mean that future
compilers that have a new inlining algorithm will have the same
problem.

What do people think is better?

Thanks,
-- Marco

> --
> ~Randy
> Reported-by: Randy Dunlap <rdunlap@infradead.org>

  reply	other threads:[~2019-11-20 19:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-20  9:34 linux-next: Tree for Nov 20 Stephen Rothwell
2019-11-20 11:22 ` Naresh Kamboju
2019-11-20 16:18 ` linux-next: Tree for Nov 20 (kcsan + objtool) Randy Dunlap
2019-11-20 19:48   ` Marco Elver [this message]
2019-11-21 18:37     ` Josh Poimboeuf
2019-11-21 18:43       ` Marco Elver
2019-11-22 15:48         ` Marco Elver
2020-03-24  9:11   ` [tip: locking/kcsan] kcsan: Prefer __always_inline for fast-path tip-bot2 for Marco Elver

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=CANpmjNOHTyTRCeo3oxEPTY__TCjAQ8nMvcqDSZ6Otfs7vVESSA@mail.gmail.com \
    --to=elver@google.com \
    --cc=dvyukov@google.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=sfr@canb.auug.org.au \
    /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).