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 AC99FEE4993 for ; Tue, 22 Aug 2023 18:57:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 419F494002D; Tue, 22 Aug 2023 14:57:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CA2F940007; Tue, 22 Aug 2023 14:57:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B98794002D; Tue, 22 Aug 2023 14:57:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1C42E940007 for ; Tue, 22 Aug 2023 14:57:20 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E581EA03AE for ; Tue, 22 Aug 2023 18:57:19 +0000 (UTC) X-FDA: 81152648598.13.8007587 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf03.hostedemail.com (Postfix) with ESMTP id 004E420023 for ; Tue, 22 Aug 2023 18:57:17 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=HlPe2atT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692730638; a=rsa-sha256; cv=none; b=i1+u7z1DSnyhfbn9mJdHP3wvYDyIl14dW7+K6cKyM+OaYWJ0h7z3ZldisYjJdqV86l+hrW KfUY7ry/nkBwLglF5DFhr/SLnYXKSCSab63GB/9fOTfoL2fpBtvOhpd+jv/ARAkYXKxxGH p1w+bn99RP7hcLkSBeT4LPfYmxd0+1Q= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=HlPe2atT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692730638; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=inlF5gsUho4gYjrYe8/Wo40BCJxua4Uvc+Bdc/N+Rj0=; b=iebHG1iRwvDukV9qRvtksmttG5hbmG2R9YmsQrj4/nbjf0vzXNuSmHxwbNMtuA0BByufQ0 JPmHEXuGwvBN+bwUlndshMz8jaYSDK75feKXlVkEbYKQFxbiuJhCBPx+i++UZ79NUD1EZI SQb5jqqHNmU65zFJj6J4jUgGm2gQlEM= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2bbbda48904so56691781fa.2 for ; Tue, 22 Aug 2023 11:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692730636; x=1693335436; 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=inlF5gsUho4gYjrYe8/Wo40BCJxua4Uvc+Bdc/N+Rj0=; b=HlPe2atTgNZzwdRxZlOrGwQL/yyg6LDet4oCcik9FAKxqjwzyJCbBsY8tjzT1EJ57Q xfdurN1gaTPOmglpAPw7dCcIlS/oDxMtVx7BSls4Pf3xyXHQ2HYv153rB2s+Gg9rDI/3 VJKuigKVdW2YoL6npCNefsq4I0oehA9wWGVK49ZKQNMk1cr6n5cJ5AIH7NbrNTuq1O6u zNpqyOYpnqG9Uq/aZSNPRAhH2KZPW+8oRn7/ngNhtlk5JSBzG+fyec5H2B8Yq2KR8pxF +SCXV19PkwqTsotwPfjeFnNrVIJs1FXpXmnJzg0q/ArOLJVu51cYgywiU5ACPPxwz+Vh klFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692730636; x=1693335436; 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=inlF5gsUho4gYjrYe8/Wo40BCJxua4Uvc+Bdc/N+Rj0=; b=RVT3+Qi9Pa9i5u95ixZk7k/OsZQVAMb5LKmI5GIJ4RtqJSzckydLBiZNujDBNbFT5E it1fFb1Zb9PEGcd/2eDfCQy6zjJcHKo5YDI6s8jjHjlAvzdHMcJHccHMXMh8XCP99LRr /PAkGPtXoOWzgS8h3kGB4qONmWb00tvbm00Aun62x4lFgLOJHTKkXdt8av2S7Hnusv5q xUi5Ctdl1EdYmIRFn8bp6VPTcE0OoRNSdhgIQg4Nbv6EnI3ABy2DC3NVxzr/PiL75ZQ5 vAi1fPH1xOpFuHjqfPFF7ANYsnXI0CuGZ6DAVNU9EFOqfpczcqMIwxwfCrhvER1T67xh RoDA== X-Gm-Message-State: AOJu0YybJLml15mgc7AJIEb65Yr5ruD2DNmCJ2gB4x5SNRm130qewTUL REIK2hXBvQB+JJ944Pc8LUwtARexRon4epGeYT0= X-Google-Smtp-Source: AGHT+IHdBh5X7vWjrrb5BdXW3igkF4/n1lbp/VoSjLD+l2XezlJMUmsz7w9oPAXXkT/8Ct67GRInWJkyfpYkAWv2tT0= X-Received: by 2002:a2e:2c18:0:b0:2b9:c644:414a with SMTP id s24-20020a2e2c18000000b002b9c644414amr7481989ljs.46.1692730635900; Tue, 22 Aug 2023 11:57:15 -0700 (PDT) MIME-Version: 1.0 References: <20230817-free_pcppages_bulk-v1-0-c14574a9f80c@kernel.org> <20230821103225.qntnsotdzuthxn2y@techsingularity.net> In-Reply-To: From: Alexei Starovoitov Date: Tue, 22 Aug 2023 11:57:04 -0700 Message-ID: Subject: Re: [PATCH RFC 0/2] mm/page_alloc: free_pcppages_bulk safeguard To: Chris Li Cc: Mel Gorman , Andrew Morton , Kemeng Shi , baolin.wang@linux.alibaba.com, Michal Hocko , David Hildenbrand , Matthew Wilcox , linux-mm , Namhyung Kim , Greg Thelen , LKML , John Sperbeck , Huang Ying , Alexei Starovoitov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 004E420023 X-Stat-Signature: tg6nufnkgwoadc4xcep4xc1jb96xqy11 X-HE-Tag: 1692730637-163576 X-HE-Meta: U2FsdGVkX1/EeRyDvWlkp2oF2LHjBjRB/pTadkHH30ztXSoQ4kqikY3Qf/YYs9cLKIBTRamzcjcFAOO6KgrTJ9RdHbR2kjGDA3x1i2CMvlUfCpsOY5Qi4jryRKeKZfFExmsKCsFvdhACtrIsf2h8aKcaN+J49FbVoi36FN3g/UPEDwk0o7TiSbTmWc5yBCNxIF67MnNkBWpCHNZSWJq2e42hkTxdTAb4cY0u+QAoyXBPAtso6Vk//GP7Lg6dZDZYYBbtbhBCQz+RUJR1rgglmJrIxQTiaUGJQtytVaW1l4yAcE64De9eXX0QKdO/3ZPqAh/UNRBjMjwcARpe5YUEkCTcHYvtGFtNFRjCmuyAJu3T7UJxFNlsGwmTUqgk0csCSHRhze/tM9RnFin3SOGVlugR8Iau93MmDTor8+QX9gqTJR8yq5WTW+czKk7pkYu5oBlVkZEDBthRlGe0LCDdrtFJIXe299xjKiWZt49PN97xWsSHcsF+qrJhX84K77KzZGbM8IlizGc/wDXEPioY/9OHAGHz4nWDwestPRYi+HG8u1ONLg5IhOQXiOnZm3SbAgvmTNGGX1ML9jVagAI3f+dNfteXWPypXh/8/JUyS4vEZtZFL9o2uChq0R+S82ALqe5eQ4HfEmVtrYCIW7Ax995+V3JnNlwbZwANt+DttxzBVAhzcZigCev4B30WIpoOy79c0dJyngDbHiILyQ7JLRfe2q59BTamp5EWrqOlPEx4BlZl05Mvh/gOZ6uNQtBlopYH4qYR4h5CPmFv3iWTyudSK1kMENFhc0/0GfRzv8nUn2/XSzqEgn636gCYMW6sPs5kwihSSvyyE5RMWSgovLb/YHnfMl9UbVoUKOC5gfB2dRKPmFPY7hutJy+JQsUzA4F+WutWb6DU9xVHnyF6AcBB8RBfnC7unLKqLwAJ0TGlWWx3002hknkNb0qFlOcxHjF0z7b/aX9RKAPvWKR vjn6+AK+ pzli5rcMkAVzOarkq4aReHWYys8XAbXzGNiI7hswVfjo9nq0kPic1GJRZrQR2OlceDlJTXbG6YC105xGdwJhlrQM3vkA4TJB2A8HRo1craf7XXuhZeAlkwPKWBPyW/2nMpFNIyNywOWS10s4PFTKtseyNPf7MRJVnBz3MRNmUn0iRwRcyvAOWE4JT2q9KmLf/POOmi9E2aOMFEr6xu9E0f7dDig1drBqYCD0xX9c5SF5yLwi1fQF9GYZjGBLLcqqgtnZluJSqB70Vmbm0lXQmf0WMeHjrXWOzL5c/eahekwbqqGVu0doxp/KlK4Vd7+8s/l/W7st1gimog3aQhmQTi8xJj1raPysdW0ucW7Ms7RY9nAJw1CwdcLfrrvIMIkMwu7zAFPI4H7fu2F7T79T0zLKdckdLHy22rNYBQ6KoYt9OttsiPPOrNOgV6Yl7/9DMtsMwbCHg6LlD1N9wx4hBc11v1261L5zckHgTDQ4Ea3tmgWKnxAebUAVgRXfyZmbRyQjxMacJ6xHmzT9KjkakDCYsoqvdL4k7WW2KSk9Fqcr6vwA= 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 Tue, Aug 22, 2023 at 10:48=E2=80=AFAM Chris Li wrote= : > > Hi Mel, > > Adding Alexei to the discussion. > > On Mon, Aug 21, 2023 at 3:32=E2=80=AFAM Mel Gorman wrote: > > > > On Thu, Aug 17, 2023 at 11:05:22PM -0700, Chris Li wrote: > > > In this patch series I want to safeguard > > > the free_pcppage_bulk against change in the > > > pcp->count outside of this function. e.g. > > > by BPF program inject on the function tracepoint. > > > > > > I break up the patches into two seperate patches > > > for the safeguard and clean up. > > > > > > Hopefully that is easier to review. > > > > > > Signed-off-by: Chris Li > > > > This sounds like a maintenance nightmare if internal state can be arbit= rary > > modified by a BPF program and still expected to work properly in all ca= ses. > > Every review would have to take into account "what if a BPF script modi= fies > > state behind our back?" Where did this concern come from? Since when BPF can modify arbitrary state? But I wasn't cc-ed on the original patch, so not sure what it attempts to d= o. Maybe concern is valid. > Thanks for the feedback. > > I agree that it is hard to support if we allow BPF to change any internal > stage as a rule. That is why it is a RFC. Would you consider it case > by case basis? > The kernel panic is bad, the first patch is actually very small. I can > also change it > to generate warnings if we detect the inconsistent state. panic and warns because of bpf prog?! bpf infra takes all the precaution to make sure that bpf progs can never cause such damage. > > How about the second (clean up) patch or Keming's clean up version? I can= modify > it to take out the pcp->count if the verdict is just not supporting > BPF changing internal > state at all. I do wish to get rid of the pindex_min and pindex_max. > > Thanks > > Chris