From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH 1/15] don't reallocate buffer in every audit_sockaddr()
Date: Wed, 17 Dec 2008 07:56:12 +0000
Message-ID: <20081217075612.GY28946@ZenIV.linux.org.uk>
References: <E1LCogg-00008b-SH@ZenIV.linux.org.uk> <20081216234927.9cb8a077.akpm@linux-foundation.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <linux-kernel-owner+glk-linux-kernel-3=40m.gmane.org-S1760112AbYLQH40@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20081216234927.9cb8a077.akpm@linux-foundation.org>
Sender: linux-kernel-owner@vger.kernel.org
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@ftp.linux.org.uk>, linux-audit@redhat.com, linux-kernel@vger.kernel.org
List-Id: linux-audit@redhat.com

On Tue, Dec 16, 2008 at 11:49:27PM -0800, Andrew Morton wrote:
> > +	if (!context->sockaddr) {
> > +		void *p = kmalloc(sizeof(struct sockaddr_storage), GFP_KERNEL);
> 
> argh, I really hate having to run all around the code verifying that
> the type passed to sizeof matches the type that we'll be storing there :(

And I really hate being unable to find the places doing such allocations
without serious parsing.  Matter of taste.
 
> stoopid question: can an audit_contect be shared between
> threads/processes?  If so, is locking needed around the read/test/write
> of context->sockaddr and friends?  

It can't.  And that's very fortunate, since otherwise all that crap would
	a) be horribly racy
	b) require shitloads of locking all over the place, driving the
overhead even higher.