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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 C8D80C4742C for ; Mon, 16 Nov 2020 14:46:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 418D722280 for ; Mon, 16 Nov 2020 14:46:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=arista.com header.i=@arista.com header.b="VzbZUJj9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 418D722280 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=arista.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C63846B006E; Mon, 16 Nov 2020 09:46:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BA0386B0071; Mon, 16 Nov 2020 09:46:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3EB26B0072; Mon, 16 Nov 2020 09:46:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190]) by kanga.kvack.org (Postfix) with ESMTP id 64DF66B006E for ; Mon, 16 Nov 2020 09:46:36 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id DF0553624 for ; Mon, 16 Nov 2020 14:46:35 +0000 (UTC) X-FDA: 77490557550.20.lift51_33144aa27329 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id C1D0C180C07A3 for ; Mon, 16 Nov 2020 14:46:35 +0000 (UTC) X-HE-Tag: lift51_33144aa27329 X-Filterd-Recvd-Size: 5685 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Mon, 16 Nov 2020 14:46:34 +0000 (UTC) Received: by mail-pl1-f177.google.com with SMTP id 5so1711627plj.8 for ; Mon, 16 Nov 2020 06:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=yAIpN8zzoudkk9iAqlz3Xqnp850qgVBSX7BT49RgjuQ=; b=VzbZUJj9cS3VQggxqhAZ+HTaGN2cNSpl5NUMQM+O2AD74aS2uajqI2pyJDdVwZD5Zp 5p4uMHMm0/BwudVqk4rhBTNhQfGq4a0TqWVKOTn4hJOGVplKq9vtjA6oE3Mrb9F3qIFk 24BhQKelrtYN/bsPvOco/4j43Vh/znjgnwGwvmAO1A9S897q00dxLHoHdsgurK2QOXFg aPz9SYRMIF7BgQo3cNkvq2DwEINvUjCvlYEQDh+pFWeDEwLKueuNRspnBEuXzLbP+N3v eBYmFVCVI1VSdBpUD8yupvc99qU6fotW3IwpBZihN9jtzVlLN1pHVWXzq9JyQJpWeq+d Gnjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=yAIpN8zzoudkk9iAqlz3Xqnp850qgVBSX7BT49RgjuQ=; b=g0Bz2WwDrd74QKp4SUkT2kN7UCkbh3F12UYalOg//+Hj1VqDjjT4pm+UsqH+LpXEeo tSu1WsQAoAZ2PGwkg9wgZDHWtphggrCGYDdLQoWhdaVe03m2nlQmEhuHlIypaLnm15ol KBqxXwjSIAXKO9oulrlGi3OXGYuc+/fQIsFVD4fLCbHV43JHuTp5VsxT0uXaiGuDzwUV k0ujjM6wqE1K54CMVQ5m5pMaAJD5H4pRG73H0KrSksLQJ6CW8RGxWoJxAFIumoP4aEcx u1tlYZ+iJonIFWQPlt/TZg5vz7R9dIk4vUsZfN4fx6ZVsxeoalDNhUYwaLZB/qxDcDcE 9ZIg== X-Gm-Message-State: AOAM532UdPHwEuQAFRcZI/jA8pn3jUdzEy9wdl2voa31xh9dBkjbNcH9 W7NTcPkZ0r38X+wVro5TPUSDYY56r3Irrj+zjfM= X-Google-Smtp-Source: ABdhPJzwpADBaSxBgeKugBDrJckn871pRLzSzUnz3cs7ZpMYdF5mdyLJfeQRf/CRk9baQCcixkXXEA== X-Received: by 2002:a17:902:c286:b029:d6:6cbd:eabf with SMTP id i6-20020a170902c286b02900d66cbdeabfmr12822532pld.41.1605537993159; Mon, 16 Nov 2020 06:46:33 -0800 (PST) Received: from ?IPv6:2a02:8084:a84:8e00:81ce:77ba:c5fc:fb03? ([2a02:8084:a84:8e00:81ce:77ba:c5fc:fb03]) by smtp.gmail.com with ESMTPSA id j8sm15764972pgb.55.2020.11.16.06.46.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2020 06:46:32 -0800 (PST) From: James Sewart Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: x86 page_fault not succeeding when mapping write-only Message-Id: <9F7238B5-58AC-485B-861B-C0862D428C00@arista.com> Date: Mon, 16 Nov 2020 14:46:25 +0000 Cc: linux-kernel@vger.kernel.org To: linux-mm@kvack.org X-Mailer: Apple Mail (2.3608.120.23.2.4) 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: Hey, I=E2=80=99m looking into an issue after remapping some memory on 4.19, = but looking=20 at the code this may also be an issue in master. I have a driver that grabs some pages using alloc_pages, these pages are=20= then remapped to userspace using calls to vm_insert_page inside a syfs=20= bin_attribute mmap handler. Userspace calls mmap64 on the sysfs file = with=20 MAP_SHARED and read/write permissions. If the process reads or writes to=20= the mapping at this point it is fine and works. The issue occurs if the=20= process calls mprotect with write-only permissions, before = reading/writing=20 to the mapping, then when writing I see the page fault handler doesn=E2=80= =99t set=20 up the page tables and the process spins entering the fault handler and=20= exiting forever. I tracked the return of page_fault down to a section in function=20 do_page_mkwrite: ret =3D vmf->vma->vm_ops->page_mkwrite(vmf); /* Restore original flags so that caller is not surprised */ vmf->flags =3D old_flags; if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE))) return ret; if (unlikely(!(ret & VM_FAULT_LOCKED))) { lock_page(page); if (!page->mapping) { unlock_page(page); return 0; /* retry */ <- we return here } A 0 return here means wp_page_shared will return before setting up the = pte. This is a snippet of the call stack: do_page_mkwrite at mm/memory.c:2404 wp_page_shared at mm/memory.c:2696 do_wp_page at mm/memory.c:2797 handle_pte_fault at mm/memory.c:4063 __handle_mm_fault at mm/memory.c:4171 We hit the (marked unlikely) condition in do_wp_page of the vma being=20 VM_WRITE and VM_SHARED only, which is why I think I only see the issue=20= when calling mprotect with write-only. Thinking about it now I haven=E2=80= =99t=20 tried calling mmap with write-only to see what happens. I think the issue is this vma has vm_ops associated with the kernfs ops,=20= but as the page was allocated outside of the filesystem stuff, it = doesn=E2=80=99t=20 have the kernfs address_space_operations associated with it.=20 kernfs_vma_page_mkwrite returns 0 indicating it didn=E2=80=99t lock the = page, but=20 do_page_mkwrite requires the page to have a mapping in this case. I=E2=80=99m not sure what the solution is, I can=E2=80=99t figure out = how to associate the=20 page with kernfs so this condition is satisfied. What is this check for? Should kernfs_vma_page_mkwrite lock the page? Or maybe it should set=20 page->mapping? Is there something I can do in my driver to the pages or vma to avoid=20 hitting this issue? I looked through some other kernel code and it seems=20= to me use of the vmalloc api or dma-iommu may hit the same issue. Cheers, James.=