On 4/30/2025 11:51 AM, Paul Moore wrote: > On Wed, Apr 30, 2025 at 12:25 PM Casey Schaufler <[email protected]> > wrote: >> On 4/24/2025 3:18 PM, Paul Moore wrote: >>> On Mar 19, 2025 Casey Schaufler <[email protected]> wrote: >>>> Refactor audit_log_task_context(), creating a new audit_log_subj_ctx(). >>>> This is used in netlabel auditing to provide multiple subject security >>>> contexts as necessary. >>>> >>>> Signed-off-by: Casey Schaufler <[email protected]> >>>> --- >>>> include/linux/audit.h | 7 +++++++ >>>> kernel/audit.c | 28 +++++++++++++++++++++------- >>>> net/netlabel/netlabel_user.c | 9 +-------- >>>> 3 files changed, 29 insertions(+), 15 deletions(-) >>> Other than moving to the subject count supplied by the LSM >>> initialization patchset previously mentioned, this looks fine to me. >> I'm perfectly willing to switch once the LSM initialization patch set >> moves past RFC. > It's obviously your choice as to if/when you switch, but I'm trying to > let you know that acceptance into the LSM tree is going to be > dependent on that switch happening.
Not a problem. Obviously, I'd prefer this patch going in before the LSM initialization work, but it is your call. > The initialization patchset is still very much alive, and the next > revision will not be an RFC. I'm simply waiting on some additional > LSM specific reviews before posting the next revision so as to not > burn out people from looking at multiple iterations. I've been told > privately by at least one LSM maintainer that reviewing the changes in > their code is on their todo list, but they have been slammed with > other work at their job and haven't had the time to look at that > patchset yet. I realize you don't have those issues anymore, but I > suspect you are still sympathetic to those problems. Of course. Waiting on reviews can be frustrating. > If you're really anxious to continue work on this RIGHT NOW, you can > simply base your patchset on top of the initialization patchset. Just > make sure you mention in the cover letter what you are using as a base > for the patchset. As I don't anticipate serious changes to your patch set this makes sense. > If that still doesn't offer any satisfaction, you can always > incorporate the feedback that I made in v2 that was ignored in your v3 > posting :-P Yeah, oops on that.
