On Thu, 21 Oct 2021 19:51:20 +0200 Vlastimil Babka <vbabka@xxxxxxx> 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.
