Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4591060imm; Mon, 17 Sep 2018 17:20:09 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYM6L+F+jUYLwxx2oZARiEVuNhsskYse5XFtkwIjNnWRPLDMIapIdVfU8ywpiSBw8u4Aq+T X-Received: by 2002:a62:cfc6:: with SMTP id b189-v6mr21993995pfg.224.1537230009772; Mon, 17 Sep 2018 17:20:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537230009; cv=none; d=google.com; s=arc-20160816; b=baDXrqlv2x67IzgZpOFMN7gBa1d/ck0tYSPeA4hz9Gf+s9T2zNHvRlm2Wx4hbEXD3f dQ15Ny7BVP4YWEPKD8kTFThAmEJ4hdGMN9y1Nk6YCniZzaQ5NCZvPYY0EeEvz7VNnH++ rQOj9ZxCTUzqTUIFmvfMPSSGTwxPlhlqk0jd+eTbZEP7O4m6TV47ecWQR0tJbx/MPyye UzrPTqcX2QihnWdV51EKdOeT8rcguQMflXSdyJqIwOIBjbB/V9cX4o+9MR3Zv7zLpwQ9 0lUPKuvdLSQWMtpRwzME4ONUYAkVELGFRnWBp+S0NBLiejma/gWA7nTJlWyezygUYDS/ Mf4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=hXAsDG8G6TnHmDDEoTG2uKYauddUqbpf9P9/W2M3DKA=; b=0Z6Rfj75AXT8Rod3gMw5UTjhVZ2gyFpgkrBVSTluyZxC+keDxYoKwZhskv58a++r/1 6ozfzwLlTXOebtM1QqvETEpiLMBPDEioVpvDf7Ewty5WZLo8chW38wPQxfoXwMEJxoD8 7v1ER0aW0EhCBbgCzGVKsh8pmjb4UZO3UoKD2cV2PiTFe1kgmzD8xzT1BCSOGi5qJp0T frOr/WWvre0FkQPY2YFBdN/yHWFOwhYvoBE/Fg8cyyYLQV7EgEUbgylkW66aTK6VjVt0 zsIr/i89OkbYyIL3AOZLGi/FycIT99llJkvr0KF2owKzSZlrugQ9IxbOvan3j9Dm7zpQ qPHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RINtpyUL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h27-v6si16602290pgh.245.2018.09.17.17.19.53; Mon, 17 Sep 2018 17:20:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RINtpyUL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728624AbeIRFte (ORCPT + 99 others); Tue, 18 Sep 2018 01:49:34 -0400 Received: from mail-yb1-f193.google.com ([209.85.219.193]:41654 "EHLO mail-yb1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727200AbeIRFte (ORCPT ); Tue, 18 Sep 2018 01:49:34 -0400 Received: by mail-yb1-f193.google.com with SMTP id v10-v6so68174ybm.8 for ; Mon, 17 Sep 2018 17:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hXAsDG8G6TnHmDDEoTG2uKYauddUqbpf9P9/W2M3DKA=; b=RINtpyULn2VsIho+DYyo8Q9B0/fmfUVMhl0G175BrPA2zzcJ1md1PVYWhb5umSdbWk Y7RK72XT7LLs2kOt8wle4GPM9SyfOtPVXz3kDCZOzTD5Oh3N56CBL/fV/pH1KWpuwM7J g+7SByHiLBsgPGfSnAfHrjvhqWVH2mwiSlgoLjXbozxZjR60eUKe7X+s530yTOagf31Z bxElLsuCJgNTLDT44UIK8eM3jZr+djk4mIGzQyGyH79bWnGimDZygzm5mpCF4d+YpDMm sCDVRGivtbTTShuy8vJX0UdbRAg77dsNCv8/FeYVSHxwu6g/huvsjYxIuv0l18T5Ago1 LKAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hXAsDG8G6TnHmDDEoTG2uKYauddUqbpf9P9/W2M3DKA=; b=I5f+k+VS7r8qHw2DjC5OjKeUWvgJaPrlntsfIDz2uYejOyKdlX79lt7M4PWBnGwvw/ BJFXngkopWod0pnGExES9PW6nm42Duy+cyZ4zoLBSSsarmKRk5lL8yig4F/Jg1gqbhig Aq6JXsmoSQagFOEy2dy3H5kW1YDjpF4t1ghERQOUZXaRynfxD0wxaE9XR3dEsecGQMKk 0M7zD++adhuZ1uQs+hHElC27lt2S8Lx5S+5cj6lo5l5lbD+NK/cTbyB2079riXURyMGf 5ERkWwSHZURl5ZVjFks0Ggtw7obfjXtqwkoill/RbbCjxbANglqdbY106dHp/y7Ljvxi EAgg== X-Gm-Message-State: APzg51Bglbki0MAAOJN9/Vp+SbxO6h2m7TXSOtDAT9t77ZKFX2qrSJ/N yRK5gDLwpGDHMkFvFZmt/a6v+QSGvcEOChh6bTa5tQ== X-Received: by 2002:a25:8b88:: with SMTP id j8-v6mr1164581ybl.183.1537229985085; Mon, 17 Sep 2018 17:19:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Salman Qazi Date: Mon, 17 Sep 2018 17:19:33 -0700 Message-ID: Subject: Re: [BUG] mm: direct I/O (using GUP) can write to COW anonymous pages To: Hugh Dickins Cc: jannh@google.com, Dan Williams , Andrew Morton , mhocko@suse.com, riel@redhat.com, aarcange@redhat.com, khlebnikov@yandex-team.ru, mst@redhat.com, jack@suse.cz, Linux Kernel Mailing List , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 17, 2018 at 5:05 PM Hugh Dickins wrote: > > Hi Jann, > > On Mon, 17 Sep 2018, Jann Horn wrote: > > > [I'm not sure who the best people to ask about this are, I hope the > > recipient list resembles something reasonable...] > > > > I have noticed that the dup_mmap() logic on fork() doesn't handle > > pages with active direct I/O properly: dup_mmap() seems to assume that > > making the PTE referencing a page readonly will always prevent future > > writes to the page, but if the kernel has acquired a direct reference > > to the page before (e.g. via get_user_pages_fast()), writes can still > > happen that way. > > > > The worst-case effect of this - as far as I can tell - is that when a > > multithreaded process forks while one thread is in the middle of > > sys_read() on a file that uses direct I/O with get_user_pages_fast(), > > the read data can become visible in the child while the parent's > > buffer stays uninitialized if the parent writes to a relevant page > > post-fork before either the I/O completes or the child writes to it. > > Yes: you're understandably more worried by the one seeing the other's > data; we've tended in the past to be more worried about the one getting > corruption, and the other not seeing the data it asked for (and usually > in the context of RDMA, rather than filesystem direct I/O). > > I've added some Cc's: I might be misremembering, but I think both > Andrea and Konstantin have offered approaches to this in the past, > and I believe Salman is taking a look at it currently. > > But my own interest ended when Michael added MADV_DONTFORK: beyond > that, we've rated it a "Patient: It hurts when I do this. Doctor: > Don't do that then" - more complexity and overhead to solve, than > we have had appetite to get into. But not a shiningly satisfactory > situation, I'll agree. The approach that I am currently investigating (at least to use internally at Google) is to be able to detect (via a heuristic with some error rate) when the patient might be doing it, and tell them not to. Of course, we would have to tell them nicely rather than killing their process, especially if we expect substantial number of false positives. I am motivated by the belief that a transparent fix is not likely to be feasible. Others, who have taken that route earlier, can correct me, if I am mistaken. > > Hugh > > > > > Reproducer code: > > > > =3D=3D=3D=3D=3D=3D START hello.c =3D=3D=3D=3D=3D=3D > > #define FUSE_USE_VERSION 26 > > > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > static const char *hello_path =3D "/hello"; > > > > static int hello_getattr(const char *path, struct stat *stbuf) > > { > > int res =3D 0; > > memset(stbuf, 0, sizeof(struct stat)); > > if (strcmp(path, "/") =3D=3D 0) { > > stbuf->st_mode =3D S_IFDIR | 0755; > > stbuf->st_nlink =3D 2; > > } else if (strcmp(path, hello_path) =3D=3D 0) { > > stbuf->st_mode =3D S_IFREG | 0666; > > stbuf->st_nlink =3D 1; > > stbuf->st_size =3D 0x1000; > > stbuf->st_blocks =3D 0; > > } else > > res =3D -ENOENT; > > return res; > > } > > > > static int hello_readdir(const char *path, void *buf, fuse_fill_dir_t > > filler, off_t offset, struct fuse_file_info *fi) { > > filler(buf, ".", NULL, 0); > > filler(buf, "..", NULL, 0); > > filler(buf, hello_path + 1, NULL, 0); > > return 0; > > } > > > > static int hello_open(const char *path, struct fuse_file_info *fi) { > > return 0; > > } > > > > static int hello_read(const char *path, char *buf, size_t size, off_t > > offset, struct fuse_file_info *fi) { > > sleep(3); > > size_t len =3D 0x1000; > > if (offset < len) { > > if (offset + size > len) > > size =3D len - offset; > > memset(buf, 0, size); > > } else > > size =3D 0; > > return size; > > } > > > > static int hello_write(const char *path, const char *buf, size_t size, > > off_t offset, struct fuse_file_info *fi) { > > while(1) pause(); > > } > > > > static struct fuse_operations hello_oper =3D { > > .getattr =3D hello_getattr, > > .readdir =3D hello_readdir, > > .open =3D hello_open, > > .read =3D hello_read, > > .write =3D hello_write, > > }; > > > > int main(int argc, char *argv[]) { > > return fuse_main(argc, argv, &hello_oper, NULL); > > } > > =3D=3D=3D=3D=3D=3D END hello.c =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D START simple_mmap.c =3D=3D=3D=3D=3D=3D > > #define _GNU_SOURCE > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > __attribute__((aligned(0x1000))) char data_buffer_[0x10000]; > > #define data_buffer (data_buffer_ + 0x8000) > > > > void *fuse_thread(void *dummy) { > > /* step 2: start direct I/O on data_buffer */ > > int fuse_fd =3D open("mount/hello", O_RDWR); > > if (fuse_fd =3D=3D -1) > > err(1, "unable to open FUSE fd"); > > printf("char in parent (before): %hhd\n", data_buffer[0]); > > int res =3D read(fuse_fd, data_buffer, 0x1000); > > /* step 6: read completes, show post-read state */ > > printf("fuse read result: %d\n", res); > > printf("char in parent (after): %hhd\n", data_buffer[0]); > > } > > > > int main(void) { > > /* step 1: make data_buffer dirty */ > > data_buffer[0] =3D 1; > > > > pthread_t thread; > > if (pthread_create(&thread, NULL, fuse_thread, NULL)) > > errx(1, "pthread_create"); > > > > sleep(1); > > /* step 3: fork a child */ > > pid_t child =3D fork(); > > if (child =3D=3D -1) > > err(1, "fork"); > > if (child =3D=3D 0) { > > prctl(PR_SET_PDEATHSIG, SIGKILL); > > sleep(1); > > > > /* step 5: show pre-read state in the child */ > > printf("char in child (before): %hhd\n", data_buffer[0]= ); > > sleep(3); > > /* step 7: read is complete, show post-read state in ch= ild */ > > printf("char in child (after): %hhd\n", data_buffer[0])= ; > > return 0; > > } > > > > /* step 4: de-CoW data_buffer in the parent */ > > data_buffer[0x800] =3D 2; > > > > int status; > > if (wait(&status) !=3D child) > > err(1, "wait"); > > } > > =3D=3D=3D=3D=3D=3D END simple_mmap.c =3D=3D=3D=3D=3D=3D > > > > Repro steps: > > > > In one terminal: > > $ mkdir mount > > $ gcc -o hello hello.c -Wall -std=3Dgnu99 `pkg-config fuse --cflags --l= ibs` > > hello.c: In function =E2=80=98hello_write=E2=80=99: > > hello.c:67:1: warning: no return statement in function returning > > non-void [-Wreturn-type] > > } > > ^ > > $ ./hello -d -o direct_io mount > > FUSE library version: 2.9.7 > > [...] > > > > In a second terminal: > > $ gcc -pthread -o simple_mmap simple_mmap.c > > $ ./simple_mmap > > char in parent (before): 1 > > char in child (before): 1 > > fuse read result: 4096 > > char in parent (after): 1 > > char in child (after): 0 > > > > I have tested that this still works on 4.19.0-rc3+. > > > > As far as I can tell, the fix would be to immediately copy pages with > > `refcount - mapcount > N` in dup_mmap(), or something like that? > >