Re: [PATCH] slub: make sysfs file removal asynchronous

[Tejun Heo]

Hello,

On Tue, Jun 20, 2017 at 06:22:05PM -0400, Steven Rostedt wrote:
> > I think we'd risk more by backporting it through -stable than keeping
> > the bug there.  The bug is very difficult to hit.
> 
> Famous last words.
>
> >  Writing to a slub
> > sysfs file has to race against kmem_cache destruction and AFAICS all
> > slub sysfs files are for debugging.
> 
> It's not that big of a change. It's simply moving the work to a work
> queue. I've done bigger changes than this and backported it to stable
> for similar reasons.

Some of our -stable backports do backfire.  This isn't a black and
white issue.  We all know even a trivial looking change carries some
level of risk.

> All it takes is for it to be hit once in a billion, and that billionth
> time could be critical. 

And we have to weight that against the possibility of breakage from
the backport, however low it may be, right?  I'm not strongly
convinced either way on this one and AFAICS the slub sysfs files there
are mostly for debugging, so we'd be risking breakage in a way more
common path (kmem_cache destruction) to avoid unlikely deadlock with a
debug facility.  I think -stable backports should be conservative and
justified as breaking things through -stable undermines the whole
thing.

Thanks.

-- 
tejun