Re: [PATCH v6 1/3] mm: Add support for kmem caches in DMA32 zone

[Sasha Levin <sashal@kernel.org>]

On Tue, Dec 11, 2018 at 08:33:01AM +0800, Nicolas Boichat wrote:
>Hi Sasha,
>
>On Tue, Dec 11, 2018 at 2:42 AM Sasha Levin <sashal@kernel.org> wrote:
>>
>> Hi,
>>
>> [This is an automated email]
>>
>> This commit has been processed because it contains a -stable tag.
>> The stable tag indicates that it's relevant for the following trees: all
>>
>> The bot has tested the following trees: v4.19.8, v4.14.87, v4.9.144, v4.4.166, v3.18.128,
>>
>> v4.19.8: Build OK!
>> v4.14.87: Failed to apply! Possible dependencies:
>>     4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit")
>>     a3ba07444782 ("mm/slab.c: only set __GFP_RECLAIMABLE once")
>>     d50112edde1d ("slab, slub, slob: add slab_flags_t")
>>
>> v4.9.144: Failed to apply! Possible dependencies:
>>     04d348ae3f0a ("drm/i915/gvt: vGPU display virtualization")
>>     12d14cc43b34 ("drm/i915/gvt: Introduce a framework for tracking HW registers.")
>>     1b36595ffb35 ("drm/i915: Show RING registers through debugfs")
>>     28a60dee2ce6 ("drm/i915/gvt: vGPU HW resource management")
>>     3f728236c516 ("drm/i915/gvt: trace stub")
>>     4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit")
>>     579cea5f30f2 ("drm/i915/gvt: golden virtual HW state management")
>>     5f0d5a3ae7cf ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")
>>     73cb97010d4f ("drm/i915: Combine seqno + tracking into a global timeline struct")
>>     82d375d1b568 ("drm/i915/gvt: Introduce basic vGPU life cycle management")
>>     8453d674ae7e ("drm/i915/gvt: vGPU execlist virtualization")
>>     a933568eb61d ("drm/i915: Tidy slab cache allocations")
>>     c8fe6a6811a7 ("drm/i915/gvt: vGPU interrupt virtualization.")
>>     d50112edde1d ("slab, slub, slob: add slab_flags_t")
>>     e39c5add3221 ("drm/i915/gvt: vGPU MMIO virtualization")
>>     e473405783c0 ("drm/i915/gvt: vGPU workload scheduler")
>>     e95433c73a11 ("drm/i915: Rearrange i915_wait_request() accounting with callers")
>>
>> v4.4.166: Failed to apply! Possible dependencies:
>>     10b2e9e8e808 ("mm/slab: factor out debugging initialization in cache_init_objs()")
>>     40b44137971c ("mm/slab: clean up DEBUG_PAGEALLOC processing code")
>>     4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit")
>>     505f5dcb1c41 ("mm, kasan: add GFP flags to KASAN API")
>>     55834c59098d ("mm: kasan: initial memory quarantine implementation")
>>     5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg")
>>     7ed2f9e66385 ("mm, kasan: SLAB support")
>>     832a15d209cd ("mm/slab: align cache size first before determination of OFF_SLAB candidate")
>>     a307ebd468e0 ("mm/slab: activate debug_pagealloc in SLAB when it is actually enabled")
>>     d50112edde1d ("slab, slub, slob: add slab_flags_t")
>>
>> v3.18.128: Failed to apply! Possible dependencies:
>>     081fa9dffcde ("staging/lustre/llite: remove llite proc root on init failure")
>>     12cf89b550d1 ("livepatch: rename config to CONFIG_LIVEPATCH")
>>     13d1cf7e7025 ("livepatch: samples: add sample live patching module")
>>     31e7213ab21e ("drivers: staging: lustre: Fix "spaces required around that '='" errors")
>>     32b7eb877165 ("livepatch: change ARCH_HAVE_LIVE_PATCHING to HAVE_LIVE_PATCHING")
>>     4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit")
>>     5aaeb5c01c5b ("x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86")
>>     5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg")
>>     6471b825c41e ("x86/kconfig: Reorganize arch feature Kconfig select's")
>>     6e0a0ea12962 ("ACPI / sleep: Introduce CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT")
>>     83ac237a950e ("livepatch: kconfig: use bool instead of boolean")
>>     957e3facd147 ("gcov: enable GCOV_PROFILE_ALL from ARCH Kconfigs")
>>     b700e7f03df5 ("livepatch: kernel: add support for live patching")
>>     b9dfe0bed999 ("livepatch: handle ancient compilers with more grace")
>>     d50112edde1d ("slab, slub, slob: add slab_flags_t")
>>
>>
>> How should we proceed with this patch?
>
>I'm not sure how we need to handle this.
>
>2/3 in this series (https://patchwork.kernel.org/patch/10720495/) is
>the patch that matters, and has correct Fixes/Cc tag (this only needs
>to apply >=4.15).
>
>I added Cc: stable@ to this patch, as it is a dependency of 2/3.
>Should I remove Cc: stable from this patch? Or add Fixes: line?

It's fine if you want to keep it. This mail is just a heads-up saying
that it won't apply on <=4.14 kernels without a backport.

--
Thanks,
Sasha