From: Vlastimil Babka <vbabka@suse.cz>
To: Rong Tao <rtoax@foxmail.com>, 42.hyeyoo@gmail.com
Cc: akpm@linux-foundation.org, cl@linux.com, iamjoonsoo.kim@lge.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
penberg@kernel.org, rientjes@google.com,
roman.gushchin@linux.dev, rongtao@cestc.cn, sdf@google.com,
yhs@fb.com
Subject: Re: [PATCH] mm: Functions used internally should not be put into
Date: Tue, 17 Jan 2023 13:57:37 +0100 [thread overview]
Message-ID: <ae5ccd01-f43f-1228-414b-48491e477768@suse.cz> (raw)
In-Reply-To: <tencent_6238B3302FB554EC5EEF475F11470C048509@qq.com>
On 1/17/23 03:01, Rong Tao wrote:
> Hi, dear Hyeonggon.
>
> If sl*b_def.h is not intended to be used externally. That is to say we should
> never include sl*b_def.h in module? The following code will not compile success
> since commit 40f3bf0cb04c("mm: Convert struct page to struct slab in functions
> used by other subsystems"), but success in older kernel. Especially for modules
> that use the kmem_cache structure, this is catastrophic.
If such module was part of the Linux tree, breaking it would be noticed
sooner and fixed, probably by changing the include to "mm/slab.h"
instead of sl*b_def
...
> You are right, if sl*b_def.h is not intended to used externally, Modules that
> use kmem_cache structures should not be designed from the outset to use
> kmem_cache structures. Or the kernel can use this patch, and these modules can
> be compiled successfully.
For out of tree modules we can't make any guarantees. It's best for
those if they don't rely on such specifics. As Hyeonggon pointed out,
there are more robust ways to get object layout than including kernel
headers. Also it was broken since 5.17, which is quite some time ago. Is
the code you're fixing still relevant or was replaced with something
based on BTF already?
> Best wishes.
>
> Rong Tao
next prev parent reply other threads:[~2023-01-17 12:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-16 8:50 [PATCH] mm: Functions used internally should not be put into slub_def.h Rong Tao
2023-01-16 11:59 ` Hyeonggon Yoo
2023-01-17 2:01 ` [PATCH] mm: Functions used internally should not be put into Rong Tao
2023-01-17 12:57 ` Vlastimil Babka [this message]
2023-01-18 7:23 ` Rong Tao
2023-01-21 20:34 ` Yonghong Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ae5ccd01-f43f-1228-414b-48491e477768@suse.cz \
--to=vbabka@suse.cz \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rongtao@cestc.cn \
--cc=rtoax@foxmail.com \
--cc=sdf@google.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox