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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D4CBEB64DA for ; Wed, 12 Jul 2023 18:52:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D33F78D0007; Wed, 12 Jul 2023 14:52:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE37E8D0002; Wed, 12 Jul 2023 14:52:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B85188D0007; Wed, 12 Jul 2023 14:52:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A61158D0002 for ; Wed, 12 Jul 2023 14:52:16 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 77B5D4032B for ; Wed, 12 Jul 2023 18:52:16 +0000 (UTC) X-FDA: 81003855072.19.81090E1 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 24704C000B for ; Wed, 12 Jul 2023 18:52:13 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WDZZGKMi; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689187934; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eNUvlVXe22EcEs7bOkbp/kMeXaobfr2lR/in313iSLU=; b=RUZRNvDsDm26N3v7rPLP4AKtUV7IbKkpm3ZfHOMC8/er1FPgUIm0QTHxQlbEH3r3S0WDiE ViZ8M/nK8gjcAUegvD8sZavXmhzj7Keb12K5Tlr6HgOhHarpM9XlSnPEFHbPFnWgTV9712 FRQBamBUEnhQEaJDpzvIGwGqoTXNPWA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689187934; a=rsa-sha256; cv=none; b=7owam+FMeJz2f94rHfoR7QBL2pCMJ4vvqBNUPMq8HqxLWXblnKQ9/P9DpQCV9DycQr/gPG oGHB0V+bPtI+H7ORiLRRx8fzZXN8qoUea83uJHilpKNm+bb2FpsNHRkLFxaqlT4FeIpHVx ExHpxdL7cgmJ1xWIf14EKko/UWOqzN4= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WDZZGKMi; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689187933; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eNUvlVXe22EcEs7bOkbp/kMeXaobfr2lR/in313iSLU=; b=WDZZGKMi2+FNvhLfqs4r7BxDvj2br5ZQ4T13cKP3J/vDEHUB0uU+SJfZrDXCHWCliBHsNk xOeRMF1qfKunPtCO1ny5KpwRf5glORMrdael6M8gNQ1F9uiy63whw34iDgeaZiU5m6vvRJ myuxmjYPz9rKMX0j0x+A6Tv6mphsIVw= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-490-RNmCzqqhPsmOrawTs1sGEA-1; Wed, 12 Jul 2023 14:52:12 -0400 X-MC-Unique: RNmCzqqhPsmOrawTs1sGEA-1 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-30e4943ca7fso3861166f8f.3 for ; Wed, 12 Jul 2023 11:52:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689187931; x=1691779931; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eNUvlVXe22EcEs7bOkbp/kMeXaobfr2lR/in313iSLU=; b=MGndDMAioeHamNMt6haTl+jNAqFRhr5p+teKZgjiZw6o+4PNMHnnOzlwEYMPQYF+jd y/jmP7+zoxi1GtaaIR+otCxH6V0uJIBkPVd3cnzupWz5qBgMNVIgECKz4tkAZMAEth6V /2aczhUkHjXXAmz9VGrtt9Cj/VR4XYrARvSuxMSkxFsaeGfOAJE3gZd0g6MsSy22OA+Q cGZ13QbI/QxHWwFlrcHpCJf25A1KhNyMZOju/9+kCiKU+2qii9NIkhFglwGND1iVpeU7 f5demoFMdmIql8LxCgSiUS62G8vFDEhdOAcM0K6WORTiior6h3VxfRkdmrlyE1bVpPSC XEvQ== X-Gm-Message-State: ABy/qLbxhS7uk6FFM+T/eZIYtV/hzNU7xBQmf90t2nrbxI9qeRnQgqEI gtjG4XR/fTI54drpGZSJbNl+3TH6Za9RHeVRj+cbgFcLb8z4tmR9FBFp+FlXUuQPPCbuDqgdioq FBkg032AgzEY= X-Received: by 2002:a5d:448b:0:b0:314:11fe:c72e with SMTP id j11-20020a5d448b000000b0031411fec72emr18456940wrq.46.1689187930827; Wed, 12 Jul 2023 11:52:10 -0700 (PDT) X-Google-Smtp-Source: APBJJlG4J9oh2cldhnx2SfzOLNxTOUZQloQ1krJy9pxx39bt2EY6cTlDAdo5Pcu68Kso+YnYmUMguA== X-Received: by 2002:a5d:448b:0:b0:314:11fe:c72e with SMTP id j11-20020a5d448b000000b0031411fec72emr18456923wrq.46.1689187930401; Wed, 12 Jul 2023 11:52:10 -0700 (PDT) Received: from ?IPV6:2003:cb:c707:3700:3eea:ace6:5bde:4478? (p200300cbc70737003eeaace65bde4478.dip0.t-ipconnect.de. [2003:cb:c707:3700:3eea:ace6:5bde:4478]) by smtp.gmail.com with ESMTPSA id y6-20020a05600c364600b003fc16ee2864sm5724545wmq.48.2023.07.12.11.52.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jul 2023 11:52:09 -0700 (PDT) Message-ID: Date: Wed, 12 Jul 2023 20:52:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [bug report] mm: replace vma->vm_flags direct modifications with modifier calls To: Matthew Wilcox Cc: Suren Baghdasaryan , Dan Carpenter , linux-mm@kvack.org, Andrew Morton , "Liam R. Howlett" , Laurent Dufour , Michel Lespinasse , Jerome Glisse , Michal Hocko , Vlastimil Babka , Johannes Weiner , Peter Xu , Dimitri Sivanich , Mike Travis , Steve Wahl References: <9704a138-60e6-4ede-91f0-844e1df2ad84@moroto.mountain> <331201b2-5f13-8e81-b5d4-b17f8784d498@redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 24704C000B X-Rspam-User: X-Stat-Signature: q5jih95e7jnmbdhfb7cpnmrq5da9owdm X-Rspamd-Server: rspam03 X-HE-Tag: 1689187933-757564 X-HE-Meta: U2FsdGVkX1/JoWhAADr91qiyY1z29t4F9Hv2EaNr2vX0+ZqCYAw7TZYKjkA72ezJqz6niU2ndNnIEjxm40XKZqliy+jn9cMv2Zweofle2c15Ipb/HsFxxEJ4KEKfLUE2mRQsLIai8ou+tMU9qykoLmahJSzD1dgj/HTr2xBli2/PcniMUL8XY5G8JvSm7y+DdOBlfXDvgcZr9SnjhZkyjaBrAtRh+xtIF3TecooMeqtsxLifNSQaHp+KwEXWH0/9KdGK3UyVucwlx/4qnnBDuEzu6QcUPtKaZlR5twCBWJzy5M0u73ziY6AcbGjy9u0SUfjFD40rnb1EsZr116UmY+To52yR/aZUgIWjwVVV1qP6NcnM+l9j6mWKYrm7GDKJqqtUru1zl0ycKGcv9a/xDTdui4j2GcdvDk01ilwX4vSAh81QdzeOPuvrseRFeajp/DWAu1URUg2iincNEyNXiZHZEwNDbPDvrgiwqkyXPuOHUh4a8Y05tOt3jiBsoskKKsl1NJOyV/zuyBuxXjqWbTS2SYavWTuXAPenMHoRqIxFaaLUnSQ2VclEE17bOOFqS7/hR6SXR8kFnaIWtOyKosPrKIMB87ihxomJRMfnZJlCDnkG/eHizDDtG2yd6dlkqKUxiO6M60qZKyIpzpIJfDim5veadI+h0Ms36reH2UBAnTSC9gX/N4tZovuPu5zc+INGZ/l3+7rVVeej50kldd9M2MqhTXZDQhcChytXXjrqk7A6tXdxnY/PUCI70X0ZlkIseP20xyJ2zeRYi/kKletEULDl02/20OaCUnU5HRmSwXLX/WPC0r1/b+Vt2kaiSsLSwTQ50f+TKog/q6NRuOnlpkp17WdF82Pu3MphId3APy9Pg90UIzUnw2NSv880P0X4gAKj5RSgSxEWNxKW/m8UQPbzfo28lTRpQF7wfVNyfWrabyrNNT7pvxWsoid+jvqlGr/auna4Eq9hG6k kaqQlj6/ 8oobL2TcrWWwvOdwYWw7hqhxymNJLNyb+OcC8QVr2PU09tYp6Ixnr3R8iv09mq0YbrZ9oX4CTlN9nIoXMk7zi4dtvj3Foqoubr2MZR1NeWvWBYC91/hNVrFoxibLt+XwiFnivWYTac4XnllU6TohfzE0ZkRz4SACZSPgvaPIe1wq00LV7P4Sk2m0PmkeyraTZG6PEwciWCfwqvnbDnbyEzfzcDpWS9K68kx1sFq8xbtvKtcmM7xII43WC1z43X1PYc6wQ2AfptppsoKOnKRVeTlfnVHFyDHTTc6uc8iGz8xrDAylvM+U4WsnjbOLzqlixUiAmY9ZogyhgoeF+qGDiGWrL0A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 12.07.23 20:49, Matthew Wilcox wrote: > On Wed, Jul 12, 2023 at 05:55:47PM +0200, David Hildenbrand wrote: >> On 12.07.23 17:52, Matthew Wilcox wrote: >>> On Wed, Jul 12, 2023 at 08:01:18AM -0700, Suren Baghdasaryan wrote: >>>> Are you suggesting to break remap_pfn_range() into two stages >>>> (remap_pfn_range_prepare() then remap_pfn_range())? >>>> If so, there are many places remap_pfn_range() is called and IIUC all >>>> of them would need to use that 2-stage approach (lots of code churn). >>>> In addition, this is an exported function, so many more drivers might >>>> expect the current behavior. >>> >>> You do not understand correctly. >>> >>> When somebody calls mmap, there are two reasonable implementations. >>> Here's one: >>> >>> .mmap = snd_dma_iram_mmap, >>> >>> static int snd_dma_iram_mmap(struct snd_dma_buffer *dmab, >>> struct vm_area_struct *area) >>> { >>> area->vm_page_prot = pgprot_writecombine(area->vm_page_prot); >>> return remap_pfn_range(area, area->vm_start, >>> dmab->addr >> PAGE_SHIFT, >>> area->vm_end - area->vm_start, >>> area->vm_page_prot); >>> } >>> >>> This is _fine_. It is not called from the fault path, it is called in >>> process context. Few locks are held (which ones aren't even >>> documented!) >>> >>> The other way is to set vma->vm_ops. The fault handler in vm_ops >>> should not be calling remap_pfn_range(). It should be calling >>> set_ptes(). I almost have this driver fixed up, but I have another >>> meeting to go to now. >> >> Just a note that we still have to make sure that the VMA flags will be set >> properly -- I guess at mmap time is the right time as I suggested above. > > It actually does that already: > > static int gru_file_mmap(struct file *file, struct vm_area_struct *vma) > { > if ((vma->vm_flags & (VM_SHARED | VM_WRITE)) != (VM_SHARED | VM_WRITE)) > return -EPERM; > > if (vma->vm_start & (GRU_GSEG_PAGESIZE - 1) || > vma->vm_end & (GRU_GSEG_PAGESIZE - 1)) > return -EINVAL; > > vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_LOCKED | > VM_DONTCOPY | VM_DONTEXPAND | VM_DONTDUMP); > > > This compiles, but obviously I don't have a spare HP supercomputer lying > around for me to test whether it works. Also set_ptes() was only just > introduced to the mm tree, so doing something that needs backporting > would take more effort (maybe having a private set_ptes() in the driver > would be a good backport option that calls set_pte_at() in a loop). > > > diff --git a/drivers/misc/sgi-gru/grumain.c b/drivers/misc/sgi-gru/grumain.c > index 4eb4b9455139..c21bcb528f12 100644 > --- a/drivers/misc/sgi-gru/grumain.c > +++ b/drivers/misc/sgi-gru/grumain.c > @@ -951,6 +951,8 @@ vm_fault_t gru_fault(struct vm_fault *vmf) > } > > if (!gts->ts_gru) { > + pte_t *ptep, pte; > + > STAT(load_user_context); > if (!gru_assign_gru_context(gts)) { > preempt_enable(); > @@ -964,9 +966,12 @@ vm_fault_t gru_fault(struct vm_fault *vmf) > } > gru_load_context(gts); > paddr = gseg_physical_address(gts->ts_gru, gts->ts_ctxnum); > - remap_pfn_range(vma, vaddr & ~(GRU_GSEG_PAGESIZE - 1), > - paddr >> PAGE_SHIFT, GRU_GSEG_PAGESIZE, > - vma->vm_page_prot); > + > + pte = pfn_pte(paddr / PAGE_SIZE, vma->vm_page_prot); > + ptep = vmf->pte - (vaddr % GRU_GSEG_PAGESIZE) / PAGE_SIZE; > + set_ptes(vma->vm_mm, vaddr & ~(GRU_GSEG_PAGESIZE - 1), > + ptep, pte_mkspecial(pte), > + GRU_GSEG_PAGESIZE / PAGE_SIZE); > } > > preempt_enable(); > Would we be able to fix it in stable simply by not triggering the vm_flags_set() in case these flags are already set? -- Cheers, David / dhildenb