From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262385AbUJ0PZQ (ORCPT ); Wed, 27 Oct 2004 11:25:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262465AbUJ0PZP (ORCPT ); Wed, 27 Oct 2004 11:25:15 -0400 Received: from mail.kroah.org ([69.55.234.183]:38787 "EHLO perch.kroah.org") by vger.kernel.org with ESMTP id S262458AbUJ0PWO (ORCPT ); Wed, 27 Oct 2004 11:22:14 -0400 Date: Wed, 27 Oct 2004 08:21:34 -0700 From: Greg KH To: Andrew Duggan Cc: linux-kernel@vger.kernel.org Subject: Re: [Patch] 2.6.10.rc1.bk6 /lib/kobject_uevent.c buffer issues Message-ID: <20041027152134.GA13991@kroah.com> References: <20041027142925.GA17484@imladris.arnor.me> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041027142925.GA17484@imladris.arnor.me> User-Agent: Mutt/1.5.6i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 27, 2004 at 10:29:25AM -0400, Andrew Duggan wrote: > Hi, > > In the lastest code I've seen 2.6.10 rc1 bk6 for lib/kobject_uevent.c > the incrementing of the sequence number is held off until the call to > hotplug_ops->hotplug (). That function can consume addtional buffer > and use addtional pointers in the envp array. The problem is that the > new value for i and the new logical end of buffer (held in scratch) do > not get updated. When the sequnce number is then processed the first > item generated by hotplug_ops->hotplug () gets overwriten, and can > potentially corrupt any env vars created by hotplug_ops->hotplug. Ah, good catch. Sorry about adding that bug. > Here is a patch to handle that. An element in envp is reserved for > the seq num and a different buffer is sent to hotplug_ops->hotplug > altogether. Using a different buffer there is OK since send_uevent > wasn't seeing the part of the buffer filled in by hotplug_ops->hotplug > anyway, and the older call_usermodehelper gets passed envp and not > buffer. Why not just use the same buffer? We should be able to do that. > I used the same size for the buffer_pt2 as buffer for simplicity, > since I didn't know if saving the memory was THAT important. If need > be the kmalloc for buffer_pt2 could be held off until just before the > call to hotplug_ops->hotplug so that it could be allocated only > (BUFFERSIZE - (scratch - buffer)). I'd prefer we use the same buffer. Care to respin your patch? thanks, greg k-h