From: Kevin Wolf <kwolf@redhat.com>
To: Peter Lieven <pl@kamp.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu block <qemu-block@nongnu.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
jsnow@redhat.com
Subject: Re: [Qemu-devel] [Qemu-block] Limiting coroutine stack usage
Date: Thu, 22 Feb 2018 12:32:04 +0100 [thread overview]
Message-ID: <20180222113204.GC4147@localhost.localdomain> (raw)
In-Reply-To: <37efa6ac-8e36-9c96-84ef-a8639ba64937@kamp.de>
Am 22.02.2018 um 12:01 hat Peter Lieven geschrieben:
> Am 22.02.2018 um 11:57 schrieb Kevin Wolf:
> > Am 20.02.2018 um 22:54 hat Paolo Bonzini geschrieben:
> >> On 20/02/2018 18:04, Peter Lieven wrote:
> >>> Hi,
> >>>
> >>> 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.
> >> IIRC the only issue was that hw/ide/atapi.c has mutual recursion between
> >> ide_atapi_cmd_reply_end -> ide_transfer_start -> ahci_start_transfer ->
> >> ide_atapi_cmd_reply_end.
> >>
> >> But perhaps it's not an issue, somebody needs to audit the code.
> > I think John intended to get rid of the recursion sometime, but I doubt
> > he has had the time so far.
>
> Apart from this is is possible to define special cflags in the
> Makefile.objs just for a subdirectory? I have patches ready to make
> the block layer files and other coroutine users compile with
> -Wstack-size=2048. But I do not want to specify each file separately.
Our Makefiles have lines like this:
iscsi.o-cflags := $(LIBISCSI_CFLAGS)
I don't think there is a direct mechanism to apply cflags to a whole
directory or just to block-obj-y/block-obj-m, but just looping over them
could work. I'm not a Makefile expert at all, but after some toying with
a simple example, something like this might work:
$(foreach x,$(block-obj-y),$(eval $x-cflags += -Wstack-size=2048))
> Limiting the coroutine size to much could also lead to trouble in some
> third party libraries that are called from a coroutine context, or
> not?
Yes, this is true.
Kevin
next prev parent reply other threads:[~2018-02-22 11:32 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 [this message]
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
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=20180222113204.GC4147@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=jsnow@redhat.com \
--cc=pbonzini@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).