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?
Thanks,
Nicolas
-- Thanks, Sasha
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
On Tue, Dec 11, 2018 at 8:44 AM Sasha Levin sashal@kernel.org 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@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.
Noted. Thanks!
-- Thanks, Sasha
linux-stable-mirror@lists.linaro.org
-
Nicolas Boichat -
Sasha Levin