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 E153DD6EC08 for ; Fri, 29 Nov 2024 13:24:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 640096B0088; Fri, 29 Nov 2024 08:24:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C8FF6B0089; Fri, 29 Nov 2024 08:24:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F4B56B008C; Fri, 29 Nov 2024 08:24:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 219196B0088 for ; Fri, 29 Nov 2024 08:24:34 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C80691211EB for ; Fri, 29 Nov 2024 13:24:33 +0000 (UTC) X-FDA: 82839201690.13.B59781E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf06.hostedemail.com (Postfix) with ESMTP id A0EB2180002 for ; Fri, 29 Nov 2024 13:24:25 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Ecmx/PLi"; spf=pass (imf06.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=1732886662; 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=nU/jhm6YJGAWyK6WiBgAqwh22b8bPeKCDvr+ExJWlOQ=; b=7R2A+kit3N7YKcBnA/rV2xXrhrv+RYjLZ9M4JoD5uXqwfDTFF+JuiAkTawcdz/0WWz8GwY I2WmVwvQCLVNMUmgK0+ZHrVNWVOr8PWyZkK2kJLxsUAk3yXFWQsVkj92GOyUYKQNTU46KH PTjYZKZg6ujIMQM2mfE0V+4wrF2BrOk= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Ecmx/PLi"; spf=pass (imf06.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732886662; a=rsa-sha256; cv=none; b=4JsaUEiVbBAaU3sNT+26qXUoViQWmM2dKCDG5Z4ELOosP19JMx+LUKTYo42+Kl0jtXTJZQ IJne+i3QiELdzc2mY4A9kY0nx59C7xCsTT/pNuzj/k7WRk81nyhFL7vrY3flz+2UtX9213 +/QmpvOtgJU7pygg0fhBAcNQ/B/VGj0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732886670; 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:autocrypt:autocrypt; bh=nU/jhm6YJGAWyK6WiBgAqwh22b8bPeKCDvr+ExJWlOQ=; b=Ecmx/PLilYe0qbsQZ9JFpfv81jx3yIq4CamFELgtMj8IT08jMrG6k63VpB4OJ2YOuMf7tU L3r2qlfPJqqRhyUdH6CgTaTkl83p+Z6CzpZqlq2HrfwL22iIGDIePXDnc+mPA52Glqa9cU exY7X/TRdJxddpPr80XnUEJ3Nt2ogOU= 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-616-vpLlr76BNPesxEe6NBGLQQ-1; Fri, 29 Nov 2024 08:24:29 -0500 X-MC-Unique: vpLlr76BNPesxEe6NBGLQQ-1 X-Mimecast-MFC-AGG-ID: vpLlr76BNPesxEe6NBGLQQ Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-385e0f3873cso113565f8f.0 for ; Fri, 29 Nov 2024 05:24:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732886668; x=1733491468; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=nU/jhm6YJGAWyK6WiBgAqwh22b8bPeKCDvr+ExJWlOQ=; b=Rww2F+WF2TLkYlINJx6T8oae9x4/c7KJMx0GV8sfvGhz6n6tVmgtWI+XlZlmN3IRpA DNcA6BPLEfjq6vUekiGHBhtSJEge8CH8gSEEt0O6Wo1SXE65C50LwIiv558c344ihXwO VP89t73G7k011B8hO/hXn7b4G2NENiPaqHhZ8kVmqfyPeapAlfCiiwKCo9YtR6nNjTus oyxEve1sA8Ug2eJFD+hDwrZlNBYg9nmPvlMGfzSO/rleQZd55lwNM+SPKRtsFpRc21vW YIGMRncT3ZTNU3poPBnMFoG91uYr//ps5eNneXZXymy4toEyV8s4x3ZDS2IbeMlmF7gd PApQ== X-Forwarded-Encrypted: i=1; AJvYcCWf6Z+e5L5X5mxOTC2fkXfnps7cpASEVk+rSaxpP3KKP4ObwcjNYqyxZDiW5RyxP7SL8zJXMQvjlg==@kvack.org X-Gm-Message-State: AOJu0YzyZ6+kdFIPKNKRV3RPWBh4K67TvndMrMTuaGQU/goojjQjfeuL ooSt5oxha/KjgAWD1jF5NPX0FeF61So7yGmVoWqmdH56LEZHH1iqP980EKoevETYCEb/7PhxJ/q eBH37rxWu9wTmnv6nUdOeYZ0eG4IetOmRQ6psRJOOgP5OcH7u X-Gm-Gg: ASbGncuAs01EL7JQgEm54cTaXxe+1ve4rZPnb+vp5kTrk+1H6NOdHz7/k9CJvM3lhW3 3OC1cPBY1RTrHRjJdr4/XHdyfBWW+rGTT8Ez9gYA3zqbbtAU0m9NLO7DRP0NuAaP4vfcMqeODwr IfJtACtzQyqlkrslzGCApWzhXD7QFF9uZ1qYTg+3RbHM9RBOWOM/VF5u+vRWpXXNfa33cknk96d rYPMJJy9rFaeTpw7S4q3aJxrPzk01fZrRJ87ZyRkj+DJ/iu1bjU93NUwCOzbBofGoXzvH02JGI5 iE05XbFnh6Q/h3guNbUiT+f4SO5MkgsVWg8i9jrvntI6lV/bKaS2ctKE1wEJOVsYXsvevfJ3kab l9A== X-Received: by 2002:a05:6000:4009:b0:37d:4ef1:1820 with SMTP id ffacd0b85a97d-385c6edb1c4mr9170062f8f.40.1732886668042; Fri, 29 Nov 2024 05:24:28 -0800 (PST) X-Google-Smtp-Source: AGHT+IHLKDmL48MsT1X5+ui/hTCh0Qw8COAwExjjwUMjnOm7abKhFVTHpkYAEIWAlS1RhZN754RaxA== X-Received: by 2002:a05:6000:4009:b0:37d:4ef1:1820 with SMTP id ffacd0b85a97d-385c6edb1c4mr9170033f8f.40.1732886667610; Fri, 29 Nov 2024 05:24:27 -0800 (PST) Received: from ?IPV6:2003:cb:c71c:a700:bba7:849a:ecf1:5404? (p200300cbc71ca700bba7849aecf15404.dip0.t-ipconnect.de. [2003:cb:c71c:a700:bba7:849a:ecf1:5404]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-385e17574ebsm129495f8f.30.2024.11.29.05.24.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Nov 2024 05:24:26 -0800 (PST) Message-ID: <6795cc9a-6230-431f-b089-7909f7bc4f30@redhat.com> Date: Fri, 29 Nov 2024 14:24:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] perf: map pages in advance To: Lorenzo Stoakes Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Kan Liang , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Matthew Wilcox References: <1af66528-0551-4735-87f3-d5feadadf33a@lucifer.local> <926b3829-784f-47b8-9903-ea7b9ad484ac@redhat.com> <31e8202d-f3db-4dcd-a988-2f531b14e40f@lucifer.local> <84fed269-3f82-47f7-89cb-671fcee5a23a@redhat.com> <20241129122624.GH24400@noisy.programming.kicks-ass.net> <74be541b-22ad-42b5-b3c5-79b201e28f04@redhat.com> <9d6be5bd-ffb9-4a27-b56d-521cf6b7486e@redhat.com> <6cab3e8a-dff7-41d1-af22-f18b8f2820dc@lucifer.local> <94dabe57-232b-4a21-b2cf-bcfbda75c881@lucifer.local> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: <94dabe57-232b-4a21-b2cf-bcfbda75c881@lucifer.local> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: G1UhXLaODQxYtgQgj9-2tA-zWAXB0TBkRTFuJrphqok_1732886668 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A0EB2180002 X-Rspam-User: X-Stat-Signature: 8txoz1xtux55u86xph64hys9u1xg6pys X-HE-Tag: 1732886665-672236 X-HE-Meta: U2FsdGVkX18vHTxIhthXei18fxjEM+2+T59cqSd6mnQCd/PG/oLM6Eiy5Jwupb0X9kbHmJg6bNHZYyhPD5FIoSO+ThGtQh556UG/2kdsksHyxni9BLtSx7sxoH7cYVK5CEEv+kelQjaxikQhn4U4q853fM1PsWYx/Pvpv1i+p5Zv6NkOsCfD+KljuXILXwIiyZcWMJYstc29i5TiB5oO8vgVPUiwulvzTqio/C/MNfrJMj9zdr78BA1/DiqnoBIYIlTfeL3Y52qj5hq/nc8dG+khx1IHjEnRadrKUk5ArZzkxPwluQ9hO/oH4jYf3AMi3AcuwXJxnbmJJU606c6/dBXAY3k+PdRBwgR3H6oyUCx0KqOTI/uLA+qMxlB+y6UTSDydf3KpvwJvmRg2F67SGjDM8N3ATlBYQWAsiClOrT56zGeD16Ybi9e1deiDvALdQL+q4BW9nETpFSP7aNUzJqKKou8exJn0WUm7bNrd6FJRw3a2gVWGY+O8WS4+kfG9VEKCsrWAzSDdxoXArTLR+6OvLdlfjC25ErP43Z4tvq/FcAD8EhGthm9moPOSE1OEGmxpge7MzfTpVhJioxev7CJd41GtmxK7tCBVsKamv7VY5wpXfc+5ExYqE4/9xDkdPwboecZrYTjwIc4j1NrtVYBijct8u6tBfUGNXoU3lN+TnWpf7M1+AbUPvuGDznn6+vhs1UUHtQo2TCMXg+3yO7Qu6p4c/jttDxGAxAzl18DYoArmm6hBH1bck9b23+dOVHoq4kfQr/+Arxbl/nqw+qOjUnVXcZmZ+2CZr0tXBFTeZeIHyAaP1mpdqj5yj7SP/fHYWmhaNO6ABMOSb9mJ3ERpGOsnDqfy0Oo5fjXFvUy8vBIGAmrJ1lf7vAvWaToDBRHhsUgr/Ahsyxnq02PsM8z5ViuH6tlndvliiozYgFoGG0g/nySYmBmyFQ8N3ACVyNp4uugwIjQ1i225uAa h40h0m6V p50aozvoB65lvsk6kpx5EmFsvSr8bPlUDMyQObNtqFwegpzbruXK89O36QmtBJQwDvqTTCEi2bBWsonpSNhlKeAPrr3qxbUx5BjUxYo4wIOnq5KRHnCaDrldlKgrHNDXZRU7C8dl0J0rAlS0YQesFyNsp3GcdYCIPgqFTlYZPpilUW55wK7CzKOR11hwQZ8+Lt7kvOrEAMhzX2NU8WDJMUMv77I9kuG/tt51u7LpOqgOKQ4nEV8v4v9ACxxDfJazDeuPcg3Lwg4VxFspm9CBLnx5HpnsKXXDQy8SZinBMYv0Z710vXwwAcevRA+61QsNA4xgLUWdvFnMhdzjiz1mUKir6cGzjGs1VKvLQ8tZ1vT/USx2GNhTEBUSplMtG/3o2dFJc9rD+13tGyUMzUDU9jbUqPVJhSsiqefmzvShWKMm1yiJ73lNFRCCpmaLWEz8/sHJBqCQP1q2gYh4= 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: List-Subscribe: List-Unsubscribe: On 29.11.24 14:19, Lorenzo Stoakes wrote: > On Fri, Nov 29, 2024 at 02:12:23PM +0100, David Hildenbrand wrote: >> On 29.11.24 14:02, Lorenzo Stoakes wrote: >>> On Fri, Nov 29, 2024 at 01:59:01PM +0100, David Hildenbrand wrote: >>>> On 29.11.24 13:55, Lorenzo Stoakes wrote: >>>>> On Fri, Nov 29, 2024 at 01:45:42PM +0100, David Hildenbrand wrote: >>>>>> On 29.11.24 13:26, Peter Zijlstra wrote: >>>>>>> On Fri, Nov 29, 2024 at 01:12:57PM +0100, David Hildenbrand wrote: >>>>>>> >>>>>>>> Well, I think we simply will want vm_insert_pages_prot() that stops treating >>>>>>>> these things like folios :) . *likely* we'd want a distinct memdesc/type. >>>>>>>> >>>>>>>> We could start that work right now by making some user (iouring, >>>>>>>> ring_buffer) set a new page->_type, and checking that in >>>>>>>> vm_insert_pages_prot() + vm_normal_page(). If set, don't touch the refcount >>>>>>>> and the mapcount. >>>>>>>> >>>>>>>> Because then, we can just make all the relevant drivers set the type, refuse >>>>>>>> in vm_insert_pages_prot() anything that doesn't have the type set, and >>>>>>>> refuse in vm_normal_page() any pages with this memdesc. >>>>>>>> >>>>>>>> Maybe we'd have to teach CoW to copy from such pages, maybe not. GUP of >>>>>>>> these things will stop working, I hope that is not a problem. >>>>>>> >>>>>>> Well... perf-tool likes to call write() upon these pages in order to >>>>>>> write out the data from the mmap() into a file. >>>>> >>>>> I'm confused about what you mean, write() using the fd should work fine, how >>>>> would they interact with the mmap? I mean be making a silly mistake here >>>> >>>> write() to file from the mmap()'ed address range to *some* file. >>>> >>> >>> Yeah sorry my brain melted down briefly, for some reason was thinking of read() >>> writing into the buffer... >>> >>>> This will GUP the pages you inserted. >>>> >>>> GUP does not work on PFNMAP. >>> >>> Well it _does_ if struct page **pages is set to NULL :) >> >> Hm? :) >> >> check_vma_flags() unconditionally refuses VM_PFNMAP. > > Ha, funny with my name all over git blame there... ok yup missed this, the > vm_normal_page() == NULL stuff must but for mixed map (and those other weird > cases I think you can get0... > > Well good. Where is write() invoking GUP? I'm kind of surprised it's not just > using uaccess? > > One thing to note is I did run all the perf tests with no issues whatsoever. You > would _think_ this would have come up... > > I'm editing some test code to explicitly write() from the buffer anyway to see. > > If we can't do pfnmap, and we definitely can't do mixedmap (because it's > basically entirely equivalent in every way to just faulting in the pages as > before and requires the same hacks) then I will have to go back to the drawing > board or somehow change the faulting code. > > This really sucks. > > I'm not quite sure I even understand why we don't allow GUP used _just for > pinning_ on VM_PFNMAP when it is -in effect- already pinned on assumption > whatever mapped it will maintain the lifetime. > > What a mess... Because VM_PFNMAP is dangerous as hell. To get a feeling for that (and also why I raised my refcounting comment earlier) just read recent: commit 79a61cc3fc0466ad2b7b89618a6157785f0293b3 Author: Linus Torvalds Date: Wed Sep 11 17:11:23 2024 -0700 mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. GUP relies on the refcount. In a PFNMAP you don't have any way to make sure the driver won't go down, free the page, to have it used by someone else while IO is still happening to that page. -- Cheers, David / dhildenb