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 2CCB8C433EF for ; Mon, 11 Jul 2022 18:23:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65FE4940012; Mon, 11 Jul 2022 14:23:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60EB3940010; Mon, 11 Jul 2022 14:23:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D837940012; Mon, 11 Jul 2022 14:23:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3C023940010 for ; Mon, 11 Jul 2022 14:23:15 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 075B720E15 for ; Mon, 11 Jul 2022 18:23:15 +0000 (UTC) X-FDA: 79675641150.14.E94FB77 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by imf20.hostedemail.com (Postfix) with ESMTP id AA5661C006A for ; Mon, 11 Jul 2022 18:23:14 +0000 (UTC) Received: by mail-wr1-f46.google.com with SMTP id q9so8096855wrd.8 for ; Mon, 11 Jul 2022 11:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LDyh/vtAqlchTUEJhEUMVYzVZhOGqr+c1tP2nxvPQ3E=; b=BaSeEBuhTSPhFm1WrSLp2YkYR10LGnYPSUVyfpevAiQd+DV3x60uiu1vOlXhEPoafT 8uhaaIcyLSG9Pfly5++bPQSfjqetrKb+e2ZuT3cl6BE2XJ9sebsq1WjXLnrFxAa9uuEy H0o65IOCCQv07sPoU38yamOZAPVR9Sd7l8Eh6TG99L8bB7C+WOf8NhQaC6Ukbid8ud4F T69SBV5AT+wvKH8c0PvqhABw//I3Wdju5UbLtOE+Id97rVZ/WeALxW8lH3P9dTY2NmWV FOYV00GouzXZIvvNtP2S6wbHzYTMayz+PPB/hR0kNDqsUC45ixtSk5aY1fgDPrAkg5ua Iqpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LDyh/vtAqlchTUEJhEUMVYzVZhOGqr+c1tP2nxvPQ3E=; b=LVNHQHtvxY95rmz6CN00I355wlEzhPaqVqmTDoT5015y2mddziEj61eyLnSrXhqdxD TTiTsIquzXi00Y8jxBV3qhAwgnmGgjoguziSVS+xmorUablAR7cmQTGJ1MX7VfIFz+Ey VUFAP8K74yuF8Ej/VUsvZvz7nlJ/f6AnM32XB5n39L0wESGwlXXBD/0u79LmjasN8GiX xpmbyEA4S/bDqFczfY5JIiYz+9IQF7KH8dg1Lpn6Vktyhx4DrPU1mYgl4lkfZNQKMZvz 8M2MsH9dYwrmtarAKdCQtgi+T2MKrOOh14KL+mqcMh9OpS6xOA4MDvB9YwlFmCYOrDKt 11QA== X-Gm-Message-State: AJIora/yC9OX1U0SVdTWwC9EFwnDuJ1Sa7nCQ1Sqh8dDF6j9MLHaCaMk huTII0a+FtITcCFG7xX/lhiGwUb7HOm+ALaN52w= X-Google-Smtp-Source: AGRyM1vnXJ5hhT+ys1lcCGj0nB0+/HxOwAfACFTvmeWcxHW8mH9vqF6mNfjJ5oVC0wEams8uv9j7kD9E93A0fTrK9e4= X-Received: by 2002:adf:f90c:0:b0:21a:3dcb:d106 with SMTP id b12-20020adff90c000000b0021a3dcbd106mr17872123wrr.448.1657563793057; Mon, 11 Jul 2022 11:23:13 -0700 (PDT) MIME-Version: 1.0 References: <20220711075225.15687-1-mlombard@redhat.com> In-Reply-To: From: Alexander Duyck Date: Mon, 11 Jul 2022 11:23:01 -0700 Message-ID: Subject: Re: [PATCH] mm: prevent page_frag_alloc() from corrupting the memory To: Maurizio Lombardi Cc: Jakub Kicinski , Andrew Morton , linux-mm , LKML , Netdev , Chen Lin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657563794; a=rsa-sha256; cv=none; b=S/EhYRd4WKvztDGvzAdOEWoTUZkal+Nsy3VYI8M1arLhFYvT3BcUXfKmwZ1ActqpofBbmb nwBr1DYBxe0w/5nmj4x4KMI/d4pEg86HOYhzYU7zDLMFL5LVh7UydaI2DF+h/EHz/5M7Q5 qzIULenA1BEvJU7Leo9Vj7N1aqhRE9M= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BaSeEBuh; spf=pass (imf20.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657563794; 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=LDyh/vtAqlchTUEJhEUMVYzVZhOGqr+c1tP2nxvPQ3E=; b=c3/OMQ25OMtJXkcbbPibgXbPwI17GJm8ykaL6Vn0rYamiObrCi9FCNxl7xPjVM3JnMbZ86 oCM2C1LR/THbm/TOnbRol0qyRla0JBbqwZIFDC82PReHiFe1oGef6/szhLxW7RVm4J55MY Wv7AXd4dHi/9tQdta2JMnFuq3rFkGdA= X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AA5661C006A X-Rspam-User: X-Stat-Signature: zd18krud1edxnkqzoemh59hmoxhesbsf Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BaSeEBuh; spf=pass (imf20.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1657563794-764793 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 Mon, Jul 11, 2022 at 9:17 AM Maurizio Lombardi wro= te: > > po 11. 7. 2022 v 17:34 odes=C3=ADlatel Alexander Duyck > napsal: > > > > Rather than forcing us to free the page it might be better to move the > > lines getting the size and computing the offset to the top of the "if > > (unlikely(offset < 0)) {" block. Then instead of freeing the page we > > could just return NULL and don't have to change the value of any > > fields in the page_frag_cache. > > > > That way a driver performing bad requests can't force us to start > > allocating and freeing pages like mad by repeatedly flushing the > > cache. > > > > I understand. On the other hand, if we free the cache page then the > next time __page_frag_cache_refill() runs it may be successful > at allocating the order=3D3 cache, the normal page_frag_alloc() behaviour= will > therefore be restored. That is a big "maybe". My concern is that it will actually make memory pressure worse by forcing us to reduce the number of uses for a lower order page. One bad actor will have us flushing memory like mad so a guy expecting a small fragment may end up allocating 32K pages because someone else is trying to allocate them. I recommend we do not optimize for a case which this code was not designed for. Try to optimize for the standard case that most of the drivers are using. These drivers that are allocating higher order pages worth of memory should really be using alloc_pages. Using this to allocate pages over 4K in size is just a waste since they are not likely to see page reuse which is what this code expects to see.