linaro-kernel October 2012

linaro-kernel@lists.linaro.org

27 participants
28 discussions

[PATCH 0/7] KDB: Kiosk (reduced capabilities) mode

by Anton Vorontsov

Hello Jason, Just as promised, I'm resending the series after the merge window. This patchset implements "kiosk" mode for KDB debugger. The mode reduces kdb features, so that it is no longer possible to leak sensitive data via the debugger, and not possible to change program flow in a predefined manner by an ordinary user. Root can control the capability. There are a few patches, some are just cleanups, some are churn-ish cleanups, but inevitable. And the rest implements the mode -- after all the preparations, everything is pretty straightforward. Thanks! Anton. -- include/linux/kdb.h | 20 ++-- kernel/debug/kdb/kdb_bp.c | 24 ++--- kernel/debug/kdb/kdb_main.c | 189 ++++++++++++++++++---------------- kernel/debug/kdb/kdb_private.h | 3 +- kernel/trace/trace_kdb.c | 4 +- 5 files changed, 125 insertions(+), 115 deletions(-)

12 years, 2 months

[PATCH v10 0/4] ARM: KDB FIQ debugger

by Anton Vorontsov

Hello Russell, The KDB/NMI core support has been merged into v3.7-rc1, so the only ARM bits are pending now. I believe I addressed all your previous comments, but surely there might be something else to improve, thus would be great if you could take a look at this. The patches were rebased onto v3.7-rc1, and this is the only change in v10. Old changelogs and rationale for these patches can be found here: v1-v5, rationale: http://lkml.org/lkml/2012/9/10/2 v6: http://lkml.org/lkml/2012/9/10/2 v7: http://lkml.org/lkml/2012/9/13/367 v8: http://lkml.org/lkml/2012/9/19/525 v9: http://lkml.org/lkml/2012/9/24/538 Thanks! Anton. -- arch/arm/Kconfig | 19 ++++ arch/arm/common/vic.c | 28 +++++ arch/arm/include/asm/hardware/vic.h | 2 + arch/arm/include/asm/kgdb.h | 8 ++ arch/arm/kernel/Makefile | 1 + arch/arm/kernel/entry-armv.S | 167 +--------------------------- arch/arm/kernel/entry-header.S | 170 +++++++++++++++++++++++++++++ arch/arm/kernel/kgdb_fiq.c | 124 +++++++++++++++++++++ arch/arm/kernel/kgdb_fiq_entry.S | 87 +++++++++++++++ arch/arm/mach-versatile/Makefile | 1 + arch/arm/mach-versatile/kgdb_fiq.c | 31 ++++++ 11 files changed, 472 insertions(+), 166 deletions(-)

12 years, 2 months

[PATCH 0/5] Fix thermal bugs and Upstream ST-Ericsson thermal driver

by hongbo.zhang

From: "hongbo.zhang" <hongbo.zhang(a)linaro.com> Hi all, This patch set is to upstream ST-Ericsson thermal driver and fix some bugs of thermal layer at the same time. All of these patches are based on v3.7-rc1. [PATCH 1/5] Thermal: do bind operation after thermal zone or cooling device register returns. In the previous bind function, cdev->get_max_state(cdev, &max_state) is called before the registration function finishes, but at this moment, the parameter cdev at thermal driver layer isn't ready--it will get ready only after its registration, so the the get_max_state callback cannot tell the max_state according to the cdev input. This problem can be fixed by separating the bind operation out of registration and doing it when registration completely finished. There is no such problem with the current exynos thermal driver because it regsters cooling device before thermal zone device. As a generic thermal layer any sequence should be supported, thermal zone first or cooling device first, this will be also helpful to add/remove cooling device dynamically. [PATCH 2/5] Thermal: add indent for code alignment. [PATCH 3/5] Thermal: fix empty list checking method. [PATCH 4/5] Thermal: make sure cpufreq cooling register after cpufreq driver Bug fix for generic cpufreq cooling layer as described in the commit logs. [PATCH 5/5] Thermal: Add ST-Ericsson db8500 thermal dirver. This patch is to add ST-Ericsson into the latest kervel version. hongbo.zhang (5): Thermal: do bind operation after thermal zone or cooling device register returns. Thermal: add indent for code alignment. Thermal: fix empty list checking method. Thermal: make sure cpufreq cooling register after cpufreq driver Thermal: Add ST-Ericsson db8500 thermal dirver. arch/arm/boot/dts/dbx5x0.dtsi | 11 + arch/arm/configs/u8500_defconfig | 4 + arch/arm/mach-ux500/board-mop500.c | 73 ++++ drivers/thermal/Kconfig | 20 ++ drivers/thermal/Makefile | 2 + drivers/thermal/cpu_cooling.c | 19 +- drivers/thermal/db8500_cpufreq_cooling.c | 118 +++++++ drivers/thermal/db8500_thermal.c | 507 +++++++++++++++++++++++++++ drivers/thermal/thermal_sys.c | 86 +++-- include/linux/platform_data/db8500_thermal.h | 39 +++ 10 files changed, 847 insertions(+), 32 deletions(-) create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c create mode 100644 drivers/thermal/db8500_thermal.c create mode 100644 include/linux/platform_data/db8500_thermal.h -- 1.7.11.3

