[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <98694f81-234e-fc7b-9bd4-477a07d91ef2@redhat.com>
Date: Thu, 19 Jan 2017 09:37:35 -0600
From: David Smith <dsmith@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Frank Ch. Eigler" <fche@...hat.com>
Subject: Re: [RFC][PATCH] x86: Verify access_ok() context
On 01/18/2017 06:19 PM, Andy Lutomirski wrote:
> On Wed, Jan 18, 2017 at 2:16 PM, David Smith <dsmith@...hat.com> wrote:
>> On 01/16/2017 03:14 PM, Thomas Gleixner wrote:
>>> On Mon, 16 Jan 2017, David Smith wrote:
... stuff deleted ...
>>>> 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. 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.
>
> That doesn't seem like such a big deal to me.
To be clear here, I'm not suggesting we replace the access_ok() macro
with an exported kernel function. I'm just stating the fact that if you
have several modules that call the access_ok() macro (or one module that
gets loaded/unloaded/reloaded multiple times), each one can produce the
new warning. I'm not seeing a "flood" of these new warnings, but a
steady enough stream of them to be annoying.
--
David Smith
dsmith@...hat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
Powered by blists - more mailing lists