[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwPo7Pbq+3Oup-oo8MUFHeEpFXp7qr6z2PrzKp7S0ON+A@mail.gmail.com>
Date: Mon, 26 Feb 2018 19:41:21 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Miklos Szeredi <mszeredi@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Containers <containers@...ts.linux-foundation.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Alban Crequy <alban@...volk.io>,
Seth Forshee <seth.forshee@...onical.com>,
Sargun Dhillon <sargun@...gun.me>,
Dongsu Park <dongsu@...volk.io>,
"Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [PATCH v7 3/7] fs/posix_acl: Document that get_acl respects ACL_DONT_CACHE
On Mon, Feb 26, 2018 at 7:14 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
>
> As such I believe that usage of forget_cached_acl should be subsumed by
> using ACL_NOT_CACHED. If not we should really come up with a different
> helper function name to call from ->get_acl. Preferably one that does
> "cmpxchng(p, sentinel, ACL_NOT_CACHED)" so that we remove the races.
You make your bias very clear, by simply trying to hide the other case.
But for chrissake, that's not the state right now. That other case
exists. You can't - and shouldn't - try to just hide it.
Besides, that "forget_cached_acl()" approach actually has a valid use
case. Maybe you _do_ want to cache ACL's, but with a timeout or
revalidation.
ACL_DONT_CACHE really is a big hammer that makes caching not work at
all. It's not necessarily the right thing to do at all.
Linus
Powered by blists - more mailing lists