[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] Limiting coroutine stack usage

From: Kevin Wolf
Subject: Re: [Qemu-block] Limiting coroutine stack usage
Date: Thu, 22 Feb 2018 12:32:04 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]