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]

 



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@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?

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



[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