12 years, 2 months

Do spinlocks really need DMB?

by Peter Fordham

Hi, I'm working with a dual Cortex-A9 system and I've been trying to understand exactly why spinlock functions need to use DMB. It seems that as long as the merging store buffer is flushed the lock value should end up in the L1 on the unlocking core and the SCU should either invalidate or update the value in the L1 of the other core. This is enough to maintain coherency and safe locking right? And doesn't STREX skip the merging store buffer anyway, meaning we don't even need the flush? DMB appears to be something of a blunt hammer, especially since it defaults to the system domain, which likely means a write all the way to main memory, which can be expensive. Are the DMBs in the locks there as a workaround for drivers that don't use smp_mb properly? I'm currently seeing, based on the performance counters, about 5% of my system cycles disappearing in stalls caused by DMB. -Pete

12 years, 2 months

[ACTIVITY] (Anton Vorontsov) 2012-10-08 - 2012-10-26

by Anton Vorontsov

== Highlights == * Got some positive reviews from Mel Gorman on the first RFC of vmevent pressure attribute. Fixed most of implementation comments; * Prepared and sent the second RFC of the pressure attribute support. The new patch integrates Minchan's and Mel's ideas of using discrete pressure levels. Also, now we use reclaimer's priority to detect pre-OOM conditions. The second RFC got some positive feedback from Minchan and Pekka; * Sent accuracy improvements for the vmevent_fd (this fixes a long standing issue noticed by Kosaki Motohiro); * vmevent_fd cleanups were merged into Pekka Enberg's tree; * All the pstore debugfs reworks landed into v3.7-rc1; * Prepared two set of slides for the upcoming Connect: status updates for my items, plus some generic notes on upstreaming; * Resent ARM KDB FIQ support patches, ARM FIQ cleanups and KDB Kiosk mode patches. Still no feedback; * Got some very nice patches for pstore: MMC backend and a tasklist dumper; briefly reviewed the patches, and hopefully they'll be merged in v3.8.

12 years, 2 months

[RFC v2 0/2] vmevent: A bit reworked pressure attribute + docs + man page

by Anton Vorontsov

