Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752746AbdFTWsS (ORCPT ); Tue, 20 Jun 2017 18:48:18 -0400 Received: from mail-yb0-f175.google.com ([209.85.213.175]:34256 "EHLO mail-yb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752020AbdFTWsR (ORCPT ); Tue, 20 Jun 2017 18:48:17 -0400 Date: Tue, 20 Jun 2017 18:48:14 -0400 From: Tejun Heo To: Steven Rostedt Cc: Andrew Morton , Christoph Lameter , Pekka Enberg , LKML , Linus Torvalds , Vladimir Davydov , David Rientjes , Joonsoo Kim Subject: Re: [PATCH] slub: make sysfs file removal asynchronous Message-ID: <20170620224814.GK21326@htj.duckdns.org> References: <20170616085507.3cc7d4b8@gandalf.local.home> <20170619203538.GN12062@htj.duckdns.org> <20170619172750.6890df32@gandalf.local.home> <20170620204512.GI21326@htj.duckdns.org> <20170620145814.9eb1b74feaf908c39e9c0de2@linux-foundation.org> <20170620220011.GJ21326@htj.duckdns.org> <20170620182205.6e0390d8@grimm.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170620182205.6e0390d8@grimm.local.home> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1288 Lines: 36 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