From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date: Thu, 25 Dec 2008 17:36:52 +0000
Subject: Re: Revisiting threaded udevd
Message-Id: <4953C4B4.1000708@tuffmail.co.uk>
List-Id: <linux-hotplug.vger.kernel.org>
References: <494F7942.6060702@tuffmail.co.uk>
In-Reply-To: <494F7942.6060702@tuffmail.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-hotplug@vger.kernel.org

Scott James Remnant wrote:
> On Mon, 2008-12-22 at 11:25 +0000, Alan Jenkins wrote:
>
>   
>> I have some time to look at this again now.
>>
>>     
> I was just looking at this myself, since it formed a natural part of the
> performance testing I'm doing on Ubuntu.
>
> I got as far as reapplying the patches to current git head, but then hit
> a segfault :-(
>
> Attached is the patch against head.
>
> The segfault occurs in the udev_device_get_properties() call at the top
> of udev_exec(), because that calls update_envp_monitor_buf() which calls
> free().
>
> I assume this is non-reentrant territory?
>   

Odd.  I have started and I've not seen anything like this.  Maybe you're 
doing something wrong.  I don't have time to look at or try your patch 
today :-).

libudev doesn't implement any locking itself.  But AFAICS it's safe to 
use *different* libudev objects such as udev_devices from different 
threads.  You generally don't need to modify the udev context object, so 
it seemed safe to share the context between threads (and just make sure 
to only call udev_ref/unref from a single thread).

Regards
Alan