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=-5.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS 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 E748AC433E0 for ; Mon, 25 May 2020 02:25:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 618AD2076C for ; Mon, 25 May 2020 02:25:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=juliacomputing-com.20150623.gappssmtp.com header.i=@juliacomputing-com.20150623.gappssmtp.com header.b="a7DtJGwD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 618AD2076C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=juliacomputing.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B7A8D8000D; Sun, 24 May 2020 22:25:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2B2E80007; Sun, 24 May 2020 22:25:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A41668000D; Sun, 24 May 2020 22:25:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0108.hostedemail.com [216.40.44.108]) by kanga.kvack.org (Postfix) with ESMTP id 87A4180007 for ; Sun, 24 May 2020 22:25:54 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 390CA181AEF09 for ; Mon, 25 May 2020 02:25:54 +0000 (UTC) X-FDA: 76853651028.19.ink64_50992c9e36656 X-HE-Tag: ink64_50992c9e36656 X-Filterd-Recvd-Size: 4625 Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Mon, 25 May 2020 02:25:53 +0000 (UTC) Received: by mail-io1-f68.google.com with SMTP id h10so17276027iob.10 for ; Sun, 24 May 2020 19:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juliacomputing-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=sExaUQG+IPyncAhsVw5lguZ0tU5GKQsX5eYb5m1nJfc=; b=a7DtJGwDeRXIAvsQzFAlpmcS0vnsn60H7HaxhJCV61CkGZ7U8QrghWMLxRQ91v2xIT KemEV/6bFVb6MAO/j00VYeSPOwL4XwCrfhCQaqU/LEz/zTLQO1JoqOEdj8UhjIsZlhoq Sq74/QlFJ1PLHFIQmW+xwzO5PcWIdP9VJnbfttTt2dS3Tz3e6E1AH20sChQpsDWHoW1z mCXTwhXPkTq0ViMyrwHK8diWJoAP68ZaLbCDN44lC1aSicREKkA9nLTCX751CVB/qAo3 nJhWWuNDtD4saJFzUgTXYZPP3yrw5zXA/4Ocj4CrgXwhYNFAiJ9Iyb12gQ4/eE048lQf xV3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=sExaUQG+IPyncAhsVw5lguZ0tU5GKQsX5eYb5m1nJfc=; b=dTGOR/Nyq+nQVGfSM77oZmfKj71bkWXcmoNWI5YU3fax4W4/3/e5sUNY5OZ6pa5qrY MJFH9fw4bncOBuoxfwtqT7USqaKcxQEfbhj3w9PNXoTh1aXL2sB9nnnczF6lqyI1Oz+3 mdmgvzuU+uoRsR3k1RDEXLmFGc2UMPRC/Tn8x+4VKjGCTkWFs2fZuLZ0n3bcra/L0j7e 1yBH4FCzc17p97jHQ88RHVNrlPXHbtLrwkMxaee38RB9ajs3YnI/bDeduhX/ffLeICdf hrIBldXj1Z1SQaiGuLUb3sPk04N3KyLS5J/q+F3sbWWGtC+tG1nC33govpBwEaQIPJiD yzWw== X-Gm-Message-State: AOAM531HOiIyQMMBdzc/FZLnyJyrou+6gi/JEjvjlOEfbCyDwECSkyca 6KVsKieovpmTACo1KML2kAde0f2ZutqxcfOGG0sMMGmD X-Google-Smtp-Source: ABdhPJyzFxKYBRcaKZBDLtOOfeO+pbYT4UVYMR7Y2gxiNj+OgIjC2XGmEH3ZF6Xds/oCJO06ZO4D/W4Sa/uR6dK7peY= X-Received: by 2002:a5e:df49:: with SMTP id g9mr8286037ioq.153.1590373552754; Sun, 24 May 2020 19:25:52 -0700 (PDT) MIME-Version: 1.0 From: Keno Fischer Date: Sun, 24 May 2020 22:25:17 -0400 Message-ID: Subject: mm: Behavior of process_vm_* with short local buffers To: linux-mm@kvack.org Cc: Andrew Morton , Linux Kernel Mailing List , Kyle Huey , "Robert O'Callahan" , Valentin Churavy Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.022907, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi everyone, I'm in the process of trying to port a debugging tool (http://rr-project.org/) from x86 to various other architectures. This tool relies on noting every change that was made to the memory of the process being debugged. As such, it has a battery of tests for corner cases of copyin/out and it is one of these that I saw behaving strangely when ported to non-x86 architectures. This particular test was testing the behavior of process_vm_readv (and writev, but for simplicity, let's assume readv here) with short local buffers. On x86 if the buffer is short and the following page is unmapped, the syscall will fill the remainder of the page, and then return however many bytes it actually wrote. However, on other architectures (I mostly looked at arm64, though the same applies elsewhere), the behavior can be quite different. In general, the behavior depends strongly on factors like how close to the start of the copy region the page break occurs, how many bytes were supposed to be left after the page break and the total size of the region to be copied. In various situations, I'm seeing: - Writes that end many bytes before the page break - Bytes being modified beyond what the syscall result would indicate happened. - Combinations thereof I can work around this in my port, but I thought it might be valuable to ask where the line is between "architecture-defined behavior" and a bug that should be reported to the appropriate architecture maintainers and eventually fixed. For example, I think it would be nice if the syscall result actually did match the actual number of bytes written in all cases. I've written a small program [1] that sets up this situation for various parameter values and prints the results. I have access to arm64, powerpc and x86, so I included results for those architectures, but I suspect other architectures have similar issues. The program should be easy to run to get your own results for a different architecture. [1] https://gist.github.com/Keno/b247bca85219c4e3bdde9f7d7ff36c77 Thanks, Keno