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.
