[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ae5ccd01-f43f-1228-414b-48491e477768@suse.cz>
Date: Tue, 17 Jan 2023 13:57:37 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Rong Tao <rtoax@...mail.com>, 42.hyeyoo@...il.com
Cc: akpm@...ux-foundation.org, cl@...ux.com, iamjoonsoo.kim@....com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
penberg@...nel.org, rientjes@...gle.com, roman.gushchin@...ux.dev,
rongtao@...tc.cn, sdf@...gle.com, yhs@...com
Subject: Re: [PATCH] mm: Functions used internally should not be put into
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
Powered by blists - more mailing lists