From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751637AbdASAVA (ORCPT ); Wed, 18 Jan 2017 19:21:00 -0500 Received: from mail-ua0-f176.google.com ([209.85.217.176]:36768 "EHLO mail-ua0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751400AbdASAUy (ORCPT ); Wed, 18 Jan 2017 19:20:54 -0500 MIME-Version: 1.0 In-Reply-To: <8758e5b4-050d-a5dd-2e58-e4f9dccc734b@redhat.com> References: <20161122095715.GN3092@twins.programming.kicks-ass.net> <20161122193720.GA3045@worktop.programming.kicks-ass.net> <20161205102747.GT3092@twins.programming.kicks-ass.net> <8758e5b4-050d-a5dd-2e58-e4f9dccc734b@redhat.com> From: Andy Lutomirski Date: Wed, 18 Jan 2017 16:19:47 -0800 Message-ID: Subject: Re: [RFC][PATCH] x86: Verify access_ok() context To: David Smith Cc: Thomas Gleixner , Peter Zijlstra , Linus Torvalds , Ingo Molnar , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , "Frank Ch. Eigler" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v0J0LVO5016872 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. page fault disable/enable >> has absolutely nothing to do with that. > > True, task context and page fault disable/enable have nothing to do with each other. However, the access_ok() comment states: > > * Context: User context only. This function may sleep if pagefaults are > * enabled. > > That seems to indicate that the function won't sleep if pagefaults are disabled, and thus there is no need for a CONFIG_DEBUG_ATOMIC_SLEEP warning if pagefaults are disabled. 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. > >>> 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.