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 7AAE3C433F5 for ; Wed, 16 Feb 2022 17:25:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 830046B0074; Wed, 16 Feb 2022 12:25:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DE176B0075; Wed, 16 Feb 2022 12:25:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A53B6B0078; Wed, 16 Feb 2022 12:25:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 56E5A6B0074 for ; Wed, 16 Feb 2022 12:25:11 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 17733232E1 for ; Wed, 16 Feb 2022 17:25:11 +0000 (UTC) X-FDA: 79149318822.04.ECD041B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id 85E654000C for ; Wed, 16 Feb 2022 17:25:10 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9B89461BAD for ; Wed, 16 Feb 2022 17:25:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01D8EC340F4 for ; Wed, 16 Feb 2022 17:25:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645032309; bh=50gayj5BhaFY1KfY4J6wEv9LL/2KBrv3TJsZgjwCNeI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=s12B1+AOmXryDhSPknuKL8IzRS63FtY1jW4IQTcFUQFmxCB1bHM2/Ad46I49kwf/J 1N4t3B+0pmEk+VM3RGTCCPp4BMoEKUD4OApK6MSr126ucgMlswQUB5BXx26xHHuTIN nIDMmz2bSNAvv2YwZvqQkNZ1VSjzEi+/bEnRawkliB/xPF6w5v2/ZpnWvzzcu60YAt b0tbgWWS2iDyu+FNJTDx6MhZ0bonly7bCCQI8ozxMfHHeK9T6LKrcaRKo68YMdnAGW SkkcTyfQRZRWBGGpnaiNe0OT4YNd8PPdnGpvOZ+aTT7Oxn7WeP/AbgH0K6UKXbmysP GFlbvOO46XMmw== Received: by mail-yb1-f182.google.com with SMTP id j2so7737091ybu.0 for ; Wed, 16 Feb 2022 09:25:08 -0800 (PST) X-Gm-Message-State: AOAM532hhX0m8EbfKRLCN2/rDcLeNUb7CKq/MMqj2kIzQSva5JIBf1e+ TWlosf5Es9roDNQ7rPhr3mkfeSPnU8flJWNSJrQ= X-Google-Smtp-Source: ABdhPJxjMQo5IVyxb0rl98kvZVGHXXkUZT6SL5l1mKrh+QNt5m3z6iWux2+7Z+U/R+Y+NG64b+eQtIGkKKWMvR0XD9c= X-Received: by 2002:a5b:5d0:0:b0:623:c68d:d473 with SMTP id w16-20020a5b05d0000000b00623c68dd473mr2991953ybp.506.1645032308053; Wed, 16 Feb 2022 09:25:08 -0800 (PST) MIME-Version: 1.0 References: <20200917112538.GD8409@ziepe.ca> <20200917193824.GL8409@ziepe.ca> <20200918164032.GA5962@xz-x1> <20200918173240.GY8409@ziepe.ca> <20200918204048.GC5962@xz-x1> <0af8c77e-ff60-cada-7d22-c7cfcf859b19@nvidia.com> <20200919000153.GZ8409@ziepe.ca> <20200921083505.GA5862@quack2.suse.cz> <20200921120301.GD8409@ziepe.ca> In-Reply-To: From: Oded Gabbay Date: Wed, 16 Feb 2022 19:24:41 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/4] mm: Trial do_wp_page() simplification To: Jason Gunthorpe , Linus Torvalds Cc: Jan Kara , John Hubbard , Leon Romanovsky , Linux-MM , Linux Kernel Mailing List , "Maya B . Gokhale" , Yang Shi , Marty Mcfadden , Kirill Shutemov , Oleg Nesterov , Jann Horn , Kirill Tkhai , Andrea Arcangeli , Christoph Hellwig , Andrew Morton , Daniel Vetter , Greg Kroah-Hartman , Peter Xu Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 85E654000C X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=s12B1+AO; spf=pass (imf07.hostedemail.com: domain of ogabbay@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ogabbay@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: c41qgmf67hfxwurzed1y3g77x5xeo816 X-Rspamd-Server: rspam03 X-HE-Tag: 1645032310-45819 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 Wed, Feb 16, 2022 at 6:59 PM Oded Gabbay wrote: > > On Mon, Sep 21, 2020 at 3:03 PM Jason Gunthorpe wrote: > > > > On Mon, Sep 21, 2020 at 10:35:05AM +0200, Jan Kara wrote: > > > > My thinking is to hit this issue you have to already be doing > > > > FOLL_LONGTERM, and if some driver hasn't been properly marked and > > > > regresses, the fix is to mark it. > > > > > > > > Remember, this use case requires the pin to extend after a system > > > > call, past another fork() system call, and still have data-coherence. > > > > > > > > IMHO that can only happen in the FOLL_LONGTERM case as it inhernetly > > > > means the lifetime of the pin is being controlled by userspace, not by > > > > the kernel. Otherwise userspace could not cause new DMA touches after > > > > fork. > > > > > > I agree that the new aggressive COW behavior is probably causing issues > > > only for FOLL_LONGTERM users. That being said it would be nice if even > > > ordinary threaded FOLL_PIN users would not have to be that careful about > > > fork(2) and possible data loss due to COW - we had certainly reports of > > > O_DIRECT IO loosing data due to fork(2) and COW exactly because it is very > > > subtle how it behaves... But as I wrote above this is not urgent since that > > > problematic behavior exists since the beginning of O_DIRECT IO in Linux. > > > > Yes, I agree - what I was thinking is to do this FOLL_LONGTERM for the > > rc and then a small patch to make it wider for the next cycle so it > > can test in linux-next for a responsible time period. > > > > Interesting to hear you confirm block has also seen subtle user > > problems with this as well. > > > > Jason > > > > Hi Jason, Linus, > Sorry for waking up this thread, but I've filed a bug against this change: > https://bugzilla.kernel.org/show_bug.cgi?id=215616 > > In the past week, I've bisected a problem we have in one of our new > demos running on our Gaudi accelerator, and after a very long > bisection, I've come to this commit. > All the details are in the bug, but the bottom line is that somehow, > this patch causes corruption when the numa balancing feature is > enabled AND we don't use process affinity AND we use GUP to pin pages > so our accelerator can DMA to/from system memory. > > Either disabling numa balancing, using process affinity to bind to > specific numa-node or reverting this patch causes the bug to > disappear. > I validated the bug and the revert on kernels 5.9, 5.11 and 5.17-rc4. > > You can see our GUP code in the driver in get_user_memory() in > drivers/misc/habanalabs/common/memory.c. > It is fairly standard and I think I got that line from Daniel (cc'ed > on this email). > > I would appreciate help from the mm experts here to understand how to > fix this, but it looks as if this simplification caused or exposed > some race between numa migration code and GUP. > > Thanks, > Oded Although I wrote it inside the bug, I just wanted to specify here the exact commit id in the tree: 2020-09-04 - 09854ba94c6aad7886996bfbee2530b3d8a7f4f4 - mm: do_wp_page() simplification Thanks, Oded