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 7F608C2BD09 for ; Tue, 9 Jul 2024 13:41:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F31076B00B9; Tue, 9 Jul 2024 09:41:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EE1456B00BB; Tue, 9 Jul 2024 09:41:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA9406B00BC; Tue, 9 Jul 2024 09:41:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BC0636B00B9 for ; Tue, 9 Jul 2024 09:41:39 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 646E2161943 for ; Tue, 9 Jul 2024 13:41:39 +0000 (UTC) X-FDA: 82320326718.09.EE43DB2 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf21.hostedemail.com (Postfix) with ESMTP id 988E51C0005 for ; Tue, 9 Jul 2024 13:41:37 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TuAQhcqf; spf=pass (imf21.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.128.52 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=1720532467; 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=knWPJfcPnK6qjC655MgiE/tsLpIcwsRamnwiOz/QKYg=; b=BVarNHVSn1BY7XESGUJp0J8uBurJqiSbbc2VHn1YPpO+lOQ5VvWhCwj+NM7mWvUMxbxN19 7HhOPrOKEM5iBx/NVBLIlN0mZtJZWYkSXqeu6RLTTKw0p0avAW1u4NHqxrH+vJyQybIsUB a9xQgrTzb6M73F0XvIhtsIACd/MNBDk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720532467; a=rsa-sha256; cv=none; b=JkptWM3J1a8f794VM9SHxCJqF2tGoj42fOEKTdHLF1xk97h3V9ibk0lu9SAtreJzCqgS2Z HHSH/aU0oJp9xRKZgpi+nR8usDms+mIOBMfP5GxQI+ZBPFhfOUPX5XqV5R31M5Nwvb64wA JQgnvf5gyImzkqFd8MvUToMeiwafGGo= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TuAQhcqf; spf=pass (imf21.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4266b1f1b21so13383855e9.1 for ; Tue, 09 Jul 2024 06:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720532496; x=1721137296; darn=kvack.org; 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=knWPJfcPnK6qjC655MgiE/tsLpIcwsRamnwiOz/QKYg=; b=TuAQhcqfVyY12Xe9jRbwevpCqUBoEs46FGpdaU+Qgkbw83N9xF4md2O/I7pklYIu/z 8yLkVmmud+UYOS7+dn2slx4/f7Srfe3vC1zRN1a+ZDBpOwn+gies7SEbjXLAa20dnCYR KLgqsyZi8A80z5Wb/qyd10Jh0yqsY9lwIQ6ymNUiSLP+ODIliorSw/5nRhF2s/bmfj2R 1fACRoKcU5tUrKHVXVyxoC7xqO63bNOMfDekS5g2Ni4my7P3MeDLClIcOPvNWrFIILc9 a5HS8hSzb1Yl2q2gLJPxsMBwAMWPdbomHb1aCHVoq6NLlSMH5DNnYIPSIgVWPwNpQD9K ayNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720532496; x=1721137296; 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=knWPJfcPnK6qjC655MgiE/tsLpIcwsRamnwiOz/QKYg=; b=FqeVDYl/OHPN3uAW5BJwrfJnPgQfDRcL+jVV+TLo5K0dMkJYWVvBjzdibmB8CCziWa QncvVsPXcuQd+NBYKiKZYzP6FEFubv2dldV9utQMbwt2nBzBrGD1qoOv44h05T3ZxWql kHP1rz+ne+FGRgdLY1YbQvTwA8WW/y39UtZXbh3YZB2ZGRsukRA0sh2TWi+o4stMdfji kTGuWzeG146C7INZfR4BNxj+GnpIogonKoc9Hv8EplMvv0+kvhyGaEt2KJ/ebNljcKuG lf1JF4p8dG+WwaFeWHwE5TagiD9DAwZQCevLV16sYl9BuhMMwNl+UzsGxPdcv9OKvM0P tI9Q== X-Forwarded-Encrypted: i=1; AJvYcCV+IAp1paTRp9ZGOGbbZzn/2orPifP9Y4Ll92uMZp2lpWkjgv6Eq/A/KSYjzyJtvWU/Adk/16odnHxPsBzmwRTrasc= X-Gm-Message-State: AOJu0YydN35+GLUtEs3SP5aGv2+xV9zR9x2XhKeJOmGiAEFDSoncwjly DZA21Y7ZmPlC0c3P1aZyLfBijbF6v8IglFe5HhwaTlUEg5zVCrIar4XRzd+9uMt1l7znlhkhCtu m0fITwIFrfeIBMD52K/vp3YCG+ac= X-Google-Smtp-Source: AGHT+IFmBVEwha1tc7CN+fLxQ0HlyLl7ulTFXUR8JuKEwrRVK3HqtTJSTw6UjD9BxhUhGU4c/0ZN+lgIEnyyqX/kAFU= X-Received: by 2002:a05:600c:2e0a:b0:426:6f15:2e4d with SMTP id 5b1f17b1804b1-426707da1b5mr15586755e9.9.1720532495871; Tue, 09 Jul 2024 06:41:35 -0700 (PDT) MIME-Version: 1.0 References: <20240625135216.47007-1-linyunsheng@huawei.com> <20240625135216.47007-11-linyunsheng@huawei.com> <33c3c7fc00d2385e741dc6c9be0eade26c30bd12.camel@gmail.com> <38da183b-92ba-ce9d-5472-def199854563@huawei.com> <0a80e362-1eb7-40b0-b1b9-07ec5a6506ea@gmail.com> <15623dac-9358-4597-b3ee-3694a5956920@gmail.com> <200ee8ff-557f-e17b-e71f-645267a49831@huawei.com> <83cf5a36-055a-f590-9d41-59c45f93e7c5@huawei.com> <2b7ecaca-9a17-e057-8897-d0684b31591d@huawei.com> In-Reply-To: <2b7ecaca-9a17-e057-8897-d0684b31591d@huawei.com> From: Alexander Duyck Date: Tue, 9 Jul 2024 06:40:59 -0700 Message-ID: Subject: Re: [PATCH net-next v9 10/13] mm: page_frag: introduce prepare/probe/commit API To: Yunsheng Lin Cc: Yunsheng Lin , davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 988E51C0005 X-Stat-Signature: 6atbt8zm7h51j6ewo9ntoqhuqh4u5hin X-HE-Tag: 1720532497-679091 X-HE-Meta: U2FsdGVkX1/9HGp0Anz87daO73+F4BCQaTXJc+Q7sR6Q6lrmXMYYyH7mvW0KFJtzWHDl+1lgcc51QDrraC4hZaEJO10vYImC0PtDNW3z+O7v7TY6EHFgSnYlFZmaXc6g7BCUEyTkMsO/O7LOO6hNRFs9Dn8R/GLlId0hoNd13DELgoG+THYTqR2O0R3rRJLGOGWR7PTdgnQHHuxzBno/NDvevU/hk37GibVsIk/4LNdZWxa+mo9v5EvxK3LJGi44YcQAhBzLt96JY3sYBmYw+QZjpFjAYr6WE9nKeO+rCJHeEohqavosNZWIqbgvyb0guQn4TqhHBEj0FSM1U+anJPU9onfhBJKjS+M5B0TdJWMFBT/JQoisQf6b2w/0Pi9fQOt9nDnwyxF3k3Xk9q0wVvfY/Gb1XLV72vQ49Sw9Nwm4ec4sM6mxyz/jnTPY4covjW8sFzUHDZLwPlHMORQ8/fAgQMaIRl+22wz33Mjgz26usyeRAT+tCNsCUOtKUqIuYZFbQflOpaOnrlGEq/GPn+0T6ljTg54c7C93xhcmVQnBsZ+07Lw78jmLPXuDlCb58fp/LVwOBzAU5R3UmdwO1q13gt6afiGBZe8UAPOoMB6CLhs0tOvIo9e6js04MWGGwCCexyo0pDzKHoCqgaoappVDCJ+EKo8FjSnVnPnaFZxjD50ifWr/bnOH5GIkocaWpaGRzoohY7IjQS3iBJsk2AinMp8AJrgstwM++zAsDKBNCASnXMZgEHhmKFn1Be/96Bh3HnxJdiKTfqIxBqdQq3EKacWs9Cg9pX/P7j9xo0ofG7aYg615Ljd60ofje34sSriOfPqU0hjOOMaCKFoNC4hGmA2pmQUg5/PC4Nn++o1CG0k3otb1beM2LecseCd1v6uPGpLHOFxmdBVbj5/t0SXprc1TyZJTkzaV0GWSLTIB4ZuU32mTXIucZdY54YIboYW1UXozx/FQB8ND3zE c6BJsrWR rTXizlSuDJp33xdEyBTsxOGrDdBVxMz+Z6qJ8c2cNdXPV113QPWz199iGyZHNFY160S3hdhYbYFJNZbljivmavTwjdRachtAGSGv34oj6veY3cUQEVZFXKlfSAlF3x8UesDnbGrEiGOVaYG/6y4Epj3JexewXlTnWtFHEug//0Kpiq5NG0xR8cWGtRs4Yl5J9p9CrJjzTfQx1Rnk3agkwEdWoyDm78be3eZC361V2XzvzEP51OFQ0SLDPWp56Sln88kIPJmQa+SQzg5Z3J5GaaZmsB/X9n64A+c/aLSApbuQmVB4ZYBMhAyyBlXeEpxamYFFCPItNQFOKn8LbjMWaIt2EazljIAHzXb7Q9j/cTSkng/MJVjC9OP78YDz8P15XZZ9Fc1l2RvTXAdBqcJc+QLv1gyAgjEPeRqqzCyj7GyjoT69+xM/FmZjiwr3C4sre53FYa7sflV1nURQ= 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: List-Subscribe: List-Unsubscribe: On Mon, Jul 8, 2024 at 11:58=E2=80=AFPM Yunsheng Lin wrote: > > On 2024/7/8 22:30, Alexander Duyck wrote: > > On Mon, Jul 8, 2024 at 3:58=E2=80=AFAM Yunsheng Lin wrote: > >> > >> On 2024/7/8 1:12, Alexander Duyck wrote: > >> > >> ... > >> > >>> The issue is the dependency mess that has been created with patch 11 > >>> in the set. Again you are conflating patches which makes this really > >>> hard to debug or discuss as I make suggestions on one patch and you > >>> claim it breaks things that are really due to issues in another patch= . > >>> So the issue is you included this header into include/linux/sched.h > >>> which is included in linux/mm_types.h. So what happens then is that > >>> you have to include page_frag_cache.h *before* you can include the > >>> bits from mm_types.h > >>> > >>> What might make more sense to solve this is to look at just moving th= e > >>> page_frag_cache into mm_types_task.h and then having it replace the > >>> page_frag struct there since mm_types.h will pull that in anyway. Tha= t > >>> way sched.h can avoid having to pull in page_frag_cache.h. > >> > >> It seems the above didn't work either, as asm-offsets.c does depend on > >> mm_types_task.h too. > >> > >> In file included from ./include/linux/mm.h:16, > >> from ./include/linux/page_frag_cache.h:10, > >> from ./include/linux/mm_types_task.h:11, > >> from ./include/linux/mm_types.h:5, > >> from ./include/linux/mmzone.h:22, > >> from ./include/linux/gfp.h:7, > >> from ./include/linux/slab.h:16, > >> from ./include/linux/resource_ext.h:11, > >> from ./include/linux/acpi.h:13, > >> from ./include/acpi/apei.h:9, > >> from ./include/acpi/ghes.h:5, > >> from ./include/linux/arm_sdei.h:8, > >> from arch/arm64/kernel/asm-offsets.c:10: > >> ./include/linux/mmap_lock.h: In function =E2=80=98mmap_assert_locked= =E2=80=99: > >> ./include/linux/mmap_lock.h:65:23: error: invalid use of undefined typ= e =E2=80=98const struct mm_struct=E2=80=99 > >> 65 | rwsem_assert_held(&mm->mmap_lock); > > > > Do not include page_frag_cache.h in mm_types_task.h. Just move the > > struct page_frag_cache there to replace struct page_frag. > > The above does seem a clever idea, but doesn't doing above also seem to > defeat some purpose of patch 1? Anyway, it seems workable for trying > to avoid adding a new header for a single struct. > > About the 'replace' part, as mentioned in [1], the 'struct page_frag' > is still needed as this patchset is large enough that replacing is only > done for sk_page_frag(), there are still other places using page_frag > that can be replaced by page_frag_cache in the following patchset. > > 1. https://lore.kernel.org/all/b200a609-2f30-ec37-39b6-f37ed8092f41@huawe= i.com/ The point is you need to avoid pulling mm.h into sched.h. To do that you have to pull the data structure out and place it in a different header file. So maybe instead of creating yet another header file you can just place the structure in mm_types_task.h and once you have dealt with all of the other users you can finally drop the page_frag structure.