Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp106380rwb; Tue, 13 Dec 2022 14:44:42 -0800 (PST) X-Google-Smtp-Source: AA0mqf6676dlWxNPyG5YvagfGwKUQmrDIm8t1SluZJj6i4XlIK01khKhXD9yxHKJ+ljY2CK90rzo X-Received: by 2002:a17:906:c1ca:b0:78d:f457:1062 with SMTP id bw10-20020a170906c1ca00b0078df4571062mr6697289ejb.31.1670971482492; Tue, 13 Dec 2022 14:44:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670971482; cv=none; d=google.com; s=arc-20160816; b=S8wTnfWQ9lSUOhS8iN0GtpBp+3PiBvLK+QW5gUhdTcOwQhoX0t56vAttVdh0ggBGPB C+2KNZXScd38ulKZZ0GMFitMkEKLwQZoNm3QWQCwG5Uoxso99eLO+Ktwi1r3oqPO90vq j3utLTYDk6ZX0JDa/tNhoSrDNthliv4ZdVcv6hl9cwZTkJNawdqLamHwgOBUz0x4fsAR aKMbOGuIwGF0PBZVuwBTFDjDSwEy5GoKd0d6qEF0bVUuUg1dJvk6f9ZfEkRoguZHyT1g x3Hrb12YXFSgQ09vBHgYTM1gUhowPVVqcmLbyImIQirGcMChr62xbirlVzq4idx+a7k7 KsZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=grg0bvt97ijbsfmyQgu+5+MNtO6B9tZuIIZrlfXrE7g=; b=qAM4sEnN3XC1HbiAttTTN8bnWPyAELca4ubVwZKGvSmCuy0qJEd46buO8dyx4G9Rm9 Zo5QrlzbfTEQbfiHZ0De4sqyuTnZhCrYQURcLPPEU57h70LyB5QT5FigobBFKK2swQnQ zIm1m1ndI3MdtvWbfnv8K7nZAj4KoPBmXCb8o2XlTQvEHocZoP1ICLdvUelZzYcFqi9J y/IUrZuY/CkCYwLDqBla+AaPEsEIQ5FJEQuBOBD/S0pDeOWNkPJBAUJHCzBvc08s9PKs Q+OlG9ZepyRccLdTr8RFVSjtYZOs9Yyt1xcBceSTLT2KhFPxS92m8wxmHdRmy3V9q+CE W0Wg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=G9cs68AG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xi1-20020a170906dac100b00782627f37d6si9733918ejb.778.2022.12.13.14.44.25; Tue, 13 Dec 2022 14:44:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=G9cs68AG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236551AbiLMWWk (ORCPT + 72 others); Tue, 13 Dec 2022 17:22:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235278AbiLMWWi (ORCPT ); Tue, 13 Dec 2022 17:22:38 -0500 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9B9291FF9C; Tue, 13 Dec 2022 14:22:35 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id c1so7374777lfi.7; Tue, 13 Dec 2022 14:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=grg0bvt97ijbsfmyQgu+5+MNtO6B9tZuIIZrlfXrE7g=; b=G9cs68AGm0bDo2dxa3H+gWo/J6MyRHIeXJ20mm/LQuWgWQUgQehvq+ynwR+urC9gwZ BLHGiQ/auh2nYN2KleCpgDML8YKeuit5PfaNAzQPpdNIvABNP/SeHVlmiylqr/8p0AAZ 6MC9RaeQKHJHAvVuHGbVYwTiGxYH2VQ2c+M7r6hBH/ic6J4JoG12hOrHLivluU+F3lEN trBhSbjWvENewcIbEfgZ2RwvoN1xGZuwGedaopx0YnwEu65SoWgJpM8Wsxj9bePxt2kI +NZInILggNT3DlntTw27WrASJa22vkPuwtTEE/2FBNHuIO1YFQ8KlQwwh6+qm660raC/ GCiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=grg0bvt97ijbsfmyQgu+5+MNtO6B9tZuIIZrlfXrE7g=; b=PWA0LKtAhIGuvc2CKP/K2/a6TnSeinhv21spuw1CgWL41fL8goooWaB6TCbNjlf8f9 ZHlZw6ejO0kHma21wWZWBburpTLAKbl8TZgZDhy3xARQle+0KW15lfJD6XvCkU7Qb9f5 mHnaKRr2JRpUWYAIMPvvoRedb10WFHHaL175piqOy6qyykO1YKu5kfVp+JLOuV/RY2DC p5/v2AcHSlnjzBbeWaKpmEUxzNDMyyym9spfbiSyh6HhEOvE1i579m2BN3BiZpE4s+O5 hs0Mx7ZaUV7ZoiF0S0Rj+Qgq95Jdg6Wc5eCfVy61btke1FLrz671v0JenT3fLx+qkqvd JiWg== X-Gm-Message-State: ANoB5pm30xpSlPvDYFBYXWkYKRhLYCEwq5faBl38INeIX+6WEQXVAu3f IWhAqyxs3x7jlympkuWwd7o= X-Received: by 2002:a05:6512:3d0e:b0:4b5:9043:2530 with SMTP id d14-20020a0565123d0e00b004b590432530mr7831770lfv.68.1670970153809; Tue, 13 Dec 2022 14:22:33 -0800 (PST) Received: from grain.localdomain ([5.18.253.97]) by smtp.gmail.com with ESMTPSA id o5-20020ac25e25000000b004acd6e441cesm530270lfg.205.2022.12.13.14.22.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Dec 2022 14:22:32 -0800 (PST) Received: by grain.localdomain (Postfix, from userid 1000) id 820EB5A0020; Wed, 14 Dec 2022 01:22:31 +0300 (MSK) Date: Wed, 14 Dec 2022 01:22:31 +0300 From: Cyrill Gorcunov To: Muhammad Usama Anjum Cc: =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Andrei Vagin , Danylo Mocherniuk , Alexander Viro , Andrew Morton , Suren Baghdasaryan , Greg KH , Christian Brauner , Peter Xu , Yang Shi , Vlastimil Babka , Zach O'Keefe , "Matthew Wilcox (Oracle)" , "Gustavo A. R. Silva" , Dan Williams , kernel@collabora.com, Gabriel Krisman Bertazi , David Hildenbrand , Peter Enderborg , "open list : KERNEL SELFTEST FRAMEWORK" , Shuah Khan , open list , "open list : PROC FILESYSTEM" , "open list : MEMORY MANAGEMENT" , Paul Gofman Subject: Re: [PATCH v6 2/3] fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs Message-ID: References: <20221109102303.851281-1-usama.anjum@collabora.com> <20221109102303.851281-3-usama.anjum@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.9 (2022-11-12) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 13, 2022 at 06:04:04PM +0500, Muhammad Usama Anjum wrote: > > Hi Muhammad! I'm really sorry for diving in such late (unfortunatelly too busy to > > step in yet). Anyway, while in general such interface looks reasonable here are > > few moments which really bothers me: as far as I undertstand you don't need > > vzalloc here, plain vmalloc should works as well since you copy only filled > > results back to userspace. > > Thank you for reviewing. Correct, I'll update to use vmalloc. > > > Next -- there is no restriction on vec_len parameter, > > is not here a door for DoS from userspace? Say I could start a number of ioctl > > on same pagemap and try to allocate very big amount of vec_len in summay causing > > big pressure on kernel's memory. Or I miss something obvious here? > > Yes, there is a chance that a large chunk of kernel memory can get > allocated here as vec_len can be very large. We need to think of limiting > this buffer in the current implementation. Any reasonable limit should > work. I'm not sure what would be the reasonable limit. Maybe couple of > hundred MBs? I'll think about it. Or I should update the implementation > such that less amount of intermediate buffer can be used like mincore does. > But this can complicate the implementation further as we are already using > page ranges instead of keeping just the flags. I'll see what can be done. You know, I'm not yet convinced about overall design. This is new uapi which should be reviewed very very carefully, once merged in we can't step back and will have to live with it forever. As to buffer size: look how pagemap_read is implemented, it allocates PAGEMAP_WALK_SIZE buffer array to gather results then copies it back to userspace. If the main idea to be able to walk over memory of a process with mm context locked it still doesn't bring much benefit because once ioctl is complete the state of mm can be changed so precise results are only possible if target process is not running. Maybe all of these aspects are been discussed already I probably need to read all previous converstaions first :)