From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B1FFC433E1 for ; Sat, 18 Jul 2020 00:44:39 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E01CB20809 for ; Sat, 18 Jul 2020 00:44:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Bax0dCgR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E01CB20809 Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-audit-bounces@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1595033077; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=hz+EsF8WWjWNJBKDAH26QZgkVE5rnak/0VgFdj+aGOU=; b=Bax0dCgR1nm/TzDyNrtV2OxzLUesAZ87c20QNiwJyt2w1lZr1V+Kh1Kp6l+73KjJN/gGJy +uEXiwljPbjCUZNM5gqB0haIs5E9MiZxKf47K7tJ0EO+qLX+3eyTdhsCoLE14BFXF1i8ol P1P1qXgRvenRe1t+jsiECFmA7qwqXV0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-325-EXFYkgYzOqCAt-RZVS92hQ-1; Fri, 17 Jul 2020 20:44:35 -0400 X-MC-Unique: EXFYkgYzOqCAt-RZVS92hQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E682D1080; Sat, 18 Jul 2020 00:44:29 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 85EC373022; Sat, 18 Jul 2020 00:44:28 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 7686A96255; Sat, 18 Jul 2020 00:44:24 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 06I0hukQ011793 for ; Fri, 17 Jul 2020 20:43:56 -0400 Received: by smtp.corp.redhat.com (Postfix) id BC3687BD70; Sat, 18 Jul 2020 00:43:56 +0000 (UTC) Received: from madcap2.tricolour.ca (unknown [10.10.110.3]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AD2427B42B; Sat, 18 Jul 2020 00:43:44 +0000 (UTC) Date: Fri, 17 Jul 2020 20:43:41 -0400 From: Richard Guy Briggs To: Paul Moore Subject: Re: [PATCH ghak90 V9 08/13] audit: add containerid support for user records Message-ID: <20200718004341.ruyre5xhlu3ps2tr@madcap2.tricolour.ca> References: <4a5019ed3cfab416aeb6549b791ac6d8cc9fb8b7.1593198710.git.rgb@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-loop: linux-audit@redhat.com Cc: nhorman@tuxdriver.com, linux-api@vger.kernel.org, containers@lists.linux-foundation.org, LKML , dhowells@redhat.com, Linux-Audit Mailing List , netfilter-devel@vger.kernel.org, ebiederm@xmission.com, simo@redhat.com, netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, Eric Paris , mpatel@redhat.com, Serge Hallyn X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline On 2020-07-05 11:11, Paul Moore wrote: > On Sat, Jun 27, 2020 at 9:23 AM Richard Guy Briggs wrote: > > > > Add audit container identifier auxiliary record to user event standalone > > records. > > > > Signed-off-by: Richard Guy Briggs > > Acked-by: Neil Horman > > Reviewed-by: Ondrej Mosnacek > > --- > > kernel/audit.c | 19 ++++++++++++------- > > 1 file changed, 12 insertions(+), 7 deletions(-) > > > > diff --git a/kernel/audit.c b/kernel/audit.c > > index 54dd2cb69402..997c34178ee8 100644 > > --- a/kernel/audit.c > > +++ b/kernel/audit.c > > @@ -1507,6 +1504,14 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh) > > audit_log_n_untrustedstring(ab, str, data_len); > > } > > audit_log_end(ab); > > + rcu_read_lock(); > > + cont = _audit_contobj_get(current); > > + rcu_read_unlock(); > > + audit_log_container_id(context, cont); > > + rcu_read_lock(); > > + _audit_contobj_put(cont); > > + rcu_read_unlock(); > > + audit_free_context(context); > > I haven't searched the entire patchset, but it seems like the pattern > above happens a couple of times in this patchset, yes? If so would it > make sense to wrap the above get/log/put in a helper function? I've redone the locking with an rcu lock around the get and a spinlock around the put. It occurs to me that putting an rcu lock around the whole thing and doing a get without the refcount increment would save us the spinlock and put and be fine since we'd be fine with stale but consistent information traversing the contobj list from this point to report it. Problem with that is needing to use GFP_ATOMIC due to the rcu lock. If I stick with the spinlock around the put then I can use GFP_KERNEL and just grab the spinlock while traversing the contobj list. > Not a big deal either way, I'm pretty neutral on it at this point in > the patchset but thought it might be worth mentioning in case you > noticed the same and were on the fence. There is only one other place this is used, in audit_log_exit in auditsc.c. I had noted the pattern but wasn't sure it was worth it. Inline or not? Should we just let the compiler decide? > paul moore - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit