From: Tejun Heo <tj@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH] slub: make sysfs file removal asynchronous
Date: Tue, 20 Jun 2017 18:48:14 -0400 [thread overview]
Message-ID: <20170620224814.GK21326@htj.duckdns.org> (raw)
In-Reply-To: <20170620182205.6e0390d8@grimm.local.home>
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
next prev parent reply other threads:[~2017-06-20 22:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-16 12:55 [LOCKDEP BUG] from slub: separate out sysfs_slab_release() from sysfs_slab_remove() Steven Rostedt
2017-06-19 20:35 ` Tejun Heo
2017-06-19 21:27 ` Steven Rostedt
2017-06-20 20:45 ` [PATCH] slub: make sysfs file removal asynchronous Tejun Heo
2017-06-20 21:58 ` Andrew Morton
2017-06-20 22:00 ` Tejun Heo
2017-06-20 22:22 ` Steven Rostedt
2017-06-20 22:48 ` Tejun Heo [this message]
2017-06-28 14:47 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170620224814.GK21326@htj.duckdns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).