[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dc7f6674-6bc4-00a5-c273-e0f61a385949@canonical.com>
Date: Tue, 13 Jun 2023 03:28:23 -0700
From: John Johansen <john.johansen@...onical.com>
To: Peter Zijlstra <peterz@...radead.org>,
torvalds@...ux-foundation.org, keescook@...omium.org,
gregkh@...uxfoundation.org, pbonzini@...hat.com
Cc: masahiroy@...nel.org, nathan@...nel.org, ndesaulniers@...gle.com,
nicolas@...sle.eu, catalin.marinas@....com, will@...nel.org,
vkoul@...nel.org, trix@...hat.com, ojeda@...nel.org,
mingo@...hat.com, longman@...hat.com, boqun.feng@...il.com,
dennis@...nel.org, tj@...nel.org, cl@...ux.com, acme@...nel.org,
mark.rutland@....com, alexander.shishkin@...ux.intel.com,
jolsa@...nel.org, namhyung@...nel.org, irogers@...gle.com,
adrian.hunter@...el.com, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
bristot@...hat.com, vschneid@...hat.com, paulmck@...nel.org,
frederic@...nel.org, quic_neeraju@...cinc.com,
joel@...lfernandes.org, josh@...htriplett.org,
mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
rientjes@...gle.com, vbabka@...e.cz, roman.gushchin@...ux.dev,
42.hyeyoo@...il.com, apw@...onical.com, joe@...ches.com,
dwaipayanray1@...il.com, lukas.bulwahn@...il.com,
paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
dmaengine@...r.kernel.org, llvm@...ts.linux.dev,
linux-perf-users@...r.kernel.org, rcu@...r.kernel.org,
linux-security-module@...r.kernel.org, tglx@...utronix.de,
ravi.bangoria@....com, error27@...il.com,
luc.vanoostenryck@...il.com
Subject: Re: [PATCH v3 02/57] apparmor: Free up __cleanup() name
On 6/12/23 02:07, Peter Zijlstra wrote:
> In order to use __cleanup for __attribute__((__cleanup__(func))) the
> name must not be used for anything else. Avoid the conflict.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
if you want, I can just pull this small change into the apparmor
tree so you don't have to carry it anymore as part of the series.
> ---
> security/apparmor/include/lib.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> --- a/security/apparmor/include/lib.h
> +++ b/security/apparmor/include/lib.h
> @@ -232,7 +232,7 @@ void aa_policy_destroy(struct aa_policy
> */
> #define fn_label_build(L, P, GFP, FN) \
> ({ \
> - __label__ __cleanup, __done; \
> + __label__ __do_cleanup, __done; \
> struct aa_label *__new_; \
> \
> if ((L)->size > 1) { \
> @@ -250,7 +250,7 @@ void aa_policy_destroy(struct aa_policy
> __new_ = (FN); \
> AA_BUG(!__new_); \
> if (IS_ERR(__new_)) \
> - goto __cleanup; \
> + goto __do_cleanup; \
> __lvec[__j++] = __new_; \
> } \
> for (__j = __count = 0; __j < (L)->size; __j++) \
> @@ -272,7 +272,7 @@ void aa_policy_destroy(struct aa_policy
> vec_cleanup(profile, __pvec, __count); \
> } else \
> __new_ = NULL; \
> -__cleanup: \
> +__do_cleanup: \
> vec_cleanup(label, __lvec, (L)->size); \
> } else { \
> (P) = labels_profile(L); \
>
>
Powered by blists - more mailing lists