Messages in this thread | | | Date | Tue, 20 Jun 2017 18:48:14 -0400 | From | Tejun Heo <> | Subject | Re: [PATCH] slub: make sysfs file removal asynchronous |
| |
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
| |