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 2DA65C3DA44 for ; Sun, 7 Jul 2024 17:13:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A08A6B0089; Sun, 7 Jul 2024 13:13:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8776E6B008A; Sun, 7 Jul 2024 13:13:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 71A856B008C; Sun, 7 Jul 2024 13:13:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 535B86B0089 for ; Sun, 7 Jul 2024 13:13:07 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E6C741A0E52 for ; Sun, 7 Jul 2024 17:13:06 +0000 (UTC) X-FDA: 82313601972.28.785538C Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by imf28.hostedemail.com (Postfix) with ESMTP id 17A97C0019 for ; Sun, 7 Jul 2024 17:13:04 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QQtb7xRA; spf=pass (imf28.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=1720372371; 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=2HjWM7/w5+5DdJAOM+7In7RUfCFAcEzKXxK1slwKZGM=; b=5rWa1vli+bb+P3Ti2wwwa13lrv3hrs4BRWLfZdcR/Lyee5sFD1/YWKpc69KHIE70t9eqhC S3Ldlg5jOaBA11v4iZDZF3goZTb6NfhZI5meAsBPd4lg5CxOREAX3sFrHA7sXiN0FRl2v0 wGjfstWMdssA98bRF984v6D6ax0kgAM= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QQtb7xRA; spf=pass (imf28.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720372371; a=rsa-sha256; cv=none; b=hWqhWo47B+wA8mn3+F2el4yupS9SDfB8PzN64NBRu6qjGge237jVWPhBG65nuxFVHb7Dym ApPr8itUGcOHx6Vt4sBUHxC0XvpdG3IdMNyf82VgXwLw1IXHh8kiVAWIAFlx3JJ0ymg3zi 90gfHr9ChivD5XggnUq5Xi/AYOHnCFU= Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-367990aaef3so2204264f8f.0 for ; Sun, 07 Jul 2024 10:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720372383; x=1720977183; 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=2HjWM7/w5+5DdJAOM+7In7RUfCFAcEzKXxK1slwKZGM=; b=QQtb7xRAfdJKRFtM6TSpi+P5hwSNMpECEsVfEh3A4EsB3Kr1XTpM8HaN/jYUHwqBJp q7YWUmQZ4PTHBjrMwEDSKq39ewwaMRZt7S4H5GP7KXP5njPwS4QBywiJIpQJqnskL6TA h3QOPPASpvgLfwlmvqq++9A4b0HX9Q0mI4zjf17j2Edw7YCdpXU9WxqhAhB7b07iZqBj /Rlo25fKh3fTOAPpfiIIWcA+wXIGnOb7adVpbypCV7TNOFLPiS8xvEylcqjO6M3A3mAr gC/bfLjiqxKkTqpHnsGc/jEiFECLSduI5bK9kvVOYOHXKTWV8sSniT3rkKi4PhjHMRfa FDVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720372383; x=1720977183; 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=2HjWM7/w5+5DdJAOM+7In7RUfCFAcEzKXxK1slwKZGM=; b=K+UCOzy2hAQ5kxjLbxuLcw7MOiB/p5m8uIJlZDCKgy+YH1HJTQMkOmcs3Y9WEYAbFs KK24ez6XtTTfNeWfL+i/XYkH7fD+0rvUvDAPP/gdeISRzzVJNi4yz+fWVTZCoPcbCnTl dJtbMIHYOoVSXhI1z59BFmh1Y+6EDT4MHySTcjOhbhG1htkp6e6bcAPERQIZ+4DvA4Iu fpvmX+mk8tqTBYb84TLMc+8Quppci+JWHUQ3J6aIWNgZ+6MdjtrXrT+IFsPzwSLSHoyK vqXOE8igHokR7Z/j3yabktwCUNP6si/WNSi+W7aoZNLpd4gmZwa3F5M0uFhGiicBFPG/ 0SgQ== X-Forwarded-Encrypted: i=1; AJvYcCWg7uIFgp5sI9ekK5GwgjX0NpiBvWomniccFORgWoG03KdlG0YddOXv9cUCw9hIE0QO+XeaNDzvuLglIkFOchwnalE= X-Gm-Message-State: AOJu0YznhQhiU73F4q1zOhyzC3HwkKZzYGEJ1zDQ1snLH+rFiHBdkdh7 qtWuil/FjnwdxHDrmvOUytBkrdWXNGhVuUviVr+E6EEH9U4y+TmgpRoi39RkFAXGpn/x0MhuSv2 N42pV9TVa9aHRgp5NLbwYsh2caNY= X-Google-Smtp-Source: AGHT+IH41zHheROtY9DzgazXdwYwjDYT4zQzVUIua/dGAi+LwnfedkPtv6ESkE2vU/RY04Ok6fD9MffkQIY1pHS0+7U= X-Received: by 2002:a5d:6889:0:b0:366:ee7b:591a with SMTP id ffacd0b85a97d-3679de74c32mr6152284f8f.71.1720372383195; Sun, 07 Jul 2024 10:13:03 -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> In-Reply-To: <200ee8ff-557f-e17b-e71f-645267a49831@huawei.com> From: Alexander Duyck Date: Sun, 7 Jul 2024 10:12:26 -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-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 17A97C0019 X-Stat-Signature: 39baksyo77i74mmdb64u1s1y6oc5g6cp X-HE-Tag: 1720372384-734270 X-HE-Meta: U2FsdGVkX19B2TaBTvFCwWoP5ht1GLaCO2Ld/ZWZhTBP5l27ijLx9JPgR8SZ1xh6T+Y72QmiUonfadNi/4PGoA5y/S7PAcMdXLYdI+3ay5ghOhKuh/z7pyzwjyPf+hNnSYOQQR1K/QsIxmlbqu20hxkBSeW/TKLBj/Ii9ES6xn1oodwdh1YbRokJjgvxFsF46cUcXBdEgKefGakhFt+28hgAEjuUvMRGqTeNbbbRDv4Dvkpf//uUwg5DX8zIfWy3AS0crFlc3qMDyCS4i18zwu3GpkW+C4uDgILFGOVw/eevpBS7uyChk7jQjDU9pWzC/wR1W2ZvZLhe0t/6heJwDfEb54HqvCaTDmU6Rd2zJSyUmcZQIMk2vIJXCbJE5Ks4t1ShYmmPecVsRDnN0TRpBCeC5q/HYF3bXpgmmLAB8LNVE9DYAPn24MLz4o40GsgbDq7fjaUi0CUJcdGCGLOYpH8fzHIes4VhWXi12uGlUtiUNwFFAuAPdYXWhhDPvoebmAQy0m6IMkwwi5LA71JqZbogNF4vXfKOZSZ1c9NlGdfH9aQQdzugR0WvMO87CkQjARPt6EsTLMVp4i1vMrfDJx/nLyAOKcVqPqbW8lvPZMduQERAEs25pHq0UbnWzBOkV0S3bQlCkWQib2rWbOio2zvYwkeN5GdeRPfQVbI3vVXYyoXgowOdAoEre/1h7VYHgge65KwRyCe9NOefb6QHzk9z7F55jdnjYgLYoQNLXP6bD86QhyLz6xmSWFdT7Z9JbHFPWmffsGKVhUB/pyBJU+rt+k1h7Sb8YZb+DxfgrI9PEtwyIvJEpEqWyHVCiJu0dxiExaQU3G8/Tf6UVDhihhU7I5NghQjbvhwg3VxJES4CRIyJPH63u5BDClqaZStgd1LrqRgoJvkIuC1JuXB3NbX9mmZjk5YTPOdPV3feGaJNzn3cZpjAV932aUoU36XXMbmNKceK1nOtAhoQr8e qlAfU4Cm +Au0FedBhJygbvvK1IjaDG0ZxkCR7gLVTJA80DDwWE6G2h+/xg/u2xEGJifIKwKX64rSUGKIygPhfmTeV5/jpcxIzmdt1hkTGPID+mFn0rw3oLhoHRLi6GE3Cs3ZvVZ8UshBw25jw8nFGhF3ylPA3uee9PtB5qS94OhIH/Euu7QEORbA79LaS3hgVD7JaUmibYVeQQ7LmMkGcPvhwgeFQsyXDL0QZ7WvIe6TkWDd7+UlJHDoaaT1tf203V3wtN1ZX4X61hgZbfJ0r9RHko/c6eT0pKCi73cNFvNzQas4WMnZGY32Jmo8n8zz6scXFNpyXhLISxWyFsD+3Bd+oKdkNzdBZpUhu8iWMSyulG14dIOaCg2Y+2k9Be6mu1Ch6R+hF0COu0gPlj0Q6zhdCdhrSglBp/uYqhTcZ1xG+ 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 Wed, Jul 3, 2024 at 5:40=E2=80=AFAM Yunsheng Lin wrote: > > On 2024/6/30 23:05, Yunsheng Lin wrote: > > On 6/30/2024 10:35 PM, Alexander Duyck wrote: > >> On Sun, Jun 30, 2024 at 7:05=E2=80=AFAM Yunsheng Lin wrote: > >>> > >>> On 6/30/2024 1:37 AM, Alexander Duyck wrote: > >>>> On Sat, Jun 29, 2024 at 4:15=E2=80=AFAM Yunsheng Lin wrote: > >>> > >>> ... > >>> > >>>>>> > >>>>>> Why is this a macro instead of just being an inline? Are you tryin= g to > >>>>>> avoid having to include a header due to the virt_to_page? > >>>>> > >>>>> Yes, you are right. > >> > >> ... > >> > >>>> I am pretty sure you just need to add: > >>>> #include > >>> > >>> I am supposing you mean adding the above to page_frag_cache.h, right? > >>> > >>> It seems thing is more complicated for SPARSEMEM_VMEMMAP case, as it > >>> needs the declaration of 'vmemmap'(some arch defines it as a pointer > >>> variable while some arch defines it as a macro) and the definition of > >>> 'struct page' for '(vmemmap + (pfn))' operation. > >>> > >>> Adding below for 'vmemmap' and 'struct page' seems to have some compi= ler > >>> error caused by interdependence between linux/mm_types.h and asm/pgta= ble.h: > >>> #include > >>> #include > >>> > >> > >> Maybe you should just include linux/mm.h as that should have all the > >> necessary includes to handle these cases. In any case though it > > > > Including linux/mm.h seems to have similar compiler error, just the > > interdependence is between linux/mm_types.h and linux/mm.h now. > > How about splitting page_frag_cache.h into page_frag_types.h and > page_frag_cache.h mirroring the above linux/mm_types.h and linux/mm.h > to fix the compiler error? > > > > > As below, linux/mmap_lock.h obviously need the definition of > > 'struct mm_struct' from linux/mm_types.h, and linux/mm_types.h > > has some a long dependency of linux/mm.h starting from > > linux/uprobes.h if we add '#include ' in linux/page_frag_ca= che.h: > > > > In file included from ./include/linux/mm.h:16, > > from ./include/linux/page_frag_cache.h:6, > > from ./include/linux/sched.h:49, > > from ./include/linux/percpu.h:13, > > from ./arch/x86/include/asm/msr.h:15, > > from ./arch/x86/include/asm/tsc.h:10, > > from ./arch/x86/include/asm/timex.h:6, > > from ./include/linux/timex.h:67, > > from ./include/linux/time32.h:13, > > from ./include/linux/time.h:60, > > from ./include/linux/jiffies.h:10, > > from ./include/linux/ktime.h:25, > > from ./include/linux/timer.h:6, > > from ./include/linux/workqueue.h:9, > > from ./include/linux/srcu.h:21, > > from ./include/linux/notifier.h:16, > > from ./arch/x86/include/asm/uprobes.h:13, > > from ./include/linux/uprobes.h:49, > > from ./include/linux/mm_types.h:16, > > from ./include/linux/mmzone.h:22, > > from ./include/linux/gfp.h:7, > > from ./include/linux/slab.h:16, > > from ./include/linux/crypto.h:17, > > from arch/x86/kernel/asm-offsets.c:9: > > ./include/linux/mmap_lock.h: In function =E2=80=98mmap_assert_locked=E2= =80=99: > > ./include/linux/mmap_lock.h:65:30: error: invalid use of undefined type= =E2=80=98const struct mm_struct=E2=80=99 > > 65 | rwsem_assert_held(&mm->mmap_lock); > > | ^~ > > > >> doesn't make any sense to have a define in one include that expects > >> the user to then figure out what other headers to include in order to > >> make the define work they should be included in the header itself to > >> avoid any sort of weird dependencies. > > > > Perhaps there are some season why there are two headers for the mm subs= ystem, linux/mm_types.h and linux/mm.h? > > And .h file is supposed to include the linux/mm_types.h while .c file > > is supposed to include the linux/mm.h? > > If the above is correct, it seems the above rule is broked by including= linux/mm.h in linux/page_frag_cache.h. > > . 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 the 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. That way sched.h can avoid having to pull in page_frag_cache.h.