On Thu, 21 Oct 2021 19:51:20 +0200 Vlastimil Babka vbabka@suse.cz wrote:
Then we have to figure out how to order a fix between DRM and mmotm...
That is the question! The problem exists only in the merge of the two. On current DRM side stack_depot_init() exists but it's __init and does not look safe to call multiple times. And obviously my changes don't exist at all in mmotm.
I guess one (admittedly hackish) option is to first add a patch in drm-next (or drm-misc-next) that makes it safe to call stack_depot_init() multiple times in non-init context. It would be dropped in favour of your changes once the trees get merged together.
Or is there some way for __drm_stack_depot_init() to detect whether it should call stack_depot_init() or not, i.e. whether your changes are there or not?
Let's try the easiest approach first. AFAIK mmotm series is now split to pre-next and post-next part
It has been this way for many years!
and moving my patch lib-stackdepot-allow-optional-init-and-stack_table-allocation-by-kvmalloc.patch with the following fixup to the post-next part should solve this. Would that work, Andrew? Thanks.
For this reason. No probs, thanks.
I merge up the post-linux-next parts late in the merge window. I do need to manually check that the prerequisites are in mainline, because sometimes the patches apply OK but don't make sense.