From: Greg KH <greg@kroah.com>
To: Andrew Duggan <cmkrnl@speakeasy.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Patch] 2.6.10.rc1.bk6 /lib/kobject_uevent.c buffer issues
Date: Wed, 27 Oct 2004 08:21:34 -0700 [thread overview]
Message-ID: <20041027152134.GA13991@kroah.com> (raw)
In-Reply-To: <20041027142925.GA17484@imladris.arnor.me>
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
next parent reply other threads:[~2004-10-27 15:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20041027142925.GA17484@imladris.arnor.me>
2004-10-27 15:21 ` Greg KH [this message]
2004-10-27 16:31 ` [Patch] 2.6.10.rc1.bk6 /lib/kobject_uevent.c buffer issues Andrew
2004-10-29 20:13 ` Greg KH
2004-10-29 21:28 ` Kay Sievers
2004-10-29 23:13 ` Greg KH
2004-10-30 0:00 ` Kay Sievers
2004-10-30 0:25 ` Kay Sievers
2004-10-30 2:54 ` Kay Sievers
2004-10-30 3:23 ` Andrew
2004-10-31 4:11 ` Kay Sievers
2004-11-01 19:46 ` Greg KH
2004-10-27 17:17 Klaus Dittrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041027152134.GA13991@kroah.com \
--to=greg@kroah.com \
--cc=cmkrnl@speakeasy.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.