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.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 AD70BC2D0A3 for ; Tue, 3 Nov 2020 07:05:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 23176206E3 for ; Tue, 3 Nov 2020 07:05:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="kBuCGNf+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 23176206E3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4BB3F6B005D; Tue, 3 Nov 2020 02:05:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 46C7E6B006C; Tue, 3 Nov 2020 02:05:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 35A4B6B006E; Tue, 3 Nov 2020 02:05:28 -0500 (EST) 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 0672D6B005D for ; Tue, 3 Nov 2020 02:05:27 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 9EB81180AD804 for ; Tue, 3 Nov 2020 07:05:27 +0000 (UTC) X-FDA: 77442221094.15.whip43_1e001d7272b6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 7F80E1814B0C1 for ; Tue, 3 Nov 2020 07:05:27 +0000 (UTC) X-HE-Tag: whip43_1e001d7272b6 X-Filterd-Recvd-Size: 5487 Received: from hqnvemgate24.nvidia.com (hqnvemgate24.nvidia.com [216.228.121.143]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Nov 2020 07:05:26 +0000 (UTC) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Mon, 02 Nov 2020 23:05:28 -0800 Received: from [10.2.49.167] (10.124.1.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 3 Nov 2020 07:05:24 +0000 Subject: Re: [PATCH v2 2/2] mm: prevent gup_fast from racing with COW during fork To: "Ahmed S. Darwish" CC: Jason Gunthorpe , Peter Xu , , Linus Torvalds , Andrea Arcangeli , Andrew Morton , Aneesh Kumar K.V , Christoph Hellwig , Hugh Dickins , Jan Kara , Jann Horn , Kirill Shutemov , Kirill Tkhai , Leon Romanovsky , Linux-MM , "Michal Hocko" , Oleg Nesterov , Peter Zijlstra , Ingo Molnar , Will Deacon , Thomas Gleixner , Sebastian Siewior References: <0-v2-dfe9ecdb6c74+2066-gup_fork_jgg@nvidia.com> <2-v2-dfe9ecdb6c74+2066-gup_fork_jgg@nvidia.com> <20201030225250.GB6357@xz-x1> <20201030235121.GQ2620339@nvidia.com> <20201103001712.GB52235@lx-t490> <20201103002532.GL2620339@nvidia.com> <20201103004133.GD52235@lx-t490> <20201103065225.GA63301@lx-t490> From: John Hubbard Message-ID: <869a07ad-97ba-a965-76ef-3b9663491a21@nvidia.com> Date: Mon, 2 Nov 2020 23:05:24 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201103065225.GA63301@lx-t490> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL111.nvidia.com (172.20.187.18) To HQMAIL107.nvidia.com (172.20.187.13) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1604387128; bh=WOXCBzo2sh8AfhJVQbxOwwcCTG/JlBmlSzu4vb+1pDY=; h=Subject:To:CC:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy; b=kBuCGNf+E8FQQ++57dzWtdImAKT1x3vP9XKKNX9zMCJ00q9fHJ3pq/zmMZX/xbrRF K6k8W95stCHRTx21/y9cCJmMj3vPgLdLS6RPSj1Cqduhvqa8v9sH/LRQr+nhHkJpK0 IQD34bZE25Gu7J19h1aKFe7+rqtR4V9Z+jZsR3cvUcukNwUNsiwoosAmso9ieue2xb 96oqc8ubjL6GiNvzKYET0gCyuMLwwZWpcA5YvvoZO4+Le6rT8cOGFLqrwVnDVZr65s 2iRhDdpHXKB9/Pu1aTYYdeN/vfEc8VBc8wTQHac4xFZGvpz6hZsbjWYCPS8fpRLrRJ +t3hdrkA46Jsg== 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 11/2/20 10:52 PM, Ahmed S. Darwish wrote: > On Mon, Nov 02, 2020 at 06:20:45PM -0800, John Hubbard wrote: >> On 11/2/20 4:41 PM, Ahmed S. Darwish wrote: >>> On Mon, Nov 02, 2020 at 08:25:32PM -0400, Jason Gunthorpe wrote: >>>> On Tue, Nov 03, 2020 at 01:17:12AM +0100, Ahmed S. Darwish wrote: >>>> >>>>> Please stick with the official exported API: raw_write_seqcount_begin(). >>>> >>>> How did you know this was 'offical exported API' ?? >>>> >>> >>> All the official exported seqlock.h APIs are marked with verbose >>> kernel-doc annotations on top. The rest are internal... >>> >> >> OK, but no one here was able to deduce that, probably because there is not >> enough consistency throughout the kernel to be able to assume such things--even >> though your seqlock project is internally consistent. It's just not *quite* >> enough communication. >> >> I think if we added the following it would be very nice: >> > > The problem is, I've already documented seqlock.h to death.... There are > more comments than code in there, and there is "seqlock.rst" under > Documentation/ to further describe the big picture. > > There comes a point where you decide what level of documentation to add, > and what level to skip. > > Because in the end, you don't want to confuse "Joe, the general driver > developer" with too much details that's not relevant to their task at > hand. (I work in the Embedded domain, and I've seen so much ugly code > from embedded drivers/SoC developers already, sorry) > > See for example my reply to Linus, where any talk about the lockdep-free > and barrier-free parts of the API was explicitly not mentioned in > seqlock.rst. This was done on purpose: 1) you want to keep the generic > case simple, but the special case do-able, 2) you want to encourage > people to use the standard entry/exit points as much as possible. > Well, OK, I'll leave it alone. This was not a normal case for the documentation, anyway. We are using seqcount-ing in a little bit different way than usual, so I guess an email thread like this is actually the proper way to work it out. Just wanted to be sure that we didn't miss an opportunity to clarify anything that needed clarifying it. Thanks for the detailed responses throughout! thanks, -- John Hubbard NVIDIA