On 10/23/24 11:23, Hyeonggon Yoo wrote: > On Wed, Oct 23, 2024 at 1:08 AM Christoph Lameter (Ampere) > <cl@xxxxxxxxxx> wrote: >> >> On Tue, 22 Oct 2024, Vlastimil Babka wrote: >> >> > On 10/21/24 18:27, Christoph Lameter (Ampere) wrote: >> > > On Mon, 21 Oct 2024, Vlastimil Babka wrote: >> > > >> > >> I think the comment "If this function returns an error, kobject_put() must >> > >> be called" means that *if* you want to destroy it due to the failure, you >> > >> must use kobject_put() and not e.g. kfree(). But IMHO it doesn't mean you >> > >> must destroy it because of the kobject_add() failure. >> > > >> > > Right. The simplest solution is to see the sysfs stuff as optional. If it >> > >> > To clarify, I only meant the case of boot caches processed for sysfs later. >> > I don't think we need to start ignoring all sysfs errors. >> >> Well not ignoring. Write something to the syslog. So it wont affect slab >> operations. /sys support is not critical to the slab subsystem operations >> and is often not used at all. >> >> If its conks out then it should be fixed but it should not impact current >> operations. We have had so many issues with sysfs support in the past that >> doing so would be wise to avoid future problems. > > Both directions look fine to me. Christoph's approach would probably be better > for maintainability I think? Failing to create sysfs files is not a > critical problem anyway. Yeah I guess, if it makes things simpler... Feel free to do that as v2 then!
