[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200410002737.GT24067@dread.disaster.area>
Date: Fri, 10 Apr 2020 10:27:37 +1000
From: Dave Chinner <david@...morbit.com>
To: Christoph Hellwig <hch@....de>
Cc: Ira Weiny <ira.weiny@...el.com>, linux-kernel@...r.kernel.org,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Dan Williams <dan.j.williams@...el.com>,
"Theodore Y. Ts'o" <tytso@....edu>, Jan Kara <jack@...e.cz>,
Jeff Moyer <jmoyer@...hat.com>, linux-ext4@...r.kernel.org,
linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH V6 6/8] fs/xfs: Combine xfs_diflags_to_linux() and
xfs_diflags_to_iflags()
On Thu, Apr 09, 2020 at 02:40:31PM +0200, Christoph Hellwig wrote:
> On Thu, Apr 09, 2020 at 10:49:21AM +1000, Dave Chinner wrote:
> > > Christoph did say:
> > >
> > > "A reasonably smart application can try to evict itself."
> > >
> > > -- https://lore.kernel.org/lkml/20200403072731.GA24176@lst.de/
> >
> > I'd love to know how an unprivileged application can force the
> > eviction of an inode from cache.
>
> Where did the "unprivileged" suddenly come from?
I'm assuming that applications are being run without the root
permissions needed to run drop_caches. i.e. the apps are
unprivileged, and therefore can't brute force inode cache eviction.
That's why I'm asking what mechanism these applications are using to
evict inodes on demand without requiring elevated privileges,
because I can't see how they'd acheive this...
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
Powered by blists - more mailing lists