[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200529135750.GA1580@lst.de>
Date: Fri, 29 May 2020 15:57:51 +0200
From: Christoph Hellwig <hch@....de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Randy Dunlap <rdunlap@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>, broonie@...nel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-next@...r.kernel.org, mhocko@...e.cz,
mm-commits@...r.kernel.org, sfr@...b.auug.org.au,
Josh Poimboeuf <jpoimboe@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
viro@...IV.linux.org.uk, hch@....de, x86@...nel.org
Subject: Re: mmotm 2020-05-13-20-30 uploaded (objtool warnings)
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.
Powered by blists - more mailing lists