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 B81E5C2BD09 for ; Wed, 3 Jul 2024 12:40:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34AA86B0098; Wed, 3 Jul 2024 08:40:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FA506B0099; Wed, 3 Jul 2024 08:40:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19B3A6B009B; Wed, 3 Jul 2024 08:40:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id ED6356B0098 for ; Wed, 3 Jul 2024 08:40:24 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 991EFC0BBF for ; Wed, 3 Jul 2024 12:40:24 +0000 (UTC) X-FDA: 82298399568.23.FAB2E58 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf06.hostedemail.com (Postfix) with ESMTP id CE6FE180017 for ; Wed, 3 Jul 2024 12:40:21 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720010390; 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; bh=ymk/hQP5gIXQqZ5sU5np3q3GABuSFJBLMO9EGTles68=; b=UJ0rpllSOrjF0BusLe4FN1OCBDAlqUErX/ylgEtz3MLz0AqmFDapqif/l0+4EbShOiyFjt ZO/I2h8ca034QybCcheAcLN+bJfjXTWEQyDliqQI+H7FpmBXet/gNgIuc3MuivxchDvFED L9hbv1UZdDZF8gR7cRBFu6pmBJ8YLZ8= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720010390; a=rsa-sha256; cv=none; b=3ZYShLBFwNJJEEbi/22TqG6Lq4qMzZO8UKHoR1UP9vd4U2s3/eJcslUDHonlSNzBybiunj gLRgRP9vMS/icn64/voZO44kyEqLkFzLOlbNNwmlzL31jt7maKnvoB1O7icT/KaU6rl1yz yVZE49pP+8sk5xmsxMD8OmOq8pW/jUc= Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4WDfQ81s21zZhG9; Wed, 3 Jul 2024 20:35:44 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id D6C6B180087; Wed, 3 Jul 2024 20:40:17 +0800 (CST) Received: from [10.69.30.204] (10.69.30.204) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 3 Jul 2024 20:40:17 +0800 Subject: Re: [PATCH net-next v9 10/13] mm: page_frag: introduce prepare/probe/commit API To: Yunsheng Lin , Alexander Duyck CC: , , , , , Andrew Morton , 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> From: Yunsheng Lin Message-ID: <200ee8ff-557f-e17b-e71f-645267a49831@huawei.com> Date: Wed, 3 Jul 2024 20:40:17 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <15623dac-9358-4597-b3ee-3694a5956920@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemf200006.china.huawei.com (7.185.36.61) X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CE6FE180017 X-Stat-Signature: fotdwzwoqjik1htzfngh3bib8d1pi4u5 X-Rspam-User: X-HE-Tag: 1720010421-282000 X-HE-Meta: U2FsdGVkX188cMpvLWyDo8xJEP3bG5Fpw/uXdRjQf0VXsl1Yd4ywZDAiKLAksW7HbtVad/oldZ+zhrp5bx4pNduEzuKBSCKMGqByAizFTxLpaoKS/Atk0T5XsY48SwTHXyZ3eV6xZD+tbfTgsTgHXqJQ2r/EBAxsEuOEy2EA2IZn6ZduSu0SqtSYKOmnFHDvirPcWIj88QwQrq/vrjC3iiZvSvNmqv5srzGqsmUzm7iXxldtzmxUUe/8zx6l1f437ROYXu/HXUdMKqkebjINED9kSLllo3XyfKQKbL5ealeQX4Js1u5YZSIJKdMNq3jgyOsEeuaClBDcz2rGdEFa4MK1BShoD2dJ8MEEuVJi5cQO1OIMxIN9AoeKRpoXETZ3nz1vz02sy2/BzLWylHERS9GXddMKwTH/BVjWrjXPLjL0q2jsPXFDGgX1+wqeAZie7BADB0DgVp1E6NxonxRyvihhSjXSdJgFvLbyDfpTJxI7N99hFvAB0b/WFTmNW/1pBgprsFPtWyWrvw76+xUNn7PdYT6OpEJqJjKyCCq5wf0XASyvnZTc1ULmOOKDLPxeoqTokuBl4a/TjY1mOnzJu5Rnt6B9+foSjyVT0UzkWwsOND5V7r6kGbo83S2JCSA1/KUxx+cVS104lCGSlh0bKknaHPwNxx1oyGLkdw5nmfP9c6SRcrgpAq0t2YEDBoUExI+krgS3pHjPPwmm3gFYPK1RlD8VhLf0Olh2l2zjPXclIhrQXSeIUx3SPFtbaHo8US0Bfb6CVaElxd1cUKX90QstwxbxeZHb34k/58f8/LKcnjJfdYY5xOwy2yn7IRJ/Ib1V53WgwYt6gq0+0qVjDOZC0jErKrQq8QOjLRrGpCI9wSTyUoqJ1PBQyo2O5Re3iJoycQFTPkZLTdVNI8daL1yc0pTi/lLyvjpo/U1ojwjvwrW2TANp5TvSkfKxUJ/SBJDO/g9BE7gqjdya6CV ZCBcEBmz tNov080EZMWdCrAhHm7ruuNuP3MxzPyL1kNIlJ9O5WC5/pHPB6JiR1b7Jtj5NQ4w7UIQcn6EH8FZ64MEndDIXY1kmsJHe4l/f5XmkVXCyI+t+DzK1pxTUaP6RGgM1Zh8RtKaBKXCl6ZZIIiud837aPxf1UeFuk93/g0SJzU/sppf9BOofPCxL+4nrR9Rqf1CpuviZCEteeXiD0X8GVaA4O5hvpVHSNkpJr1FhUtvgXXsPSHJxf+WFhMVKoY2cj9GLHOeUrlYT+6+sc73Oz8DNEM1RgRxvbqJNlaDk5/1UR0uC6hRwgykXQ7dR4gHa/LYxWizSxKM9KF8gM1o= 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 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 AM Yunsheng Lin wrote: >>> >>> On 6/30/2024 1:37 AM, Alexander Duyck wrote: >>>> On Sat, Jun 29, 2024 at 4:15 AM Yunsheng Lin wrote: >>> >>> ... >>> >>>>>> >>>>>> Why is this a macro instead of just being an inline? Are you trying 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 compiler >>> error caused by interdependence between linux/mm_types.h and asm/pgtable.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_cache.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 ‘mmap_assert_locked’: > ./include/linux/mmap_lock.h:65:30: error: invalid use of undefined type ‘const struct mm_struct’ > 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 subsystem, 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. > . >