linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	broonie@kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-next@vger.kernel.org, mhocko@suse.cz,
	mm-commits@vger.kernel.org, sfr@canb.auug.org.au,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	viro@ZenIV.linux.org.uk, x86@kernel.org,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: mmotm 2020-05-13-20-30 uploaded (objtool warnings)
Date: Fri, 29 May 2020 16:53:25 +0200	[thread overview]
Message-ID: <20200529145325.GB706518@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200529143556.GE706478@hirez.programming.kicks-ass.net>

On Fri, May 29, 2020 at 04:35:56PM +0200, Peter Zijlstra wrote:
> On Fri, May 29, 2020 at 03:57:51PM +0200, Christoph Hellwig wrote:
> > On Thu, May 28, 2020 at 07:20:05PM +0200, Peter Zijlstra wrote:
> > > > on x86_64:
> > > > 
> > > > arch/x86/lib/csum-wrappers_64.o: warning: objtool: csum_and_copy_from_user()+0x2a4: call to memset() with UACCESS enabled
> > > > arch/x86/lib/csum-wrappers_64.o: warning: objtool: csum_and_copy_to_user()+0x243: return with UACCESS enabled
> > > 
> > > Urgh, that's horrible code. That's got plain stac()/clac() calls on
> > > instead of the regular uaccess APIs.
> > 
> > Does it?  If this is from the code in linux-next, then the code does a
> > user_access_begin/end in csum_and_copy_{from,to}_user, then uses
> > unsafe_{get,put}_user inside those function itself.  But then they call
> > csum_partial_copy_generic with the __user casted away, but without any
> > comment on why this is safe.
> 
> Bah, clearly I was looking at the wrong tree. You're right, Al cleaned
> it all up.
> 
> Let me try and figure out why objtool is unhappy with it.

*groan*, this is one of those CONFIG_PROFILE_ALL_BRANCHES builds. If I
disable that it goes away.

Still trying to untangle the mess it generated, but on first go it
looks like objtool is right, but I'm not sure what went wrong.

  reply	other threads:[~2020-05-29 14:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200513175005.1f4839360c18c0238df292d1@linux-foundation.org>
2020-05-14  3:31 ` mmotm 2020-05-13-20-30 uploaded Andrew Morton
2020-05-14 15:30   ` mmotm 2020-05-13-20-30 uploaded (gpu/drm/bridge/sil-sii8620) Randy Dunlap
2020-05-14 15:32   ` mmotm 2020-05-13-20-30 uploaded (objtool warnings) Randy Dunlap
2020-05-14 15:33     ` Randy Dunlap
2020-05-28 15:54     ` Josh Poimboeuf
2020-05-28 17:04       ` Josh Poimboeuf
2020-05-28 17:20     ` Peter Zijlstra
2020-05-29 13:57       ` Christoph Hellwig
2020-05-29 14:35         ` Peter Zijlstra
2020-05-29 14:53           ` Peter Zijlstra [this message]
2020-05-29 15:33             ` Peter Zijlstra
2020-05-29 16:05               ` Josh Poimboeuf
2020-05-29 16:12                 ` Peter Zijlstra
2020-05-29 16:50                   ` Josh Poimboeuf
2020-05-29 16:54                     ` Peter Zijlstra
2020-05-29 17:25                       ` [PATCH] x86/uaccess: Remove redundant likely/unlikely annotations Josh Poimboeuf
2020-05-29 18:29                         ` Randy Dunlap
2020-05-29 19:31                     ` mmotm 2020-05-13-20-30 uploaded (objtool warnings) Linus Torvalds
2020-05-29 20:08                       ` Al Viro
2020-05-29 20:14                         ` Al Viro
2020-05-15 23:30 ` mmotm 2020-05-15-16-29 uploaded Andrew Morton
2020-05-16  5:53   ` Stephen Rothwell
2020-05-18 23:15     ` Stephen Rothwell
2020-05-20  4:48 ` mmotm 2020-05-19-21-47 uploaded Andrew Morton
2020-05-22  3:43 ` mmotm 2020-05-21-20-42 uploaded Andrew Morton
2020-05-22 16:26   ` mmotm 2020-05-21-20-42 uploaded (atomisp) Randy Dunlap
2020-05-23  3:36 ` mmotm 2020-05-22-20-35 uploaded Andrew Morton
2020-05-23 15:08   ` mmotm 2020-05-22-20-35 uploaded (phy/intel/phy-intel-combo.c) Randy Dunlap

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=20200529145325.GB706518@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=hch@lst.de \
    --cc=jpoimboe@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mhocko@suse.cz \
    --cc=mm-commits@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    --cc=x86@kernel.org \
    /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).