On Tue, Dec 11, 2018 at 8:44 AM Sasha Levin <sashal@xxxxxxxxxx> wrote:
>
> 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.
Noted. Thanks!
> --
> Thanks,
> Sasha