Hi all, So this is the second RFC. The main change is that I decided to go with discrete levels of the pressure. When I started writing the man page, I had to describe the 'reclaimer inefficiency index', and while doing this I realized that I'm describing how the kernel is doing the memory management, which we try to avoid in the vmevent. And applications don't really care about these details: reclaimers, its inefficiency indexes, scanning window sizes, priority levels, etc. -- it's all "not interesting", and purely kernel's stuff. So I guess Mel Gorman was right, we need some sort of levels. What applications (well, activity managers) are really interested in is this: 1. Do we we sacrifice resources for new memory allocations (e.g. files cache)? 2. Does the new memory allocations' cost becomes too high, and the system hurts because of this? 3. Are we about to OOM soon? And here are the answers: 1. VMEVENT_PRESSURE_LOW 2. VMEVENT_PRESSURE_MED 3. VMEVENT_PRESSURE_OOM There is no "high" pressure, since I really don't see any definition of it, but it's possible to introduce new levels without breaking ABI. The levels described in more details in the patches, and the stuff is still tunable, but now via sysctls, not the vmevent_fd() call itself (i.e. we don't need to rebuild applications to adjust window size or other mm "details"). What I couldn't fix in this RFC is making vmevent_{scanned,reclaimed} stuff per-CPU (there's a comment describing the problem with this). But I made it lockless and tried to make it very lightweight (plus I moved the vmevent_pressure() call to a more "cold" path). Thanks, Anton.

12 years, 2 months

[ACTIVITY] (Linus Walleij) 2012-09-15 - 2012-09-23

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Drilled into the RCU lockup. With some help from Paul McKenney we got a task dump from CPU0 (the CPU that is locking) but not much more - only the swapper thread is running there and we need to dump its stack. * Puffed and pinged on the SPARSE_IRQ patch, yet no reaction so far. * Mainlining some stuff in the PL011 driver that has been sitting internally for some time. Easy stuff went in first and then we ran into the trickier patches - some odd baudrates are impossible since th TTY layer will "snap" the baudrate to a standard baudrate from a table if it's "close enough". We used to work around this by not calling out to the TTY layer in the PL011 driver for certain baudrates, but this is duct-taping. Still debating the real solution with Alan Cox and Russell King who help out a lot. * Reviewed and merged various GPIO patches. * Reviewed and merged various pinctrl patches. * Reviewed some ux500 patches coming from Lee. * Reviewed Arnd's iomem cleanups. * Sent out Patrice Chotard's pinctrl patch for the PL022 SPI driver, Mark has merged it. === Plans === * Ongoing work on sparse IRQ for Nomadik and Ux500. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Look into regmap. Try something out, get to know it. === Issues === * N/A Thanks, Linus Walleij

12 years, 3 months

Connect session: "Kernel Development with Linaro CI and LAVA"

by Michael Hudson-Doyle

Hi all, We'd like to let you know about a session at Connect: http://summit.linaro.org/lce12/meeting/21231/kernel-development-with-linaro… We want to make your jobs easier -- let us know how! Cheers, mwh

12 years, 3 months

[ACTIVITY] (Linus Walleij) 2012-10-13 - 2012-10-22

by Linus Walleij

== Linus Walleij linusw == I realized that my [ACTIVITY] report appears to trigger everyone else to send theirs so when I missed mine, no reports came in, sorry! Here it goes, a weekend late, but still probably the first one. === Highlights === * SPARSE_IRQ patch set for Ux500 ready and rolling, now ready to look at multiplatform for Ux500. * Reviewed and merged some GPIO patches, wrote some GPIO driver patches trying to clean out some irqdomain business, mainly because I don't fully understand the semantics of that API myself. Now I think I do. * Wrote a few U300 patches cleaning up some pinctrl business (irqdomains, nocheinmal). * Again debated issues around runtime PM / suspend and resume proper in the different drivers. We have planned a runtime PM session @connect with Ulf and Amit. * Some heavy lifting as internal adivisor and reviewer of the pinctrl switch for the company. === Plans === * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Look into regmap. Try something out, get to know it. === Issues === N/A Thanks, Linus Walleij

12 years, 3 months

linker error when using modulo operator in kernel

by Venkatraman S

After making some patch which adds a x = y % z statement in kernel, I get this linker error when trying to compile for Pandboard (omap2plus) undefined reference to `__aeabi_uldivmod' make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2 Simple search revealed that it's been reported before in linaro gcc and upstream gcc as well. https://bugs.launchpad.net/gcc-linaro/+bug/771832 -> still not resolved. I'm surprised that kernel doesn't use modulo for unsigned long anywhere else except in my patch. Has anyone else seen this or some weird issue in my (typical desktop) setup ? Any workarounds ? TIA, Venkat.

12 years, 3 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel October 2012