At several instances we iterate over all possible clock-bases for a particular
cpu-base. Whereas, we only need to iterate over active bases.
We already have per cpu-base 'active_bases' field which is updated on
addition/removal of hrtimers.
To prepare for this, first patch updates '->active_bases' before calling
hrtimer_force_reprogram(), otherwise kernel will throw NULL pointer dereference
errors and will crash.
Second patch creates for_each_active_base() and converts other routines to use
it.
git://git.linaro.org/people/viresh.kumar/linux.git cleanup-hrtimer-for-each-active
V1->V2:
- Added reviewed-by's from Preeti
- Merged 1/3 and 3/3 to form 2/2 as suggested by Frederic
- Added a coverletter as well..
Viresh Kumar (2):
hrtimer: update '->active_bases' before calling
hrtimer_force_reprogram()
hrtimer: create for_each_active_base() to iterate over active
clock-bases
kernel/hrtimer.c | 74 +++++++++++++++++++++++++++++---------------------------
1 file changed, 38 insertions(+), 36 deletions(-)
--
2.0.0.rc2
At several instances we iterate over all possible clock-bases for a particular
cpu-base. Whereas, we only need to iterate over active bases.
We already have per cpu-base 'active_bases' field which is updated on
addition/removal of hrtimers.
This patch creates for_each_active_base() which uses this existing
infrastructure to only iterate over active bases.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
Hi,
I am trying to upstream useful parts of my long cleanup series which never got
attention due to my bad approach. Please see if it looks fine, I will send it
upstream then.
It doesn't have anything to do with ONESHOT_STOPPED series :).
kernel/hrtimer.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 3ab2899..c751322 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -109,6 +109,19 @@ static inline int hrtimer_clockid_to_base(clockid_t clock_id)
/*
+ * for_each_active_base: iterate over all active clock bases
+ * @_index: 'int' variable for internal purpose
+ * @_base: holds pointer to a active clock base
+ * @_cpu_base: cpu base to iterate on
+ * @_active_bases: 'unsigned int' variable for internal purpose
+ */
+#define for_each_active_base(_index, _base, _cpu_base, _active_bases) \
+ for ((_active_bases) = (_cpu_base)->active_bases; \
+ (_index) = ffs(_active_bases), \
+ (_base) = (_cpu_base)->clock_base + (_index) - 1, (_index); \
+ (_active_bases) &= ~(1 << ((_index) - 1)))
+
+/*
* Get the coarse grained time at the softirq based on xtime and
* wall_to_monotonic.
*/
--
2.0.0.rc2
From: Mark Brown <broonie(a)linaro.org>
This is an interface intended for client drivers and exported but it is
not prototyped in the headers so can't be used. Add a prototype.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
include/linux/mailbox_client.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
index 53eb0784261b..cbfcf8478ca9 100644
--- a/include/linux/mailbox_client.h
+++ b/include/linux/mailbox_client.h
@@ -40,6 +40,7 @@ struct mbox_client {
struct mbox_chan *mbox_request_channel(const struct mbox_client *cl);
int mbox_send_message(struct mbox_chan *chan, void *mssg);
void mbox_client_txdone(struct mbox_chan *chan, int r);
+bool mbox_client_peek_data(struct mbox_chan *chan);
void mbox_free_channel(struct mbox_chan *chan);
#endif /* __MAILBOX_CLIENT_H */
--
2.0.0
Hi Tixy,
I have 2 new patches for you. Patch 1 is a bug I found on a
platform where all the little CPUs can be unplugged. Patch 2
is one that got missed during the initial LSK population. This
patch stops us giving Android services (started by init) an initial
boost to an A15 and lets them be scheduled as normal given the
tracked load. The main reason for this is so that when they allocate
timers etc, they are allocated on little CPUs.
Basil will send our test results out separately.
Best Regards,
Chris
Hi Mark, Alex
There is just one big.LITTLE MP patch for LSK this month. As you
probably saw [1] a second patch was triggering a (probably pre-existing)
problem and needs more time to investigate. So can you pull the other
patch into LSK? Thanks...
The following changes since commit d1df056f9e6dd9707037ed74621e170dfa8f4c52:
hmp: dont attempt to pull tasks if affinity doesn't allow it (2014-05-09 17:22:39 +0100)
are available in the git repository at:
https://git.linaro.org/arm/big.LITTLE/mp.git for-lsk
for you to fetch changes up to 4378062f289e67259f017f6b176ee385dc974836:
sched: hmp: fix out-of-range CPU possible (2014-06-11 15:08:35 +0100)
----------------------------------------------------------------
Chris Redpath (1):
sched: hmp: fix out-of-range CPU possible
kernel/sched/fair.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
[1] http://lists.linaro.org/pipermail/linaro-kernel/2014-June/015547.html
commit 6fffb5b47ea1a0f1267b5a218cdea2057cffc1aa
The value of ESR has been stored into x1, and should be directly pass to
do_sp_pc_abort function, "MOV x1, x25" is an extra operation and do_sp_pc_abort
will get the wrong value of ESR.
This patch is just confirmed by Catalin.
---
arch/arm64/kernel/entry.S | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index fa78916..56ef569 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -275,7 +275,6 @@ el1_sp_pc:
* Stack or PC alignment exception handling
*/
mrs x0, far_el1
- mov x1, x25
mov x2, sp
b do_sp_pc_abort
el1_undef:
Andy
Hi,
I am running lubuntu 14.04 with the latest Linaro kernel
(git.linaro.org/kernel/linux-linaro-tracking)
on arndale, I found once X is started ('xinit' is enough) , any one of
the following operations will
very easily cause kernel panic or hang,
(1) Ctrl+Alt+F1 and Alt+F7 switch between graphic mode and text mode;
(2) 'xinit' to start graphic mode, then 'exit' to quit graphic mode;
(3) After login into Lunbuntu desktop, switch user account to login;
The kernel is compiled by using the 'exynos_defconfig' and
'exynos5250-arndale.dts'.
Sometimes the kernel hang without any response, sometimes the kernel
panic with messages below,
[ 72.675919] Unable to handle kernel paging request at virtual address
72643d5
[ 72.676016] pgd = e8bdc000
[ 72.676055] [72643d45] *pgd=00000000
[ 72.676111] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 72.676181] Modules linked in:
[ 72.676231] CPU: 0 PID: 3840 Comm: udev-acl.ck Not tainted
3.15.0-rc8-dirty 2
[ 72.682703] task: e93b0c00 ti: e88fe000 task.ti: e88fe000
[ 72.688091] PC is at strnlen+0xc/0x54
[ 72.691733] LR is at string.isra.4+0x2c/0xcc
...
[<c01c63c0>] (strnlen) from [<c01c7f34>] (string.isra.4+0x2c/0xc)
[ 73.296125] [<c01c7f34>] (string.isra.4) from [<c01c92e4>]
(vsnprintf+0x180/)
[ 73.303676] [<c01c92e4>] (vsnprintf) from [<c01c9570>]
(sprintf+0x24/0x34)
[ 73.310536] [<c01c9570>] (sprintf) from [<c025f9fc>]
(uevent_show+0xcc/0x100)
[ 73.317651] [<c025f9fc>] (uevent_show) from [<c026004c>]
(dev_attr_show+0x20)
[ 73.325204] [<c026004c>] (dev_attr_show) from [<c0114ed0>]
(sysfs_kf_seq_sho)
[ 73.333276] [<c0114ed0>] (sysfs_kf_seq_show) from [<c0113cb4>]
(kernfs_seq_s)
[ 73.341522] [<c0113cb4>] (kernfs_seq_show) from [<c00d9670>]
(seq_read+0x1c0)
[ 73.349160] [<c00d9670>] (seq_read) from [<c00bb204>]
(vfs_read+0x9c/0x12c)
[ 73.356103] [<c00bb204>] (vfs_read) from [<c00bb3d0>]
(SyS_read+0x44/0x84)
[ 73.362961] [<c00bb3d0>] (SyS_read) from [<c000e420>]
(ret_fast_syscall+0x0/)
[ 73.370423] Code: e12fff1e e3510000 01a00001 012fff1e (e5d02000)
or sometimes with below,
[ 55.480788] Unable to handle kernel NULL pointer dereference ac
[ 55.480896] pgd = e9b84000
[ 55.480935] [0000026c] *pgd=00000000
[ 55.480991] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 55.481061] Modules linked in:
[ 55.481155] CPU: 1 PID: 3488 Comm: Xorg Not tainted 3.15.0-rc8-dirty #12
[ 55.487835] task: ea1aa400 ti: e8f54000 task.ti: e8f54000
[ 55.493222] PC is at evdev_poll+0x28/0x64
[ 55.497218] LR is at do_select+0x328/0x650
[ 55.501291] pc : [<c02eb088>] lr : [<c00cb2dc>] psr: 600f0013
[ 55.501291] sp : e8f55b30 ip : e9bc4900 fp : c02eb060
[ 55.512747] r10: e9bc4900 r9 : 00000000 r8 : 00003c00
[ 55.517955] r7 : 0000000e r6 : 00000016 r5 : 00000000 r4 : e9355000
[ 55.524465] r3 : 00000000 r2 : e8f55bb4 r1 : 00000028 r0 : e9bc4900
[ 55.530976] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment user
[ 55.538093] Control: 10c5387d Table: 69b8406a DAC: 00000015
...
[<c02eb088>] (evdev_poll) from [<c00cb2dc>] (do_select+0x328/0x6)
[ 56.505313] [<c00cb2dc>] (do_select) from [<c00cb754>]
(core_sys_select+0x15)
[ 56.513037] [<c00cb754>] (core_sys_select) from [<c00cb9d4>]
(SyS_select+0xc)
[ 56.520764] [<c00cb9d4>] (SyS_select) from [<c000e420>]
(ret_fast_syscall+0x)
[ 56.528397] Code: e2851028 e3530000 13750028 1a00000c (e5d5326c)
[ 56.534547] ---[ end trace 6b03dd550054bcfd ]---
Any suggestion on how to fix this is appreciated.
Cheers,
This is my second version of patchset for ftrace support.
Actually v1 was submitted serveral weeks ago, but is still moderated.
(Just ignore them for now.)
There is another implementation from Cavium network, but both works
are independent, and my code has additional system call trace support.
I confirmed that I could compile the patches on v3.12-rc4 by Linaro's
coming 2013.10 gcc (4.8.2), and that the kernel worked on Fast Model
with the following tracers:
function tracer with dynamic ftrace
function graph tracer with dynamic ftrace
syscall tracepoint
irqsoff & preemptirqsoff (which use CALLER_ADDRx)
Also verified with in-kernel tests, FTRACE_SELFTEST, FTRACE_STARTUP_TEST
and EVENT_TRACE_TEST_SYSCALLS.
Patch[3/6] has warnings from checkpatch, but they follow other arch's style.
Please be careful that host's elf.h must have AArch64 definitions,
EM_AARCH64 and R_AARCH64_ABS64, to build the kernel. See [4/6].
Issues
* Can we optimize register usages in asm (by not saving x0, x1 and x2)? [1/6]
* Do we need "fault protection" code in ftrace_modify_code()? [1/6]
It exists in x86 and other architectures, but not in arm.
* We may be able to use aarch64_insn_patch_text_nosync() instead of
ftrace_modify_code().[2/6] But the former function does not use
probe_kernel_write(). Is this safe?
Changes from v1 to v2:
* splitted one patch into some pieces for easier review
(especially function tracer + dynamic ftrace + CALLER_ADDRx)
* put return_address() in a separate file
* renamed __mcount to _mcount (it was my mistake)
* changed stackframe handling to get parent's frame pointer
* removed ARCH_SUPPORTS_FTRACE_OPS
* switched to "hotpatch" interfaces from Huawai
* revised descriptions in comments
AKASHI Takahiro (6):
arm64: Add ftrace support
arm64: ftrace: Add dynamic ftrace support
arm64: ftrace: Add CALLER_ADDRx macros
ftrace: Add arm64 support to recordmcount
arm64: ftrace: Add system call tracepoint
arm64: Add 'notrace' attribute to unwind_frame() for ftrace
arch/arm64/Kconfig | 6 +
arch/arm64/include/asm/ftrace.h | 54 +++++++++
arch/arm64/include/asm/syscall.h | 1 +
arch/arm64/include/asm/thread_info.h | 1 +
arch/arm64/include/asm/unistd.h | 2 +
arch/arm64/kernel/Makefile | 9 +-
arch/arm64/kernel/arm64ksyms.c | 4 +
arch/arm64/kernel/entry-ftrace.S | 211 ++++++++++++++++++++++++++++++++++
arch/arm64/kernel/entry.S | 1 +
arch/arm64/kernel/ftrace.c | 186 ++++++++++++++++++++++++++++++
arch/arm64/kernel/ptrace.c | 10 ++
arch/arm64/kernel/return_address.c | 55 +++++++++
arch/arm64/kernel/stacktrace.c | 2 +-
scripts/recordmcount.c | 4 +
scripts/recordmcount.pl | 5 +
15 files changed, 549 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/include/asm/ftrace.h
create mode 100644 arch/arm64/kernel/entry-ftrace.S
create mode 100644 arch/arm64/kernel/ftrace.c
create mode 100644 arch/arm64/kernel/return_address.c
--
1.7.9.5