linux-kernel - Re: [PATCH 2/4] bdi: Add bdi->id

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: <775309de70c1371e852fa5e6f84ca1ca2727faa0.camel@fb.com>
Date:   Fri, 9 Aug 2019 00:57:24 +0000
From:   Rik van Riel <riel@...com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Tejun Heo <tj@...nel.org>
CC:     "axboe@...nel.dk" <axboe@...nel.dk>, "jack@...e.cz" <jack@...e.cz>,
        "hannes@...xchg.org" <hannes@...xchg.org>,
        "mhocko@...nel.org" <mhocko@...nel.org>,
        "vdavydov.dev@...il.com" <vdavydov.dev@...il.com>,
        "cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>,
        "Roman Gushchin" <guro@...com>
Subject: Re: [PATCH 2/4] bdi: Add bdi->id

On Wed, 2019-08-07 at 12:00 -0700, Andrew Morton wrote:
> On Wed, 7 Aug 2019 11:31:51 -0700 Tejun Heo <tj@...nel.org> wrote:
> 
> > Hello,
> > 
> > On Tue, Aug 06, 2019 at 04:01:02PM -0700, Andrew Morton wrote:
> > > On Sat,  3 Aug 2019 07:01:53 -0700 Tejun Heo <tj@...nel.org>
> > > wrote:
> > > > There currently is no way to universally identify and lookup a
> > > > bdi
> > > > without holding a reference and pointer to it.  This patch adds
> > > > an
> > > > non-recycling bdi->id and implements bdi_get_by_id() which
> > > > looks up
> > > > bdis by their ids.  This will be used by memcg foreign inode
> > > > flushing.
> > > 
> > > Why is the id non-recycling?  Presumably to address some
> > > lifetime/lookup issues, but what are they?
> > 
> > The ID by itself is used to point to the bdi from cgroup and idr
> > recycles really aggressively.  Combined with, for example, loop
> > device
> > based containers, stale pointing can become pretty common.  We're
> > having similar issues with cgroup IDs.
> 
> OK, but why is recycling a problem?  For example, file descriptors
> recycle as aggressively as is possible, and that doesn't cause any
> trouble.  Presumably recycling is a problem with cgroups because of
> some sort of stale reference problem?

PIDs, on the other hand, we recycle as slowly as
possible...