On 10/22/21 05:38, Andrew Morton wrote: > 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! Aha, great. Looks like I misinterpreted few months ago the thread about adding folio tree to next. >> 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. 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. >
