- Linux-stable-mirror - lists.linaro.org

[PATCH] Bluetooth: hci_bcm: Remove DMI quirk for the MINIX Z83-4

by ianwmorrison＠gmail.com

As Interrupt resource specified IRQs are now assumed to be always active-low the DMI quirk for the MINIX Z83-4 is no longer required. Cc: stable(a)vger.kernel.org Signed-off-by: Ian W MORRISON <ianwmorrison(a)gmail.com> --- drivers/bluetooth/hci_bcm.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c index 6828e485bc24..8a011267a4f6 100644 --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -804,13 +804,6 @@ static const struct dmi_system_id bcm_active_low_irq_dmi_table[] = { DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "ThinkPad 8"), }, }, - { - .ident = "MINIX Z83-4", - .matches = { - DMI_EXACT_MATCH(DMI_SYS_VENDOR, "MINIX"), - DMI_MATCH(DMI_PRODUCT_NAME, "Z83-4"), - }, - }, { } }; -- 2.11.0

7 years, 5 months

2
1
0 0

[PATCH V4] ZBOOT: fix stack protector in compressed boot phase

by Huacai Chen

Call __stack_chk_guard_setup() in decompress_kernel() is too late that stack checking always fails for decompress_kernel() itself. So remove __stack_chk_guard_setup() and initialize __stack_chk_guard before we call decompress_kernel(). Original code comes from ARM but also used for MIPS and SH, so fix them together. If without this fix, compressed booting of these archs will fail because stack checking is enabled by default (>=4.16). V1 -> V2: Fix build on ARM. V2 -> V3: Fix build on SuperH. V3 -> V4: Initialize __stack_chk_guard in C code as a constant. Cc: stable(a)vger.kernel.org Signed-off-by: Huacai Chen <chenhc(a)lemote.com> --- arch/arm/boot/compressed/head.S | 4 ++++ arch/arm/boot/compressed/misc.c | 7 ------- arch/mips/boot/compressed/decompress.c | 7 ------- arch/mips/boot/compressed/head.S | 4 ++++ arch/sh/boot/compressed/head_32.S | 8 ++++++++ arch/sh/boot/compressed/head_64.S | 4 ++++ arch/sh/boot/compressed/misc.c | 7 ------- 7 files changed, 20 insertions(+), 21 deletions(-) diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c index 16a8a80..e8fe51f 100644 --- a/arch/arm/boot/compressed/misc.c +++ b/arch/arm/boot/compressed/misc.c @@ -128,12 +128,7 @@ asmlinkage void __div0(void) error("Attempting division by 0!"); } -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +const unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -150,8 +145,6 @@ decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p, { int ret; - __stack_chk_guard_setup(); - output_data = (unsigned char *)output_start; free_mem_ptr = free_mem_ptr_p; free_mem_end_ptr = free_mem_ptr_end_p; diff --git a/arch/mips/boot/compressed/decompress.c b/arch/mips/boot/compressed/decompress.c index fdf99e9..81df904 100644 --- a/arch/mips/boot/compressed/decompress.c +++ b/arch/mips/boot/compressed/decompress.c @@ -76,12 +76,7 @@ void error(char *x) #include "../../../../lib/decompress_unxz.c" #endif -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +const unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -92,8 +87,6 @@ void decompress_kernel(unsigned long boot_heap_start) { unsigned long zimage_start, zimage_size; - __stack_chk_guard_setup(); - zimage_start = (unsigned long)(&__image_begin); zimage_size = (unsigned long)(&__image_end) - (unsigned long)(&__image_begin); diff --git a/arch/sh/boot/compressed/misc.c b/arch/sh/boot/compressed/misc.c index 627ce8e..c15cac9 100644 --- a/arch/sh/boot/compressed/misc.c +++ b/arch/sh/boot/compressed/misc.c @@ -104,12 +104,7 @@ static void error(char *x) while(1); /* Halt */ } -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +const unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -130,8 +125,6 @@ void decompress_kernel(void) { unsigned long output_addr; - __stack_chk_guard_setup(); - #ifdef CONFIG_SUPERH64 output_addr = (CONFIG_MEMORY_START + 0x2000); #else

7 years, 5 months

2
1
0 0

[PATCH] drm/amdgpu/sdma: fix mask in emit_pipeline_sync

by Alex Deucher

Needs to be a 32 bit mask. Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c index f48ea0dad875..a7576255cc30 100644 --- a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c +++ b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c @@ -859,7 +859,7 @@ static void cik_sdma_ring_emit_pipeline_sync(struct amdgpu_ring *ring) amdgpu_ring_write(ring, addr & 0xfffffffc); amdgpu_ring_write(ring, upper_32_bits(addr) & 0xffffffff); amdgpu_ring_write(ring, seq); /* reference */ - amdgpu_ring_write(ring, 0xfffffff); /* mask */ + amdgpu_ring_write(ring, 0xffffffff); /* mask */ amdgpu_ring_write(ring, (0xfff << 16) | 4); /* retry count, poll interval */ } diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c index 6452101c7aab..c7190c39c4f5 100644 --- a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c @@ -837,7 +837,7 @@ static void sdma_v2_4_ring_emit_pipeline_sync(struct amdgpu_ring *ring) amdgpu_ring_write(ring, addr & 0xfffffffc); amdgpu_ring_write(ring, upper_32_bits(addr) & 0xffffffff); amdgpu_ring_write(ring, seq); /* reference */ - amdgpu_ring_write(ring, 0xfffffff); /* mask */ + amdgpu_ring_write(ring, 0xffffffff); /* mask */ amdgpu_ring_write(ring, SDMA_PKT_POLL_REGMEM_DW5_RETRY_COUNT(0xfff) | SDMA_PKT_POLL_REGMEM_DW5_INTERVAL(4)); /* retry count, poll interval */ } diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c index ecaef084dab1..be20a387d961 100644 --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c @@ -1105,7 +1105,7 @@ static void sdma_v3_0_ring_emit_pipeline_sync(struct amdgpu_ring *ring) amdgpu_ring_write(ring, addr & 0xfffffffc); amdgpu_ring_write(ring, upper_32_bits(addr) & 0xffffffff); amdgpu_ring_write(ring, seq); /* reference */ - amdgpu_ring_write(ring, 0xfffffff); /* mask */ + amdgpu_ring_write(ring, 0xffffffff); /* mask */ amdgpu_ring_write(ring, SDMA_PKT_POLL_REGMEM_DW5_RETRY_COUNT(0xfff) | SDMA_PKT_POLL_REGMEM_DW5_INTERVAL(4)); /* retry count, poll interval */ } diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c index 2a8184082cd1..399f876f9cad 100644 --- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c @@ -1121,7 +1121,7 @@ static void sdma_v4_0_ring_emit_pipeline_sync(struct amdgpu_ring *ring) amdgpu_ring_write(ring, addr & 0xfffffffc); amdgpu_ring_write(ring, upper_32_bits(addr) & 0xffffffff); amdgpu_ring_write(ring, seq); /* reference */ - amdgpu_ring_write(ring, 0xfffffff); /* mask */ + amdgpu_ring_write(ring, 0xffffffff); /* mask */ amdgpu_ring_write(ring, SDMA_PKT_POLL_REGMEM_DW5_RETRY_COUNT(0xfff) | SDMA_PKT_POLL_REGMEM_DW5_INTERVAL(4)); /* retry count, poll interval */ } -- 2.13.6

7 years, 5 months

3
2
0 0

[PATCH v2] drm/i915/gvt: Add drm_format_mod update

by Tina Zhang

