linux-kernel - Re: [PATCH] slub: make sysfs file removal asynchronous

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170620224814.GK21326@htj.duckdns.org>
Date:   Tue, 20 Jun 2017 18:48:14 -0400
From:   Tejun Heo <tj@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Lameter <cl@...ux.com>,
        Pekka Enberg <penberg@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>
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