From: William Lee Irwin III <wli@holomorphy.com>
To: Matt Mackall <mpm@selenic.com>
Cc: Andrew Morton <akpm@osdl.org>,
J?rn Engel <joern@wohnheim.fh-wedel.de>,
arjanv@redhat.com, benh@kernel.crashing.org,
kronos@kronoz.cjb.net, linux-kernel@vger.kernel.org
Subject: Re: [4KSTACK][2.6.6] Stack overflow in radeonfb
Date: Wed, 19 May 2004 03:28:46 -0700 [thread overview]
Message-ID: <20040519102846.GG1223@holomorphy.com> (raw)
In-Reply-To: <20040517233515.GR5414@waste.org>
On Mon, May 17, 2004 at 06:35:15PM -0500, Matt Mackall wrote:
> I have a cleaned up version of this script in -tiny which is a bit
> nicer for adding new arches to and produces simpler output:
> 1428 huft_build
> 1292 inflate_dynamic
> 1168 inflate_fixed
> 528 ip_setsockopt
> 496 tcp_check_req
> 496 tcp_v4_conn_request
> 484 tcp_timewait_state_process
> 440 ip_getsockopt
> 408 extract_entropy
> 364 shrink_zone
> 324 do_execve
By eyeballing things, I see >= 384B on-stack in ep_send_events(). Hence:
kmalloc() the event buffer, since 384B on-stack is a bit large for i386.
Also minor cleanups so the thing can actually be read.
Untested, but simple.
Index: mm3-2.6.6/fs/eventpoll.c
===================================================================
--- mm3-2.6.6.orig/fs/eventpoll.c 2004-05-16 19:54:38.000000000 -0700
+++ mm3-2.6.6/fs/eventpoll.c 2004-05-19 03:09:24.000000000 -0700
@@ -148,14 +148,6 @@
#define EP_ITEM_FROM_EPQUEUE(p) (container_of(p, struct ep_pqueue, pt)->epi)
/*
- * This is used to optimize the event transfer to userspace. Since this
- * is kept on stack, it should be pretty small.
- */
-#define EP_MAX_BUF_EVENTS 32
-
-
-
-/*
* Node that is linked into the "wake_task_list" member of the "struct poll_safewake".
* It is used to keep track on all tasks that are currently inside the wake_up() code
* to 1) short-circuit the one coming from the same task and same wait queue head
@@ -1426,16 +1418,20 @@
* This function is called without holding the "ep->lock" since the call to
* __copy_to_user() might sleep, and also f_op->poll() might reenable the IRQ
* because of the way poll() is traditionally implemented in Linux.
+ * Buffering events is used to optimize the event transfer to userspace.
*/
static int ep_send_events(struct eventpoll *ep, struct list_head *txlist,
struct epoll_event __user *events)
{
- int eventcnt = 0, eventbuf = 0;
+ int eventcnt = 0, eventbuf = 0, bytes;
unsigned int revents;
struct list_head *lnk;
struct epitem *epi;
- struct epoll_event event[EP_MAX_BUF_EVENTS];
+ struct epoll_event *event;
+ event = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!event)
+ return -ENOMEM;
/*
* We can loop without lock because this is a task private list.
* The test done during the collection loop will guarantee us that
@@ -1458,30 +1454,36 @@
* the item to its "txlist" will write this field.
*/
epi->revents = revents & epi->event.events;
+ if (!epi->revents)
+ continue;
- if (epi->revents) {
- event[eventbuf] = epi->event;
- event[eventbuf].events &= revents;
- eventbuf++;
- if (eventbuf == EP_MAX_BUF_EVENTS) {
- if (__copy_to_user(&events[eventcnt], event,
- eventbuf * sizeof(struct epoll_event)))
- return -EFAULT;
- eventcnt += eventbuf;
- eventbuf = 0;
- }
- if (epi->event.events & EPOLLONESHOT)
- epi->event.events &= EP_PRIVATE_BITS;
+ event[eventbuf] = epi->event;
+ event[eventbuf].events &= revents;
+ eventbuf++;
+ if (eventbuf < PAGE_SIZE/sizeof(struct epoll_event))
+ goto mask_private_bits;
+ bytes = eventbuf * sizeof(struct epoll_event);
+ if (__copy_to_user(&events[eventcnt], event, bytes)) {
+ eventcnt = -EFAULT;
+ goto out;
}
- }
-
- if (eventbuf) {
- if (__copy_to_user(&events[eventcnt], event,
- eventbuf * sizeof(struct epoll_event)))
- return -EFAULT;
eventcnt += eventbuf;
- }
-
+ eventbuf = 0;
+mask_private_bits:
+ if (epi->event.events & EPOLLONESHOT)
+ epi->event.events &= EP_PRIVATE_BITS;
+ }
+
+ if (!eventbuf)
+ goto out;
+ bytes = eventbuf * sizeof(struct epoll_event);
+ if (__copy_to_user(&events[eventcnt], event, bytes)) {
+ eventcnt = -EFAULT;
+ goto out;
+ }
+ eventcnt += eventbuf;
+out:
+ kfree(event);
return eventcnt;
}
next prev parent reply other threads:[~2004-05-19 10:29 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-13 13:48 [4KSTACK][2.6.6] Stack overflow in radeonfb Kronos
2004-05-13 14:03 ` Kronos
2004-05-13 14:56 ` Kronos
2004-05-13 15:15 ` Jörn Engel
2004-05-13 15:36 ` Valdis.Kletnieks
2004-05-13 16:02 ` Jörn Engel
2004-05-13 22:56 ` Benjamin Herrenschmidt
2004-05-14 10:00 ` Jörn Engel
2004-05-13 22:55 ` Benjamin Herrenschmidt
2004-05-14 1:21 ` Andrew Morton
2004-05-14 3:26 ` Randy.Dunlap
2004-05-14 9:49 ` Arjan van de Ven
2004-05-14 11:47 ` Jörn Engel
2004-05-14 22:15 ` Andrew Morton
2004-05-14 22:56 ` Chris Wright
2004-05-14 23:18 ` Andrew Morton
2004-05-14 23:19 ` Chris Wright
2004-05-14 23:48 ` Andrew Morton
2004-05-17 10:53 ` Jörn Engel
2004-05-15 7:19 ` Arjan van de Ven
2004-05-17 23:35 ` Matt Mackall
2004-05-17 23:59 ` Andrew Morton
2004-05-26 10:06 ` Jörn Engel
2004-05-26 10:08 ` Jörn Engel
2004-05-19 10:28 ` William Lee Irwin III [this message]
2004-05-19 12:01 ` William Lee Irwin III
2004-05-26 10:17 ` Jörn Engel
[not found] ` <20040518051745.GK2151@krispykreme>
[not found] ` <20040518171136.GC28735@waste.org>
[not found] ` <20040518171959.GQ2151@krispykreme>
[not found] ` <20040518174734.GE28735@waste.org>
2004-05-26 10:14 ` Jörn Engel
2004-05-14 16:41 ` Kronos
2004-05-14 21:48 ` Benjamin Herrenschmidt
2004-05-14 22:34 ` Andrew Morton
2004-05-14 22:36 ` Benjamin Herrenschmidt
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=20040519102846.GG1223@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@osdl.org \
--cc=arjanv@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=joern@wohnheim.fh-wedel.de \
--cc=kronos@kronoz.cjb.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
/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.