From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C5B3C282CE for ; Wed, 22 May 2019 17:40:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 65CAA21473 for ; Wed, 22 May 2019 17:40:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729531AbfEVRkV (ORCPT ); Wed, 22 May 2019 13:40:21 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:59166 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727499AbfEVRkV (ORCPT ); Wed, 22 May 2019 13:40:21 -0400 Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::3d8]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 39F1515002414; Wed, 22 May 2019 10:40:20 -0700 (PDT) Date: Wed, 22 May 2019 10:40:19 -0700 (PDT) Message-Id: <20190522.104019.40493905027242516.davem@davemloft.net> To: rick.p.edgecombe@intel.com Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, linux-mm@kvack.org, mroos@linux.ee, mingo@redhat.com, namit@vmware.com, luto@kernel.org, bp@alien8.de, netdev@vger.kernel.org, dave.hansen@intel.com, sparclinux@vger.kernel.org Subject: Re: [PATCH v2] vmalloc: Fix issues with flush flag From: David Miller In-Reply-To: <339ef85d984f329aa66f29fa80781624e6e4aecc.camel@intel.com> References: <20190520.184336.743103388474716249.davem@davemloft.net> <339ef85d984f329aa66f29fa80781624e6e4aecc.camel@intel.com> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 22 May 2019 10:40:20 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Edgecombe, Rick P" Date: Tue, 21 May 2019 01:59:54 +0000 > On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote: >> From: "Edgecombe, Rick P" >> Date: Tue, 21 May 2019 01:20:33 +0000 >> >> > Should it handle executing an unmapped page gracefully? Because >> > this >> > change is causing that to happen much earlier. If something was >> > relying >> > on a cached translation to execute something it could find the >> > mapping >> > disappear. >> >> Does this work by not mapping any kernel mappings at the beginning, >> and then filling in the BPF mappings in response to faults? > No, nothing too fancy. It just flushes the vm mapping immediatly in > vfree for execute (and RO) mappings. The only thing that happens around > allocation time is setting of a new flag to tell vmalloc to do the > flush. > > The problem before was that the pages would be freed before the execute > mapping was flushed. So then when the pages got recycled, random, > sometimes coming from userspace, data would be mapped as executable in > the kernel by the un-flushed tlb entries. If I am to understand things correctly, there was a case where 'end' could be smaller than 'start' when doing a range flush. That would definitely kill some of the sparc64 TLB flush routines. From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Date: Wed, 22 May 2019 17:40:19 +0000 Subject: Re: [PATCH v2] vmalloc: Fix issues with flush flag Message-Id: <20190522.104019.40493905027242516.davem@davemloft.net> List-Id: References: <20190520.184336.743103388474716249.davem@davemloft.net> <339ef85d984f329aa66f29fa80781624e6e4aecc.camel@intel.com> In-Reply-To: <339ef85d984f329aa66f29fa80781624e6e4aecc.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: rick.p.edgecombe@intel.com Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, linux-mm@kvack.org, mroos@linux.ee, mingo@redhat.com, namit@vmware.com, luto@kernel.org, bp@alien8.de, netdev@vger.kernel.org, dave.hansen@intel.com, sparclinux@vger.kernel.org From: "Edgecombe, Rick P" Date: Tue, 21 May 2019 01:59:54 +0000 > On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote: >> From: "Edgecombe, Rick P" >> Date: Tue, 21 May 2019 01:20:33 +0000 >> >> > Should it handle executing an unmapped page gracefully? Because >> > this >> > change is causing that to happen much earlier. If something was >> > relying >> > on a cached translation to execute something it could find the >> > mapping >> > disappear. >> >> Does this work by not mapping any kernel mappings at the beginning, >> and then filling in the BPF mappings in response to faults? > No, nothing too fancy. It just flushes the vm mapping immediatly in > vfree for execute (and RO) mappings. The only thing that happens around > allocation time is setting of a new flag to tell vmalloc to do the > flush. > > The problem before was that the pages would be freed before the execute > mapping was flushed. So then when the pages got recycled, random, > sometimes coming from userspace, data would be mapped as executable in > the kernel by the un-flushed tlb entries. If I am to understand things correctly, there was a case where 'end' could be smaller than 'start' when doing a range flush. That would definitely kill some of the sparc64 TLB flush routines.