Add drm_format_mod update, which is omitted. Fixes: e546e281("drm/i915/gvt: Dmabuf support for GVT-g") Cc: stable(a)vger.kernel.org Signed-off-by: Tina Zhang <tina.zhang(a)intel.com> --- drivers/gpu/drm/i915/gvt/dmabuf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c b/drivers/gpu/drm/i915/gvt/dmabuf.c index 459d37c..e332470 100644 --- a/drivers/gpu/drm/i915/gvt/dmabuf.c +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c @@ -321,6 +321,7 @@ static void update_fb_info(struct vfio_device_gfx_plane_info *gvt_dmabuf, struct intel_vgpu_fb_info *fb_info) { gvt_dmabuf->drm_format = fb_info->drm_format; + gvt_dmabuf->drm_format_mod = fb_info->drm_format_mod; gvt_dmabuf->width = fb_info->width; gvt_dmabuf->height = fb_info->height; gvt_dmabuf->stride = fb_info->stride; -- 2.7.4

7 years, 5 months

1
0
0 0

Applied "ASoC: topology: Fix kcontrol name string handling" to the asoc tree

by Mark Brown

The patch ASoC: topology: Fix kcontrol name string handling has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 267e2c6fd7ca3d4076d20f9d52d49dc91addfe9d Mon Sep 17 00:00:00 2001 From: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> Date: Tue, 27 Mar 2018 12:04:04 +0100 Subject: [PATCH] ASoC: topology: Fix kcontrol name string handling Fix the topology kcontrol string handling so that string pointer references are strdup()ed instead of being copied. This fixes issues with kcontrol templates on the stack or ones that are freed. Remember and free the strings too when topology is unloaded. Signed-off-by: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- sound/soc/soc-topology.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index 01a50413c66f..782c580b7aa3 100644 --- a/sound/soc/soc-topology.c +++ b/sound/soc/soc-topology.c @@ -523,6 +523,7 @@ static void remove_widget(struct snd_soc_component *comp, kfree(se->dobj.control.dtexts[j]); kfree(se); + kfree(w->kcontrol_news[i].name); } kfree(w->kcontrol_news); } else { @@ -540,6 +541,7 @@ static void remove_widget(struct snd_soc_component *comp, */ kfree((void *)kcontrol->private_value); snd_ctl_remove(card, kcontrol); + kfree(w->kcontrol_news[i].name); } kfree(w->kcontrol_news); } @@ -1233,7 +1235,9 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dmixer_create( dev_dbg(tplg->dev, " adding DAPM widget mixer control %s at %d\n", mc->hdr.name, i); - kc[i].name = mc->hdr.name; + kc[i].name = kstrdup(mc->hdr.name, GFP_KERNEL); + if (kc[i].name == NULL) + goto err_str; kc[i].private_value = (long)sm; kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER; kc[i].access = mc->hdr.access; @@ -1278,8 +1282,10 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dmixer_create( err_str: kfree(sm); err: - for (--i; i >= 0; i--) + for (--i; i >= 0; i--) { kfree((void *)kc[i].private_value); + kfree(kc[i].name); + } kfree(kc); return NULL; } @@ -1310,7 +1316,9 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_denum_create( dev_dbg(tplg->dev, " adding DAPM widget enum control %s\n", ec->hdr.name); - kc[i].name = ec->hdr.name; + kc[i].name = kstrdup(ec->hdr.name, GFP_KERNEL); + if (kc[i].name == NULL) + goto err_se; kc[i].private_value = (long)se; kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER; kc[i].access = ec->hdr.access; @@ -1386,6 +1394,7 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_denum_create( kfree(se->dobj.control.dtexts[j]); kfree(se); + kfree(kc[i].name); } err: kfree(kc); @@ -1424,7 +1433,9 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dbytes_create( "ASoC: adding bytes kcontrol %s with access 0x%x\n", be->hdr.name, be->hdr.access); - kc[i].name = be->hdr.name; + kc[i].name = kstrdup(be->hdr.name, GFP_KERNEL); + if (kc[i].name == NULL) + goto err; kc[i].private_value = (long)sbe; kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER; kc[i].access = be->hdr.access; @@ -1454,8 +1465,10 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dbytes_create( return kc; err: - for (--i; i >= 0; i--) + for (--i; i >= 0; i--) { kfree((void *)kc[i].private_value); + kfree(kc[i].name); + } kfree(kc); return NULL; -- 2.16.2

7 years, 5 months

1
0
0 0

Re: [PATCH] ARM64: dts: meson: reduce odroid-c2 eMMC maximum rate

by Kevin Hilman

On Fri, Mar 2, 2018 at 5:44 AM, Jerome Brunet <jbrunet(a)baylibre.com> wrote: > Different modules maybe installed by the user on the eMMC connector > of the odroid-c2. While the red modules are working without an issue, > it seems some black modules (apparently Samsung based) are having > issue at 200MHz > > While the tuning algorithm introduced in v4.14 enables high speed modes > on every other tested designs, it seems a problem remains for this > particular combination of board and eMMC module. > > Lowering the maximum frequency of the eMMC on this board until we can > figure out a better solution. > > Fixes: d341ca88eead ("mmc: meson-gx: rework tuning function") > Suggested-by: Ellie Reeves <ellierevves(a)gmail.com> > Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Now in mainline as commit c04ffa71ff49 upstream. The mainline patch has "Cc: stable(a)vger.kernel.org", but it doesn't seem to have appeared in stable yet, and I've verified that it applies cleanly to linux-4.15.y and linux-4.14.y. Kevin > --- > arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > index 73a030a5ecf3..43475139576c 100644 > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > @@ -311,7 +311,7 @@ > pinctrl-names = "default", "clk-gate"; > > bus-width = <8>; > - max-frequency = <200000000>; > + max-frequency = <100000000>; > non-removable; > disable-wp; > cap-mmc-highspeed; > -- > 2.14.3 >

7 years, 5 months

2
2
0 0

[PATCH] pwm: rcar: fix a condition to prevent mismatch value setting to duty

by Yoshihiro Shimoda

From: Ryo Kodama <ryo.kodama.vz(a)renesas.com> This patch fixes an issue that is possible to set mismatch value to duty for R-Car PWM if we input the following commands: # cd /sys/class/pwm/<pwmchip>/ # echo 0 > export # cd pwm0 # echo 30 > period # echo 30 > duty_cycle # echo 0 > duty_cycle # cat duty_cycle 0 # echo 1 > enable --> Then, the actual duty_cycle is 30, not 0. So, this patch adds a condition into rcar_pwm_config() to fix this issue. Signed-off-by: Ryo Kodama <ryo.kodama.vz(a)renesas.com> [shimoda: revise the commit log and add Fixes and Cc tags] Fixes: ed6c1476bf7f ("pwm: Add support for R-Car PWM Timer") Cc: Cc: <stable(a)vger.kernel.org> # v4.4+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> --- drivers/pwm/pwm-rcar.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c index 1c85ecc..0fcf94f 100644 --- a/drivers/pwm/pwm-rcar.c +++ b/drivers/pwm/pwm-rcar.c @@ -156,8 +156,12 @@ static int rcar_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, if (div < 0) return div; - /* Let the core driver set pwm->period if disabled and duty_ns == 0 */ - if (!pwm_is_enabled(pwm) && !duty_ns) + /* + * Let the core driver set pwm->period if disabled and duty_ns == 0. + * But, this driver should prevent to set the new duty_ns if current + * duty_cycle is not set + */ + if (!pwm_is_enabled(pwm) && !duty_ns && !pwm->state.duty_cycle) return 0; rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR); -- 1.9.1

7 years, 5 months

2
1
0 0

+ task_struct-only-use-anon-struct-under-randstruct-plugin.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: task_struct: only use anon struct under randstruct plugin has been added to the -mm tree. Its filename is task_struct-only-use-anon-struct-under-randstruct-plugin.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/task_struct-only-use-anon-struct-u… and later at http://ozlabs.org/~akpm/mmotm/broken-out/task_struct-only-use-anon-struct-u… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Kees Cook <keescook(a)chromium.org> Subject: task_struct: only use anon struct under randstruct plugin The original intent for always adding the anonymous struct in task_struct was to make sure we had compiler coverage. However, this caused pathological padding of 40 bytes at the start of task_struct. Instead, move the anonymous struct to being only used when struct layout randomization is enabled. Link: http://lkml.kernel.org/r/20180327213609.GA2964@beast Fixes: 29e48ce87f1e ("task_struct: Allow randomized") Signed-off-by: Kees Cook <keescook(a)chromium.org> Reported-by: Peter Zijlstra <peterz(a)infradead.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/compiler-clang.h | 3 --- include/linux/compiler-gcc.h | 12 +++--------- 2 files changed, 3 insertions(+), 12 deletions(-) diff -puN include/linux/compiler-clang.h~task_struct-only-use-anon-struct-under-randstruct-plugin include/linux/compiler-clang.h --- a/include/linux/compiler-clang.h~task_struct-only-use-anon-struct-under-randstruct-plugin +++ a/include/linux/compiler-clang.h @@ -17,9 +17,6 @@ */ #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) -#define randomized_struct_fields_start struct { -#define randomized_struct_fields_end }; - /* all clang versions usable with the kernel support KASAN ABI version 5 */ #define KASAN_ABI_VERSION 5 diff -puN include/linux/compiler-gcc.h~task_struct-only-use-anon-struct-under-randstruct-plugin include/linux/compiler-gcc.h --- a/include/linux/compiler-gcc.h~task_struct-only-use-anon-struct-under-randstruct-plugin +++ a/include/linux/compiler-gcc.h @@ -242,6 +242,9 @@ #if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__) #define __randomize_layout __attribute__((randomize_layout)) #define __no_randomize_layout __attribute__((no_randomize_layout)) +/* This anon struct can add padding, so only enable it under randstruct. */ +#define randomized_struct_fields_start struct { +#define randomized_struct_fields_end } __randomize_layout; #endif #endif /* GCC_VERSION >= 40500 */ @@ -256,15 +259,6 @@ */ #define __visible __attribute__((externally_visible)) -/* - * RANDSTRUCT_PLUGIN wants to use an anonymous struct, but it is only - * possible since GCC 4.6. To provide as much build testing coverage - * as possible, this is used for all GCC 4.6+ builds, and not just on - * RANDSTRUCT_PLUGIN builds. - */ -#define randomized_struct_fields_start struct { -#define randomized_struct_fields_end } __randomize_layout; - #endif /* GCC_VERSION >= 40600 */ _ Patches currently in -mm which might be from keescook(a)chromium.org are taint-convert-to-indexed-initialization.patch taint-consolidate-documentation.patch taint-add-taint-for-randstruct.patch kernelh-introduce-const_max-for-vla-removal.patch remove-false-positive-vlas-when-using-max.patch task_struct-only-use-anon-struct-under-randstruct-plugin.patch test_bitmap-do-not-accidentally-use-stack-vla.patch fork-unconditionally-clear-stack-on-fork.patch exec-pass-stack-rlimit-into-mm-layout-functions.patch exec-introduce-finalize_exec-before-start_thread.patch exec-pin-stack-limit-during-exec.patch exofs-avoid-vla-in-structures.patch

7 years, 5 months

1
0
0 0

[PATCH v1] pwm: mediatek: improve precision in rate calculation

by sean.wang＠mediatek.com

From: Sean Wang <sean.wang(a)mediatek.com> Add a way that turning resolution from in nanosecond into in picosecond to improve noticeably almost 4.5% precision. It's necessary to hold the new resolution with type u64 and thus related operations on u64 are applied instead in those rate calculations. And the patch has a dependency on [1]. [1] http://lists.infradead.org/pipermail/linux-mediatek/2018-March/012225.html Cc: stable(a)vger.kernel.org Fixes: caf065f8fd58 ("pwm: Add MediaTek PWM support") Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> --- drivers/pwm/pwm-mediatek.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c index 796baea..98b0a93 100644 --- a/drivers/pwm/pwm-mediatek.c +++ b/drivers/pwm/pwm-mediatek.c @@ -135,19 +135,25 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, { struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip); struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]; - u32 resolution, clkdiv = 0, reg_width = PWMDWIDTH, + u32 clkdiv = 0, cnt_period, cnt_duty, reg_width = PWMDWIDTH, reg_thres = PWMTHRES; + u64 resolution; int ret; ret = mtk_pwm_clk_enable(chip, pwm); if (ret < 0) return ret; - resolution = NSEC_PER_SEC / clk_get_rate(clk); + /* Using resolution in picosecond gets accuracy higher */ + resolution = (u64)NSEC_PER_SEC * 1000; + do_div(resolution, clk_get_rate(clk)); - while (period_ns / resolution > 8191) { + cnt_period = DIV_ROUND_CLOSEST_ULL((u64)period_ns * 1000, resolution); + while (cnt_period > 8191) { resolution *= 2; clkdiv++; + cnt_period = DIV_ROUND_CLOSEST_ULL((u64)period_ns * 1000, + resolution); } if (clkdiv > PWM_CLK_DIV_MAX) { @@ -165,9 +171,10 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, reg_thres = PWM45THRES_FIXUP; } + cnt_duty = DIV_ROUND_CLOSEST_ULL((u64)duty_ns * 1000, resolution); mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv); - mtk_pwm_writel(pc, pwm->hwpwm, reg_width, period_ns / resolution); - mtk_pwm_writel(pc, pwm->hwpwm, reg_thres, duty_ns / resolution); + mtk_pwm_writel(pc, pwm->hwpwm, reg_width, cnt_period); + mtk_pwm_writel(pc, pwm->hwpwm, reg_thres, cnt_duty); mtk_pwm_clk_disable(chip, pwm); -- 2.7.4

7 years, 5 months

2
1
0 0

Re: [PATCH v3] pwm: mediatek: fix up PWM4 and PWM5 malfunction on MT7623

by Sean Wang

On Fri, 2018-03-02 at 11:57 +0100, Thierry Reding wrote: > On Thu, Mar 01, 2018 at 04:19:12PM +0800, sean.wang(a)mediatek.com wrote: > > From: Sean Wang <sean.wang(a)mediatek.com> > > > > Since the offset for both registers, PWMDWIDTH and PWMTHRES, used to > > control PWM4 or PWM5 are distinct from the other PWMs, whose wrong > > programming on PWM hardware causes waveform cannot be output as expected. > > Thus, the patch adds the extra condition for fixing up the weird case to > > let PWM4 or PWM5 able to work on MT7623. > > > > v1 -> v2: use pwm45_fixup naming instead of pwm45_quirk > > v2 -> v3: add more tags for Reviewed-by, Fixes, and Cc stable > > > > Cc: stable(a)vger.kernel.org > > Fixes: caf065f8fd58 ("pwm: Add MediaTek PWM support") > > Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> > > Reviewed-by: Matthias Brugger <matthias.bgg(a)gmail.com> > > Cc: Zhi Mao <zhi.mao(a)mediatek.com> > > Cc: John Crispin <john(a)phrozen.org> > > Cc: Matthias Brugger <matthias.bgg(a)gmail.com> > > --- > > drivers/pwm/pwm-mediatek.c | 24 +++++++++++++++++++++--- > > 1 file changed, 21 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c > [...] > > @@ -151,9 +156,18 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, > > return -EINVAL; > > } > > > > + if (pc->soc->pwm45_fixup && pwm->hwpwm > 2) { > > + /* > > + * PWM[4,5] has distinct offset for PWMDWIDTH and PWMTHRES > > + * from the other PWMs on MT7623. > > + */ > > + reg_width = PWM45DWIDTH_FIXUP; > > + reg_thres = PWM45THRES_FIXUP; > > + } > > I don't understand this. According to the condition above the above > would also use the PWM[4,5] "fixup" register offsets with PWM[3]. Should > the condition be pwm->hwpwm > 3? > > Thierry PWM[4,5] are the naming specified in datasheet and kept it as is here and driver or userspace would use index 3 and 4 to have a reference to them respectively.

7 years, 5 months

2
1
0 0

[PATCH] x86/platform/uv/BAU: add APIC idt entry

by Andrew Banman

BAU uses the old alloc_initr_gate method to setup its interrupt. This fails silently as the BAU vector is in the range of APIC vectors that are registerted to the spurious interrupt handler. Then BAU broadcasts are not handled, and the broadcast source CPU hangs. Fixed by updating BAU to use new idt structure. Signed-off-by: Andrew Banman <abanman(a)hpe.com> Acked-by: Mike Travis <mike.travis(a)hpe.com> --- arch/x86/include/asm/hw_irq.h | 1 + arch/x86/kernel/idt.c | 3 +++ arch/x86/platform/uv/tlb_uv.c | 2 -- 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h index 6dfe366..a56cd0b 100644 --- a/arch/x86/include/asm/hw_irq.h +++ b/arch/x86/include/asm/hw_irq.h @@ -33,6 +33,7 @@ extern asmlinkage void kvm_posted_intr_nested_ipi(void); extern asmlinkage void error_interrupt(void); extern asmlinkage void irq_work_interrupt(void); +extern asmlinkage void uv_bau_message_intr1(void); extern asmlinkage void spurious_interrupt(void); extern asmlinkage void thermal_interrupt(void); diff --git a/arch/x86/kernel/idt.c b/arch/x86/kernel/idt.c index 99f93a6..c5da34e 100644 --- a/arch/x86/kernel/idt.c +++ b/arch/x86/kernel/idt.c @@ -138,6 +138,9 @@ struct idt_data { # ifdef CONFIG_IRQ_WORK INTG(IRQ_WORK_VECTOR, irq_work_interrupt), # endif +#ifdef CONFIG_X86_UV + INTG(UV_BAU_MESSAGE, uv_bau_message_intr1), +#endif INTG(SPURIOUS_APIC_VECTOR, spurious_interrupt), INTG(ERROR_APIC_VECTOR, error_interrupt), #endif diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c index f44c0bc..5e22845 100644 --- a/arch/x86/platform/uv/tlb_uv.c +++ b/arch/x86/platform/uv/tlb_uv.c @@ -2254,8 +2254,6 @@ static int __init uv_bau_init(void) init_uvhub(uvhub, vector, uv_base_pnode); } - alloc_intr_gate(vector, uv_bau_message_intr1); - for_each_possible_blade(uvhub) { if (uv_blade_nr_possible_cpus(uvhub)) { unsigned long val; -- 1.8.2.1

7 years, 5 months

1
0
0 0

[PATCH 2/4] Drivers: hv: vmbus: do not mark HV_PCIE as perf_device

by kys＠linuxonhyperv.comi

From: Dexuan Cui <decui(a)microsoft.com> The pci-hyperv driver's channel callback hv_pci_onchannelcallback() is not really a hot path, so we don't need to mark it as a perf_device, meaning with this patch all HV_PCIE channels' target_cpu will be CPU0. Signed-off-by: Dexuan Cui <decui(a)microsoft.com> Cc: stable(a)vger.kernel.org Cc: Stephen Hemminger <sthemmin(a)microsoft.com> Cc: K. Y. Srinivasan <kys(a)microsoft.com> Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com> --- drivers/hv/channel_mgmt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index c6d9d19bc04e..ecc2bd275a73 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -71,7 +71,7 @@ static const struct vmbus_device vmbus_devs[] = { /* PCIE */ { .dev_type = HV_PCIE, HV_PCIE_GUID, - .perf_device = true, + .perf_device = false, }, /* Synthetic Frame Buffer */ -- 2.15.1

7 years, 5 months

1
0
0 0

[PATCH v3 1/6] PCI: aardvark: introduce an advk_pcie_valid_device() helper

by Thomas Petazzoni

From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> In other to mimic other PCIe host controller drivers, introduce an advk_pcie_valid_device() helper, used in the configuration read/write functions. This patch by itself is not a fix, but it is required for a follow-up patch that is a fix, hence the Fixes tag and the Cc to stable. Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> --- Changes since v2: - New patch --- drivers/pci/host/pci-aardvark.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c index b04d37b3c5de..ccd0304a0c21 100644 --- a/drivers/pci/host/pci-aardvark.c +++ b/drivers/pci/host/pci-aardvark.c @@ -430,6 +430,15 @@ static int advk_pcie_wait_pio(struct advk_pcie *pcie) return -ETIMEDOUT; } +static int advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus, + int devfn) +{ + if (PCI_SLOT(devfn) != 0) + return false; + + return true; +} + static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val) { @@ -437,7 +446,7 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn, u32 reg; int ret; - if (PCI_SLOT(devfn) != 0) { + if (!advk_pcie_valid_device(pcie, bus, devfn)) { *val = 0xffffffff; return PCIBIOS_DEVICE_NOT_FOUND; } @@ -491,7 +500,7 @@ static int advk_pcie_wr_conf(struct pci_bus *bus, u32 devfn, int offset; int ret; - if (PCI_SLOT(devfn) != 0) + if (!advk_pcie_valid_device(pcie, bus, devfn)) return PCIBIOS_DEVICE_NOT_FOUND; if (where % size) -- 2.14.3

7 years, 5 months

2
1
0 0

[PATCHv2] irqchip: arm-gic: take gic_lock when updating irq type

by Aniruddha Banerjee

The kernel documentation states that the locking of the irq-chip registers should be handled by the irq-chip driver. In the irq-gic, the accesses to the irqchip are seemingly not protected and multiple writes to SPIs from different irq descriptors do RMW requests without taking the irq-chip lock. When multiple irqs call the request_irq at the same time, there can be a simultaneous write at the gic distributor, leading to a race. Acquire the gic_lock when the irq_type is updated. Signed-off-by: Aniruddha Banerjee <aniruddha.nitd(a)gmail.com> --- drivers/irqchip/irq-gic-common.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c index 9ae71804b5dd..73dd39959e6e 100644 --- a/drivers/irqchip/irq-gic-common.c +++ b/drivers/irqchip/irq-gic-common.c @@ -21,6 +21,8 @@ #include "irq-gic-common.h" +static DEFINE_RAW_SPINLOCK(irq_controller_lock); + static const struct gic_kvm_info *gic_kvm_info; const struct gic_kvm_info *gic_get_kvm_info(void) @@ -57,6 +59,7 @@ int gic_configure_irq(unsigned int irq, unsigned int type, * Read current configuration register, and insert the config * for "irq", depending on "type". */ + raw_spin_lock(&irq_controller_lock); val = oldval = readl_relaxed(base + GIC_DIST_CONFIG + confoff); if (type & IRQ_TYPE_LEVEL_MASK) val &= ~confmask; @@ -64,8 +67,10 @@ int gic_configure_irq(unsigned int irq, unsigned int type, val |= confmask; /* If the current configuration is the same, then we are done */ - if (val == oldval) + if (val == oldval) { + raw_spin_unlock(&irq_controller_lock); return 0; + } /* * Write back the new configuration, and possibly re-enable @@ -83,6 +88,7 @@ int gic_configure_irq(unsigned int irq, unsigned int type, pr_warn("GIC: PPI%d is secure or misconfigured\n", irq - 16); } + raw_spin_unlock(&irq_controller_lock); if (sync_access) sync_access(); -- 2.16.2

7 years, 5 months

1
0
0 0

[PATCH v3 2/6] phy: qcom-qusb2: Fix crash if nvmem cell not specified

by Manu Gautam

Driver currently crashes due to NULL pointer deference while updating PHY tune register if nvmem cell is NULL. Since, fused value for Tune1/2 register is optional, we'd rather bail out. Fixes: ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips") Reviewed-by: Vivek Gautam <vivek.gautam(a)codeaurora.org> Cc: stable <stable(a)vger.kernel.org> # 4.14+ Signed-off-by: Manu Gautam <mgautam(a)codeaurora.org> --- drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c index 94afeac..40fdef8 100644 --- a/drivers/phy/qualcomm/phy-qcom-qusb2.c +++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c @@ -315,6 +315,10 @@ static void qusb2_phy_set_tune2_param(struct qusb2_phy *qphy) const struct qusb2_phy_cfg *cfg = qphy->cfg; u8 *val; + /* efuse register is optional */ + if (!qphy->cell) + return; + /* * Read efuse register having TUNE2/1 parameter's high nibble. * If efuse register shows value as 0x0, or if we fail to find -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] [PATCH v6] usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()

by Jeffy Chen

From: AMAN DEEP <aman.deep(a)samsung.com> There is a race condition between finish_unlinks->finish_urb() function and usb_kill_urb() in ohci controller case. The finish_urb calls spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call, then if during this time, usb_kill_urb is called for another endpoint, then new ed will be added to ed_rm_list at beginning for unlink, and ed_rm_list will point to newly added. When finish_urb() is completed in finish_unlinks() and ed->td_list becomes empty as in below code (in finish_unlinks() function): if (list_empty(&ed->td_list)) { *last = ed->ed_next; ed->ed_next = NULL; } else if (ohci->rh_state == OHCI_RH_RUNNING) { *last = ed->ed_next; ed->ed_next = NULL; ed_schedule(ohci, ed); } The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next and previously added ed by usb_kill_urb will be left unreferenced by ed_rm_list. This causes usb_kill_urb() hang forever waiting for finish_unlink to remove added ed from ed_rm_list. The main reason for hang in this race condtion is addition and removal of ed from ed_rm_list in the beginning during usb_kill_urb and later last* is modified in finish_unlinks(). As suggested by Alan Stern, the solution for proper handling of ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing any URBs. Then at the end, we can add ed back to the list if necessary. This properly handle the updated ohci->ed_rm_list in usb_kill_urb(). Fixes:977dcfdc6031("USB:OHCI:don't lose track of EDs when a controller dies") Acked-by: Alan Stern <stern(a)rowland.harvard.edu> CC: <stable(a)vger.kernel.org> Signed-off-by: Aman Deep <aman.deep(a)samsung.com> Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com> --- Changes in v6: This is a resend of Aman Deep's v5 patch [0], which solved the hang we hit [1]. (Thanks Aman :) The v5 has some format issues, so i slightly adjust the commit message. [0] https://www.spinics.net/lists/linux-usb/msg129010.html [1] https://bugs.chromium.org/p/chromium/issues/detail?id=803749 drivers/usb/host/ohci-q.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/usb/host/ohci-q.c b/drivers/usb/host/ohci-q.c index b2ec8c399363..4ccb85a67bb3 100644 --- a/drivers/usb/host/ohci-q.c +++ b/drivers/usb/host/ohci-q.c @@ -1019,6 +1019,8 @@ static void finish_unlinks(struct ohci_hcd *ohci) * have modified this list. normally it's just prepending * entries (which we'd ignore), but paranoia won't hurt. */ + *last = ed->ed_next; + ed->ed_next = NULL; modified = 0; /* unlink urbs as requested, but rescan the list after @@ -1077,21 +1079,22 @@ static void finish_unlinks(struct ohci_hcd *ohci) goto rescan_this; /* - * If no TDs are queued, take ED off the ed_rm_list. + * If no TDs are queued, ED is now idle. * Otherwise, if the HC is running, reschedule. - * If not, leave it on the list for further dequeues. + * If the HC isn't running, add ED back to the + * start of the list for later processing. */ if (list_empty(&ed->td_list)) { - *last = ed->ed_next; - ed->ed_next = NULL; ed->state = ED_IDLE; list_del(&ed->in_use_list); } else if (ohci->rh_state == OHCI_RH_RUNNING) { - *last = ed->ed_next; - ed->ed_next = NULL; ed_schedule(ohci, ed); } else { - last = &ed->ed_next; + ed->ed_next = ohci->ed_rm_list; + ohci->ed_rm_list = ed; + /* Don't loop on the same ED */ + if (last == &ohci->ed_rm_list) + last = &ed->ed_next; } if (modified) -- 2.11.0

7 years, 5 months

3
4
0 0

Patch "kbuild: disable clang's default use of -fmerge-all-constants" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kbuild: disable clang's default use of -fmerge-all-constants to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79 Mon Sep 17 00:00:00 2001 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Wed, 21 Mar 2018 01:18:24 +0100 Subject: kbuild: disable clang's default use of -fmerge-all-constants From: Daniel Borkmann <daniel(a)iogearbox.net> commit 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79 upstream. Prasad reported that he has seen crashes in BPF subsystem with netd on Android with arm64 in the form of (note, the taint is unrelated): [ 4134.721483] Unable to handle kernel paging request at virtual address 800000001 [ 4134.820925] Mem abort info: [ 4134.901283] Exception class = DABT (current EL), IL = 32 bits [ 4135.016736] SET = 0, FnV = 0 [ 4135.119820] EA = 0, S1PTW = 0 [ 4135.201431] Data abort info: [ 4135.301388] ISV = 0, ISS = 0x00000021 [ 4135.359599] CM = 0, WnR = 0 [ 4135.470873] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffe39b946000 [ 4135.499757] [0000000800000001] *pgd=0000000000000000, *pud=0000000000000000 [ 4135.660725] Internal error: Oops: 96000021 [#1] PREEMPT SMP [ 4135.674610] Modules linked in: [ 4135.682883] CPU: 5 PID: 1260 Comm: netd Tainted: G S W 4.14.19+ #1 [ 4135.716188] task: ffffffe39f4aa380 task.stack: ffffff801d4e0000 [ 4135.731599] PC is at bpf_prog_add+0x20/0x68 [ 4135.741746] LR is at bpf_prog_inc+0x20/0x2c [ 4135.751788] pc : [<ffffff94ab7ad584>] lr : [<ffffff94ab7ad638>] pstate: 60400145 [ 4135.769062] sp : ffffff801d4e3ce0 [...] [ 4136.258315] Process netd (pid: 1260, stack limit = 0xffffff801d4e0000) [ 4136.273746] Call trace: [...] [ 4136.442494] 3ca0: ffffff94ab7ad584 0000000060400145 ffffffe3a01bf8f8 0000000000000006 [ 4136.460936] 3cc0: 0000008000000000 ffffff94ab844204 ffffff801d4e3cf0 ffffff94ab7ad584 [ 4136.479241] [<ffffff94ab7ad584>] bpf_prog_add+0x20/0x68 [ 4136.491767] [<ffffff94ab7ad638>] bpf_prog_inc+0x20/0x2c [ 4136.504536] [<ffffff94ab7b5d08>] bpf_obj_get_user+0x204/0x22c [ 4136.518746] [<ffffff94ab7ade68>] SyS_bpf+0x5a8/0x1a88 Android's netd was basically pinning the uid cookie BPF map in BPF fs (/sys/fs/bpf/traffic_cookie_uid_map) and later on retrieving it again resulting in above panic. Issue is that the map was wrongly identified as a prog! Above kernel was compiled with clang 4.0, and it turns out that clang decided to merge the bpf_prog_iops and bpf_map_iops into a single memory location, such that the two i_ops could then not be distinguished anymore. Reason for this miscompilation is that clang has the more aggressive -fmerge-all-constants enabled by default. In fact, clang source code has a comment about it in lib/AST/ExprConstant.cpp on why it is okay to do so: Pointers with different bases cannot represent the same object. (Note that clang defaults to -fmerge-all-constants, which can lead to inconsistent results for comparisons involving the address of a constant; this generally doesn't matter in practice.) The issue never appeared with gcc however, since gcc does not enable -fmerge-all-constants by default and even *explicitly* states in it's option description that using this flag results in non-conforming behavior, quote from man gcc: Languages like C or C++ require each variable, including multiple instances of the same variable in recursive calls, to have distinct locations, so using this option results in non-conforming behavior. There are also various clang bug reports open on that matter [1], where clang developers acknowledge the non-conforming behavior, and refer to disabling it with -fno-merge-all-constants. But even if this gets fixed in clang today, there are already users out there that triggered this. Thus, fix this issue by explicitly adding -fno-merge-all-constants to the kernel's Makefile to generically disable this optimization, since potentially other places in the kernel could subtly break as well. Note, there is also a flag called -fmerge-constants (not supported by clang), which is more conservative and only applies to strings and it's enabled in gcc's -O/-O2/-O3/-Os optimization levels. In gcc's code, the two flags -fmerge-{all-,}constants share the same variable internally, so when disabling it via -fno-merge-all-constants, then we really don't merge any const data (e.g. strings), and text size increases with gcc (14,927,214 -> 14,942,646 for vmlinux.o). $ gcc -fverbose-asm -O2 foo.c -S -o foo.S -> foo.S lists -fmerge-constants under options enabled $ gcc -fverbose-asm -O2 -fno-merge-all-constants foo.c -S -o foo.S -> foo.S doesn't list -fmerge-constants under options enabled $ gcc -fverbose-asm -O2 -fno-merge-all-constants -fmerge-constants foo.c -S -o foo.S -> foo.S lists -fmerge-constants under options enabled Thus, as a workaround we need to set both -fno-merge-all-constants *and* -fmerge-constants in the Makefile in order for text size to stay as is. [1] https://bugs.llvm.org/show_bug.cgi?id=18538 Reported-by: Prasad Sodagudi <psodagud(a)codeaurora.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Chenbo Feng <fengc(a)google.com> Cc: Richard Smith <richard-llvm(a)metafoo.co.uk> Cc: Chandler Carruth <chandlerc(a)gmail.com> Cc: linux-kernel(a)vger.kernel.org Tested-by: Prasad Sodagudi <psodagud(a)codeaurora.org> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Makefile | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/Makefile +++ b/Makefile @@ -790,6 +790,15 @@ KBUILD_CFLAGS += $(call cc-disable-warni # disable invalid "can't wrap" optimizations for signed / pointers KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow) +# clang sets -fmerge-all-constants by default as optimization, but this +# is non-conforming behavior for C and in fact breaks the kernel, so we +# need to disable it here generally. +KBUILD_CFLAGS += $(call cc-option,-fno-merge-all-constants) + +# for gcc -fno-merge-all-constants disables everything, but it is fine +# to have actual conforming behavior enabled. +KBUILD_CFLAGS += $(call cc-option,-fmerge-constants) + # Make sure -fstack-check isn't enabled (like gentoo apparently did) KBUILD_CFLAGS += $(call cc-option,-fno-stack-check,) Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-4.9/kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch queue-4.9/bpf-skip-unnecessary-capability-check.patch queue-4.9/bpf-x64-increase-number-of-passes.patch

7 years, 5 months

1
0
0 0

Patch "bpf, x64: increase number of passes" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf, x64: increase number of passes to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bpf-x64-increase-number-of-passes.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6007b080d2e2adb7af22bf29165f0594ea12b34c Mon Sep 17 00:00:00 2001 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Wed, 7 Mar 2018 22:10:01 +0100 Subject: bpf, x64: increase number of passes From: Daniel Borkmann <daniel(a)iogearbox.net> commit 6007b080d2e2adb7af22bf29165f0594ea12b34c upstream. In Cilium some of the main programs we run today are hitting 9 passes on x64's JIT compiler, and we've had cases already where we surpassed the limit where the JIT then punts the program to the interpreter instead, leading to insertion failures due to CONFIG_BPF_JIT_ALWAYS_ON or insertion failures due to the prog array owner being JITed but the program to insert not (both must have the same JITed/non-JITed property). One concrete case the program image shrunk from 12,767 bytes down to 10,288 bytes where the image converged after 16 steps. I've measured that this took 340us in the JIT until it converges on my i7-6600U. Thus, increase the original limit we had from day one where the JIT covered cBPF only back then before we run into the case (as similar with the complexity limit) where we trip over this and hit program rejections. Also add a cond_resched() into the compilation loop, the JIT process runs without any locks and may sleep anyway. Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/net/bpf_jit_comp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -1135,7 +1135,7 @@ struct bpf_prog *bpf_int_jit_compile(str * may converge on the last pass. In such case do one more * pass to emit the final image */ - for (pass = 0; pass < 10 || image; pass++) { + for (pass = 0; pass < 20 || image; pass++) { proglen = do_jit(prog, addrs, image, oldproglen, &ctx); if (proglen <= 0) { image = NULL; @@ -1162,6 +1162,7 @@ struct bpf_prog *bpf_int_jit_compile(str } } oldproglen = proglen; + cond_resched(); } if (bpf_jit_enable > 1) Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-4.9/kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch queue-4.9/bpf-skip-unnecessary-capability-check.patch queue-4.9/bpf-x64-increase-number-of-passes.patch

7 years, 5 months

1
0
0 0

Patch "bpf: skip unnecessary capability check" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: skip unnecessary capability check to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bpf-skip-unnecessary-capability-check.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0fa4fe85f4724fff89b09741c437cbee9cf8b008 Mon Sep 17 00:00:00 2001 From: Chenbo Feng <fengc(a)google.com> Date: Mon, 19 Mar 2018 17:57:27 -0700 Subject: bpf: skip unnecessary capability check From: Chenbo Feng <fengc(a)google.com> commit 0fa4fe85f4724fff89b09741c437cbee9cf8b008 upstream. The current check statement in BPF syscall will do a capability check for CAP_SYS_ADMIN before checking sysctl_unprivileged_bpf_disabled. This code path will trigger unnecessary security hooks on capability checking and cause false alarms on unprivileged process trying to get CAP_SYS_ADMIN access. This can be resolved by simply switch the order of the statement and CAP_SYS_ADMIN is not required anyway if unprivileged bpf syscall is allowed. Signed-off-by: Chenbo Feng <fengc(a)google.com> Acked-by: Lorenzo Colitti <lorenzo(a)google.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/syscall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -801,7 +801,7 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf union bpf_attr attr = {}; int err; - if (!capable(CAP_SYS_ADMIN) && sysctl_unprivileged_bpf_disabled) + if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN)) return -EPERM; if (!access_ok(VERIFY_READ, uattr, 1)) Patches currently in stable-queue which might be from fengc(a)google.com are queue-4.9/kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch queue-4.9/bpf-skip-unnecessary-capability-check.patch

7 years, 5 months

1
0
0 0

Patch "kbuild: disable clang's default use of -fmerge-all-constants" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kbuild: disable clang's default use of -fmerge-all-constants to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79 Mon Sep 17 00:00:00 2001 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Wed, 21 Mar 2018 01:18:24 +0100 Subject: kbuild: disable clang's default use of -fmerge-all-constants From: Daniel Borkmann <daniel(a)iogearbox.net> commit 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79 upstream. Prasad reported that he has seen crashes in BPF subsystem with netd on Android with arm64 in the form of (note, the taint is unrelated): [ 4134.721483] Unable to handle kernel paging request at virtual address 800000001 [ 4134.820925] Mem abort info: [ 4134.901283] Exception class = DABT (current EL), IL = 32 bits [ 4135.016736] SET = 0, FnV = 0 [ 4135.119820] EA = 0, S1PTW = 0 [ 4135.201431] Data abort info: [ 4135.301388] ISV = 0, ISS = 0x00000021 [ 4135.359599] CM = 0, WnR = 0 [ 4135.470873] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffe39b946000 [ 4135.499757] [0000000800000001] *pgd=0000000000000000, *pud=0000000000000000 [ 4135.660725] Internal error: Oops: 96000021 [#1] PREEMPT SMP [ 4135.674610] Modules linked in: [ 4135.682883] CPU: 5 PID: 1260 Comm: netd Tainted: G S W 4.14.19+ #1 [ 4135.716188] task: ffffffe39f4aa380 task.stack: ffffff801d4e0000 [ 4135.731599] PC is at bpf_prog_add+0x20/0x68 [ 4135.741746] LR is at bpf_prog_inc+0x20/0x2c [ 4135.751788] pc : [<ffffff94ab7ad584>] lr : [<ffffff94ab7ad638>] pstate: 60400145 [ 4135.769062] sp : ffffff801d4e3ce0 [...] [ 4136.258315] Process netd (pid: 1260, stack limit = 0xffffff801d4e0000) [ 4136.273746] Call trace: [...] [ 4136.442494] 3ca0: ffffff94ab7ad584 0000000060400145 ffffffe3a01bf8f8 0000000000000006 [ 4136.460936] 3cc0: 0000008000000000 ffffff94ab844204 ffffff801d4e3cf0 ffffff94ab7ad584 [ 4136.479241] [<ffffff94ab7ad584>] bpf_prog_add+0x20/0x68 [ 4136.491767] [<ffffff94ab7ad638>] bpf_prog_inc+0x20/0x2c [ 4136.504536] [<ffffff94ab7b5d08>] bpf_obj_get_user+0x204/0x22c [ 4136.518746] [<ffffff94ab7ade68>] SyS_bpf+0x5a8/0x1a88 Android's netd was basically pinning the uid cookie BPF map in BPF fs (/sys/fs/bpf/traffic_cookie_uid_map) and later on retrieving it again resulting in above panic. Issue is that the map was wrongly identified as a prog! Above kernel was compiled with clang 4.0, and it turns out that clang decided to merge the bpf_prog_iops and bpf_map_iops into a single memory location, such that the two i_ops could then not be distinguished anymore. Reason for this miscompilation is that clang has the more aggressive -fmerge-all-constants enabled by default. In fact, clang source code has a comment about it in lib/AST/ExprConstant.cpp on why it is okay to do so: Pointers with different bases cannot represent the same object. (Note that clang defaults to -fmerge-all-constants, which can lead to inconsistent results for comparisons involving the address of a constant; this generally doesn't matter in practice.) The issue never appeared with gcc however, since gcc does not enable -fmerge-all-constants by default and even *explicitly* states in it's option description that using this flag results in non-conforming behavior, quote from man gcc: Languages like C or C++ require each variable, including multiple instances of the same variable in recursive calls, to have distinct locations, so using this option results in non-conforming behavior. There are also various clang bug reports open on that matter [1], where clang developers acknowledge the non-conforming behavior, and refer to disabling it with -fno-merge-all-constants. But even if this gets fixed in clang today, there are already users out there that triggered this. Thus, fix this issue by explicitly adding -fno-merge-all-constants to the kernel's Makefile to generically disable this optimization, since potentially other places in the kernel could subtly break as well. Note, there is also a flag called -fmerge-constants (not supported by clang), which is more conservative and only applies to strings and it's enabled in gcc's -O/-O2/-O3/-Os optimization levels. In gcc's code, the two flags -fmerge-{all-,}constants share the same variable internally, so when disabling it via -fno-merge-all-constants, then we really don't merge any const data (e.g. strings), and text size increases with gcc (14,927,214 -> 14,942,646 for vmlinux.o). $ gcc -fverbose-asm -O2 foo.c -S -o foo.S -> foo.S lists -fmerge-constants under options enabled $ gcc -fverbose-asm -O2 -fno-merge-all-constants foo.c -S -o foo.S -> foo.S doesn't list -fmerge-constants under options enabled $ gcc -fverbose-asm -O2 -fno-merge-all-constants -fmerge-constants foo.c -S -o foo.S -> foo.S lists -fmerge-constants under options enabled Thus, as a workaround we need to set both -fno-merge-all-constants *and* -fmerge-constants in the Makefile in order for text size to stay as is. [1] https://bugs.llvm.org/show_bug.cgi?id=18538 Reported-by: Prasad Sodagudi <psodagud(a)codeaurora.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Chenbo Feng <fengc(a)google.com> Cc: Richard Smith <richard-llvm(a)metafoo.co.uk> Cc: Chandler Carruth <chandlerc(a)gmail.com> Cc: linux-kernel(a)vger.kernel.org Tested-by: Prasad Sodagudi <psodagud(a)codeaurora.org> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Makefile | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/Makefile +++ b/Makefile @@ -784,6 +784,15 @@ KBUILD_CFLAGS += $(call cc-disable-warni # disable invalid "can't wrap" optimizations for signed / pointers KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow) +# clang sets -fmerge-all-constants by default as optimization, but this +# is non-conforming behavior for C and in fact breaks the kernel, so we +# need to disable it here generally. +KBUILD_CFLAGS += $(call cc-option,-fno-merge-all-constants) + +# for gcc -fno-merge-all-constants disables everything, but it is fine +# to have actual conforming behavior enabled. +KBUILD_CFLAGS += $(call cc-option,-fmerge-constants) + # Make sure -fstack-check isn't enabled (like gentoo apparently did) KBUILD_CFLAGS += $(call cc-option,-fno-stack-check,) Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-4.4/kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch queue-4.4/bpf-skip-unnecessary-capability-check.patch queue-4.4/bpf-x64-increase-number-of-passes.patch

7 years, 5 months

1
0
0 0

Patch "bpf: skip unnecessary capability check" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: skip unnecessary capability check to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bpf-skip-unnecessary-capability-check.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0fa4fe85f4724fff89b09741c437cbee9cf8b008 Mon Sep 17 00:00:00 2001 From: Chenbo Feng <fengc(a)google.com> Date: Mon, 19 Mar 2018 17:57:27 -0700 Subject: bpf: skip unnecessary capability check From: Chenbo Feng <fengc(a)google.com> commit 0fa4fe85f4724fff89b09741c437cbee9cf8b008 upstream. The current check statement in BPF syscall will do a capability check for CAP_SYS_ADMIN before checking sysctl_unprivileged_bpf_disabled. This code path will trigger unnecessary security hooks on capability checking and cause false alarms on unprivileged process trying to get CAP_SYS_ADMIN access. This can be resolved by simply switch the order of the statement and CAP_SYS_ADMIN is not required anyway if unprivileged bpf syscall is allowed. Signed-off-by: Chenbo Feng <fengc(a)google.com> Acked-by: Lorenzo Colitti <lorenzo(a)google.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/syscall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -673,7 +673,7 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf union bpf_attr attr = {}; int err; - if (!capable(CAP_SYS_ADMIN) && sysctl_unprivileged_bpf_disabled) + if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN)) return -EPERM; if (!access_ok(VERIFY_READ, uattr, 1)) Patches currently in stable-queue which might be from fengc(a)google.com are queue-4.4/kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch queue-4.4/bpf-skip-unnecessary-capability-check.patch

7 years, 5 months

1
0
0 0

Patch "bpf, x64: increase number of passes" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf, x64: increase number of passes to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bpf-x64-increase-number-of-passes.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6007b080d2e2adb7af22bf29165f0594ea12b34c Mon Sep 17 00:00:00 2001 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Wed, 7 Mar 2018 22:10:01 +0100 Subject: bpf, x64: increase number of passes From: Daniel Borkmann <daniel(a)iogearbox.net> commit 6007b080d2e2adb7af22bf29165f0594ea12b34c upstream. In Cilium some of the main programs we run today are hitting 9 passes on x64's JIT compiler, and we've had cases already where we surpassed the limit where the JIT then punts the program to the interpreter instead, leading to insertion failures due to CONFIG_BPF_JIT_ALWAYS_ON or insertion failures due to the prog array owner being JITed but the program to insert not (both must have the same JITed/non-JITed property). One concrete case the program image shrunk from 12,767 bytes down to 10,288 bytes where the image converged after 16 steps. I've measured that this took 340us in the JIT until it converges on my i7-6600U. Thus, increase the original limit we had from day one where the JIT covered cBPF only back then before we run into the case (as similar with the complexity limit) where we trip over this and hit program rejections. Also add a cond_resched() into the compilation loop, the JIT process runs without any locks and may sleep anyway. Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/net/bpf_jit_comp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -1077,7 +1077,7 @@ void bpf_int_jit_compile(struct bpf_prog * may converge on the last pass. In such case do one more * pass to emit the final image */ - for (pass = 0; pass < 10 || image; pass++) { + for (pass = 0; pass < 20 || image; pass++) { proglen = do_jit(prog, addrs, image, oldproglen, &ctx); if (proglen <= 0) { image = NULL; @@ -1100,6 +1100,7 @@ void bpf_int_jit_compile(struct bpf_prog goto out; } oldproglen = proglen; + cond_resched(); } if (bpf_jit_enable > 1) Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-4.4/kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch queue-4.4/bpf-skip-unnecessary-capability-check.patch queue-4.4/bpf-x64-increase-number-of-passes.patch

7 years, 5 months

1
0
0 0

Patch "kbuild: disable clang's default use of -fmerge-all-constants" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kbuild: disable clang's default use of -fmerge-all-constants to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79 Mon Sep 17 00:00:00 2001 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Wed, 21 Mar 2018 01:18:24 +0100 Subject: kbuild: disable clang's default use of -fmerge-all-constants From: Daniel Borkmann <daniel(a)iogearbox.net> commit 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79 upstream. Prasad reported that he has seen crashes in BPF subsystem with netd on Android with arm64 in the form of (note, the taint is unrelated): [ 4134.721483] Unable to handle kernel paging request at virtual address 800000001 [ 4134.820925] Mem abort info: [ 4134.901283] Exception class = DABT (current EL), IL = 32 bits [ 4135.016736] SET = 0, FnV = 0 [ 4135.119820] EA = 0, S1PTW = 0 [ 4135.201431] Data abort info: [ 4135.301388] ISV = 0, ISS = 0x00000021 [ 4135.359599] CM = 0, WnR = 0 [ 4135.470873] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffe39b946000 [ 4135.499757] [0000000800000001] *pgd=0000000000000000, *pud=0000000000000000 [ 4135.660725] Internal error: Oops: 96000021 [#1] PREEMPT SMP [ 4135.674610] Modules linked in: [ 4135.682883] CPU: 5 PID: 1260 Comm: netd Tainted: G S W 4.14.19+ #1 [ 4135.716188] task: ffffffe39f4aa380 task.stack: ffffff801d4e0000 [ 4135.731599] PC is at bpf_prog_add+0x20/0x68 [ 4135.741746] LR is at bpf_prog_inc+0x20/0x2c [ 4135.751788] pc : [<ffffff94ab7ad584>] lr : [<ffffff94ab7ad638>] pstate: 60400145 [ 4135.769062] sp : ffffff801d4e3ce0 [...] [ 4136.258315] Process netd (pid: 1260, stack limit = 0xffffff801d4e0000) [ 4136.273746] Call trace: [...] [ 4136.442494] 3ca0: ffffff94ab7ad584 0000000060400145 ffffffe3a01bf8f8 0000000000000006 [ 4136.460936] 3cc0: 0000008000000000 ffffff94ab844204 ffffff801d4e3cf0 ffffff94ab7ad584 [ 4136.479241] [<ffffff94ab7ad584>] bpf_prog_add+0x20/0x68 [ 4136.491767] [<ffffff94ab7ad638>] bpf_prog_inc+0x20/0x2c [ 4136.504536] [<ffffff94ab7b5d08>] bpf_obj_get_user+0x204/0x22c [ 4136.518746] [<ffffff94ab7ade68>] SyS_bpf+0x5a8/0x1a88 Android's netd was basically pinning the uid cookie BPF map in BPF fs (/sys/fs/bpf/traffic_cookie_uid_map) and later on retrieving it again resulting in above panic. Issue is that the map was wrongly identified as a prog! Above kernel was compiled with clang 4.0, and it turns out that clang decided to merge the bpf_prog_iops and bpf_map_iops into a single memory location, such that the two i_ops could then not be distinguished anymore. Reason for this miscompilation is that clang has the more aggressive -fmerge-all-constants enabled by default. In fact, clang source code has a comment about it in lib/AST/ExprConstant.cpp on why it is okay to do so: Pointers with different bases cannot represent the same object. (Note that clang defaults to -fmerge-all-constants, which can lead to inconsistent results for comparisons involving the address of a constant; this generally doesn't matter in practice.) The issue never appeared with gcc however, since gcc does not enable -fmerge-all-constants by default and even *explicitly* states in it's option description that using this flag results in non-conforming behavior, quote from man gcc: Languages like C or C++ require each variable, including multiple instances of the same variable in recursive calls, to have distinct locations, so using this option results in non-conforming behavior. There are also various clang bug reports open on that matter [1], where clang developers acknowledge the non-conforming behavior, and refer to disabling it with -fno-merge-all-constants. But even if this gets fixed in clang today, there are already users out there that triggered this. Thus, fix this issue by explicitly adding -fno-merge-all-constants to the kernel's Makefile to generically disable this optimization, since potentially other places in the kernel could subtly break as well. Note, there is also a flag called -fmerge-constants (not supported by clang), which is more conservative and only applies to strings and it's enabled in gcc's -O/-O2/-O3/-Os optimization levels. In gcc's code, the two flags -fmerge-{all-,}constants share the same variable internally, so when disabling it via -fno-merge-all-constants, then we really don't merge any const data (e.g. strings), and text size increases with gcc (14,927,214 -> 14,942,646 for vmlinux.o). $ gcc -fverbose-asm -O2 foo.c -S -o foo.S -> foo.S lists -fmerge-constants under options enabled $ gcc -fverbose-asm -O2 -fno-merge-all-constants foo.c -S -o foo.S -> foo.S doesn't list -fmerge-constants under options enabled $ gcc -fverbose-asm -O2 -fno-merge-all-constants -fmerge-constants foo.c -S -o foo.S -> foo.S lists -fmerge-constants under options enabled Thus, as a workaround we need to set both -fno-merge-all-constants *and* -fmerge-constants in the Makefile in order for text size to stay as is. [1] https://bugs.llvm.org/show_bug.cgi?id=18538 Reported-by: Prasad Sodagudi <psodagud(a)codeaurora.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Chenbo Feng <fengc(a)google.com> Cc: Richard Smith <richard-llvm(a)metafoo.co.uk> Cc: Chandler Carruth <chandlerc(a)gmail.com> Cc: linux-kernel(a)vger.kernel.org Tested-by: Prasad Sodagudi <psodagud(a)codeaurora.org> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Makefile | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/Makefile +++ b/Makefile @@ -798,6 +798,15 @@ KBUILD_CFLAGS += $(call cc-disable-warni # disable invalid "can't wrap" optimizations for signed / pointers KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow) +# clang sets -fmerge-all-constants by default as optimization, but this +# is non-conforming behavior for C and in fact breaks the kernel, so we +# need to disable it here generally. +KBUILD_CFLAGS += $(call cc-option,-fno-merge-all-constants) + +# for gcc -fno-merge-all-constants disables everything, but it is fine +# to have actual conforming behavior enabled. +KBUILD_CFLAGS += $(call cc-option,-fmerge-constants) + # Make sure -fstack-check isn't enabled (like gentoo apparently did) KBUILD_CFLAGS += $(call cc-option,-fno-stack-check,) Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-4.15/trace-bpf-remove-helper-bpf_perf_prog_read_value-from-tracepoint-type-programs.patch queue-4.15/kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch queue-4.15/bpf-skip-unnecessary-capability-check.patch queue-4.15/bpf-x64-increase-number-of-passes.patch

7 years, 5 months

1
0
0 0

Patch "bpf, x64: increase number of passes" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf, x64: increase number of passes to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bpf-x64-increase-number-of-passes.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6007b080d2e2adb7af22bf29165f0594ea12b34c Mon Sep 17 00:00:00 2001 From: Daniel Borkmann <daniel(a)iogearbox.net> Date: Wed, 7 Mar 2018 22:10:01 +0100 Subject: bpf, x64: increase number of passes From: Daniel Borkmann <daniel(a)iogearbox.net> commit 6007b080d2e2adb7af22bf29165f0594ea12b34c upstream. In Cilium some of the main programs we run today are hitting 9 passes on x64's JIT compiler, and we've had cases already where we surpassed the limit where the JIT then punts the program to the interpreter instead, leading to insertion failures due to CONFIG_BPF_JIT_ALWAYS_ON or insertion failures due to the prog array owner being JITed but the program to insert not (both must have the same JITed/non-JITed property). One concrete case the program image shrunk from 12,767 bytes down to 10,288 bytes where the image converged after 16 steps. I've measured that this took 340us in the JIT until it converges on my i7-6600U. Thus, increase the original limit we had from day one where the JIT covered cBPF only back then before we run into the case (as similar with the complexity limit) where we trip over this and hit program rejections. Also add a cond_resched() into the compilation loop, the JIT process runs without any locks and may sleep anyway. Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/net/bpf_jit_comp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -1156,7 +1156,7 @@ struct bpf_prog *bpf_int_jit_compile(str * may converge on the last pass. In such case do one more * pass to emit the final image */ - for (pass = 0; pass < 10 || image; pass++) { + for (pass = 0; pass < 20 || image; pass++) { proglen = do_jit(prog, addrs, image, oldproglen, &ctx); if (proglen <= 0) { image = NULL; @@ -1183,6 +1183,7 @@ struct bpf_prog *bpf_int_jit_compile(str } } oldproglen = proglen; + cond_resched(); } if (bpf_jit_enable > 1) Patches currently in stable-queue which might be from daniel(a)iogearbox.net are queue-4.15/trace-bpf-remove-helper-bpf_perf_prog_read_value-from-tracepoint-type-programs.patch queue-4.15/kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch queue-4.15/bpf-skip-unnecessary-capability-check.patch queue-4.15/bpf-x64-increase-number-of-passes.patch

7 years, 5 months

1
0
0 0

Patch "bpf: skip unnecessary capability check" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: skip unnecessary capability check to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bpf-skip-unnecessary-capability-check.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0fa4fe85f4724fff89b09741c437cbee9cf8b008 Mon Sep 17 00:00:00 2001 From: Chenbo Feng <fengc(a)google.com> Date: Mon, 19 Mar 2018 17:57:27 -0700 Subject: bpf: skip unnecessary capability check From: Chenbo Feng <fengc(a)google.com> commit 0fa4fe85f4724fff89b09741c437cbee9cf8b008 upstream. The current check statement in BPF syscall will do a capability check for CAP_SYS_ADMIN before checking sysctl_unprivileged_bpf_disabled. This code path will trigger unnecessary security hooks on capability checking and cause false alarms on unprivileged process trying to get CAP_SYS_ADMIN access. This can be resolved by simply switch the order of the statement and CAP_SYS_ADMIN is not required anyway if unprivileged bpf syscall is allowed. Signed-off-by: Chenbo Feng <fengc(a)google.com> Acked-by: Lorenzo Colitti <lorenzo(a)google.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/syscall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -1687,7 +1687,7 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf union bpf_attr attr = {}; int err; - if (!capable(CAP_SYS_ADMIN) && sysctl_unprivileged_bpf_disabled) + if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN)) return -EPERM; err = check_uarg_tail_zero(uattr, sizeof(attr), size); Patches currently in stable-queue which might be from fengc(a)google.com are queue-4.15/kbuild-disable-clang-s-default-use-of-fmerge-all-constants.patch queue-4.15/bpf-skip-unnecessary-capability-check.patch

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror