Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1163119AbbKFUzO (ORCPT ); Fri, 6 Nov 2015 15:55:14 -0500 Received: from mail-ig0-f182.google.com ([209.85.213.182]:36621 "EHLO mail-ig0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1163038AbbKFUzJ (ORCPT ); Fri, 6 Nov 2015 15:55:09 -0500 MIME-Version: 1.0 In-Reply-To: References: <20151106192205.351595349@linuxfoundation.org> <20151106192205.899033919@linuxfoundation.org> Date: Fri, 6 Nov 2015 12:55:08 -0800 X-Google-Sender-Auth: CKJ89QVEeAO-686zYByOelRmQzU Message-ID: Subject: Re: [PATCH 4.1 11/86] iommu/amd: Fix BUG when faulting a PROT_NONE VMA From: Linus Torvalds To: Greg Kroah-Hartman Cc: Linux Kernel Mailing List , stable , Jay Cornwall , Joerg Roedel , linux-mm 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-Length: 1280 Lines: 30 On Fri, Nov 6, 2015 at 12:49 PM, Linus Torvalds wrote: > > And some "handle_mm_fault would BUG_ON()" comment is just bogus. It's > not handle_mm_fault()'s case that you called it without checking > proper permissions. Side note: as to why handle_mm_fault() doesn't just do things itself, there's a historical situation where we used to let people do things in ptrace() that they couldn't do directly, and punch through protections (and turn shared read-only pages into a dirty private page). So the permissions checking was up to the caller, because some callers could do things that other callers could not. I *think* we have gotten rid of all those cases, and I guess we could consider just making handle_mm_fault() itself stricter. But that's the historical background on why callers need to check this. Adding linux-mm to the cc, to see if anybody there has some comments wrt just moving all the EFAULT handling into handle_mm_fault() and relaxing the caller requirements. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/