From: Thomas Gleixner <tglx@linutronix.de>
To: David Smith <dsmith@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andy Lutomirski <luto@amacapital.net>,
Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Frank Ch. Eigler" <fche@redhat.com>
Subject: Re: [RFC][PATCH] x86: Verify access_ok() context
Date: Thu, 19 Jan 2017 19:12:48 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1701191910080.5358@nanos> (raw)
In-Reply-To: <8758e5b4-050d-a5dd-2e58-e4f9dccc734b@redhat.com>
On Wed, 18 Jan 2017, David Smith wrote:
> On 01/16/2017 03:14 PM, Thomas Gleixner wrote:
> >> If you put that new access_ok() call in a module that gets
> >> loaded/unloaded, you see one warning for every module load, which gets a
> >> bit annoying.
> >
> > Can you please elaborate where this access_ok() is placed in the module
> > code?
>
> It doesn't really matter where you place the access_ok() call in the
> module code.
It does matter very much, because the fact that the warning triggers tells
me that it's placed in code which is NOT executed in task context.
> If you call access_ok() in a module, then that module has
> its own WARN_ON_ONCE() static variable. If access_ok() was a function
> exported from the kernel, then there would be only one copy of the
> WARN_ON_ONCE() static variable.
Not a big deal. If access_ok() is called from the wrong context in that
module then this should be fixed and not the warning supressed.
We are not papering over problems.
Thanks,
tglx
next prev parent reply other threads:[~2017-01-19 18:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-22 9:57 [RFC][PATCH] x86: Verify access_ok() context Peter Zijlstra
2016-11-22 17:28 ` Andy Lutomirski
2016-11-22 19:37 ` Peter Zijlstra
2016-11-22 19:42 ` Linus Torvalds
2016-12-05 10:27 ` Peter Zijlstra
2017-01-16 20:27 ` David Smith
2017-01-16 21:14 ` Thomas Gleixner
2017-01-18 22:16 ` David Smith
2017-01-19 0:19 ` Andy Lutomirski
2017-01-19 15:37 ` David Smith
2017-01-20 8:24 ` Peter Zijlstra
2017-01-20 8:50 ` Thomas Gleixner
2017-01-19 18:12 ` Thomas Gleixner [this message]
2017-01-19 20:22 ` Frank Ch. Eigler
2017-01-19 20:50 ` Thomas Gleixner
2017-01-19 21:27 ` Frank Ch. Eigler
2017-01-19 22:20 ` Peter Zijlstra
2017-01-19 23:04 ` Thomas Gleixner
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=alpine.DEB.2.20.1701191910080.5358@nanos \
--to=tglx@linutronix.de \
--cc=dsmith@redhat.com \
--cc=fche@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.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