[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpeguqW4mPE9UyLmccisTex_gmwq6p9_6_EfVm-1oh6CrEBA@mail.gmail.com>
Date: Fri, 12 Apr 2024 14:36:21 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Vinicius Costa Gomes <vinicius.gomes@...el.com>
Cc: brauner@...nel.org, amir73il@...il.com, hu1.chen@...el.com,
malini.bhandaru@...el.com, tim.c.chen@...el.com, mikko.ylinen@...el.com,
lizhen.you@...el.com, linux-unionfs@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 0/3] overlayfs: Optimize override/revert creds
On Wed, 3 Apr 2024 at 04:18, Vinicius Costa Gomes
<vinicius.gomes@...el.com> wrote:
> - in ovl_rename() I had to manually call the "light" the overrides,
> both using the guard() macro or using the non-light version causes
> the workload to crash the kernel. I still have to investigate why
> this is happening. Hints are appreciated.
Don't know. Well, there's nesting (in ovl_nlink_end()) but I don't
see why that should be an issue.
I see why Amir suggested moving away from scoped guards, but that also
introduces the possibility of subtle bugs if we don't audit every one
of those sites carefully...
Maybe patchset should be restructured to first do the
override_creds_light() conversion without guards, and then move over
to guards. Or the other way round, I don't have a preference. But
mixing these two independent changes doesn't sound like a great idea
in any case.
Thanks,
Miklos
Powered by blists - more mailing lists