[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190807120037.72018c136db40e88d89c05d1@linux-foundation.org>
Date: Wed, 7 Aug 2019 12:00:37 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Tejun Heo <tj@...nel.org>
Cc: axboe@...nel.dk, jack@...e.cz, hannes@...xchg.org,
mhocko@...nel.org, vdavydov.dev@...il.com, cgroups@...r.kernel.org,
linux-mm@...ck.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, kernel-team@...com, guro@...com
Subject: Re: [PATCH 2/4] bdi: Add bdi->id
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?
Powered by blists - more mailing lists