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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5AF4DC76196 for ; Fri, 7 Apr 2023 10:14:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231777AbjDGKOT (ORCPT ); Fri, 7 Apr 2023 06:14:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229863AbjDGKOR (ORCPT ); Fri, 7 Apr 2023 06:14:17 -0400 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BAA94903F for ; Fri, 7 Apr 2023 03:14:15 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-4fb22f1f91eso1636760a12.1 for ; Fri, 07 Apr 2023 03:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680862454; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=quNG0/wNI8R4PE48ZPLbRS2Bu1I51NvVN8NOjnDtCG0=; b=JcECVJwtE1OnPOTAeOUPTVfA5DreOqkA9WYtxG4fnxJ2f84SN0+8ur0Ij38TZ8F0Ey +E13rWXKyFkyiraUO9dvaxcoIGBpad6Smc5H/L0RqNZIZAWzdTcVOdfJOfMIm8jSVfCa dVUOxoHjI8FYYh81x6bvI4Iyqv1qpTo/1PFxUIzz4uNQycwswnWKDnG67CpXYPbcRKgr qy60/lnshum8MWT71alOWw3DaYY+8VovHIAVLaq4nbKhDRIvehY2B7kz/VcMFOHLtrVZ pvzCSfY9mGlE9CYYde3Oac6L/GEcJ8D3gTkfFQ9fofuHnwENI/JreGFoq4iROZS9ApaL QyKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680862454; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=quNG0/wNI8R4PE48ZPLbRS2Bu1I51NvVN8NOjnDtCG0=; b=SpxS6jBnmRq8MNrw/n7oRnv59nlW20sftY9cBYrG7Rh6F2vFrdscxcgvOKqv2x5xzN tFPZWKihuzXT3ff+Umw9lRfRXL5L001FtZ37e74G9f6ZIng3bUq9ZR99PxDBftof2Eyu lAnWagEOxf9QHg0GtMiTnTpcmYKJ8DUL0nzMMtx6UAhg0EUv/C/QJ9Ua6ngDPI5hFhdy b5/AS/vnbYvZdwGd1v0NYiABqoTCQwx9AqpbtJEqNVmFGtp7YzESpVOfDakDtD/KQxNO jskO4nA1dpvq9zYAPMW9WVf0EKRg/aaPuQoi8PL4fuHI4CVFFGhmIpZudjjGSlpZoiz5 oHIw== X-Gm-Message-State: AAQBX9dxUoaWl8H+L1dUH1pCAkWIVFzmsNpHdPKL9+lHzRYbscAaLCZ5 5YHPjOcU/Hise7fLb7qj1Lr56/kJD+1DHkBKDRRnog== X-Google-Smtp-Source: AKy350aXhjdkSqobczCxGxZfYh9g2IVUgJJqiGQ7eeBTICfWYwKlrYT86twOyByKnkSZt/pnAlZQTgEbn3ZN2++tDSk= X-Received: by 2002:a50:cd84:0:b0:4ad:6052:ee90 with SMTP id p4-20020a50cd84000000b004ad6052ee90mr1254691edi.7.1680862454074; Fri, 07 Apr 2023 03:14:14 -0700 (PDT) MIME-Version: 1.0 References: <20230406074005.1784728-1-usama.anjum@collabora.com> <20230406074005.1784728-3-usama.anjum@collabora.com> <0351b563-5193-6431-aa9c-c5bf5741b791@collabora.com> <8a837998-604f-a871-729e-aa274a621481@collabora.com> In-Reply-To: From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Fri, 7 Apr 2023 12:14:02 +0200 Message-ID: Subject: Re: [PATCH v12 2/5] fs/proc/task_mmu: Implement IOCTL to get and optionally clear info about PTEs To: Muhammad Usama Anjum Cc: Mike Rapoport , Peter Xu , David Hildenbrand , Andrew Morton , Andrei Vagin , Danylo Mocherniuk , Paul Gofman , Cyrill Gorcunov , Nadav Amit , Alexander Viro , Shuah Khan , Christian Brauner , Yang Shi , Vlastimil Babka , "Liam R . Howlett" , Yun Zhou , Suren Baghdasaryan , Alex Sierra , Matthew Wilcox , Pasha Tatashin , Axel Rasmussen , "Gustavo A . R . Silva" , Dan Williams , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Greg KH , kernel@collabora.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, 7 Apr 2023 at 12:04, Muhammad Usama Anjum wrote: > On 4/7/23 12:34=E2=80=AFPM, Micha=C5=82 Miros=C5=82aw wrote: > > On Thu, 6 Apr 2023 at 23:04, Muhammad Usama Anjum > > wrote: > >> On 4/7/23 1:00=E2=80=AFAM, Micha=C5=82 Miros=C5=82aw wrote: > >>> On Thu, 6 Apr 2023 at 19:58, Muhammad Usama Anjum > >>> wrote: [...] > >>>>>> + /* > >>>>>> + * Allocate smaller buffer to get output from inside the p= age walk > >>>>>> + * functions and walk page range in PAGEMAP_WALK_SIZE size= chunks. As > >>>>>> + * we want to return output to user in compact form where = no two > >>>>>> + * consecutive regions should be continuous and have the s= ame flags. > >>>>>> + * So store the latest element in p.cur between different = walks and > >>>>>> + * store the p.cur at the end of the walk to the user buff= er. > >>>>>> + */ > >>>>>> + p.vec =3D kmalloc_array(p.vec_len, sizeof(struct page_regi= on), > >>>>>> + GFP_KERNEL); > >>>>>> + if (!p.vec) > >>>>>> + return -ENOMEM; > >>>>>> + > >>>>>> + walk_start =3D walk_end =3D start; > >>>>>> + while (walk_end < end && !ret) { > >>>>> > >>>>> The loop will stop if a previous iteration returned ENOSPC (and the > >>>>> error will be lost) - is it intended? > >>>> It is intentional. -ENOSPC means that the user buffer is full even t= hough > >>>> there was more memory to walk over. We don't treat this error. So wh= en > >>>> buffer gets full, we stop walking over further as user buffer has go= tten > >>>> full and return as success. > >>> > >>> Thanks. What's the difference between -ENOSPC and > >>> PM_SCAN_FOUND_MAX_PAGES? They seem to result in the same effect (code > >>> flow). > >> -ENOSPC --> user buffer has been filled completely > >> PM_SCAN_FOUND_MAX_PAGES --> max_pages have been found, user buffer may > >> still have more space > > > > What is the difference in code behaviour when those two cases are > > compared? (I'd expect none.) > There is difference: > We add data to user buffer. If it succeeds with return code 0, we engage > the WP. If it succeeds with PM_SCAN_FOUND_MAX_PAGES, we still engage the > WP. But if we get -ENOSPC, we don't perform engage as the data wasn't add= ed > to the user buffer. Thanks! I see it now. I see a few more corner cases here: 1. If we did engage WP but fail to copy the vector we return -EFAULT but the WP is already engaged. I'm not sure this is something worth guarding against, but documenting that would be helpful I think. 2. If uffd_wp_range() fails, but we have already processed pages earlier, we should treat the error like ENOSPC and back out the failed range (the earier changes would be lost otherwise). Best Regards Micha=C5=82 Miros=C5=82aw