All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Peter Lieven <pl@kamp.de>
Cc: qemu block <qemu-block@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Qemu-block] Limiting coroutine stack usage
Date: Tue, 6 Mar 2018 11:51:24 +0000	[thread overview]
Message-ID: <20180306115124.GG31045@stefanha-x1.localdomain> (raw)
In-Reply-To: <7b01ba4b-7f5f-30c7-d6d8-3c22f2774e7e@kamp.de>

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

On Tue, Feb 20, 2018 at 06:04:02PM +0100, Peter Lieven wrote:
> I remember we discussed a long time ago to limit the stack usage of all functions that are executed in a coroutine
> context to a very low value to be able to safely limit the coroutine stack size as well.
> 
> I checked through all functions in block/, migration/ and nbd/ and there are only very few larger or unbound stack
> allocations that can easily be fixed.
> 
> Now my question: Is there an easy way to add a cflag like -Wstack-usage=2048 to all objects in a given directory only?
> I tried to add a llimit to the whole project, but fixing this will be a larger task.

2KB is fine for QEMU code but actual coroutine stack sizes will have to
be at least 8KB, I guess, in order for third-party libraries to work
(e.g. curl, rbd).  PATH_MAX is 4KB on Linux.

Nested event loops in QEMU code can also result in deep call stacks.
This happens when aio_poll() invokes an fd handler or BH that also
invokes aio_poll().

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  parent reply	other threads:[~2018-03-06 11:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-20 17:04 [Qemu-devel] Limiting coroutine stack usage Peter Lieven
2018-02-20 21:54 ` [Qemu-devel] [Qemu-block] " Paolo Bonzini
2018-02-22 10:57   ` Kevin Wolf
2018-02-22 11:01     ` Peter Lieven
2018-02-22 11:32       ` Kevin Wolf
2018-02-22 11:40         ` Daniel P. Berrangé
2018-02-22 11:51           ` Peter Lieven
2018-02-22 12:00             ` Daniel P. Berrangé
2018-02-22 12:02               ` Peter Lieven
2018-02-22 12:03                 ` Daniel P. Berrangé
2018-02-22 12:06                   ` Peter Lieven
2018-02-22 12:16                     ` Daniel P. Berrangé
2018-02-22 12:19                     ` Kevin Wolf
2018-02-22 11:42         ` Peter Lieven
2018-02-22 17:06     ` John Snow
2018-02-23 11:17       ` Paolo Bonzini
2018-03-06 11:51 ` Stefan Hajnoczi [this message]
2018-03-07 20:36   ` Peter Lieven
2018-03-08 17:27     ` Stefan Hajnoczi

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=20180306115124.GG31045@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=pl@kamp.de \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.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.