On Fri, 20 Jan 2017, Peter Zijlstra wrote:
> On Wed, Jan 18, 2017 at 04:19:47PM -0800, Andy Lutomirski wrote:
> > ISTM even with pagefault_disable() in play, using access_ok() from,
> > say, interrupt context is dangerous unless you've first checked that
> > you're in a task. But I guess that in_
On Wed, Jan 18, 2017 at 04:19:47PM -0800, Andy Lutomirski wrote:
> ISTM even with pagefault_disable() in play, using access_ok() from,
> say, interrupt context is dangerous unless you've first checked that
> you're in a task. But I guess that in_task() would still return
> false, e.g. in perf.
Th
Frank.
On Thu, 19 Jan 2017, Frank Ch. Eigler wrote:
> > Well, if you are not in thread context then the check is pointless:
> > __range_not_ok(addr, size, user_addr_max())
> > and:
> > #define user_addr_max() (current->thread.addr_limit.seg)
> >
> > So what guarantees when you are not in cont
On Thu, Jan 19, 2017 at 04:27:18PM -0500, Frank Ch. Eigler wrote:
> Hi, Thomas -
>
> > Well, if you are not in thread context then the check is pointless:
> > __range_not_ok(addr, size, user_addr_max())
> > and:
> > #define user_addr_max() (current->thread.addr_limit.seg)
> >
> > So what guar
Hi, Thomas -
> Well, if you are not in thread context then the check is pointless:
> __range_not_ok(addr, size, user_addr_max())
> and:
> #define user_addr_max() (current->thread.addr_limit.seg)
>
> So what guarantees when you are not in context of current, i.e. in thread
> context, that th
On Thu, 19 Jan 2017, Frank Ch. Eigler wrote:
> Hi, Thomas -
>
> On Thu, Jan 19, 2017 at 07:12:48PM +0100, Thomas Gleixner wrote:
> > [...]
> > 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.
> > [...
Hi, Thomas -
On Thu, Jan 19, 2017 at 07:12:48PM +0100, Thomas Gleixner wrote:
> [...]
> 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.
> [...]
> We are not papering over problems.
Understood. We were
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 acce
On 01/18/2017 06:19 PM, Andy Lutomirski wrote:
> On Wed, Jan 18, 2017 at 2:16 PM, David Smith 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/unl
On Wed, Jan 18, 2017 at 2:16 PM, David Smith wrote:
> On 01/16/2017 03:14 PM, Thomas Gleixner wrote:
>> On Mon, 16 Jan 2017, David Smith wrote:
>>
>>> If you call access_ok() with page faulting disabled, you'll still see
>>> this new warning.
>>
>> And how so? It's just checking for task context.
On 01/16/2017 03:14 PM, Thomas Gleixner wrote:
> On Mon, 16 Jan 2017, David Smith wrote:
>
>> If you call access_ok() with page faulting disabled, you'll still see
>> this new warning.
>
> And how so? It's just checking for task context. page fault disable/enable
> has absolutely nothing to do wi
On Mon, 16 Jan 2017, David Smith wrote:
> If you call access_ok() with page faulting disabled, you'll still see
> this new warning.
And how so? It's just checking for task context. page fault disable/enable
has absolutely nothing to do with that.
> If you put that new access_ok() call in a modul
If you call access_ok() with page faulting disabled, you'll still see this new
warning. 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.
How about modifying it like this:
---
From: David Smith
Dat
On Tue, Nov 22, 2016 at 11:42:19AM -0800, Linus Torvalds wrote:
> On Tue, Nov 22, 2016 at 11:37 AM, Peter Zijlstra wrote:
> >
> > CONFIG_DEBUG_VM seems somehow inappropriate.
>
> The usual might_fault() logic? That uses
>
> defined(CONFIG_PROVE_LOCKING) || defined(CONFIG_DEBUG_ATOMIC_SLEEP)
On Tue, Nov 22, 2016 at 11:37 AM, Peter Zijlstra wrote:
>
> CONFIG_DEBUG_VM seems somehow inappropriate.
The usual might_fault() logic? That uses
defined(CONFIG_PROVE_LOCKING) || defined(CONFIG_DEBUG_ATOMIC_SLEEP)
(and "might_sleep()" uses just CONFIG_DEBUG_ATOMIC_SLEEP, maybe that's fine).
On Tue, Nov 22, 2016 at 09:28:01AM -0800, Andy Lutomirski wrote:
> On Tue, Nov 22, 2016 at 1:57 AM, Peter Zijlstra wrote:
> > +#define access_ok(type, addr, size)\
> > +({ \
> > + WARN_ON
On Tue, Nov 22, 2016 at 1:57 AM, Peter Zijlstra wrote:
>
> I recently encountered wreckage because access_ok() was used where it
> should not be, add an explicit WARN when access_ok() is used wrongly.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/include/asm/uaccess.h | 7 +--
>
17 matches
Mail list logo
