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

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

 



Hi Sasha,

On Tue, Dec 11, 2018 at 2:42 AM Sasha Levin <sashal@xxxxxxxxxx> 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?

Thanks,

Nicolas

> --
> Thanks,
> Sasha



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux