Re: mmotm 2014-10-02-16-22 uploaded
On Thu, Oct 02, 2014 at 04:22:52PM -0700, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2014-10-02-16-22 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > Build summary: total: 133 pass: 127 fail: 6 Failed builds: arm:cm_x2xx_defconfig avr32:defconfig m68k:allmodconfig mn10300:asb2303_defconfig sparc64:allmodconfig um:defconfig Qemu tests: total: 26 pass: 26 fail: 0 --- avr32:defconfig has a new build failure. drivers/input/leds.o: In function `init_module': leds.c:(.init.text+0x0): multiple definition of `init_module' drivers/input/input.o:input.c:(.init.text+0x0): first defined here drivers/input/leds.o: In function `cleanup_module': leds.c:(.exit.text+0x0): multiple definition of `cleanup_module' drivers/input/input.o:input.c:(.exit.text+0x0): first defined here make[2]: *** [drivers/input/input-core.o] Error 1 --- powerpc qemu tests create a number of tracebacks, all similar to the following. [ cut here ] WARNING: at kernel/workqueue.c:1360 Modules linked in: CPU: 0 PID: 32 Comm: kadbprobe Not tainted 3.17.0-rc7-mm1-yocto-standard+ #1 task: c79f29a0 ti: c7ac2000 task.ti: c7ac2000 NIP: c0045274 LR: c004533c CTR: c04af658 REGS: c7ac3ae0 TRAP: 0700 Not tainted (3.17.0-rc7-mm1-yocto-standard+) MSR: 00021032 CR: 82008082 XER: GPR00: c004533c c7ac3b90 c79f29a0 0001 c099c140 c090 GPR08: 0001 0002 82008082 c004bdd8 c79d1a20 GPR16: 0003 c79daa5c 0001 c08e89e4 GPR24: c08e7fa4 c08f784c c7ac2000 c099c144 c781cc00 c0aab500 c099c140 NIP [c0045274] __queue_work+0xf8/0x3e8 LR [c004533c] __queue_work+0x1c0/0x3e8 Call Trace: [c7ac3b90] [c004533c] __queue_work+0x1c0/0x3e8 (unreliable) [c7ac3bc0] [c00455cc] queue_work_on+0x68/0x88 [c7ac3bd0] [c05113dc] led_trigger_event+0x4c/0xa8 [c7ac3bf0] [c0434660] kbd_ledstate_trigger_activate+0x7c/0xa4 [c7ac3c00] [c0511594] led_trigger_set+0x15c/0x1dc [c7ac3c30] [c0511840] led_trigger_set_default+0x90/0xd4 [c7ac3c50] [c0511004] led_classdev_register+0x108/0x12c [c7ac3c60] [c04af8fc] input_led_connect+0xd4/0x250 [c7ac3ca0] [c04ac350] input_register_device+0x42c/0x4b4 [c7ac3cc0] [c045ecac] adbhid_input_register+0x4e0/0x62c [c7ac3d00] [c045eea0] adbhid_input_reregister+0xa8/0xac [c7ac3d20] [c045efdc] adbhid_probe+0x138/0x4fc [c7ac3de0] [c045f860] adb_message_handler+0x30/0xec [c7ac3e00] [c004ceb8] notifier_call_chain+0x78/0xc0 [c7ac3e20] [c004d424] __blocking_notifier_call_chain+0x5c/0x80 [c7ac3e40] [c0460eb0] do_adb_reset_bus+0x11c/0x3c4 [c7ac3ee0] [c0461180] adb_probe_task+0x28/0x58 [c7ac3ef0] [c004bea0] kthread+0xc8/0xdc [c7ac3f40] [c00106fc] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 419e019c 3f40c08f 3b5a784c 813a0018 2f89 419d021c 813f0004 3b9f0004 7f894a78 7d290034 5529d97e 69290001 <0f09> 2f89 409e008c 80be0008 ---[ end trace 76dca08f6b486638 ]--- --- Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the target-updates tree
Hi Nicholas,
After merging the target-updates tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/target/target_core_user.c: In function 'tcmu_netlink_event':
drivers/target/target_core_user.c:780:2: error: expected ';' before 'ret'
ret = nla_put_u32(skb, TCMU_ATTR_MINOR, minor);
^
Caused by commit 7f2ea21b2c8d ("target/user: Fix up smatch warnings in
tcmu_netlink_event").
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[GIT PULL REQUEST] one last-minute update for md/raid5
Hi Linus,
I hope this is in time for 3.17...
It turns out that 'discard_zeroes_data' is not a guarantee, and RAID4/5/6
really depends on it for DISCARD to be handled safely.
So it is safest to default to disabling DISCARD on these arrays until some
sort of whitelist arrangement can be found.
Thanks,
NeilBrown
The following changes since commit fe82dcec644244676d55a1384c958d5f67979adb:
Linux 3.17-rc7 (2014-09-28 14:29:07 -0700)
are available in the git repository at:
git://neil.brown.name/md tags/md/3.17-final-fix
for you to fetch changes up to 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93:
md/raid5: disable 'DISCARD' by default due to safety concerns. (2014-10-02
13:45:00 +1000)
One fix for raid5 discard issue.
NeilBrown (1):
md/raid5: disable 'DISCARD' by default due to safety concerns.
drivers/md/raid5.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
commit 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93
Author: NeilBrown
Date: Thu Oct 2 13:45:00 2014 +1000
md/raid5: disable 'DISCARD' by default due to safety concerns.
It has come to my attention (thanks Martin) that 'discard_zeroes_data'
is only a hint. Some devices in some cases don't do what it
says on the label.
The use of DISCARD in RAID5 depends on reads from discarded regions
being predictably zero. If a write to a previously discarded region
performs a read-modify-write cycle it assumes that the parity block
was consistent with the data blocks. If all were zero, this would
be the case. If some are and some aren't this would not be the case.
This could lead to data corruption after a device failure when
data needs to be reconstructed from the parity.
As we cannot trust 'discard_zeroes_data', ignore it by default
and so disallow DISCARD on all raid4/5/6 arrays.
As many devices are trustworthy, and as there are benefits to using
DISCARD, add a module parameter to over-ride this caution and cause
DISCARD to work if discard_zeroes_data is set.
If a site want to enable DISCARD on some arrays but not on others they
should select DISCARD support at the filesystem level, and set the
raid456 module parameter.
raid456.devices_handle_discard_safely=Y
As this is a data-safety issue, I believe this patch is suitable for
-stable.
DISCARD support for RAID456 was added in 3.7
Cc: Shaohua Li
Cc: "Martin K. Petersen"
Cc: Mike Snitzer
Cc: Heinz Mauelshagen
Cc: sta...@vger.kernel.org (3.7+)
Acked-by: Martin K. Petersen
Acked-by: Mike Snitzer
Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637
Signed-off-by: NeilBrown
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 183588b11fc1..9f0fbecd1eb5 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -64,6 +64,10 @@
#define cpu_to_group(cpu) cpu_to_node(cpu)
#define ANY_GROUP NUMA_NO_NODE
+static bool devices_handle_discard_safely = false;
+module_param(devices_handle_discard_safely, bool, 0644);
+MODULE_PARM_DESC(devices_handle_discard_safely,
+"Set to Y if all devices in each array reliably return zeroes
on reads from discarded regions");
static struct workqueue_struct *raid5_wq;
/*
* Stripe cache
@@ -6208,7 +6212,7 @@ static int run(struct mddev *mddev)
mddev->queue->limits.discard_granularity = stripe;
/*
* unaligned part of discard request will be ignored, so can't
-* guarantee discard_zerors_data
+* guarantee discard_zeroes_data
*/
mddev->queue->limits.discard_zeroes_data = 0;
@@ -6233,6 +6237,18 @@ static int run(struct mddev *mddev)
!bdev_get_queue(rdev->bdev)->
limits.discard_zeroes_data)
discard_supported = false;
+ /* Unfortunately, discard_zeroes_data is not currently
+* a guarantee - just a hint. So we only allow DISCARD
+* if the sysadmin has confirmed that only safe devices
+* are in use by setting a module parameter.
+*/
+ if (!devices_handle_discard_safely) {
+ if (discard_supported) {
+ pr_info("md/raid456: discard support
disabled due to uncertainty.\n");
+ pr_info("Set
raid456.devices_handle_discard_safely=Y to override.\n");
+ }
+ discard_supported = false;
+ }
}
if (discard_supported &&
pgpO2JWWEJGiv.pgp
Description: OpenPGP digital
[tip:sched/core] sched/x86: Fix up typo in topology detection
Commit-ID: 728e5653e6fdb2a0892e94a600aef8c9a036c7eb
Gitweb: http://git.kernel.org/tip/728e5653e6fdb2a0892e94a600aef8c9a036c7eb
Author: Dave Hansen
AuthorDate: Tue, 30 Sep 2014 14:45:46 -0700
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 05:46:52 +0200
sched/x86: Fix up typo in topology detection
Commit:
cebf15eb09a2 ("x86, sched: Add new topology for multi-NUMA-node CPUs")
some code to try to detect the situation where we have a NUMA node
inside of the "DIE" sched domain.
It detected this by looking for cpus which match_die() but do not match
NUMA nodes via topology_same_node().
I wrote it up as:
if (match_die(c, o) == !topology_same_node(c, o))
which actually seemed to work some of the time, albiet
accidentally.
It should have been doing an &&, not an ==.
This code essentially chopped off the "DIE" domain on one of
Andrew Morton's systems. He reported that this patch fixed his
issue.
Signed-off-by: Dave Hansen
Reported-by: Andrew Morton
Signed-off-by: Peter Zijlstra (Intel)
Cc: Dave Hansen
Cc: Andrew Morton
Cc: David Rientjes
Cc: Igor Mammedov
Cc: Jan Kiszka
Cc: Lan Tianyu
Cc: Linus Torvalds
Cc: Prarit Bhargava
Cc: Toshi Kani
Link: http://lkml.kernel.org/r/20140930214546.fd481...@viggo.jf.intel.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/smpboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 8de8eb7..bae9e09 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -445,7 +445,7 @@ void set_cpu_sibling_map(int cpu)
} else if (i != cpu && !c->booted_cores)
c->booted_cores = cpu_data(i).booted_cores;
}
- if (match_die(c, o) == !topology_same_node(c, o))
+ if (match_die(c, o) && !topology_same_node(c, o))
primarily_use_numa_for_topology();
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf/x86/intel/uncore: Fix minor race in box set up
Commit-ID: 4f971248bc6ad2bb2a89a25a072ebfec5757d298
Gitweb: http://git.kernel.org/tip/4f971248bc6ad2bb2a89a25a072ebfec5757d298
Author: Andi Kleen
AuthorDate: Mon, 22 Sep 2014 15:27:06 -0700
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 06:02:49 +0200
perf/x86/intel/uncore: Fix minor race in box set up
I was looking for the trinity oops cause in the uncore driver.
(so far didn't found it)
However I found this tiny race: when a box is set up two threads on the
same CPU, they may be setting up the box in parallel (e.g. with kernel
preemption). This could lead to the reference count being increasing
too much. Always recheck there is no existing cpu reference inside the lock.
Signed-off-by: Andi Kleen
Signed-off-by: Peter Zijlstra (Intel)
Cc: eran...@google.com
Cc: Arnaldo Carvalho de Melo
Link:
http://lkml.kernel.org/r/1411424826-15629-1-git-send-email-a...@firstfloor.org
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 42d00e5..9762dbd 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -42,6 +42,9 @@ struct intel_uncore_box *uncore_pmu_to_box(struct
intel_uncore_pmu *pmu, int cpu
return box;
raw_spin_lock(_box_lock);
+ /* Recheck in lock to handle races. */
+ if (*per_cpu_ptr(pmu->box, cpu))
+ goto out;
list_for_each_entry(box, >box_list, list) {
if (box->phys_id == topology_physical_package_id(cpu)) {
atomic_inc(>refcnt);
@@ -49,6 +52,7 @@ struct intel_uncore_box *uncore_pmu_to_box(struct
intel_uncore_pmu *pmu, int cpu
break;
}
}
+out:
raw_spin_unlock(_box_lock);
return *per_cpu_ptr(pmu->box, cpu);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:locking/core] locking/lockdep: Revert qrwlock recusive stuff
Commit-ID: 8acd91e8620836a56ff62028ed28ba629f2881a0
Gitweb: http://git.kernel.org/tip/8acd91e8620836a56ff62028ed28ba629f2881a0
Author: Peter Zijlstra
AuthorDate: Tue, 30 Sep 2014 15:26:00 +0200
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 06:09:30 +0200
locking/lockdep: Revert qrwlock recusive stuff
Commit f0bab73cb539 ("locking/lockdep: Restrict the use of recursive
read_lock() with qrwlock") changed lockdep to try and conform to the
qrwlock semantics which differ from the traditional rwlock semantics.
In particular qrwlock is fair outside of interrupt context, but in
interrupt context readers will ignore all fairness.
The problem modeling this is that read and write side have different
lock state (interrupts) semantics but we only have a single
representation of these. Therefore lockdep will get confused, thinking
the lock can cause interrupt lock inversions.
So revert it for now; the old rwlock semantics were already imperfectly
modeled and the qrwlock extra won't fit either.
If we want to properly fix this, I think we need to resurrect the work
by Gautham did a few years ago that split the read and write state of
locks:
http://lwn.net/Articles/332801/
FWIW the locking selftest that would've failed (and was reported by
Borislav earlier) is something like:
RL(X1); /* IRQ-ON */
LOCK(A);
UNLOCK(A);
RU(X1);
IRQ_ENTER();
RL(X1); /* IN-IRQ */
RU(X1);
IRQ_EXIT();
At which point it would report that because A is an IRQ-unsafe lock we
can suffer the following inversion:
CPU0CPU1
lock(A)
lock(X1)
lock(A)
lock(X1)
And this is 'wrong' because X1 can recurse (assuming the above lock are
in fact read-lock) but lockdep doesn't know about this.
Signed-off-by: Peter Zijlstra (Intel)
Cc: Waiman Long
Cc: e...@linux.vnet.ibm.com
Cc: b...@alien8.de
Cc: Linus Torvalds
Cc: Paul E. McKenney
Link:
http://lkml.kernel.org/r/20140930132600.ga7...@worktop.programming.kicks-ass.net
Signed-off-by: Ingo Molnar
---
include/linux/lockdep.h | 10 +
kernel/locking/lockdep.c | 6 --
lib/locking-selftest.c | 56 ++--
3 files changed, 8 insertions(+), 64 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index b5a84b62..f388481 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -478,24 +478,16 @@ static inline void print_irqtrace_events(struct
task_struct *curr)
* on the per lock-class debug mode:
*/
-/*
- * Read states in the 2-bit held_lock:read field:
- * 0: Exclusive lock
- * 1: Shareable lock, cannot be recursively called
- * 2: Shareable lock, can be recursively called
- * 3: Shareable lock, cannot be recursively called except in interrupt context
- */
#define lock_acquire_exclusive(l, s, t, n, i) lock_acquire(l, s, t,
0, 1, n, i)
#define lock_acquire_shared(l, s, t, n, i) lock_acquire(l, s, t,
1, 1, n, i)
#define lock_acquire_shared_recursive(l, s, t, n, i) lock_acquire(l, s, t,
2, 1, n, i)
-#define lock_acquire_shared_irecursive(l, s, t, n, i) lock_acquire(l, s, t,
3, 1, n, i)
#define spin_acquire(l, s, t, i) lock_acquire_exclusive(l, s, t,
NULL, i)
#define spin_acquire_nest(l, s, t, n, i) lock_acquire_exclusive(l, s, t,
n, i)
#define spin_release(l, n, i) lock_release(l, n, i)
#define rwlock_acquire(l, s, t, i) lock_acquire_exclusive(l, s, t,
NULL, i)
-#define rwlock_acquire_read(l, s, t, i)
lock_acquire_shared_irecursive(l, s, t, NULL, i)
+#define rwlock_acquire_read(l, s, t, i)
lock_acquire_shared_recursive(l, s, t, NULL, i)
#define rwlock_release(l, n, i)lock_release(l, n, i)
#define seqcount_acquire(l, s, t, i) lock_acquire_exclusive(l, s, t,
NULL, i)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 420ba68..88d0d44 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3597,12 +3597,6 @@ void lock_acquire(struct lockdep_map *lock, unsigned int
subclass,
raw_local_irq_save(flags);
check_flags(flags);
- /*
-* An interrupt recursive read in interrupt context can be considered
-* to be the same as a recursive read from checking perspective.
-*/
- if ((read == 3) && in_interrupt())
- read = 2;
current->lockdep_recursion = 1;
trace_lock_acquire(lock, subclass, trylock, read, check, nest_lock, ip);
__lock_acquire(lock, subclass, trylock, read, check,
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index 62af709..872a15a 100644
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -267,46 +267,19 @@ GENERATE_TESTCASE(AA_rsem)
#undef E
/*
- * Special-case for read-locking, they are not allowed to
- * recurse on the same lock class except under
[tip:locking/core] locking/rwsem: Avoid double checking before try acquiring write lock
Commit-ID: debfab74e453f079cd8b12b0604387a8c510ef3a
Gitweb: http://git.kernel.org/tip/debfab74e453f079cd8b12b0604387a8c510ef3a
Author: Jason Low
AuthorDate: Tue, 16 Sep 2014 17:16:57 -0700
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 06:09:29 +0200
locking/rwsem: Avoid double checking before try acquiring write lock
Commit 9b0fc9c09f1b ("rwsem: skip initial trylock in rwsem_down_write_failed")
checks for if there are known active lockers in order to avoid write trylocking
using expensive cmpxchg() when it likely wouldn't get the lock.
However, a subsequent patch was added such that we directly
check for sem->count == RWSEM_WAITING_BIAS right before trying
that cmpxchg().
Thus, commit 9b0fc9c09f1b now just adds overhead.
This patch modifies it so that we only do a check for if
count == RWSEM_WAITING_BIAS.
Also, add a comment on why we do an "extra check" of count
before the cmpxchg().
Signed-off-by: Jason Low
Acked-by: Davidlohr Bueso
Signed-off-by: Peter Zijlstra (Intel)
Cc: Aswin Chandramouleeswaran
Cc: Chegu Vinod
Cc: Peter Hurley
Cc: Tim Chen
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/1410913017.2447.22.camel@j-VirtualBox
Signed-off-by: Ingo Molnar
---
kernel/locking/rwsem-xadd.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 12166ec..7628c3f 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -250,16 +250,18 @@ EXPORT_SYMBOL(rwsem_down_read_failed);
static inline bool rwsem_try_write_lock(long count, struct rw_semaphore *sem)
{
- if (!(count & RWSEM_ACTIVE_MASK)) {
- /* try acquiring the write lock */
- if (sem->count == RWSEM_WAITING_BIAS &&
- cmpxchg(>count, RWSEM_WAITING_BIAS,
- RWSEM_ACTIVE_WRITE_BIAS) == RWSEM_WAITING_BIAS) {
- if (!list_is_singular(>wait_list))
- rwsem_atomic_update(RWSEM_WAITING_BIAS, sem);
- return true;
- }
+ /*
+* Try acquiring the write lock. Check count first in order
+* to reduce unnecessary expensive cmpxchg() operations.
+*/
+ if (count == RWSEM_WAITING_BIAS &&
+ cmpxchg(>count, RWSEM_WAITING_BIAS,
+ RWSEM_ACTIVE_WRITE_BIAS) == RWSEM_WAITING_BIAS) {
+ if (!list_is_singular(>wait_list))
+ rwsem_atomic_update(RWSEM_WAITING_BIAS, sem);
+ return true;
}
+
return false;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:locking/arch] locking,arch: Use ACCESS_ONCE() instead of cast to volatile in atomic_read()
Commit-ID: 2291059c852706c6f5ffb400366042b7625066cd
Gitweb: http://git.kernel.org/tip/2291059c852706c6f5ffb400366042b7625066cd
Author: Pranith Kumar
AuthorDate: Tue, 23 Sep 2014 10:29:50 -0400
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 06:06:23 +0200
locking,arch: Use ACCESS_ONCE() instead of cast to volatile in atomic_read()
Use the much more reader friendly ACCESS_ONCE() instead of the cast to volatile.
This is purely a stylistic change.
Signed-off-by: Pranith Kumar
Acked-by: Jesper Nilsson
Acked-by: Hans-Christian Egtvedt
Acked-by: Max Filippov
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: linux-a...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1411482607-20948-1-git-send-email-bobby.pr...@gmail.com
Signed-off-by: Ingo Molnar
---
arch/alpha/include/asm/atomic.h| 4 ++--
arch/arm/include/asm/atomic.h | 2 +-
arch/arm64/include/asm/atomic.h| 4 ++--
arch/avr32/include/asm/atomic.h| 2 +-
arch/cris/include/asm/atomic.h | 2 +-
arch/frv/include/asm/atomic.h | 2 +-
arch/ia64/include/asm/atomic.h | 4 ++--
arch/m32r/include/asm/atomic.h | 2 +-
arch/m68k/include/asm/atomic.h | 2 +-
arch/mips/include/asm/atomic.h | 4 ++--
arch/parisc/include/asm/atomic.h | 4 ++--
arch/sh/include/asm/atomic.h | 2 +-
arch/sparc/include/asm/atomic_32.h | 2 +-
arch/sparc/include/asm/atomic_64.h | 4 ++--
arch/x86/include/asm/atomic.h | 2 +-
arch/x86/include/asm/atomic64_64.h | 2 +-
arch/xtensa/include/asm/atomic.h | 2 +-
include/asm-generic/atomic.h | 2 +-
18 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/atomic.h
index 6fbb53a..8f8eafb 100644
--- a/arch/alpha/include/asm/atomic.h
+++ b/arch/alpha/include/asm/atomic.h
@@ -17,8 +17,8 @@
#define ATOMIC_INIT(i) { (i) }
#define ATOMIC64_INIT(i) { (i) }
-#define atomic_read(v) (*(volatile int *)&(v)->counter)
-#define atomic64_read(v) (*(volatile long *)&(v)->counter)
+#define atomic_read(v) ACCESS_ONCE((v)->counter)
+#define atomic64_read(v) ACCESS_ONCE((v)->counter)
#define atomic_set(v,i)((v)->counter = (i))
#define atomic64_set(v,i) ((v)->counter = (i))
diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index 832f1cd..e22c119 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -27,7 +27,7 @@
* strex/ldrex monitor on some implementations. The reason we can use it for
* atomic_set() is the clrex or dummy strex done on every exception return.
*/
-#define atomic_read(v) (*(volatile int *)&(v)->counter)
+#define atomic_read(v) ACCESS_ONCE((v)->counter)
#define atomic_set(v,i)(((v)->counter) = (i))
#if __LINUX_ARM_ARCH__ >= 6
diff --git a/arch/arm64/include/asm/atomic.h b/arch/arm64/include/asm/atomic.h
index b83c325..7047051 100644
--- a/arch/arm64/include/asm/atomic.h
+++ b/arch/arm64/include/asm/atomic.h
@@ -35,7 +35,7 @@
* strex/ldrex monitor on some implementations. The reason we can use it for
* atomic_set() is the clrex or dummy strex done on every exception return.
*/
-#define atomic_read(v) (*(volatile int *)&(v)->counter)
+#define atomic_read(v) ACCESS_ONCE((v)->counter)
#define atomic_set(v,i)(((v)->counter) = (i))
/*
@@ -139,7 +139,7 @@ static inline int __atomic_add_unless(atomic_t *v, int a,
int u)
*/
#define ATOMIC64_INIT(i) { (i) }
-#define atomic64_read(v) (*(volatile long *)&(v)->counter)
+#define atomic64_read(v) ACCESS_ONCE((v)->counter)
#define atomic64_set(v,i) (((v)->counter) = (i))
#define ATOMIC64_OP(op, asm_op)
\
diff --git a/arch/avr32/include/asm/atomic.h b/arch/avr32/include/asm/atomic.h
index 83e980a..2d07ce1 100644
--- a/arch/avr32/include/asm/atomic.h
+++ b/arch/avr32/include/asm/atomic.h
@@ -19,7 +19,7 @@
#define ATOMIC_INIT(i) { (i) }
-#define atomic_read(v) (*(volatile int *)&(v)->counter)
+#define atomic_read(v) ACCESS_ONCE((v)->counter)
#define atomic_set(v, i) (((v)->counter) = i)
#define ATOMIC_OP_RETURN(op, asm_op, asm_con) \
diff --git a/arch/cris/include/asm/atomic.h b/arch/cris/include/asm/atomic.h
index 0033f9d..279766a 100644
--- a/arch/cris/include/asm/atomic.h
+++ b/arch/cris/include/asm/atomic.h
@@ -17,7 +17,7 @@
#define ATOMIC_INIT(i) { (i) }
-#define atomic_read(v) (*(volatile int *)&(v)->counter)
+#define atomic_read(v) ACCESS_ONCE((v)->counter)
#define atomic_set(v,i) (((v)->counter) = (i))
/* These should be written in asm but we do it in C for now. */
diff --git a/arch/frv/include/asm/atomic.h b/arch/frv/include/asm/atomic.h
index f6c3a16..102190a 100644
--- a/arch/frv/include/asm/atomic.h
+++ b/arch/frv/include/asm/atomic.h
@@ -31,7 +31,7 @@
*/
#define ATOMIC_INIT(i) { (i) }
-#define atomic_read(v) (*(volatile int
[tip:perf/core] perf/x86: Tone down kernel messages when the PMU check fails in a virtual environment
Commit-ID: cc6cd47e7395bc05c5077009808b820633eb3f18 Gitweb: http://git.kernel.org/tip/cc6cd47e7395bc05c5077009808b820633eb3f18 Author: Wei Huang AuthorDate: Wed, 24 Sep 2014 22:55:14 -0500 Committer: Ingo Molnar CommitDate: Fri, 3 Oct 2014 06:04:41 +0200 perf/x86: Tone down kernel messages when the PMU check fails in a virtual environment PMU checking can fail due to various reasons. On native machine, this is mostly caused by faulty hardware and it is reasonable to use KERN_ERR in reporting. However, when kernel is running on virtualized environment, this checking can fail if virtual PMU is not supported (e.g. KVM on AMD host). It is annoying to see an error message on splash screen, even though we know such failure is benign on virtualized environment. This patch checks if the kernel is running in a virtualized environment. If so, it will use KERN_INFO in reporting, which reduces the syslog priority of them. This patch was tested successfully on KVM. Signed-off-by: Wei Huang Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Link: http://lkml.kernel.org/r/1411617314-24659-1-git-send-email-...@redhat.com Signed-off-by: Ingo Molnar --- arch/x86/kernel/cpu/perf_event.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c index 918d75f..16c7302 100644 --- a/arch/x86/kernel/cpu/perf_event.c +++ b/arch/x86/kernel/cpu/perf_event.c @@ -243,7 +243,8 @@ static bool check_hw_exists(void) msr_fail: printk(KERN_CONT "Broken PMU hardware detected, using software events only.\n"); - printk(KERN_ERR "Failed to access perfctr msr (MSR %x is %Lx)\n", reg, val_new); + printk(boot_cpu_has(X86_FEATURE_HYPERVISOR) ? KERN_INFO : KERN_ERR + "Failed to access perfctr msr (MSR %x is %Lx)\n", reg, val_new); return false; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched: Improve sysbench performance by fixing spurious active migration
Commit-ID: 43f4d66637bc752e93a77ff2536474a5a3888442
Gitweb: http://git.kernel.org/tip/43f4d66637bc752e93a77ff2536474a5a3888442
Author: Vincent Guittot
AuthorDate: Wed, 1 Oct 2014 15:38:55 +0200
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 05:46:54 +0200
sched: Improve sysbench performance by fixing spurious active migration
Since commit caeb178c60f4 ("sched/fair: Make update_sd_pick_busiest() ...")
sd_pick_busiest returns a group that can be neither imbalanced nor overloaded
but is only more loaded than others. This change has been introduced to ensure
a better load balance in system that are not overloaded but as a side effect,
it can also generate useless active migration between groups.
Let take the example of 3 tasks on a quad cores system. We will always have an
idle core so the load balance will find a busiest group (core) whenever an ILB
is triggered and it will force an active migration (once above
nr_balance_failed threshold) so the idle core becomes busy but another core
will become idle. With the next ILB, the freshly idle core will try to pull the
task of a busy CPU.
The number of spurious active migration is not so huge in quad core system
because the ILB is not triggered so much. But it becomes significant as soon as
you have more than one sched_domain level like on a dual cluster of quad cores
where the ILB is triggered every tick when you have more than 1 busy_cpu
We need to ensure that the migration generate a real improveùent and will not
only move the avg_load imbalance on another CPU.
Before caeb178c60f4f93f1b45c0bc056b5cf6d217b67f, the filtering of such use
case was ensured by the following test in f_b_g:
if ((local->idle_cpus < busiest->idle_cpus) &&
busiest->sum_nr_running <= busiest->group_weight)
This patch modified the condition to take into account situation where busiest
group is not overloaded: If the diff between the number of idle cpus in 2
groups is less than or equal to 1 and the busiest group is not overloaded,
moving a task will not improve the load balance but just move it.
A test with sysbench on a dual clusters of quad cores gives the following
results:
command: sysbench --test=cpu --num-threads=5 --max-time=5 run
The HZ is 200 which means that 1000 ticks has fired during the test.
With Mainline, perf gives the following figures:
Samples: 727 of event 'sched:sched_migrate_task'
Event count (approx.): 727
Overhead Command Shared Object Symbol
... . ..
12.52% migration/1 [unknown] [.]
12.52% migration/5 [unknown] [.]
12.52% migration/7 [unknown] [.]
12.10% migration/6 [unknown] [.]
11.83% migration/0 [unknown] [.]
11.83% migration/3 [unknown] [.]
11.14% migration/4 [unknown] [.]
10.87% migration/2 [unknown] [.]
2.75% sysbench [unknown] [.]
0.83% swapper [unknown] [.]
0.55% ktps65090charge [unknown] [.]
0.41% mmcqd/1 [unknown] [.]
0.14% perf [unknown] [.]
With this patch, perf gives the following figures
Samples: 20 of event 'sched:sched_migrate_task'
Event count (approx.): 20
Overhead Command Shared Object Symbol
... . ..
80.00% sysbench [unknown] [.]
10.00% swapper [unknown] [.]
5.00% ktps65090charge [unknown] [.]
5.00% migration/1 [unknown] [.]
Signed-off-by: Vincent Guittot
Reviewed-by: Rik van Riel
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Link:
http://lkml.kernel.org/r/1412170735-5356-1-git-send-email-vincent.guit...@linaro.org
Signed-off-by: Ingo Molnar
---
kernel/sched/fair.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 10a5a28..dfdcbfd 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6436,13 +6436,14 @@ static struct sched_group *find_busiest_group(struct
lb_env *env)
if (env->idle == CPU_IDLE) {
/*
-* This cpu is idle. If the busiest group load doesn't
-* have more tasks than the number of available cpu's and
-* there is no imbalance between this and busiest group
-* wrt to idle cpu's, it is balanced.
+* This cpu is idle. If the busiest group is not overloaded
+* and there is no imbalance between this and busiest group
+* wrt idle cpus, it is balanced. The imbalance becomes
+* significant if the diff is greater than 1 otherwise we
+* might end up to just move the
[tip:sched/core] sched/fair: Delete resched_cpu() from idle_balance()
Commit-ID: 10a12983b3d437a6998b3845870e52c1c752c101
Gitweb: http://git.kernel.org/tip/10a12983b3d437a6998b3845870e52c1c752c101
Author: Kirill Tkhai
AuthorDate: Wed, 1 Oct 2014 01:04:44 +0400
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 05:46:56 +0200
sched/fair: Delete resched_cpu() from idle_balance()
We already reschedule env.dst_cpu in attach_tasks()->check_preempt_curr()
if this is necessary.
Furthermore, a higher priority class task may be current on dest rq,
we shouldn't disturb it.
Signed-off-by: Kirill Tkhai
Cc: Juri Lelli
Signed-off-by: Peter Zijlstra (Intel)
Link: http://lkml.kernel.org/r/20140930210441.5258.55054.stgit@localhost
Signed-off-by: Ingo Molnar
---
kernel/sched/fair.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index dfdcbfd..bd61cff 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6701,12 +6701,6 @@ more_balance:
local_irq_restore(flags);
- /*
-* some other cpu did the load balance for us.
-*/
- if (cur_ld_moved && env.dst_cpu != smp_processor_id())
- resched_cpu(env.dst_cpu);
-
if (env.flags & LBF_NEED_BREAK) {
env.flags &= ~LBF_NEED_BREAK;
goto more_balance;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched, time: Fix build error with 64 bit cputime_t on 32 bit systems
Commit-ID: 347abad981c1ef815ea5ba861adba6a8c6aa1580
Gitweb: http://git.kernel.org/tip/347abad981c1ef815ea5ba861adba6a8c6aa1580
Author: Rik van Riel
AuthorDate: Tue, 30 Sep 2014 15:59:47 -0400
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 05:46:55 +0200
sched, time: Fix build error with 64 bit cputime_t on 32 bit systems
On 32 bit systems cmpxchg cannot handle 64 bit values, so
some additional magic is required to allow a 32 bit system
with CONFIG_VIRT_CPU_ACCOUNTING_GEN=y enabled to build.
Make sure the correct cmpxchg function is used when doing
an atomic swap of a cputime_t.
Reported-by: Arnd Bergmann
Signed-off-by: Rik van Riel
Acked-by: Arnd Bergmann
Signed-off-by: Peter Zijlstra (Intel)
Cc: umgwanakikb...@gmail.com
Cc: fweis...@gmail.com
Cc: s...@redhat.com
Cc: lwood...@redhat.com
Cc: atheu...@redhat.com
Cc: o...@redhat.com
Cc: Andrew Morton
Cc: Benjamin Herrenschmidt
Cc: Heiko Carstens
Cc: Linus Torvalds
Cc: Martin Schwidefsky
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: linux...@de.ibm.com
Cc: linux-a...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Link: http://lkml.kernel.org/r/20140930155947.070cd...@annuminas.surriel.com
Signed-off-by: Ingo Molnar
---
arch/powerpc/include/asm/cputime.h| 2 ++
arch/s390/include/asm/cputime.h | 2 ++
include/asm-generic/cputime_jiffies.h | 2 ++
include/asm-generic/cputime_nsecs.h | 2 ++
kernel/sched/cputime.c| 29 +++--
5 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/cputime.h
b/arch/powerpc/include/asm/cputime.h
index 607559a..6c840ce 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -32,6 +32,8 @@ static inline void setup_cputime_one_jiffy(void) { }
typedef u64 __nocast cputime_t;
typedef u64 __nocast cputime64_t;
+#define cmpxchg_cputime(ptr, old, new) cmpxchg(ptr, old, new)
+
#ifdef __KERNEL__
/*
diff --git a/arch/s390/include/asm/cputime.h b/arch/s390/include/asm/cputime.h
index f65bd36..3001887 100644
--- a/arch/s390/include/asm/cputime.h
+++ b/arch/s390/include/asm/cputime.h
@@ -18,6 +18,8 @@
typedef unsigned long long __nocast cputime_t;
typedef unsigned long long __nocast cputime64_t;
+#define cmpxchg_cputime(ptr, old, new) cmpxchg64(ptr, old, new)
+
static inline unsigned long __div(unsigned long long n, unsigned long base)
{
#ifndef CONFIG_64BIT
diff --git a/include/asm-generic/cputime_jiffies.h
b/include/asm-generic/cputime_jiffies.h
index d5cb78f5..fe386fc 100644
--- a/include/asm-generic/cputime_jiffies.h
+++ b/include/asm-generic/cputime_jiffies.h
@@ -3,6 +3,8 @@
typedef unsigned long __nocast cputime_t;
+#define cmpxchg_cputime(ptr, old, new) cmpxchg(ptr, old, new)
+
#define cputime_one_jiffy jiffies_to_cputime(1)
#define cputime_to_jiffies(__ct) (__force unsigned long)(__ct)
#define cputime_to_scaled(__ct)(__ct)
diff --git a/include/asm-generic/cputime_nsecs.h
b/include/asm-generic/cputime_nsecs.h
index 4e81760..0419485 100644
--- a/include/asm-generic/cputime_nsecs.h
+++ b/include/asm-generic/cputime_nsecs.h
@@ -21,6 +21,8 @@
typedef u64 __nocast cputime_t;
typedef u64 __nocast cputime64_t;
+#define cmpxchg_cputime(ptr, old, new) cmpxchg64(ptr, old, new)
+
#define cputime_one_jiffy jiffies_to_cputime(1)
#define cputime_div(__ct, divisor) div_u64((__force u64)__ct, divisor)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 64492df..8394b1e 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -555,6 +555,23 @@ drop_precision:
}
/*
+ * Atomically advance counter to the new value. Interrupts, vcpu
+ * scheduling, and scaling inaccuracies can cause cputime_advance
+ * to be occasionally called with a new value smaller than counter.
+ * Let's enforce atomicity.
+ *
+ * Normally a caller will only go through this loop once, or not
+ * at all in case a previous caller updated counter the same jiffy.
+ */
+static void cputime_advance(cputime_t *counter, cputime_t new)
+{
+ cputime_t old;
+
+ while (new > (old = ACCESS_ONCE(*counter)))
+ cmpxchg_cputime(counter, old, new);
+}
+
+/*
* Adjust tick based cputime random precision against scheduler
* runtime accounting.
*/
@@ -599,16 +616,8 @@ static void cputime_adjust(struct task_cputime *curr,
utime = rtime - stime;
}
- /*
-* If the tick based count grows faster than the scheduler one,
-* the result of the scaling may go backward.
-* Let's enforce monotonicity.
-* Atomic exchange protects against concurrent cputime_adjust().
-*/
- while (stime > (rtime = ACCESS_ONCE(prev->stime)))
- cmpxchg(>stime, rtime, stime);
- while (utime > (rtime = ACCESS_ONCE(prev->utime)))
- cmpxchg(>utime, rtime, utime);
+ cputime_advance(>stime, stime);
+
[tip:sched/core] sched/dl: Use dl_bw_of() under rcu_read_lock_sched()
Commit-ID: f10e00f4bf360c36edbe6bf18a6c75b171cbe012
Gitweb: http://git.kernel.org/tip/f10e00f4bf360c36edbe6bf18a6c75b171cbe012
Author: Kirill Tkhai
AuthorDate: Tue, 30 Sep 2014 12:23:37 +0400
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 05:46:58 +0200
sched/dl: Use dl_bw_of() under rcu_read_lock_sched()
rq->rd is freed using call_rcu_sched(), so rcu_read_lock() to access it
is not enough. We should use either rcu_read_lock_sched() or preempt_disable().
Reported-by: Sasha Levin
Suggested-by: Peter Zijlstra
Signed-off-by: Kirill Tkhai
Fixes: 66339c31bc39 "sched: Use dl_bw_of() under RCU read lock"
Link: http://lkml.kernel.org/r/1412065417.20287.24.camel@tkhai
Signed-off-by: Ingo Molnar
---
kernel/sched/core.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b5349fe..c84bdc0 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5264,6 +5264,7 @@ static int sched_cpu_inactive(struct notifier_block *nfb,
{
unsigned long flags;
long cpu = (long)hcpu;
+ struct dl_bw *dl_b;
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_DOWN_PREPARE:
@@ -5271,15 +5272,19 @@ static int sched_cpu_inactive(struct notifier_block
*nfb,
/* explicitly allow suspend */
if (!(action & CPU_TASKS_FROZEN)) {
- struct dl_bw *dl_b = dl_bw_of(cpu);
bool overflow;
int cpus;
+ rcu_read_lock_sched();
+ dl_b = dl_bw_of(cpu);
+
raw_spin_lock_irqsave(_b->lock, flags);
cpus = dl_bw_cpus(cpu);
overflow = __dl_overflow(dl_b, cpus, 0, 0);
raw_spin_unlock_irqrestore(_b->lock, flags);
+ rcu_read_unlock_sched();
+
if (overflow)
return notifier_from_errno(-EBUSY);
}
@@ -7647,11 +7652,10 @@ static int sched_dl_global_constraints(void)
u64 runtime = global_rt_runtime();
u64 period = global_rt_period();
u64 new_bw = to_ratio(period, runtime);
+ struct dl_bw *dl_b;
int cpu, ret = 0;
unsigned long flags;
- rcu_read_lock();
-
/*
* Here we want to check the bandwidth not being set to some
* value smaller than the currently allocated bandwidth in
@@ -7662,25 +7666,27 @@ static int sched_dl_global_constraints(void)
* solutions is welcome!
*/
for_each_possible_cpu(cpu) {
- struct dl_bw *dl_b = dl_bw_of(cpu);
+ rcu_read_lock_sched();
+ dl_b = dl_bw_of(cpu);
raw_spin_lock_irqsave(_b->lock, flags);
if (new_bw < dl_b->total_bw)
ret = -EBUSY;
raw_spin_unlock_irqrestore(_b->lock, flags);
+ rcu_read_unlock_sched();
+
if (ret)
break;
}
- rcu_read_unlock();
-
return ret;
}
static void sched_dl_do_global(void)
{
u64 new_bw = -1;
+ struct dl_bw *dl_b;
int cpu;
unsigned long flags;
@@ -7690,18 +7696,19 @@ static void sched_dl_do_global(void)
if (global_rt_runtime() != RUNTIME_INF)
new_bw = to_ratio(global_rt_period(), global_rt_runtime());
- rcu_read_lock();
/*
* FIXME: As above...
*/
for_each_possible_cpu(cpu) {
- struct dl_bw *dl_b = dl_bw_of(cpu);
+ rcu_read_lock_sched();
+ dl_b = dl_bw_of(cpu);
raw_spin_lock_irqsave(_b->lock, flags);
dl_b->bw = new_bw;
raw_spin_unlock_irqrestore(_b->lock, flags);
+
+ rcu_read_unlock_sched();
}
- rcu_read_unlock();
}
static int sched_rt_global_validate(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf: Fix unclone_ctx() vs. locking
Commit-ID: 211de6eba8960521e2be450a7d07db85fba4604c
Gitweb: http://git.kernel.org/tip/211de6eba8960521e2be450a7d07db85fba4604c
Author: Peter Zijlstra
AuthorDate: Tue, 30 Sep 2014 19:23:08 +0200
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 05:41:06 +0200
perf: Fix unclone_ctx() vs. locking
The idiot who did 4a1c0f262f88 ("perf: Fix lockdep warning on process exit")
forgot to pay attention and fix all similar cases. Do so now.
In particular, unclone_ctx() must be called while holding ctx->lock,
therefore all such sites are broken for the same reason. Pull the
put_ctx() call out from under ctx->lock.
Reported-by: Sasha Levin
Probably-also-reported-by: Vince Weaver
Fixes: 4a1c0f262f88 ("perf: Fix lockdep warning on process exit")
Signed-off-by: Peter Zijlstra (Intel)
Cc: Paul Mackerras
Cc: Arnaldo Carvalho de Melo
Cc: Sasha Levin
Cc: Cong Wang
Cc: Linus Torvalds
Link:
http://lkml.kernel.org/r/20140930172308.gi4...@worktop.programming.kicks-ass.net
Signed-off-by: Ingo Molnar
---
kernel/events/core.c | 54 ++--
1 file changed, 31 insertions(+), 23 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index d640a8b..afdd9e1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -902,13 +902,23 @@ static void put_ctx(struct perf_event_context *ctx)
}
}
-static void unclone_ctx(struct perf_event_context *ctx)
+/*
+ * This must be done under the ctx->lock, such as to serialize against
+ * context_equiv(), therefore we cannot call put_ctx() since that might end up
+ * calling scheduler related locks and ctx->lock nests inside those.
+ */
+static __must_check struct perf_event_context *
+unclone_ctx(struct perf_event_context *ctx)
{
- if (ctx->parent_ctx) {
- put_ctx(ctx->parent_ctx);
+ struct perf_event_context *parent_ctx = ctx->parent_ctx;
+
+ lockdep_assert_held(>lock);
+
+ if (parent_ctx)
ctx->parent_ctx = NULL;
- }
ctx->generation++;
+
+ return parent_ctx;
}
static u32 perf_event_pid(struct perf_event *event, struct task_struct *p)
@@ -2210,6 +2220,9 @@ static void ctx_sched_out(struct perf_event_context *ctx,
static int context_equiv(struct perf_event_context *ctx1,
struct perf_event_context *ctx2)
{
+ lockdep_assert_held(>lock);
+ lockdep_assert_held(>lock);
+
/* Pinning disables the swap optimization */
if (ctx1->pin_count || ctx2->pin_count)
return 0;
@@ -2943,6 +2956,7 @@ static int event_enable_on_exec(struct perf_event *event,
*/
static void perf_event_enable_on_exec(struct perf_event_context *ctx)
{
+ struct perf_event_context *clone_ctx = NULL;
struct perf_event *event;
unsigned long flags;
int enabled = 0;
@@ -2974,7 +2988,7 @@ static void perf_event_enable_on_exec(struct
perf_event_context *ctx)
* Unclone this context if we enabled any event.
*/
if (enabled)
- unclone_ctx(ctx);
+ clone_ctx = unclone_ctx(ctx);
raw_spin_unlock(>lock);
@@ -2984,6 +2998,9 @@ static void perf_event_enable_on_exec(struct
perf_event_context *ctx)
perf_event_context_sched_in(ctx, ctx->task);
out:
local_irq_restore(flags);
+
+ if (clone_ctx)
+ put_ctx(clone_ctx);
}
void perf_event_exec(void)
@@ -3135,7 +3152,7 @@ errout:
static struct perf_event_context *
find_get_context(struct pmu *pmu, struct task_struct *task, int cpu)
{
- struct perf_event_context *ctx;
+ struct perf_event_context *ctx, *clone_ctx = NULL;
struct perf_cpu_context *cpuctx;
unsigned long flags;
int ctxn, err;
@@ -3169,9 +3186,12 @@ find_get_context(struct pmu *pmu, struct task_struct
*task, int cpu)
retry:
ctx = perf_lock_task_context(task, ctxn, );
if (ctx) {
- unclone_ctx(ctx);
+ clone_ctx = unclone_ctx(ctx);
++ctx->pin_count;
raw_spin_unlock_irqrestore(>lock, flags);
+
+ if (clone_ctx)
+ put_ctx(clone_ctx);
} else {
ctx = alloc_perf_context(pmu, task);
err = -ENOMEM;
@@ -7523,7 +7543,7 @@ __perf_event_exit_task(struct perf_event *child_event,
static void perf_event_exit_task_context(struct task_struct *child, int ctxn)
{
struct perf_event *child_event, *next;
- struct perf_event_context *child_ctx, *parent_ctx;
+ struct perf_event_context *child_ctx, *clone_ctx = NULL;
unsigned long flags;
if (likely(!child->perf_event_ctxp[ctxn])) {
@@ -7550,28 +7570,16 @@ static void perf_event_exit_task_context(struct
task_struct *child, int ctxn)
child->perf_event_ctxp[ctxn] = NULL;
/*
-* In order to avoid freeing: child_ctx->parent_ctx->task
-* under perf_event_context::lock, grab another reference.
[tip:perf/urgent] perf: Fix perf bug in fork()
Commit-ID: 9c2b9d30e28559a78c9e431cdd7f2c6bf5a9ee67
Gitweb: http://git.kernel.org/tip/9c2b9d30e28559a78c9e431cdd7f2c6bf5a9ee67
Author: Peter Zijlstra
AuthorDate: Mon, 29 Sep 2014 12:12:01 +0200
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 05:41:08 +0200
perf: Fix perf bug in fork()
Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by
calling perf_event_free_task() when failing sched_fork() we will not yet
have done the memset() on ->perf_event_ctxp[] and will therefore try and
'free' the inherited contexts, which are still in use by the parent
process.
This is bad and might explain some outstanding fuzzer failures ...
Suggested-by: Oleg Nesterov
Reported-by: Oleg Nesterov
Reported-by: Sylvain 'ythier' Hitier
Signed-off-by: Peter Zijlstra (Intel)
Cc: Aaron Tomlin
Cc: Andrew Morton
Cc: Arnaldo Carvalho de Melo
Cc: Daeseok Youn
Cc: David Rientjes
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Paul Mackerras
Cc: Rik van Riel
Cc: Vladimir Davydov
Cc:
Link: http://lkml.kernel.org/r/20140929101201.GE5430@worktop
Signed-off-by: Ingo Molnar
---
kernel/events/core.c | 4 +++-
kernel/fork.c| 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index afdd9e1..658f232 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7956,8 +7956,10 @@ int perf_event_init_task(struct task_struct *child)
for_each_task_context_nr(ctxn) {
ret = perf_event_init_context(child, ctxn);
- if (ret)
+ if (ret) {
+ perf_event_free_task(child);
return ret;
+ }
}
return 0;
diff --git a/kernel/fork.c b/kernel/fork.c
index 0cf9cdb..a91e47d 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1360,7 +1360,7 @@ static struct task_struct *copy_process(unsigned long
clone_flags,
goto bad_fork_cleanup_policy;
retval = audit_alloc(p);
if (retval)
- goto bad_fork_cleanup_policy;
+ goto bad_fork_cleanup_perf;
/* copy all the process information */
shm_init_task(p);
retval = copy_semundo(clone_flags, p);
@@ -1566,8 +1566,9 @@ bad_fork_cleanup_semundo:
exit_sem(p);
bad_fork_cleanup_audit:
audit_free(p);
-bad_fork_cleanup_policy:
+bad_fork_cleanup_perf:
perf_event_free_task(p);
+bad_fork_cleanup_policy:
#ifdef CONFIG_NUMA
mpol_put(p->mempolicy);
bad_fork_cleanup_threadgroup_lock:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] introduce ioctl to completely invalidate page cache
On Thu, Oct 02, 2014 at 01:59:40PM -0600, Jens Axboe wrote: > On 10/02/2014 10:09 AM, Thanos Makatos wrote: > > This patch introduces a new ioctl called BLKFLUSHBUFS2, which is pretty What a horrible name. Whatever happened to naming ioctls interfaces after their function? i.e. BLKFLUSHINVAL? Cheers, Dave? -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf record: Fix error message for --filter option not coming after tracepoint
Commit-ID: 281f92f233a59ef52bb45287242bd815a67f5647
Gitweb: http://git.kernel.org/tip/281f92f233a59ef52bb45287242bd815a67f5647
Author: Arnaldo Carvalho de Melo
AuthorDate: Wed, 1 Oct 2014 15:05:32 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 1 Oct 2014 15:05:32 -0300
perf record: Fix error message for --filter option not coming after tracepoint
[root@zoo ~]# perf record --filter "common_pid != PERF_PID" -a
-F option should follow a -e tracepoint option.
The -F option is for --freq, not --filter. Fix it up to show:
[root@zoo ~]# perf record --filter "common_pid != PERF_PID" -a
--filter option should follow a -e tracepoint option
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-z0yrm8stn9w3423nkov3e...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 9522cf2..d76aa30 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -984,7 +984,7 @@ int parse_filter(const struct option *opt, const char *str,
if (last == NULL || last->attr.type != PERF_TYPE_TRACEPOINT) {
fprintf(stderr,
- "-F option should follow a -e tracepoint option\n");
+ "--filter option should follow a -e tracepoint
option\n");
return -1;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf symbols: Improve DSO long names lookup speed with rbtree
Commit-ID: 4598a0a6d22fadfb7b37f2b44ee7fdcb24632fcf
Gitweb: http://git.kernel.org/tip/4598a0a6d22fadfb7b37f2b44ee7fdcb24632fcf
Author: Waiman Long
AuthorDate: Tue, 30 Sep 2014 13:36:15 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 1 Oct 2014 14:39:57 -0300
perf symbols: Improve DSO long names lookup speed with rbtree
With workload that spawns and destroys many threads and processes, it
was found that perf-mem could took a long time to post-process the perf
data after the target workload had completed its operation.
The performance bottleneck was found to be the lookup and insertion of
the new DSO structures (thousands of them in this case).
In a dual-socket Ivy-Bridge E7-4890 v2 machine (30-core, 60-thread), the
perf profile below shows what perf was doing after the profiled AIM7
shared workload completed:
- 83.94% perf libc-2.11.3.so [.] __strcmp_sse42
- __strcmp_sse42
- 99.82% map__new
machine__process_mmap_event
perf_session_deliver_event
perf_session__process_event
__perf_session__process_events
cmd_record
cmd_mem
run_builtin
main
__libc_start_main
- 13.17% perf perf [.] __dsos__findnew
__dsos__findnew
map__new
machine__process_mmap_event
perf_session_deliver_event
perf_session__process_event
__perf_session__process_events
cmd_record
cmd_mem
run_builtin
main
__libc_start_main
So about 97% of CPU times were spent in the map__new() function trying
to insert new DSO entry into the DSO linked list. The whole
post-processing step took about 9 minutes.
The DSO structures are currently searched linearly. So the total
processing time will be proportional to n^2.
To overcome this performance problem, the DSO code is modified to also
put the DSO structures in a RB tree sorted by its long name in
additional to being in a simple linked list. With this change, the
processing time will become proportional to n*log(n) which will be much
quicker for large n. However, the short name will still be searched
using the old linear searching method. With that patch in place, the
same perf-mem post-processing step took less than 30 seconds to
complete.
Signed-off-by: Waiman Long
Cc: Adrian Hunter
Cc: Don Zickus
Cc: Douglas Hatch
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Scott J Norton
Link:
http://lkml.kernel.org/r/1412098575-27863-3-git-send-email-waiman.l...@hp.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/dso.c | 70 ---
tools/perf/util/dso.h | 5 +++-
tools/perf/util/machine.c | 1 +
3 files changed, 71 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 901a58f..0247acf 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -653,6 +653,65 @@ struct dso *dso__kernel_findnew(struct machine *machine,
const char *name,
return dso;
}
+/*
+ * Find a matching entry and/or link current entry to RB tree.
+ * Either one of the dso or name parameter must be non-NULL or the
+ * function will not work.
+ */
+static struct dso *dso__findlink_by_longname(struct rb_root *root,
+struct dso *dso, const char *name)
+{
+ struct rb_node **p = >rb_node;
+ struct rb_node *parent = NULL;
+
+ if (!name)
+ name = dso->long_name;
+ /*
+* Find node with the matching name
+*/
+ while (*p) {
+ struct dso *this = rb_entry(*p, struct dso, rb_node);
+ int rc = strcmp(name, this->long_name);
+
+ parent = *p;
+ if (rc == 0) {
+ /*
+* In case the new DSO is a duplicate of an existing
+* one, print an one-time warning & put the new entry
+* at the end of the list of duplicates.
+*/
+ if (!dso || (dso == this))
+ return this;/* Find matching dso */
+ /*
+* The core kernel DSOs may have duplicated long name.
+* In this case, the short name should be different.
+* Comparing the short names to differentiate the DSOs.
+*/
+ rc = strcmp(dso->short_name, this->short_name);
+ if (rc == 0) {
+ pr_err("Duplicated dso name: %s\n", name);
+ return NULL;
+ }
+ }
+ if (rc < 0)
+ p = >rb_left;
+ else
+ p = >rb_right;
+ }
+ if (dso) {
+ /* Add new node and rebalance tree */
+
[tip:perf/core] perf symbols: Encapsulate dsos list head into struct dsos
Commit-ID: 8fa7d87f91479f7124142ca4ad93a37b80f8c1c0
Gitweb: http://git.kernel.org/tip/8fa7d87f91479f7124142ca4ad93a37b80f8c1c0
Author: Waiman Long
AuthorDate: Mon, 29 Sep 2014 16:07:28 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 30 Sep 2014 12:11:49 -0300
perf symbols: Encapsulate dsos list head into struct dsos
This is a precursor patch to enable long name searching of DSOs using
a rbtree.
In this patch, a new dsos structure is created which contains only a
list head structure for the moment.
The new dsos structure is used, in turn, in the machine structure for
the user_dsos and kernel_dsos fields.
Only the following 3 dsos functions are modified to accept the new dsos
structure parameter instead of list_head:
- dsos__add()
- dsos__find()
- __dsos__findnew()
Signed-off-by: Waiman Long
Cc: Adrian Hunter
Cc: Don Zickus
Cc: Douglas Hatch
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Scott J Norton
Link:
http://lkml.kernel.org/r/1412021249-19201-2-git-send-email-waiman.l...@hp.com
[ Move struct dsos to dso.h to reduce the dso methods depends on machine.h ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/dso.c | 17 +
tools/perf/util/dso.h | 13 ++---
tools/perf/util/header.c | 32 ++--
tools/perf/util/machine.c | 24
tools/perf/util/machine.h | 5 +++--
tools/perf/util/probe-event.c | 3 ++-
tools/perf/util/symbol-elf.c | 7 ++-
7 files changed, 60 insertions(+), 41 deletions(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 55e39dc..901a58f 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -851,35 +851,36 @@ bool __dsos__read_build_ids(struct list_head *head, bool
with_hits)
return have_build_id;
}
-void dsos__add(struct list_head *head, struct dso *dso)
+void dsos__add(struct dsos *dsos, struct dso *dso)
{
- list_add_tail(>node, head);
+ list_add_tail(>node, >head);
}
-struct dso *dsos__find(const struct list_head *head, const char *name, bool
cmp_short)
+struct dso *dsos__find(const struct dsos *dsos, const char *name,
+ bool cmp_short)
{
struct dso *pos;
if (cmp_short) {
- list_for_each_entry(pos, head, node)
+ list_for_each_entry(pos, >head, node)
if (strcmp(pos->short_name, name) == 0)
return pos;
return NULL;
}
- list_for_each_entry(pos, head, node)
+ list_for_each_entry(pos, >head, node)
if (strcmp(pos->long_name, name) == 0)
return pos;
return NULL;
}
-struct dso *__dsos__findnew(struct list_head *head, const char *name)
+struct dso *__dsos__findnew(struct dsos *dsos, const char *name)
{
- struct dso *dso = dsos__find(head, name, false);
+ struct dso *dso = dsos__find(dsos, name, false);
if (!dso) {
dso = dso__new(name);
if (dso != NULL) {
- dsos__add(head, dso);
+ dsos__add(dsos, dso);
dso__set_basename(dso);
}
}
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index 5e463c0..b63dc98 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -90,6 +90,13 @@ struct dso_cache {
char data[0];
};
+/*
+ * DSOs are put into a list for fast iteration.
+ */
+struct dsos {
+ struct list_head head;
+};
+
struct dso {
struct list_head node;
struct rb_root symbols[MAP__NR_TYPES];
@@ -224,10 +231,10 @@ struct map *dso__new_map(const char *name);
struct dso *dso__kernel_findnew(struct machine *machine, const char *name,
const char *short_name, int dso_type);
-void dsos__add(struct list_head *head, struct dso *dso);
-struct dso *dsos__find(const struct list_head *head, const char *name,
+void dsos__add(struct dsos *dsos, struct dso *dso);
+struct dso *dsos__find(const struct dsos *dsos, const char *name,
bool cmp_short);
-struct dso *__dsos__findnew(struct list_head *head, const char *name);
+struct dso *__dsos__findnew(struct dsos *dsos, const char *name);
bool __dsos__read_build_ids(struct list_head *head, bool with_hits);
size_t __dsos__fprintf_buildid(struct list_head *head, FILE *fp,
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 158c787..ce0de00 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -214,11 +214,11 @@ static int machine__hit_all_dsos(struct machine *machine)
{
int err;
- err = __dsos__hit_all(>kernel_dsos);
+ err = __dsos__hit_all(>kernel_dsos.head);
if (err)
return err;
- return __dsos__hit_all(>user_dsos);
+ return
[tip:perf/core] perf tools: Fix build breakage on arm64 targets
Commit-ID: 660d13296bbbe79635d1d9d700080b88061faffb
Gitweb: http://git.kernel.org/tip/660d13296bbbe79635d1d9d700080b88061faffb
Author: Will Deacon
AuthorDate: Tue, 30 Sep 2014 12:27:12 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 1 Oct 2014 14:44:17 -0300
perf tools: Fix build breakage on arm64 targets
Attempting to build the perf tool for an arm64 target results in the
following failure:
arch/arm64/util/unwind-libunwind.c: In function 'libunwind__arch_reg_id':
arch/arm64/util/unwind-libunwind.c:77:3: error: implicit declaration of
function 'pr_err'
pr_err("unwind: invalid reg id %d\n", regnum);
^
arch/arm64/util/unwind-libunwind.c:77:3: error: nested extern declaration of
'pr_err'
This is due to commit 84f5d36f4866 ("perf tools: Move pr_* debug macros
into debug object") moving the pr_* macros into a new header file, but
failing to update architectures other than x86.
This patch adds the missing include, and fixes the build again.
Signed-off-by: Will Deacon
Cc: Jean Pihet
Cc: Jiri Olsa
Cc: linux-arm-ker...@lists.infradead.org
Link:
http://lkml.kernel.org/r/1412076432-22045-1-git-send-email-will.dea...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/arm64/util/unwind-libunwind.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/arch/arm64/util/unwind-libunwind.c
b/tools/perf/arch/arm64/util/unwind-libunwind.c
index 436ee43..a87afa9 100644
--- a/tools/perf/arch/arm64/util/unwind-libunwind.c
+++ b/tools/perf/arch/arm64/util/unwind-libunwind.c
@@ -3,6 +3,7 @@
#include
#include "perf_regs.h"
#include "../../util/unwind.h"
+#include "../../util/debug.h"
int libunwind__arch_reg_id(int regnum)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf bench futex: Support operations for shared futexes
Commit-ID: 86c87e13f8a5dffc6cc7b0f37340f815dc172945
Gitweb: http://git.kernel.org/tip/86c87e13f8a5dffc6cc7b0f37340f815dc172945
Author: Davidlohr Bueso
AuthorDate: Mon, 29 Sep 2014 09:41:07 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 29 Sep 2014 15:43:21 -0300
perf bench futex: Support operations for shared futexes
Unlike futex-hash, requeuing and wakeup benchmarks do not support shared
futexes, limiting the usefulness of the programs. Correct this, and
allow using the local -S parameter. The default remains using private
futexes.
Signed-off-by: Davidlohr Bueso
Cc: Davidlohr Bueso
Link:
http://lkml.kernel.org/r/1412008868-22328-1-git-send-email-d...@stgolabs.net
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/bench/futex-hash.c| 7 +--
tools/perf/bench/futex-requeue.c | 24 +++-
tools/perf/bench/futex-wake.c| 15 ++-
3 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/tools/perf/bench/futex-hash.c b/tools/perf/bench/futex-hash.c
index a84206e..fc9bebd 100644
--- a/tools/perf/bench/futex-hash.c
+++ b/tools/perf/bench/futex-hash.c
@@ -26,6 +26,7 @@ static unsigned int nsecs= 10;
/* amount of futexes per thread */
static unsigned int nfutexes = 1024;
static bool fshared = false, done = false, silent = false;
+static int futex_flag = 0;
struct timeval start, end, runtime;
static pthread_mutex_t thread_lock;
@@ -75,8 +76,7 @@ static void *workerfn(void *arg)
* such as internal waitqueue handling, thus enlarging
* the critical region protected by hb->lock.
*/
- ret = futex_wait(>futex[i], 1234, NULL,
-fshared ? 0 : FUTEX_PRIVATE_FLAG);
+ ret = futex_wait(>futex[i], 1234, NULL, futex_flag);
if (!silent &&
(!ret || errno != EAGAIN || errno != EWOULDBLOCK))
warn("Non-expected futex return call");
@@ -135,6 +135,9 @@ int bench_futex_hash(int argc, const char **argv,
if (!worker)
goto errmem;
+ if (!fshared)
+ futex_flag = FUTEX_PRIVATE_FLAG;
+
printf("Run summary [PID %d]: %d threads, each operating on %d [%s]
futexes for %d secs.\n\n",
getpid(), nthreads, nfutexes, fshared ? "shared":"private",
nsecs);
diff --git a/tools/perf/bench/futex-requeue.c b/tools/perf/bench/futex-requeue.c
index 732403b..9837a88 100644
--- a/tools/perf/bench/futex-requeue.c
+++ b/tools/perf/bench/futex-requeue.c
@@ -30,16 +30,18 @@ static u_int32_t futex1 = 0, futex2 = 0;
static unsigned int nrequeue = 1;
static pthread_t *worker;
-static bool done = 0, silent = 0;
+static bool done = false, silent = false, fshared = false;
static pthread_mutex_t thread_lock;
static pthread_cond_t thread_parent, thread_worker;
static struct stats requeuetime_stats, requeued_stats;
static unsigned int ncpus, threads_starting, nthreads = 0;
+static int futex_flag = 0;
static const struct option options[] = {
OPT_UINTEGER('t', "threads", , "Specify amount of threads"),
OPT_UINTEGER('q', "nrequeue", , "Specify amount of threads to
requeue at once"),
OPT_BOOLEAN( 's', "silent", , "Silent mode: do not display
data/details"),
+ OPT_BOOLEAN( 'S', "shared", , "Use shared futexes instead of
private ones"),
OPT_END()
};
@@ -70,7 +72,7 @@ static void *workerfn(void *arg __maybe_unused)
pthread_cond_wait(_worker, _lock);
pthread_mutex_unlock(_lock);
- futex_wait(, 0, NULL, FUTEX_PRIVATE_FLAG);
+ futex_wait(, 0, NULL, futex_flag);
return NULL;
}
@@ -127,9 +129,12 @@ int bench_futex_requeue(int argc, const char **argv,
if (!worker)
err(EXIT_FAILURE, "calloc");
- printf("Run summary [PID %d]: Requeuing %d threads (from %p to %p), "
- "%d at a time.\n\n",
- getpid(), nthreads, , , nrequeue);
+ if (!fshared)
+ futex_flag = FUTEX_PRIVATE_FLAG;
+
+ printf("Run summary [PID %d]: Requeuing %d threads (from [%s] %p to
%p), "
+ "%d at a time.\n\n", getpid(), nthreads,
+ fshared ? "shared":"private", , , nrequeue);
init_stats(_stats);
init_stats(_stats);
@@ -156,13 +161,14 @@ int bench_futex_requeue(int argc, const char **argv,
/* Ok, all threads are patiently blocked, start requeueing */
gettimeofday(, NULL);
- for (nrequeued = 0; nrequeued < nthreads; nrequeued += nrequeue)
+ for (nrequeued = 0; nrequeued < nthreads; nrequeued +=
nrequeue) {
/*
* Do not wakeup any tasks blocked on futex1, allowing
* us to really measure futex_wait functionality.
*/
-
[tip:perf/core] perf tools: Refactor unit and scale function parameters
Commit-ID: 46441bdc76fee08e297ebcf17e4ca91013b1ee9e
Gitweb: http://git.kernel.org/tip/46441bdc76fee08e297ebcf17e4ca91013b1ee9e
Author: Matt Fleming
AuthorDate: Wed, 24 Sep 2014 15:04:06 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 29 Sep 2014 15:03:57 -0300
perf tools: Refactor unit and scale function parameters
Passing pointers to alias modifiers 'unit' and 'scale' isn't very
future-proof since if we add more modifiers to the list we'll end up
passing more arguments.
Instead wrap everything up in a struct perf_pmu_info, which can easily
be expanded when additional alias modifiers are necessary in the future.
Signed-off-by: Matt Fleming
Acked-by: Jiri Olsa
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1411567455-31264-3-git-send-email-m...@console-pimps.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 9 -
tools/perf/util/pmu.c | 38 +++---
tools/perf/util/pmu.h | 7 ++-
3 files changed, 33 insertions(+), 21 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 61be3e6..9522cf2 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -634,10 +634,9 @@ int parse_events_add_pmu(struct list_head *list, int *idx,
char *name, struct list_head *head_config)
{
struct perf_event_attr attr;
+ struct perf_pmu_info info;
struct perf_pmu *pmu;
struct perf_evsel *evsel;
- const char *unit;
- double scale;
pmu = perf_pmu__find(name);
if (!pmu)
@@ -656,7 +655,7 @@ int parse_events_add_pmu(struct list_head *list, int *idx,
return evsel ? 0 : -ENOMEM;
}
- if (perf_pmu__check_alias(pmu, head_config, , ))
+ if (perf_pmu__check_alias(pmu, head_config, ))
return -EINVAL;
/*
@@ -671,8 +670,8 @@ int parse_events_add_pmu(struct list_head *list, int *idx,
evsel = __add_event(list, idx, , pmu_event_name(head_config),
pmu->cpus);
if (evsel) {
- evsel->unit = unit;
- evsel->scale = scale;
+ evsel->unit = info.unit;
+ evsel->scale = info.scale;
}
return evsel ? 0 : -ENOMEM;
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 22a4ad5..93a41ca 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -210,6 +210,19 @@ static int perf_pmu__new_alias(struct list_head *list,
char *dir, char *name, FI
return 0;
}
+static inline bool pmu_alias_info_file(char *name)
+{
+ size_t len;
+
+ len = strlen(name);
+ if (len > 5 && !strcmp(name + len - 5, ".unit"))
+ return true;
+ if (len > 6 && !strcmp(name + len - 6, ".scale"))
+ return true;
+
+ return false;
+}
+
/*
* Process all the sysfs attributes located under the directory
* specified in 'dir' parameter.
@@ -218,7 +231,6 @@ static int pmu_aliases_parse(char *dir, struct list_head
*head)
{
struct dirent *evt_ent;
DIR *event_dir;
- size_t len;
int ret = 0;
event_dir = opendir(dir);
@@ -234,13 +246,9 @@ static int pmu_aliases_parse(char *dir, struct list_head
*head)
continue;
/*
-* skip .unit and .scale info files
-* parsed in perf_pmu__new_alias()
+* skip info files parsed in perf_pmu__new_alias()
*/
- len = strlen(name);
- if (len > 5 && !strcmp(name + len - 5, ".unit"))
- continue;
- if (len > 6 && !strcmp(name + len - 6, ".scale"))
+ if (pmu_alias_info_file(name))
continue;
snprintf(path, PATH_MAX, "%s/%s", dir, name);
@@ -645,7 +653,7 @@ static int check_unit_scale(struct perf_pmu_alias *alias,
* defined for the alias
*/
int perf_pmu__check_alias(struct perf_pmu *pmu, struct list_head *head_terms,
- const char **unit, double *scale)
+ struct perf_pmu_info *info)
{
struct parse_events_term *term, *h;
struct perf_pmu_alias *alias;
@@ -655,8 +663,8 @@ int perf_pmu__check_alias(struct perf_pmu *pmu, struct
list_head *head_terms,
* Mark unit and scale as not set
* (different from default values, see below)
*/
- *unit = NULL;
- *scale = 0.0;
+ info->unit = NULL;
+ info->scale = 0.0;
list_for_each_entry_safe(term, h, head_terms, list) {
alias = pmu_find_alias(pmu, term);
@@ -666,7 +674,7 @@ int perf_pmu__check_alias(struct perf_pmu *pmu, struct
list_head *head_terms,
if (ret)
return ret;
-
[tip:perf/core] perf bench futex: Sanitize -q option in requeue
Commit-ID: e19685ed24b518440c0717719ff02e74c0e6d2cb Gitweb: http://git.kernel.org/tip/e19685ed24b518440c0717719ff02e74c0e6d2cb Author: Davidlohr Bueso AuthorDate: Mon, 29 Sep 2014 09:41:08 -0700 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 29 Sep 2014 15:43:26 -0300 perf bench futex: Sanitize -q option in requeue When given the number of threads to requeue at once by user input, there's always the risk of this value being larger than the total number of threads. This doesn't make any sense, and the kernel can easily deal with such sort of situations, hence no big deal. We should however prevent bogus output such as: ./perf bench --repeat 2 futex requeue -q 10 Run summary [PID 22210]: Requeuing 4 threads (from [private] 0x99ef3c to 0x99ef38), 10 at a time. [Run 1]: Requeued 10 of 4 threads in 0.0040 ms [Run 2]: Requeued 10 of 4 threads in 0.0030 ms Requeued 10 of 4 threads in 0.0035 ms (+-14.29%) Signed-off-by: Davidlohr Bueso Cc: Davidlohr Bueso Link: http://lkml.kernel.org/r/1412008868-22328-2-git-send-email-d...@stgolabs.net Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/bench/futex-requeue.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/perf/bench/futex-requeue.c b/tools/perf/bench/futex-requeue.c index 9837a88..bedff6b 100644 --- a/tools/perf/bench/futex-requeue.c +++ b/tools/perf/bench/futex-requeue.c @@ -172,6 +172,9 @@ int bench_futex_requeue(int argc, const char **argv, gettimeofday(, NULL); timersub(, , ); + if (nrequeued > nthreads) + nrequeued = nthreads; + update_stats(_stats, nrequeued); update_stats(_stats, runtime.tv_usec); @@ -190,7 +193,6 @@ int bench_futex_requeue(int argc, const char **argv, if (ret) err(EXIT_FAILURE, "pthread_join"); } - } /* cleanup & report results */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf trace: Fix mmap return address truncation to 32-bit
Commit-ID: 2c82c3ad56921c47f28af9eb8ed96b6d99b47623
Gitweb: http://git.kernel.org/tip/2c82c3ad56921c47f28af9eb8ed96b6d99b47623
Author: Chang Hyun Park
AuthorDate: Fri, 26 Sep 2014 21:54:01 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 29 Sep 2014 15:25:36 -0300
perf trace: Fix mmap return address truncation to 32-bit
Using 'perf trace' for mmap is truncating return values by stripping the
top 32 bits, actually printing only the lower 32 bits.
This was because the ret value was of an 'int' type and not a 'long'
type.
The Problem:
991258501.244 ( 0.004 ms): mmap(len: 40001536, prot: READ|WRITE, flags:
PRIVATE|ANONYMOUS, fd: -1) = 0x56691000
991258501.257 ( 0.000 ms): minfault [_int_malloc+0x1038] =>
//anon@0x7fa056691008 //(d.)
The first line shows an mmap, which succeeds and returns 0x56691000.
However the next line shows a memory access to that virtual memory area,
specifically to 0x7fa056691008. The upper 32 bit is lost due to the
problem mentioned above, and thus mmap's return value didn't have the
upper 0x7fa0.
Tested on 3.17-rc5 from the linus's tree, and the HEAD of tip/master
Signed-off-by: Chang Hyun Park
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1411736041-8017-1-git-send-email-heartinpi...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-trace.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index c70e69e..09bcf23 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1695,7 +1695,7 @@ static int trace__sys_exit(struct trace *trace, struct
perf_evsel *evsel,
union perf_event *event __maybe_unused,
struct perf_sample *sample)
{
- int ret;
+ long ret;
u64 duration = 0;
struct thread *thread;
int id = perf_evsel__sc_tp_uint(evsel, id, sample);
@@ -1748,7 +1748,7 @@ static int trace__sys_exit(struct trace *trace, struct
perf_evsel *evsel,
if (sc->fmt == NULL) {
signed_print:
- fprintf(trace->output, ") = %d", ret);
+ fprintf(trace->output, ") = %ld", ret);
} else if (ret < 0 && sc->fmt->errmsg) {
char bf[STRERR_BUFSIZE];
const char *emsg = strerror_r(-ret, bf, sizeof(bf)),
@@ -1758,7 +1758,7 @@ signed_print:
} else if (ret == 0 && sc->fmt->timeout)
fprintf(trace->output, ") = 0 Timeout");
else if (sc->fmt->hexret)
- fprintf(trace->output, ") = %#x", ret);
+ fprintf(trace->output, ") = %#lx", ret);
else
goto signed_print;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm i915 and nouveau fixes
Hi Linus, Nothing too major or scary, one i915 regression fix, nouveau has a tmds regression fix, along with a regression fix for the runtime pm code for optimus laptops not restoring the display hw correctly. Dave. The following changes since commit fe82dcec644244676d55a1384c958d5f67979adb: Linux 3.17-rc7 (2014-09-28 14:29:07 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to eee0815dabbdd7d584bea8275f5758d25c97cb9b: Merge tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-10-03 11:38:16 +1000) Ben Skeggs (4): drm/nv50/disp: fix dpms regression on certain boards drm/nouveau: fix regression on original nv50 board drm/nouveau: punt fbcon resume out to a workqueue drm/nouveau: make sure display hardware is reinitialised on runtime resume Chris Wilson (1): drm/i915: Flush the PTEs after updating them before suspend Dave Airlie (2): Merge branch 'linux-3.17' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Merge tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel into drm-fixes drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++- drivers/gpu/drm/nouveau/core/engine/disp/nv50.c | 3 +- drivers/gpu/drm/nouveau/nouveau_chan.c | 7 +++- drivers/gpu/drm/nouveau/nouveau_display.c | 23 ++- drivers/gpu/drm/nouveau/nouveau_display.h | 5 +-- drivers/gpu/drm/nouveau/nouveau_drm.c | 51 +++-- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 23 --- drivers/gpu/drm/nouveau/nouveau_fbcon.h | 1 + 8 files changed, 65 insertions(+), 62 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf: Fix typos in sample code in the perf_event.h header
struct perf_event_mmap_page has members called "index" and
"cap_user_rdpmc". Spell them correctly in the examples.
Signed-off-by: Andy Lutomirski
---
include/uapi/linux/perf_event.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 9269de254874..9d845404d875 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -364,7 +364,7 @@ struct perf_event_mmap_page {
/*
* Bits needed to read the hw events in user-space.
*
-* u32 seq, time_mult, time_shift, idx, width;
+* u32 seq, time_mult, time_shift, index, width;
* u64 count, enabled, running;
* u64 cyc, time_offset;
* s64 pmc = 0;
@@ -383,11 +383,11 @@ struct perf_event_mmap_page {
* time_shift = pc->time_shift;
* }
*
-* idx = pc->index;
+* index = pc->index;
* count = pc->offset;
-* if (pc->cap_usr_rdpmc && idx) {
+* if (pc->cap_user_rdpmc && index) {
* width = pc->pmc_width;
-* pmc = rdpmc(idx - 1);
+* pmc = rdpmc(index - 1);
* }
*
* barrier();
@@ -415,7 +415,7 @@ struct perf_event_mmap_page {
};
/*
-* If cap_usr_rdpmc this field provides the bit-width of the value
+* If cap_user_rdpmc this field provides the bit-width of the value
* read using the rdpmc() or equivalent instruction. This can be used
* to sign extend the result like:
*
@@ -439,10 +439,10 @@ struct perf_event_mmap_page {
*
* Where time_offset,time_mult,time_shift and cyc are read in the
* seqcount loop described above. This delta can then be added to
-* enabled and possible running (if idx), improving the scaling:
+* enabled and possible running (if index), improving the scaling:
*
* enabled += delta;
-* if (idx)
+* if (index)
* running += delta;
*
* quot = count / running;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pipe/page fault oddness.
On 10/02/2014 12:10 PM, Linus Torvalds wrote: > On Thu, Oct 2, 2014 at 8:04 AM, Sasha Levin wrote: >> > >> > I have a new one for you. I know it doesn't say "numa" anywhere, but I >> > haven't ever seen that trace before so I'll just go ahead and blame it >> > on your patch... > Fair enough, but the oops doesn't really give even a hint of what > could be wrong. > > The stack is clearly too deep: > > Thread overran stack, or stack corrupted > task.ti: 880dba2ec000 > RSP: 880dba2ebf48 > > but my patch shouldn't have added any deeper call-chains anywhere. For the record, I tweaked the environment to put some more pressure on the scheduler and found out what broke (which is not related to this thread at all). For the curious ones: https://lkml.org/lkml/2014/10/3/5 Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] Perf Bench: Locking Microbenchmark
On Wed, 2014-10-01 at 14:12 -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 01, 2014 at 07:28:32AM +0200, Ingo Molnar escreveu: > > If you compare an strace of AIM7 steady state and 'perf bench > > lock' steady state, is it comparable, i.e. do the syscalls and > > Isn't "lock" too generic? Isn't this stressing some specific lock and if > so shouldn't that be made abundantly clear in the 'perf bench' test name > and in the docs? yeah, and 'perf bench locking creat' just doesn't sound right. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86: Only do a single page fault for copy_from_user_nmi
* Andi Kleen wrote: > > For now, changing the semantics of the function seems like a > > sure way to fail in the future though. > > I doubt it. Nearly nobody uses the exact return value > semantics. > > (iirc it's mostly write() and some bizarre code in mount) > > In fact it's a regular mistake to assume it returns -errno. > > > > In theory we could also duplicate the whole copy_*_ path > > > for cases where the caller doesn't care about the exact > > > bytes. But that seems overkill for just this issue, and I'm > > > not sure anyone else cares about how fast this is. The > > > simpler check works as well for now. > > > > So I don't get that code, but why not fix it in general? > > Taking two faults seems silly. > > It's really complicated to reconstruct the exact bytes, as an > optimized memcpy is very complicated and has a lot of corner > cases. > > I tried it originally when writing the original copy function, > but failed. That is why people came up later with this > two-fault scheme. > > I think two fault is fine for most cases, just not for NMIs. Slapping an ugly in_nmi() check into a generic memcpy routine, especially if it changes semantics, is asking for trouble. It is a non-starter and I'm NAK-ing it. There are cleaner ways to solve this problem - PeterZ offered one, but there are other options as well, such as: - removing exact-bytes semantics explicitly from almost all cases and offering a separate (and more expensive, in the faulting case) memcpy variant for write() and other code that absolutely must know the number of copied bytes. - or adding a special no-bytes-copied memcpy variant that the NMI code could use. Use one of these or outline that they cannot possibly work. It might be more work for you, but it gives us a cleaner and more maintainable kernel. The problem is that you should know this general principle already, instead you are wasting maintainer bandwidth via arguing in favor of ugly hacks again and again... Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] Perf Bench: Locking Microbenchmark
On Wed, 2014-10-01 at 07:28 +0200, Ingo Molnar wrote: > If you compare an strace of AIM7 steady state and 'perf bench > lock' steady state, is it comparable, i.e. do the syscalls and > other behavioral patterns match up? With more than 1000 users I'm seeing: - 33.74%locking-creat [kernel.kallsyms] [k] mspin_lock ◆ + mspin_lock ▒ + __mutex_lock_slowpath ▒ + mutex_lock ▒ - 7.97%locking-creat [kernel.kallsyms] [k] mutex_spin_on_owner ▒ + mutex_spin_on_owner ▒ + __mutex_lock_slowpath ▒ + mutex_lock Lower users count just shows the syscall entries. Of course, the aim7 setup was running on a ramdisk, thus avoiding any IO overhead in the traces. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/asm] x86: Speed up ___preempt_schedule*() by using THUNK helpers
On 09/24/2014 11:02 AM, tip-bot for Oleg Nesterov wrote: > Commit-ID: 0ad6e3c5199be12c9745da8f8b9e3c9f8066c235 > Gitweb: http://git.kernel.org/tip/0ad6e3c5199be12c9745da8f8b9e3c9f8066c235 > Author: Oleg Nesterov > AuthorDate: Sun, 21 Sep 2014 20:41:53 +0200 > Committer: Ingo Molnar > CommitDate: Wed, 24 Sep 2014 15:15:38 +0200 > > x86: Speed up ___preempt_schedule*() by using THUNK helpers > > ___preempt_schedule() does SAVE_ALL/RESTORE_ALL but this is > suboptimal, we do not need to save/restore the callee-saved > register. And we already have arch/x86/lib/thunk_*.S which > implements the similar asm wrappers, so it makes sense to > redefine ___preempt_schedule() as "THUNK ..." and remove > preempt.S altogether. > > Signed-off-by: Oleg Nesterov > Reviewed-by: Andy Lutomirski > Cc: Denys Vlasenko > Cc: Peter Zijlstra > Cc: Linus Torvalds > Link: http://lkml.kernel.org/r/20140921184153.ga23...@redhat.com > Signed-off-by: Ingo Molnar > --- Hi Oleg, I *think* that this patch is causing the following trace (arch/x86/lib/thunk_64.S:44 is new code introduced by this patch): [ 921.908530] kernel BUG at kernel/sched/core.c:2702! [ 921.909159] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 921.910084] Dumping ftrace buffer: [ 921.910626](ftrace buffer empty) [ 921.911178] Modules linked in: [ 921.915690] CPU: 18 PID: 9489 Comm: trinity-c195 Not tainted 3.17.0-rc7-next-20141002-sasha-00031-gbdb4244 #1273 [ 921.917016] task: 8802bd748000 ti: 8802bda3c000 task.ti: 8802bda3c000 [ 921.917752] RIP: __schedule (kernel/sched/core.c:2702 kernel/sched/core.c:2808) [ 921.917752] RSP: 0018:8802bda3c360 EFLAGS: 00010297 [ 921.917752] RAX: 8802bda3c000 RBX: 8808501e2a00 RCX: 0001 [ 921.917752] RDX: RSI: RDI: 0286 [ 921.917752] RBP: 8802bda3c3c0 R08: 0001aa50 R09: [ 921.917752] R10: R11: 0001 R12: 0012 [ 921.917752] R13: 8808501e2a00 R14: 0002 R15: 8802bda3c428 [ 921.917752] FS: 7f5475cc2700() GS:88085000() knlGS: [ 921.917752] CS: 0010 DS: ES: CR0: 8005003b [ 921.917752] CR2: 7f5475abe60c CR3: 0002bebab000 CR4: 06a0 [ 921.917752] DR0: 006f DR1: DR2: [ 921.917752] DR3: DR6: 0ff0 DR7: 0600 [ 921.917752] Stack: [ 921.917752] 0001aa50 8802bd748000 8802bda3ffd8 001e2a00 [ 921.917752] 001e2a00 8802bd748000 8802bda3c3a0 001e2a00 [ 921.917752] 8802bd748000 0001a9ea 0002 8802bda3c428 [ 921.917752] Call Trace: [ 921.917752] schedule_user (kernel/sched/core.c:2894 include/linux/jump_label.h:114 include/linux/context_tracking_state.h:27 include/linux/context_tracking.h:20 kernel/sched/core.c:2909) [ 921.917752] int_careful (arch/x86/kernel/entry_64.S:560) [ 921.917752] ? retint_careful (arch/x86/kernel/entry_64.S:889) [ 921.917752] ? preempt_schedule (./arch/x86/include/asm/preempt.h:80 (discriminator 1) kernel/sched/core.c:2943 (discriminator 1)) [ 921.917752] ? preempt_schedule_context (./arch/x86/include/asm/preempt.h:75 kernel/context_tracking.c:143) [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) [ 921.917752] ? preempt_schedule_context (kernel/context_tracking.c:145) [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) [ 921.917752] ? preempt_schedule_context (kernel/context_tracking.c:145) [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) [ 921.917752] ? preempt_schedule_context (kernel/context_tracking.c:145) [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) [ 921.917752] ? preempt_schedule_context (kernel/context_tracking.c:145) [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) [ 921.917752] ? preempt_schedule_context (kernel/context_tracking.c:145) [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) [ 921.917752] ? preempt_schedule_context (kernel/context_tracking.c:145) [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) [ 921.917752] ? preempt_schedule_context (kernel/context_tracking.c:145) [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) [ 921.917752] ? preempt_schedule_context (kernel/context_tracking.c:145) [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) [ 921.917752] ? preempt_schedule_context (kernel/context_tracking.c:145) [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) [ 921.917752] ? preempt_schedule_context (kernel/context_tracking.c:145) [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk
Re: [PATCH] serial/core: Initialize the console pm state
On Wed, Oct 01, 2014 at 10:27:20AM -0700, Kevin Hilman wrote: > On Sun, Sep 21, 2014 at 11:30 PM, Sudhir Sreedharan > wrote: > > For console devices having UART_CAP_SLEEP capability, the uart_pm_state has > > to be initialized to UART_PM_STATE_ON. Otherwise the LCR regiser values > > are reinitialized when uart_change_pm is called from uart_configure_port. > > > > Signed-off-by: Sudhir Sreedharan > > Multiple boot failures on ARM[1] were bisected down to this patch. > > How was this patch tested, and on which platforms? > > Also, the changelog states that this should be done only for > UART_CAP_SLEEP, but the patch does it for every UART. > > Greg, I suggest this patch be dropped from tty-next until it has been > better described and tested. Now reverted, thanks for letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] perf tools: Add option to copy events when queueing
* Alexander Yarygin wrote: > When processing events the session code has an ordered samples > queue which is used to time-sort events coming in across > multiple mmaps. At a later point in time samples on the queue > are flushed up to some timestamp at which point the event is > actually processed. > > When analyzing events live (ie., record/analysis path in the > same command) there is a race that leads to corrupted events > and parse errors which cause perf to terminate. The problem is > that when the event is placed in the ordered samples queue it > is only a reference to the event which is really sitting in the > mmap buffer. Even though the event is queued for later > processing the mmap tail pointer is updated which indicates to > the kernel that the event has been processed. The race is > flushing the event from the queue before it gets overwritten by > some other event. For commands trying to process events live > (versus just writing to a file) and processing a high rate of > events this leads to parse failures and perf terminates. > > Examples hitting this problem are 'perf kvm stat live', > especially with nested VMs which generate 100,000+ traces per > second, and a command processing scheduling events with a high > rate of context switching -- e.g., running 'perf bench sched > pipe'. > > This patch offers live commands an option to copy the event > when it is placed in the ordered samples queue. What's the performance effect of this - i.e. by how much does CPU use increase due to copying the events? Wouldn't it be faster to fix this problem by updating the mmap tail pointer only once the event has truly been consumed? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] powerpc/iommu/ddw: Fix endianness
Hi Alexey, > rtas_call() accepts and returns values in CPU endianness. > The ddw_query_response and ddw_create_response structs members are > defined and treated as BE but as they are passed to rtas_call() as > (u32 *) and they get byteswapped automatically, the data is > CPU-endian. This fixes ddw_query_response and ddw_create_response > definitions and use. > > of_read_number() is designed to work with device tree cells - it > assumes the input is big-endian and returns data in CPU-endian. > However due to the ddw_create_response struct fix, create.addr_hi/lo > are already CPU-endian so do not byteswap them. > > ddw_avail is a pointer to the "ibm,ddw-applicable" property which > contains 3 cells which are big-endian as it is a device tree. > rtas_call() accepts a RTAS token in CPU-endian. This makes use of > of_property_read_u32_array to byte swap and avoid the need for a > number of be32_to_cpu calls. > > Cc: sta...@vger.kernel.org # v3.13 > Cc: Benjamin Herrenschmidt > Reviewed-by: Anton Blanchard > [aik: folded Anton's patch with of_property_read_u32_array] > Signed-off-by: Alexey Kardashevskiy Thanks for updating, looks good. Could we make it clear the bug is present in 3.13-3.17 with: Cc: sta...@vger.kernel.org # v3.13+ Acked-by: Anton Blanchard Anton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf, x86: Use INTEL_FLAGS_UEVENT_CONSTRAINT for PRECDIST
* Peter Zijlstra wrote: > On Wed, Sep 10, 2014 at 04:22:32PM +0200, Peter Zijlstra wrote: > > On Wed, Sep 10, 2014 at 07:02:58AM -0700, Andi Kleen wrote: > > > On Wed, Sep 10, 2014 at 09:59:26AM +0200, Peter Zijlstra wrote: > > > > On Tue, Sep 09, 2014 at 05:49:08PM -0700, Andi Kleen wrote: > > > > > From: Andi Kleen > > > > > > > > > > The earlier commit 86a04461a made near all PEBS on > > > > > Sandy/IvyBridge/Haswell to reject non zero flags. > > > > > > > > What's magic about nehalem and westmere? > > > > > > I wasn't able to confirm their behavior explicitly, so I felt > > > it best to leave them alone. > > > > > > But in principle adding the _FLAGS changes there too would > > > make sense too. > > > > Yeah please do that patch ASAP, having PEBS behave differently across > > uarchs is wrong. > > Ping! Also, I have to NAK this patch for trivial style reasons: the patch adds gobs of misaligned, misplaced spaces instead of using proper tabs - and apparently that's not the first time Andi did that to the constraints tables. This is annoying and ineffective and Andi Kleen continues to introduce trivial flaws into the kernel despite repeated complaints and requests for him to use available tools to check patch quality such as scripts/checkpatch.pl. As a result I'm dropping most patches from Andi in the perf/core pipeline and I will delay them to at least until v3.19 when I might have more time to waste on reviewing trivially flawed patches. I only took this single patch: perf/x86/intel/uncore: Fix minor race in box set up which fixes a bug, and I've dropped all other patches from Andi. Next time I see trivial flaws in Andi's patches I'll drop and delay them for two cycles, not one, to give them ample time to be improved. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] mm: add mremap flag for preserving the old mapping
This introduces the MREMAP_RETAIN flag for preserving the source mapping
when MREMAP_MAYMOVE moves the pages to a new destination. Accesses to
the source mapping will fault and map in fresh zeroed pages.
It is currently limited to writable MAP_PRIVATE|MAP_ANONYMOUS mappings
and will return EFAULT when used on anything else. This covers the
intended use case in general purpose allocators.
For consistency, the old_len >= new_len case could decommit the pages
instead of unmapping. However, userspace can accomplish the same thing
via madvise and the flag is coherent without the additional complexity.
Motivation:
TCMalloc and jemalloc avoid releasing virtual memory in order to reduce
virtual memory fragmentation. A call to munmap or mremap would leave a
hole in the address space. Instead, unused pages are lazily returned to
the operating system via MADV_DONTNEED.
Since mremap cannot be used to elide copies, TCMalloc and jemalloc end
up being significantly slower for patterns like repeated vector / hash
table reallocations. Consider the typical vector building pattern:
#include
#include
int main(void) {
for (size_t i = 0; i < 100; i++) {
void *ptr = NULL;
size_t old_size = 0;
for (size_t size = 4; size < (1 << 30); size *= 2) {
ptr = realloc(ptr, size);
if (!ptr) return 1;
memset(ptr + old_size, 0xff, size - old_size);
old_size = size;
}
free(ptr);
}
}
Transparent huge pages disabled:
glibc (baseline, uses mremap already): 15.051s
jemalloc without MREMAP_RETAIN: 38.540s
jemalloc with MREMAP_RETAIN: 15.086s
Transparent huge pages enabled:
glibc (baseline, uses mremap already): 8.464s
jemalloc without MREMAP_RETAIN: 18.230s
jemalloc with MREMAP_RETAIN: 6.696s
In practice, in-place growth never occurs for huge allocations because
the heap grows in the downwards direction for all 3 allocators. TCMalloc
and jemalloc pay for enormous copies while glibc is only spending time
writing new elements to the vector. Even if it was grown in the other
direction, real-world applications would end up blocking in-place growth
with new allocations.
The allocators could attempt to map the source location again after an
mremap call, but there is no guarantee of success in a multi-threaded
program and fragmentating memory over time is considered unacceptable.
Signed-off-by: Daniel Micay
---
include/linux/huge_mm.h | 2 +-
include/linux/mm.h| 6 ++
include/uapi/linux/mman.h | 1 +
mm/huge_memory.c | 4 ++--
mm/memory.c | 2 +-
mm/mmap.c | 12 +++
mm/mremap.c | 52 +++
7 files changed, 57 insertions(+), 22 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 63579cb..3c13b20 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -143,7 +143,7 @@ static inline void vma_adjust_trans_huge(struct
vm_area_struct *vma,
unsigned long end,
long adjust_next)
{
- if (!vma->anon_vma || vma->vm_ops)
+ if (!vma->anon_vma || (vma->vm_ops && !vma->vm_ops->allow_huge_pages))
return;
__vma_adjust_trans_huge(vma, start, end, adjust_next);
}
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8981cc8..1e61036 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -273,6 +273,12 @@ struct vm_operations_struct {
/* called by sys_remap_file_pages() to populate non-linear mapping */
int (*remap_pages)(struct vm_area_struct *vma, unsigned long addr,
unsigned long size, pgoff_t pgoff);
+
+ /* Check if the mapping may be duplicated by MREMAP_RETAIN */
+ bool (*may_duplicate)(struct vm_area_struct *vma);
+
+ /* if there is no vm_ops table, this is considered true */
+ bool allow_huge_pages;
};
struct mmu_gather;
diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h
index ade4acd..4e9a546 100644
--- a/include/uapi/linux/mman.h
+++ b/include/uapi/linux/mman.h
@@ -5,6 +5,7 @@
#define MREMAP_MAYMOVE 1
#define MREMAP_FIXED 2
+#define MREMAP_RETAIN 4
#define OVERCOMMIT_GUESS 0
#define OVERCOMMIT_ALWAYS 1
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index d9a21d06..350b478 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2077,7 +2077,7 @@ int khugepaged_enter_vma_merge(struct vm_area_struct *vma)
* page fault if needed.
*/
return 0;
- if (vma->vm_ops)
+ if ((vma->vm_ops && !vma->vm_ops->allow_huge_pages))
/* khugepaged not yet working on file or special mappings */
return 0;
VM_BUG_ON(vma->vm_flags & VM_NO_THP);
@@ -2405,7 +2405,7 @@ static bool
[PATCH] rcutorture: Remove stale test configurations
Remove rcutorture configuration files which are no longer necessary. Signed-off-by: Pranith Kumar --- .../selftests/rcutorture/configs/rcu/v0.0/CFLIST | 14 -- .../configs/rcu/v0.0/N1-S-T-NH-SD-SMP-HP | 18 --- .../configs/rcu/v0.0/N2-2-t-nh-sd-SMP-hp | 20 .../configs/rcu/v0.0/N3-3-T-nh-SD-SMP-hp | 22 - .../configs/rcu/v0.0/N4-A-t-NH-sd-SMP-HP | 18 --- .../configs/rcu/v0.0/N5-U-T-NH-sd-SMP-hp | 22 - .../selftests/rcutorture/configs/rcu/v0.0/NT1-nh | 23 - .../selftests/rcutorture/configs/rcu/v0.0/NT3-NH | 20 .../configs/rcu/v0.0/P1-S-T-NH-SD-SMP-HP | 19 .../configs/rcu/v0.0/P2-2-t-nh-sd-SMP-hp | 20 .../configs/rcu/v0.0/P3-3-T-nh-SD-SMP-hp | 20 .../configs/rcu/v0.0/P4-A-t-NH-sd-SMP-HP | 22 - .../configs/rcu/v0.0/P5-U-T-NH-sd-SMP-hp | 27 -- .../selftests/rcutorture/configs/rcu/v0.0/PT1-nh | 23 - .../selftests/rcutorture/configs/rcu/v0.0/PT2-NH | 22 - .../rcutorture/configs/rcu/v0.0/ver_functions.sh | 33 - .../selftests/rcutorture/configs/rcu/v3.12/CFLIST | 17 --- .../configs/rcu/v3.12/N1-S-T-NH-SD-SMP-HP | 19 .../configs/rcu/v3.12/N2-2-t-nh-sd-SMP-hp | 20 .../configs/rcu/v3.12/N3-3-T-nh-SD-SMP-hp | 22 - .../configs/rcu/v3.12/N4-A-t-NH-sd-SMP-HP | 18 --- .../configs/rcu/v3.12/N5-U-T-NH-sd-SMP-hp | 22 - .../configs/rcu/v3.12/N6---t-nh-SD-smp-hp | 19 .../configs/rcu/v3.12/N7-4-T-NH-SD-SMP-HP | 26 -- .../configs/rcu/v3.12/N8-2-T-NH-SD-SMP-HP | 22 - .../selftests/rcutorture/configs/rcu/v3.12/NT1-nh | 23 - .../selftests/rcutorture/configs/rcu/v3.12/NT3-NH | 20 .../configs/rcu/v3.12/P1-S-T-NH-SD-SMP-HP | 20 .../configs/rcu/v3.12/P2-2-t-nh-sd-SMP-hp | 20 .../configs/rcu/v3.12/P3-3-T-nh-SD-SMP-hp | 20 .../configs/rcu/v3.12/P4-A-t-NH-sd-SMP-HP | 22 - .../configs/rcu/v3.12/P5-U-T-NH-sd-SMP-hp | 27 -- .../configs/rcu/v3.12/P6---t-nh-SD-smp-hp | 18 --- .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-HP | 30 .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-HP-all | 30 .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-HP-none | 30 .../configs/rcu/v3.12/P7-4-T-NH-SD-SMP-hp | 30 .../selftests/rcutorture/configs/rcu/v3.12/PT1-nh | 23 - .../selftests/rcutorture/configs/rcu/v3.12/PT2-NH | 22 - .../selftests/rcutorture/configs/rcu/v3.3/CFLIST | 14 -- .../configs/rcu/v3.3/N1-S-T-NH-SD-SMP-HP | 19 .../configs/rcu/v3.3/N2-2-t-nh-sd-SMP-hp | 20 .../configs/rcu/v3.3/N3-3-T-nh-SD-SMP-hp | 22 - .../configs/rcu/v3.3/N4-A-t-NH-sd-SMP-HP | 18 --- .../configs/rcu/v3.3/N5-U-T-NH-sd-SMP-hp | 22 - .../selftests/rcutorture/configs/rcu/v3.3/NT1-nh | 23 - .../selftests/rcutorture/configs/rcu/v3.3/NT3-NH | 20 .../configs/rcu/v3.3/P1-S-T-NH-SD-SMP-HP | 20 .../configs/rcu/v3.3/P2-2-t-nh-sd-SMP-hp | 20 .../configs/rcu/v3.3/P3-3-T-nh-SD-SMP-hp | 20 .../configs/rcu/v3.3/P4-A-t-NH-sd-SMP-HP | 22 - .../configs/rcu/v3.3/P5-U-T-NH-sd-SMP-hp | 27 -- .../selftests/rcutorture/configs/rcu/v3.3/PT1-nh | 23 - .../selftests/rcutorture/configs/rcu/v3.3/PT2-NH | 22 - .../rcutorture/configs/rcu/v3.3/ver_functions.sh | 44 - .../selftests/rcutorture/configs/rcu/v3.5/CFLIST | 14 -- .../configs/rcu/v3.5/N1-S-T-NH-SD-SMP-HP | 19 .../configs/rcu/v3.5/N2-2-t-nh-sd-SMP-hp | 20 .../configs/rcu/v3.5/N3-3-T-nh-SD-SMP-hp | 22 - .../configs/rcu/v3.5/N4-A-t-NH-sd-SMP-HP | 18 --- .../configs/rcu/v3.5/N5-U-T-NH-sd-SMP-hp | 22 - .../selftests/rcutorture/configs/rcu/v3.5/NT1-nh | 23 - .../selftests/rcutorture/configs/rcu/v3.5/NT3-NH | 20 .../configs/rcu/v3.5/P1-S-T-NH-SD-SMP-HP | 20 .../configs/rcu/v3.5/P2-2-t-nh-sd-SMP-hp | 20 .../configs/rcu/v3.5/P3-3-T-nh-SD-SMP-hp | 20 .../configs/rcu/v3.5/P4-A-t-NH-sd-SMP-HP | 22 - .../configs/rcu/v3.5/P5-U-T-NH-sd-SMP-hp | 27 -- .../selftests/rcutorture/configs/rcu/v3.5/PT1-nh | 23 - .../selftests/rcutorture/configs/rcu/v3.5/PT2-NH | 22 - .../rcutorture/configs/rcu/v3.5/ver_functions.sh | 57 -- 71 files changed, 1588 deletions(-) delete mode 100644 tools/testing/selftests/rcutorture/configs/rcu/v0.0/CFLIST delete mode 100644
Re: [GIT PULL 0/8] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > Best Regards, > > - Arnaldo > > The following changes since commit 07394b5f13a04f86b27e0ddd96a36c7d9bfe1a4f: > > Merge tag 'perf-core-for-mingo' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > (2014-09-27 09:15:48 +0200) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo > > for you to fetch changes up to 281f92f233a59ef52bb45287242bd815a67f5647: > > perf record: Fix error message for --filter option not coming after > tracepoint (2014-10-01 15:05:32 -0300) > > > perf/core improvements and fixes: > > User visible: > > . Fix mmap return address truncation to 32-bit in 'perf trace'. (Chang Hyun > Park) > > o Support operations for shared futexes. (Davidlohr Bueso) > > . Fix error message for --filter option not coming after tracepoint. (Arnaldo > Carvalho de Melo) > > Infrastructure: > > . Refactor unit and scale function parameters for pmu parsing routines. (Matt > Fleming) > > . Improve DSO long names lookup with rbtree, resulting in great speedup for > workloads with lots of DSOs. (Waiman Long) > > . Fix build breakage on arm64 targets. (Will Deacon) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (1): > perf record: Fix error message for --filter option not coming after > tracepoint > > Chang Hyun Park (1): > perf trace: Fix mmap return address truncation to 32-bit > > Davidlohr Bueso (2): > perf bench futex: Support operations for shared futexes > perf bench futex: Sanitize -q option in requeue > > Matt Fleming (1): > perf tools: Refactor unit and scale function parameters > > Waiman Long (2): > perf symbols: Encapsulate dsos list head into struct dsos > perf symbols: Improve DSO long names lookup speed with rbtree > > Will Deacon (1): > perf tools: Fix build breakage on arm64 targets > > tools/perf/arch/arm64/util/unwind-libunwind.c | 1 + > tools/perf/bench/futex-hash.c | 7 ++- > tools/perf/bench/futex-requeue.c | 28 + > tools/perf/bench/futex-wake.c | 15 +++-- > tools/perf/builtin-trace.c| 6 +- > tools/perf/util/dso.c | 85 > +++ > tools/perf/util/dso.h | 16 - > tools/perf/util/header.c | 32 +- > tools/perf/util/machine.c | 25 > tools/perf/util/machine.h | 5 +- > tools/perf/util/parse-events.c| 11 ++-- > tools/perf/util/pmu.c | 38 +++- > tools/perf/util/pmu.h | 7 ++- > tools/perf/util/probe-event.c | 3 +- > tools/perf/util/symbol-elf.c | 7 ++- > 15 files changed, 200 insertions(+), 86 deletions(-) Pulled into tip:perf/core, thanks a lot Arnaldo! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] block: disable entropy contributions from nonrot devices
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Mike Snitzer
> Sent: Thursday, 02 October, 2014 7:11 PM
> To: ax...@kernel.dk; linux-kernel@vger.kernel.org
> Cc: ty...@mit.edu; gmazyl...@gmail.com; a...@redhat.com; mpato...@redhat.com
> Subject: [PATCH] block: disable entropy contributions from nonrot devices
>
> Introduce queue_flags_set_nonrot_clear_add_random() and convert all
> block drivers that set QUEUE_FLAG_NONROT over to using it instead.
>
> Historically, all block devices have automatically made entropy
> contributions. But as previously stated in commit e2e1a148 ("block: add
> sysfs knob for turning off disk entropy contributions"):
> - On SSD disks, the completion times aren't as random as they
> are for rotational drives. So it's questionable whether they
> should contribute to the random pool in the first place.
> - Calling add_disk_randomness() has a lot of overhead.
>
> There are more reliable sources for randomness than non-rotational block
> devices. From a security perspective it is better to err on the side of
> caution than to allow entropy contributions from unreliable "random"
> sources.
blk-mq defaults to off (QUEUE_FLAG_MQ_DEFAULT does not
include QUEUE_FLAG_ADD_RANDOM).
Even when it's off in block layer completion processing, all interrupts,
storage or not, are forced to contribute during hardirq processing.
I've seen this add 3-12 us latency blips every 64 interrupts (when
the "fast_mix" code runs out of bits).
Example of fast_mix only taking 0.071 us:
(from ftrace function_graph)
8) |
handle_irq_event() {
8) |
handle_irq_event_percpu() {
8) |
do_hpsa_intr_msi [hpsa]() {
8) 0.060 us|
SA5_performant_completed [hpsa]();
8) 0.397 us| }
8) 0.071 us|
add_interrupt_randomness();
8) 0.071 us|
note_interrupt();
8) 1.495 us|}
8) 0.045 us|
_raw_spin_lock();
8) 2.165 us| }
Example of the 64th bit taking 3.814 us:
8) |handle_irq_event() {
8) |
handle_irq_event_percpu() {
...
8) |
add_interrupt_randomness() {
8) |
__mix_pool_bytes() {
8) 0.312 us|
_mix_pool_bytes();
8) 0.688 us| }
8) |
credit_entropy_bits() {
8) |__wake_up() {
8) 0.070 us|
_raw_spin_lock_irqsave();
8) 0.050 us|
__wake_up_common();
8) 0.056 us|
_raw_spin_unlock_irqrestore();
8) 1.448 us|}
8) 0.048 us|kill_fasync();
8) 2.313 us| }
8) 3.814 us|}
---
Rob ElliottHP Server Storage
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/4] pmbus: ltc2978: add regulator support
On 10/02/2014 11:37 AM, at...@opensource.altera.com wrote:
From: Alan Tull
Add simple on/off regulator support for ltc2978 and
other pmbus parts supported by ltc2978.c
Signed-off-by: Alan Tull
---
v2: Remove '#include '
Only one regulator per pmbus device
Get regulator_init_data from pdata or device tree
v3: Support multiple regulators for each chip
Move most code to pmbus_core.c
fixed values for on/off
v4: fix a #endif comment
simplify probe code, remove added switch statement
remove BUG_ON(), add error message and fix num_regulators
v5: Kconfig: update list of supported chips
use "regulator: of: Provide simplified DT parsing method"
remove #include
remove of_regulator_match
---
drivers/hwmon/pmbus/Kconfig | 11 +--
drivers/hwmon/pmbus/ltc2978.c | 24
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 6e1e493..a674cd8 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -47,15 +47,22 @@ config SENSORS_LM25066
be called lm25066.
config SENSORS_LTC2978
- tristate "Linear Technologies LTC2974, LTC2978, LTC3880, and LTC3883"
+ tristate "Linear Technologies LTC2978 and compatibles"
default n
help
If you say yes here you get hardware monitoring support for Linear
- Technology LTC2974, LTC2978, LTC3880, and LTC3883.
+ Technology LTC2974, LTC2977, LTC2978, LTC3880, LTC3883, and LTM4676.
This driver can also be built as a module. If so, the module will
be called ltc2978.
+config SENSORS_LTC2978_REGULATOR
+ boolean "Regulator support for LTC2978 and compatibles"
+ depends on SENSORS_LTC2978 && REGULATOR
+ help
+ If you say yes here you get regulator support for Linear
+ Technology LTC2974, LTC2977, LTC2978, LTC3880, LTC3883, and LTM4676.
+
config SENSORS_MAX16064
tristate "Maxim MAX16064"
default n
diff --git a/drivers/hwmon/pmbus/ltc2978.c b/drivers/hwmon/pmbus/ltc2978.c
index e24ed52..efac4bf 100644
--- a/drivers/hwmon/pmbus/ltc2978.c
+++ b/drivers/hwmon/pmbus/ltc2978.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "pmbus.h"
enum chips { ltc2974, ltc2977, ltc2978, ltc3880, ltc3883, ltm4676 };
@@ -374,6 +375,19 @@ static const struct i2c_device_id ltc2978_id[] = {
};
MODULE_DEVICE_TABLE(i2c, ltc2978_id);
+#if IS_ENABLED(CONFIG_SENSORS_LTC2978_REGULATOR)
+static const struct regulator_desc ltc2978_reg_desc[] = {
+ PMBUS_REGULATOR("vout_en", 0),
+ PMBUS_REGULATOR("vout_en", 1),
+ PMBUS_REGULATOR("vout_en", 2),
+ PMBUS_REGULATOR("vout_en", 3),
+ PMBUS_REGULATOR("vout_en", 4),
+ PMBUS_REGULATOR("vout_en", 5),
+ PMBUS_REGULATOR("vout_en", 6),
+ PMBUS_REGULATOR("vout_en", 7),
+};
+#endif /* CONFIG_SENSORS_LTC2978_REGULATOR */
+
static int ltc2978_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -487,6 +501,16 @@ static int ltc2978_probe(struct i2c_client *client,
default:
return -ENODEV;
}
+
+#if IS_ENABLED(CONFIG_SENSORS_LTC2978_REGULATOR)
+ info->num_regulators = info->pages;
+ info->reg_desc = ltc2978_reg_desc;
+ if (info->num_regulators > ARRAY_SIZE(ltc2978_reg_desc)) {
+ dev_err(>dev, "num_regulators too large!");
+ info->num_regulators = ARRAY_SIZE(ltc2978_reg_desc);
+ }
+#endif
+
return pmbus_do_probe(client, id, info);
}
Unfortunately the code now only compiles in -next, since the following
fields are only defined there.
drivers/hwmon/pmbus/ltc2978.c:380:2: error: unknown field 'of_match' specified
in initializer
drivers/hwmon/pmbus/ltc2978.c:380:2: error: unknown field 'regulators_node'
specified in initializer
This means I can not apply the code unless I pull in the relevant changes.
Mark, do you have an immutable branch / tag for me to merge ?
If not this patch series will have to wait until the relevant regulator
changes are available in mainline.
On a side note, I am not too happy with the following comment in the
"Provide simplified DT parsing method" patch: "The current code leaks
the phandles for the child nodes, this will be addressed incrementally
and makes no practical difference for FDT anyway as the DT data
structures are never freed".
My use case includes instantiating the LTC chips through devicetree overlays,
which obviously does not work well with leaking DT nodes.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 1/5] audit: implement audit by executable
From: Eric Paris
This patch implements the ability to filter on the executable. It is
clearly incomplete! This patch adds the inode/dev of the executable at
the moment the rule is loaded. It does not update if the executable is
updated/moved/whatever. That should be added. But at this moment, this
patch works.
Based-on-user-interface-by: Richard Guy Briggs
Cc: r...@redhat.com
Based-on-idea-by: Peter Moody
Cc: pmo...@google.com
Signed-off-by: Eric Paris
Signed-off-by: Richard Guy Briggs
---
include/linux/audit.h |1 +
include/uapi/linux/audit.h |2 +
kernel/Makefile|2 +-
kernel/audit.h | 32 +
kernel/audit_exe.c | 109
kernel/auditfilter.c | 44 ++
kernel/auditsc.c | 16 ++
7 files changed, 205 insertions(+), 1 deletions(-)
create mode 100644 kernel/audit_exe.c
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 36dffec..ce51204 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -59,6 +59,7 @@ struct audit_krule {
struct audit_field *inode_f; /* quick access to an inode field */
struct audit_watch *watch; /* associated watch */
struct audit_tree *tree; /* associated watched tree */
+ struct audit_exe*exe;
struct list_headrlist; /* entry in audit_{watch,tree}.rules
list */
struct list_headlist; /* for AUDIT_LIST* purposes only */
u64 prio;
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 4d100c8..101d344 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -266,6 +266,8 @@
#define AUDIT_OBJ_UID 109
#define AUDIT_OBJ_GID 110
#define AUDIT_FIELD_COMPARE111
+#define AUDIT_EXE 112
+#define AUDIT_EXE_CHILDREN 113
#define AUDIT_ARG0 200
#define AUDIT_ARG1 (AUDIT_ARG0+1)
diff --git a/kernel/Makefile b/kernel/Makefile
index f2a8b62..60def04 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_SMP) += stop_machine.o
obj-$(CONFIG_KPROBES_SANITY_TEST) += test_kprobes.o
obj-$(CONFIG_AUDIT) += audit.o auditfilter.o
obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
-obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o
+obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o audit_exe.o
obj-$(CONFIG_AUDIT_TREE) += audit_tree.o
obj-$(CONFIG_GCOV_KERNEL) += gcov/
obj-$(CONFIG_KPROBES) += kprobes.o
diff --git a/kernel/audit.h b/kernel/audit.h
index 3cdffad..7825c7e 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -56,6 +56,7 @@ enum audit_state {
/* Rule lists */
struct audit_watch;
+struct audit_exe;
struct audit_tree;
struct audit_chunk;
@@ -279,6 +280,13 @@ extern int audit_add_watch(struct audit_krule *krule,
struct list_head **list);
extern void audit_remove_watch_rule(struct audit_krule *krule);
extern char *audit_watch_path(struct audit_watch *watch);
extern int audit_watch_compare(struct audit_watch *watch, unsigned long ino,
dev_t dev);
+
+int audit_make_exe_rule(struct audit_krule *krule, char *pathname, int len,
u32 op);
+void audit_remove_exe_rule(struct audit_krule *krule);
+char *audit_exe_path(struct audit_exe *exe);
+int audit_dup_exe(struct audit_krule *new, struct audit_krule *old);
+int audit_exe_compare(struct task_struct *tsk, struct audit_exe *exe);
+
#else
#define audit_put_watch(w) {}
#define audit_get_watch(w) {}
@@ -288,6 +296,30 @@ extern int audit_watch_compare(struct audit_watch *watch,
unsigned long ino, dev
#define audit_watch_path(w) ""
#define audit_watch_compare(w, i, d) 0
+static inline int audit_make_exe_rule(struct audit_krule *krule, char
*pathname, int len, u32 op)
+{
+ return -EINVAL;
+}
+static inline void audit_remove_exe_rule(struct audit_krule *krule)
+{
+ BUG();
+ return 0;
+}
+static inline char *audit_exe_path(struct audit_exe *exe)
+{
+ BUG();
+ return "";
+}
+static inline int audit_dup_exe(struct audit_krule *new, struct audit_krule
*old)
+{
+ BUG();
+ return -EINVAL
+}
+static inline int audit_exe_compare(struct task_struct *tsk, struct audit_exe
*exe)
+{
+ BUG();
+ return 0;
+}
#endif /* CONFIG_AUDIT_WATCH */
#ifdef CONFIG_AUDIT_TREE
diff --git a/kernel/audit_exe.c b/kernel/audit_exe.c
new file mode 100644
index 000..ec3231b
--- /dev/null
+++ b/kernel/audit_exe.c
@@ -0,0 +1,109 @@
+/* audit_exe.c -- filtering of audit events
+ *
+ * Copyright 2014 Red Hat, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A
[PATCH V5 4/5] audit: avoid double copying the audit_exe path string
Make this interface consistent with watch and filter key, avoiding the extra
string copy and simply consume the new string pointer.
Signed-off-by: Richard Guy Briggs
---
kernel/audit_exe.c |5 -
kernel/audit_fsnotify.c | 12 ++--
kernel/auditfilter.c|2 +-
3 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/kernel/audit_exe.c b/kernel/audit_exe.c
index 0c7ee8d..ff6e3d6 100644
--- a/kernel/audit_exe.c
+++ b/kernel/audit_exe.c
@@ -27,10 +27,13 @@ int audit_dup_exe(struct audit_krule *new, struct
audit_krule *old)
struct audit_fsnotify_mark *audit_mark;
char *pathname;
- pathname = audit_mark_path(old->exe);
+ pathname = kstrdup(audit_mark_path(old->exe), GFP_KERNEL);
+ if (!pathname)
+ return -ENOMEM;
audit_mark = audit_alloc_mark(new, pathname, strlen(pathname));
if (IS_ERR(audit_mark))
+ kfree(pathname);
return PTR_ERR(audit_mark);
new->exe = audit_mark;
diff --git a/kernel/audit_fsnotify.c b/kernel/audit_fsnotify.c
index f4b3e66..6daf5c3 100644
--- a/kernel/audit_fsnotify.c
+++ b/kernel/audit_fsnotify.c
@@ -94,7 +94,6 @@ struct audit_fsnotify_mark *audit_alloc_mark(struct
audit_krule *krule, char *pa
struct dentry *dentry;
struct inode *inode;
unsigned long ino;
- char *local_pathname;
dev_t dev;
int ret;
@@ -115,20 +114,13 @@ struct audit_fsnotify_mark *audit_alloc_mark(struct
audit_krule *krule, char *pa
ino = dentry->d_inode->i_ino;
}
- audit_mark = ERR_PTR(-ENOMEM);
- local_pathname = kstrdup(pathname, GFP_KERNEL);
- if (!local_pathname)
- goto out;
-
audit_mark = kzalloc(sizeof(*audit_mark), GFP_KERNEL);
- if (unlikely(!audit_mark)) {
- kfree(local_pathname);
+ if (unlikely(!audit_mark))
goto out;
- }
fsnotify_init_mark(_mark->mark, audit_free_fsnotify_mark);
audit_mark->mark.mask = AUDIT_FS_EVENTS;
- audit_mark->path = local_pathname;
+ audit_mark->path = pathname;
audit_mark->ino = ino;
audit_mark->dev = dev;
audit_mark->rule = krule;
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index fff92cf..570e79a 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -575,8 +575,8 @@ static struct audit_entry *audit_data_to_entry(struct
audit_rule_data *data,
entry->rule.buflen += f->val;
audit_mark = audit_alloc_mark(>rule, str,
f->val);
- kfree(str);
if (IS_ERR(audit_mark)) {
+ kfree(str);
err = PTR_ERR(audit_mark);
goto exit_free;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 2/5] audit: clean simple fsnotify implementation
From: Eric Paris
This is to be used to audit by executable rules, but audit watches
should be able to share this code eventually.
At the moment the audit watch code is a lot more complex, that code only
creates one fsnotify watch per parent directory. That 'audit_parent' in
turn has a list of 'audit_watches' which contain the name, ino, dev of
the specific object we care about. This just creates one fsnotify watch
per object we care about. So if you watch 100 inodes in /etc this code
will create 100 fsnotify watches on /etc. The audit_watch code will
instead create 1 fsnotify watch on /etc (the audit_parent) and then 100
individual watches chained from that fsnotify mark.
We should be able to convert the audit_watch code to do one fsnotify
mark per watch and simplify things/remove a whole lot of code. After
that conversion we should be able to convert the audit_fsnotify code to
support that hierarchy if the optomization is necessary.
RGB: Move the access to the entry for audit_match_signal() to the beginning of
the function in case the entry found is the same one passed in. This will
enable it to be used by audit_remove_mark_rule().
RGB: Rename several "watch" references to "mark".
RGB: Rename audit_remove_rule() to audit_remove_mark_rule().
RGB: Let audit_free_rule() take care of calling audit_remove_mark().
RGB: Put audit_alloc_mark() arguments in same order as watch, tree and inode.
RGB: Remove space from audit log value text in audit_remove_mark_rule().
Signed-off-by: Eric Paris
Signed-off-by: Richard Guy Briggs
---
kernel/Makefile |2 +-
kernel/audit.h | 29 ++
kernel/audit_fsnotify.c | 245 +++
kernel/auditfilter.c| 10 +-
4 files changed, 280 insertions(+), 6 deletions(-)
create mode 100644 kernel/audit_fsnotify.c
diff --git a/kernel/Makefile b/kernel/Makefile
index 60def04..e82583f 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_SMP) += stop_machine.o
obj-$(CONFIG_KPROBES_SANITY_TEST) += test_kprobes.o
obj-$(CONFIG_AUDIT) += audit.o auditfilter.o
obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
-obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o audit_exe.o
+obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o audit_exe.o audit_fsnotify.o
obj-$(CONFIG_AUDIT_TREE) += audit_tree.o
obj-$(CONFIG_GCOV_KERNEL) += gcov/
obj-$(CONFIG_KPROBES) += kprobes.o
diff --git a/kernel/audit.h b/kernel/audit.h
index 7825c7e..b8ecc06 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -56,6 +56,7 @@ enum audit_state {
/* Rule lists */
struct audit_watch;
+struct audit_fsnotify_mark;
struct audit_exe;
struct audit_tree;
struct audit_chunk;
@@ -266,6 +267,7 @@ struct audit_net {
extern int selinux_audit_rule_update(void);
extern struct mutex audit_filter_mutex;
+extern int audit_del_rule(struct audit_entry *);
extern void audit_free_rule_rcu(struct rcu_head *);
extern struct list_head audit_filter_list[];
@@ -281,6 +283,11 @@ extern void audit_remove_watch_rule(struct audit_krule
*krule);
extern char *audit_watch_path(struct audit_watch *watch);
extern int audit_watch_compare(struct audit_watch *watch, unsigned long ino,
dev_t dev);
+struct audit_fsnotify_mark *audit_alloc_mark(struct audit_krule *krule, char
*pathname, int len);
+char *audit_mark_path(struct audit_fsnotify_mark *mark);
+void audit_remove_mark(struct audit_fsnotify_mark *audit_mark);
+int audit_mark_compare(struct audit_fsnotify_mark *mark, unsigned long ino,
dev_t dev);
+
int audit_make_exe_rule(struct audit_krule *krule, char *pathname, int len,
u32 op);
void audit_remove_exe_rule(struct audit_krule *krule);
char *audit_exe_path(struct audit_exe *exe);
@@ -296,6 +303,28 @@ int audit_exe_compare(struct task_struct *tsk, struct
audit_exe *exe);
#define audit_watch_path(w) ""
#define audit_watch_compare(w, i, d) 0
+static inline struct audit_fsnotify_mark *audit_alloc_mark(struct audit_krule
*krule, char *pathname, int len)
+{
+ return ERR_PTR(-EINVAL);
+}
+
+static inline char *audit_mark_path(struct audit_fsnotify_mark *mark)
+{
+ BUG();
+ return "";
+}
+
+static inline void audit_remove_mark(struct audit_fsnotify_mark *audit_mark)
+{
+ BUG();
+}
+
+static inline int audit_mark_compare(struct audit_fsnotify_mark *mark,
unsigned long ino, dev_t dev)
+{
+ BUG();
+ return 0;
+}
+
static inline int audit_make_exe_rule(struct audit_krule *krule, char
*pathname, int len, u32 op)
{
return -EINVAL;
diff --git a/kernel/audit_fsnotify.c b/kernel/audit_fsnotify.c
new file mode 100644
index 000..f4b3e66
--- /dev/null
+++ b/kernel/audit_fsnotify.c
@@ -0,0 +1,245 @@
+/* audit_fsnotify.c -- tracking inodes
+ *
+ * Copyright 2003-2009 Red Hat, Inc.
+ * Copyright 2005 Hewlett-Packard Development Company, L.P.
+ * Copyright 2005 IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as
[PATCH V5 5/5] Revert "fixup! audit: clean simple fsnotify implementation"
This reverts commit 826a3dbd65f0fdb1d7ddfa2849de700f360e1494.
"Let audit_free_rule() take care of calling audit_remove_mark()."
It was causing a group mark deadlock.
With kernel locking debugging config options enabled, I get the following
output. Could I get some help interpreting it?
I thought I had done a fairly careful job of justifying to myself that the mark
remove should be moved from audit_free_rule() to audit_del_rule(), but
evidently it wasn't happy.
[root@c1-f18 ~]# killall auditd;sleep 1;/usr/local/sbin/auditd
[root@c1-f18 ~]# /usr/local/sbin/auditctl -l
No rules
[root@c1-f18 ~]# /usr/local/sbin/auditctl -a always,exit -F dir=/tmp -F
exe=/usr/sbin/touch -F key=touch_tmp
[root@c1-f18 ~]# /usr/local/sbin/auditctl -l
-a always,exit -S all -F dir=/tmp -F exe=/usr/sbin/touch -F key=touch_tmp
[root@c1-f18 ~]# /usr/local/sbin/auditctl -d always,exit -F dir=/tmp -F
exe=/usr/sbin/touch -F key=touch_tmp
[root@c1-f18 ~]# [ 53.824114] BUG: sleeping function called from invalid
context at kernel/locking/mutex.c:616
[ 53.825152] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/3
[ 53.826154]
[ 53.826349] =
[ 53.826854] [ INFO: inconsistent lock state ]
[ 53.827108] 3.14.0-bz837856-audit-filter-name-v2+ #280 Not tainted
[ 53.827108] -
[ 53.827108] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 53.827108] swapper/3/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 53.827108] (>mark_mutex/1){+.?...}, at: []
fsnotify_destroy_mark+0x33/0x60
[ 53.827108] {SOFTIRQ-ON-W} state was registered at:
[ 53.827108] [] __lock_acquire+0x7d3/0x1890
[ 53.827108] [] lock_acquire+0xaa/0x180
[ 53.827108] [] mutex_lock_nested+0x6d/0x4e0
[ 53.827108] []
fsnotify_clear_marks_by_group_flags+0x3b/0xc0
[ 53.827108] [] fsnotify_clear_marks_by_group+0x13/0x20
[ 53.827108] [] fsnotify_destroy_group+0x16/0x50
[ 53.827108] [] inotify_release+0x68/0x80
[ 53.827108] [] __fput+0x115/0x2a0
[ 53.827108] [] fput+0xe/0x10
[ 53.827108] [] task_work_run+0xad/0xe0
[ 53.827108] [] do_notify_resume+0x97/0xd0
[ 53.827108] [] int_signal+0x12/0x17
[ 53.827108] irq event stamp: 2397788
[ 53.827108] hardirqs last enabled at (2397788): []
vprintk_emit+0x119/0x630
[ 53.827108] hardirqs last disabled at (2397787): []
vprintk_emit+0xa4/0x630
[ 53.827108] softirqs last enabled at (2397606): []
_local_bh_enable+0x9c/0xd0
[ 53.827108] softirqs last disabled at (2397607): []
irq_exit+0x105/0x110
[ 53.827108]
[ 53.827108] other info that might help us debug this:
[ 53.827108] Possible unsafe locking scenario:
[ 53.827108]
[ 53.827108]CPU0
[ 53.827108]
[ 53.827108] lock(>mark_mutex/1);
[ 53.827108]
[ 53.827108] lock(>mark_mutex/1);
[ 53.827108]
[ 53.827108] *** DEADLOCK ***
[ 53.827108]
[ 53.827108] 1 lock held by swapper/3/0:
[ 53.827108] #0: (rcu_callback){.+}, at: []
rcu_process_callbacks+0x577/0xd00
[ 53.827108]
[ 53.827108] stack backtrace:
[ 53.827108] CPU: 3 PID: 0 Comm: swapper/3 Not tainted
3.14.0-bz837856-audit-filter-name-v2+ #280
[ 53.827108] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
[ 53.827108] 825e90a0 88003e403b18 817e8908
88003d2e
[ 53.827108] 88003d2e 88003e403b68 810ecf4f
0001
[ 53.827108] 0001 825e9138
88003d2e0848
[ 53.827108] Call Trace:
[ 53.827108][] dump_stack+0x51/0x71
[ 53.827108] [] print_usage_bug+0x22f/0x280
[ 53.827108] [] mark_lock+0x392/0x470
[ 53.827108] [] __lock_acquire+0x788/0x1890
[ 53.827108] [] ? show_stack_log_lvl+0xb6/0x1a0
[ 53.827108] [] lock_acquire+0xaa/0x180
[ 53.827108] [] ? fsnotify_destroy_mark+0x33/0x60
[ 53.827108] [] ? fsnotify_destroy_mark+0x33/0x60
[ 53.827108] [] mutex_lock_nested+0x6d/0x4e0
[ 53.827108] [] ? fsnotify_destroy_mark+0x33/0x60
[ 53.827108] [] ? sched_clock_local+0x43/0xb0
[ 53.827108] [] ? sched_clock_cpu+0x128/0x130
[ 53.827108] [] fsnotify_destroy_mark+0x33/0x60
[ 53.827108] [] audit_remove_mark+0x21/0x30
[ 53.827108] [] audit_free_rule_rcu+0x38/0xc0
[ 53.827108] [] rcu_process_callbacks+0xc54/0xd00
[ 53.827108] [] ? rcu_process_callbacks+0x577/0xd00
[ 53.827108] [] ? _raw_spin_unlock_irq+0x30/0x50
[ 53.827108] [] ? run_timer_softirq+0x1c0/0x350
[ 53.827108] [] ? audit_filter_type+0x260/0x260
[ 53.827108] [] __do_softirq+0x134/0x530
[ 53.827108] [] irq_exit+0x105/0x110
[ 53.827108] [] smp_apic_timer_interrupt+0x4a/0x60
[ 53.827108] [] apic_timer_interrupt+0x72/0x80
[ 53.827108][] ? rcu_eqs_enter_common+0x1c4/0x410
[ 53.827108] [] ? native_safe_halt+0x6/0x10
[ 53.827108] [] ? trace_hardirqs_on+0xd/0x10
[ 53.827108] [] default_idle+0x24/0x240
[ 53.827108] [] arch_cpu_idle+0x2e/0x40
[ 53.827108] [] cpu_startup_entry+0x2db/0x430
[
[PATCH V5 3/5] audit: convert audit_exe to audit_fsnotify
From: Eric Paris
Instead of just hard coding the ino and dev of the executable we care
about at the moment the rule is inserted into the kernel, use the new
audit_fsnotify infrastructure. This means that if the inode in question
is unlinked and creat'd (aka updated) the rule will just continue to
work.
Signed-off-by: Eric Paris
Signed-off-by: Richard Guy Briggs
---
include/linux/audit.h |2 +-
kernel/audit.h| 32 +++---
kernel/audit_exe.c| 87 +++--
kernel/auditfilter.c | 15 +---
4 files changed, 27 insertions(+), 109 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index ce51204..0ffa268 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -59,7 +59,7 @@ struct audit_krule {
struct audit_field *inode_f; /* quick access to an inode field */
struct audit_watch *watch; /* associated watch */
struct audit_tree *tree; /* associated watched tree */
- struct audit_exe*exe;
+ struct audit_fsnotify_mark *exe;
struct list_headrlist; /* entry in audit_{watch,tree}.rules
list */
struct list_headlist; /* for AUDIT_LIST* purposes only */
u64 prio;
diff --git a/kernel/audit.h b/kernel/audit.h
index b8ecc06..9821732 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -57,7 +57,6 @@ enum audit_state {
/* Rule lists */
struct audit_watch;
struct audit_fsnotify_mark;
-struct audit_exe;
struct audit_tree;
struct audit_chunk;
@@ -288,11 +287,8 @@ char *audit_mark_path(struct audit_fsnotify_mark *mark);
void audit_remove_mark(struct audit_fsnotify_mark *audit_mark);
int audit_mark_compare(struct audit_fsnotify_mark *mark, unsigned long ino,
dev_t dev);
-int audit_make_exe_rule(struct audit_krule *krule, char *pathname, int len,
u32 op);
-void audit_remove_exe_rule(struct audit_krule *krule);
-char *audit_exe_path(struct audit_exe *exe);
int audit_dup_exe(struct audit_krule *new, struct audit_krule *old);
-int audit_exe_compare(struct task_struct *tsk, struct audit_exe *exe);
+int audit_exe_compare(struct task_struct *tsk, struct audit_fsnotify_mark
*mark);
#else
#define audit_put_watch(w) {}
@@ -319,36 +315,18 @@ static inline void audit_remove_mark(struct
audit_fsnotify_mark *audit_mark)
BUG();
}
-static inline int audit_mark_compare(struct audit_fsnotify_mark *mark,
unsigned long ino, dev_t dev)
+static inline int audit_exe_compare(struct task_struct *tsk, struct
audit_fsnotify_mark *mark)
{
BUG();
- return 0;
-}
-
-static inline int audit_make_exe_rule(struct audit_krule *krule, char
*pathname, int len, u32 op)
-{
return -EINVAL;
}
-static inline void audit_remove_exe_rule(struct audit_krule *krule)
-{
- BUG();
- return 0;
-}
-static inline char *audit_exe_path(struct audit_exe *exe)
-{
- BUG();
- return "";
-}
+
static inline int audit_dup_exe(struct audit_krule *new, struct audit_krule
*old)
{
BUG();
- return -EINVAL
-}
-static inline int audit_exe_compare(struct task_struct *tsk, struct audit_exe
*exe)
-{
- BUG();
- return 0;
+ return -EINVAL;
}
+
#endif /* CONFIG_AUDIT_WATCH */
#ifdef CONFIG_AUDIT_TREE
diff --git a/kernel/audit_exe.c b/kernel/audit_exe.c
index ec3231b..0c7ee8d 100644
--- a/kernel/audit_exe.c
+++ b/kernel/audit_exe.c
@@ -17,93 +17,30 @@
#include
#include
-#include
#include
#include
#include
#include "audit.h"
-struct audit_exe {
- char *pathname;
- unsigned long ino;
- dev_t dev;
-};
-
-/* Translate a watch string to kernel respresentation. */
-int audit_make_exe_rule(struct audit_krule *krule, char *pathname, int len,
u32 op)
-{
- struct audit_exe *exe;
- struct path path;
- struct dentry *dentry;
- unsigned long ino;
- dev_t dev;
-
- if (pathname[0] != '/' || pathname[len-1] == '/')
- return -EINVAL;
-
- dentry = kern_path_locked(pathname, );
- if (IS_ERR(dentry))
- return PTR_ERR(dentry);
- mutex_unlock(>d_inode->i_mutex);
-
- if (!dentry->d_inode)
- return -ENOENT;
- dev = dentry->d_inode->i_sb->s_dev;
- ino = dentry->d_inode->i_ino;
- dput(dentry);
-
- exe = kmalloc(sizeof(*exe), GFP_KERNEL);
- if (!exe)
- return -ENOMEM;
- exe->ino = ino;
- exe->dev = dev;
- exe->pathname = pathname;
- krule->exe = exe;
-
- return 0;
-}
-
-void audit_remove_exe_rule(struct audit_krule *krule)
-{
- struct audit_exe *exe;
-
- exe = krule->exe;
- krule->exe = NULL;
- kfree(exe->pathname);
- kfree(exe);
-}
-
-char *audit_exe_path(struct audit_exe *exe)
-{
- return exe->pathname;
-}
-
int audit_dup_exe(struct audit_krule *new, struct audit_krule *old)
{
- struct audit_exe *exe;
-
- exe =
[PATCH V5 0/5] audit by executable name
This is a part of Peter Moody, my and Eric Paris' work to implement audit by executable name. Please see the accompanying userspace patch: https://www.redhat.com/archives/linux-audit/2014-May/msg00019.html The userspace interface is not expected to change appreciably unless something important has been overlooked. Setting and deleting rules works as expected. If the path does not exist at rule creation time, it will be re-evaluated every time there is a change to the parent directory at which point the change in device and inode will be noted. Here's a sample run: # /usr/local/sbin/auditctl -a always,exit -F dir=/tmp -F exe=/bin/touch -F key=touch_tmp # /usr/local/sbin/ausearch --start recent -k touch_tmp time->Mon Jun 30 14:15:06 2014 type=CONFIG_CHANGE msg=audit(1404152106.683:149): auid=0 ses=1 subj=unconfined_u :unconfined_r:auditctl_t:s0-s0:c0.c1023 op="add_rule" key="touch_tmp" list=4 res =1 # /usr/local/sbin/auditctl -l -a always,exit -S all -F dir=/tmp -F exe=/bin/touch -F key=touch_tmp # touch /tmp/test # /usr/local/sbin/ausearch --start recent -k touch_tmp time->Wed Jul 2 12:18:47 2014 type=UNKNOWN[1327] msg=audit(1404317927.319:132): proctitle=746F756368002F746D702F74657374 type=PATH msg=audit(1404317927.319:132): item=1 name="/tmp/test" inode=25997 dev=00:20 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE type=PATH msg=audit(1404317927.319:132): item=0 name="/tmp/" inode=11144 dev=00:20 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype=PARENT type=CWD msg=audit(1404317927.319:132): cwd="/root" type=SYSCALL msg=audit(1404317927.319:132): arch=c03e syscall=2 success=yes exit=3 a0=7a403dd5 a1=941 a2=1b6 a3=34b65b2c6c items=2 ppid=4321 pid=6436 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=1 comm="touch" exe="/usr/bin/touch" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="touch_tmp" Revision history: v5: Revert patch "Let audit_free_rule() take care of calling audit_remove_mark()." since it caused a group mark deadlock. v4: Re-order and squash down fixups Fix audit_dup_exe() to copy pathname string before calling audit_alloc_mark(). v3: Rationalize and rename some function names and clean up get/put and free code. Rename several "watch" references to "mark". Rename audit_remove_rule() to audit_remove_mark_rule(). Let audit_free_rule() take care of calling audit_remove_mark(). Put audit_alloc_mark() arguments in same order as watch, tree and inode. Move the access to the entry for audit_match_signal() to the beginning of the function in case the entry found is the same one passed in. This will enable it to be used by audit_remove_mark_rule(). https://www.redhat.com/archives/linux-audit/2014-July/msg0.html v2: Misguided attempt to add in audit_exe similar to watches https://www.redhat.com/archives/linux-audit/2014-June/msg00066.html v1.5: eparis' switch to fsnotify https://www.redhat.com/archives/linux-audit/2014-May/msg00046.html https://www.redhat.com/archives/linux-audit/2014-May/msg00066.html v1: Change to path interface instead of inode https://www.redhat.com/archives/linux-audit/2014-May/msg00017.html v0: Peter Moodie's original patches https://www.redhat.com/archives/linux-audit/2012-August/msg00033.html Next step: Get full-path notify working. Eric Paris (3): audit: implement audit by executable audit: clean simple fsnotify implementation audit: convert audit_exe to audit_fsnotify Richard Guy Briggs (2): audit: avoid double copying the audit_exe path string Revert "fixup! audit: clean simple fsnotify implementation" include/linux/audit.h |1 + include/uapi/linux/audit.h |2 + kernel/Makefile|2 +- kernel/audit.h | 39 +++ kernel/audit_exe.c | 49 + kernel/audit_fsnotify.c| 237 kernel/auditfilter.c | 52 +- kernel/auditsc.c | 16 +++ 8 files changed, 395 insertions(+), 3 deletions(-) create mode 100644 kernel/audit_exe.c create mode 100644 kernel/audit_fsnotify.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] power: reset: corrections for simple syscon reboot driver
Hi, On Thu, Oct 02, 2014 at 11:24:15AM -0700, Feng Kan wrote: > This patch is to fix some bugs in reboot driver. Which includes auto selection > of the MFD_SYSCON for the driver, use of container to locate restart handler, > correction of the count down failure timer and ordering of the header file. > > Signed-off-by: Feng Kan Thanks, applied (incl. Guenter's latest suggestion): http://git.infradead.org/battery-2.6.git/commit/afaebbdbd48ada5ead707d6a90ce4b604e1d77d4 -- Sebastian signature.asc Description: Digital signature
[PATCH] Staging: media: lirc: cleaned up packet dump in 2 files.
lirc_imon.c and lirc_sasem.c contain an incoming_packet method that
is using deprecated printk's. Removed blocks replacing with single
dev_info with a %*ph format instead.
Signed-off-by: Amber Thrall
---
drivers/staging/media/lirc/lirc_imon.c | 10 ++
drivers/staging/media/lirc/lirc_sasem.c | 10 ++
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_imon.c
b/drivers/staging/media/lirc/lirc_imon.c
index 7aca44f..232edd5 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -606,7 +606,6 @@ static void imon_incoming_packet(struct imon_context
*context,
struct device *dev = context->driver->dev;
int octet, bit;
unsigned char mask;
- int i;
/*
* just bail out if no listening IR client
@@ -620,13 +619,8 @@ static void imon_incoming_packet(struct imon_context
*context,
return;
}
- if (debug) {
- dev_info(dev, "raw packet: ");
- for (i = 0; i < len; ++i)
- printk("%02x ", buf[i]);
- printk("\n");
- }
-
+ if (debug)
+ dev_info(dev, "raw packet: %*ph\n", len, buf);
/*
* Translate received data to pulse and space lengths.
* Received data is active low, i.e. pulses are 0 and
diff --git a/drivers/staging/media/lirc/lirc_sasem.c
b/drivers/staging/media/lirc/lirc_sasem.c
index c20ef56..2f0463e 100644
--- a/drivers/staging/media/lirc/lirc_sasem.c
+++ b/drivers/staging/media/lirc/lirc_sasem.c
@@ -573,7 +573,6 @@ static void incoming_packet(struct sasem_context *context,
unsigned char *buf = urb->transfer_buffer;
long ms;
struct timeval tv;
- int i;
if (len != 8) {
dev_warn(>dev->dev,
@@ -582,13 +581,8 @@ static void incoming_packet(struct sasem_context *context,
return;
}
- if (debug) {
- printk(KERN_INFO "Incoming data: ");
- for (i = 0; i < 8; ++i)
- printk(KERN_CONT "%02x ", buf[i]);
- printk(KERN_CONT "\n");
- }
-
+ if (debug)
+ dev_info(>dev->dev, "Incoming data: %*ph\n", len, buf);
/*
* Lirc could deal with the repeat code, but we really need to block it
* if it arrives too late. Otherwise we could repeat the wrong code.
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HSI: remove deprecated IRQF_DISABLED
Hi, On Wed, Oct 01, 2014 at 10:28:55PM +0200, Michael Opdenacker wrote: > Remove the use of the IRQF_DISABLED flag > from drivers/hsi/clients/nokia-modem.c > > It's a NOOP since 2.6.35 and it will be removed soon. > > Signed-off-by: Michael Opdenacker https://git.kernel.org/cgit/linux/kernel/git/sre/linux-hsi.git/commit/?h=for-next=a26a42508157bc9fda89e3b1d64e47b9e4b55c30 -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.
On Thu, Oct 02, 2014 at 05:35:26AM -0500, Chuck Ebbert wrote: > On Wed, 1 Oct 2014 01:16:15 +0100 > Al Viro wrote: > > Can we get the below added somewhere in Documentation/filesystems/ ? I > don't see anything there that covers all this. More documentation would of course be nice, but the root cause of my confusion was attempting to give an intelligent review of a significant change to VFS given a 2-hour chunk of time, and without having spent enough time getting familiar with VFS. I would of course need to spend more like a week or two, or at least several days, going through the current code. Thanx, Paul > > Huh? copy_name() does copy a _reference_, not the name itself. All the > > copying involved is source->d_name.name = target->d_name.name. And those > > are simply unsigned char *. > > > > write_seqcount_begin() is irrelevant here. Look: all callers of > > __d_move(x, y) are holding references both to x and y. Contributing to > > the refcount of dentries themselves, that is, not the names. > > > > That gives exclusion between __d_move() and free_dentry() - the latter > > cannot > > be called until dentry refcount reaches zero. RCU is completely irrelevant > > here. In fact, no call chain leads to __d_move() under rcu_read_lock(). > > You must hold the target dentry hard, or it could simply be freed right > > under you. > > > > And __d_move() is taking ->d_lock on all dentries involved (in > > addition to rename_lock serializing it system-wide). > > > > What could possibly lead to refcount zero being observed on target of > > __d_move()? The history of any dentry is this: > > * it is created by __d_alloc(). Nobody can see it until __d_alloc() > > returns. Dentry refcount (not to be confused with refcount of external > > name) is 1. > > * it passes through some (usually - zero) __d_move() calls. > > Some - as the first argument, some - as the second one. All those > > calls are serialized by global seqlock - callers must hold rename_lock. > > And all of them are done by somebody who is holding a counting reference > > to dentries in question. > > * counting references to dentry might be taken and dropped; > > eventually refcount reaches zero (under ->d_lock) and no further > > counting references can be taken after that. See __dentry_kill() - the > > first thing it does is poisoning the refcount, so that any future > > attempt to increment it would fail. __dentry_kill() (still under ->d_lock > > of dentry, ->d_lock of its parent and ->i_lock of its inode) removes > > dentry from the tree, from hash and from the alias list of inode; > > Then it drops the locks. At that point the only search structure dentry > > might be found in is shrink list; if it's not on such list, free_dentry() > > is called immediately, otherwise it's marked so that the code processing > > the shrink list in question would, as soon as it gets to that sucker, > > remove it from the shrink list and call the same free_dentry(). And that's > > the only thing done to such dentry by somebody finding it via a shrink list. > > * once free_dentry() has been reached, dentry can can be only seen > > by RCU lookups, and after the grace period ends it gets physically freed. > > > > free_dentry() isn't allowed to overlap __d_move(); to have that happen is > > a serious dentry refcounting bug. No __d_move() is allowed _after_ > > free_dentry() has been entered, either. Again, it would take a refcounting > > bug for dentries to have that happen - basically, double dput() somewhere. > > If that happens, all bets are off, of course - if dentry gets unexpectedly > > freed under somebody who has grabbed a reference to it and has not dropped > > it yet, we are fucked. > > > > Nothing outside of __d_move() is allowed to change ->d_name.name. > > RCU-critical > > code is allowed to fetch and dereference it, and such code relies upon > > a) freeing of name seen by somebody who'd done rcu_read_lock() being > > delayed until after the matching rcu_read_unlock() > > b) store of terminating NUL done by __d_alloc() (and never overwritten > > afterwards) being seen by RCU-critical code that has found the pointer to > > that name in dentry->d_name.name > > > > All other code accessing ->d_name.name is required to hold one of the locks > > that are held by __d_move() and its callers. Grabbing any of those leads > > to smp_mb() on alpha, which serves as data dependency barrier there, so > > we don't need explicit barrier there as we do in RCU-critical places - > > guarding > > NUL will be seen. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] audit: put rule existence check in canonical order
Use same rule existence check order as audit_make_tree(), audit_to_watch(),
update_lsm_rule() for legibility.
Signed-off-by: Richard Guy Briggs
---
kernel/auditfilter.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 40ed981..4a11697 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -163,7 +163,7 @@ static inline int audit_to_inode(struct audit_krule *krule,
struct audit_field *f)
{
if (krule->listnr != AUDIT_FILTER_EXIT ||
- krule->watch || krule->inode_f || krule->tree ||
+ krule->inode_f || krule->watch || krule->tree ||
(f->op != Audit_equal && f->op != Audit_not_equal))
return -EINVAL;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] audit: eliminate string copy for new tree rules
New tree rules copy the path twice and discard the intermediary copy.
This saves one pointer at the expense of one path string copy.
Signed-off-by: Richard Guy Briggs
---
kernel/audit_tree.c |9 +
kernel/auditfilter.c |5 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
index bd418c4..ace72ed 100644
--- a/kernel/audit_tree.c
+++ b/kernel/audit_tree.c
@@ -17,7 +17,7 @@ struct audit_tree {
struct list_head list;
struct list_head same_root;
struct rcu_head head;
- char pathname[];
+ char *pathname;
};
struct audit_chunk {
@@ -70,11 +70,11 @@ static LIST_HEAD(prune_list);
static struct fsnotify_group *audit_tree_group;
-static struct audit_tree *alloc_tree(const char *s)
+static struct audit_tree *alloc_tree(char *s)
{
struct audit_tree *tree;
- tree = kmalloc(sizeof(struct audit_tree) + strlen(s) + 1, GFP_KERNEL);
+ tree = kmalloc(sizeof(struct audit_tree), GFP_KERNEL);
if (tree) {
atomic_set(>count, 1);
tree->goner = 0;
@@ -83,7 +83,7 @@ static struct audit_tree *alloc_tree(const char *s)
INIT_LIST_HEAD(>list);
INIT_LIST_HEAD(>same_root);
tree->root = NULL;
- strcpy(tree->pathname, s);
+ tree->pathname = s;
}
return tree;
}
@@ -96,6 +96,7 @@ static inline void get_tree(struct audit_tree *tree)
static inline void put_tree(struct audit_tree *tree)
{
if (atomic_dec_and_test(>count))
+ kfree(tree->pathname);
kfree_rcu(tree, head);
}
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index e3378a4..facd704 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -534,9 +534,10 @@ static struct audit_entry *audit_data_to_entry(struct
audit_rule_data *data,
entry->rule.buflen += f->val;
err = audit_make_tree(>rule, str, f->op);
- kfree(str);
- if (err)
+ if (err) {
+ kfree(str);
goto exit_free;
+ }
break;
case AUDIT_INODE:
err = audit_to_inode(>rule, f);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] audit: optimize add to parent skipping needless search and consuming parent ref
When parent has just been created there is no need to search for the parent in
the list. Add a parameter to skip the search and consume the parent reference
no matter what happens.
Signed-off-by: Richard Guy Briggs
---
kernel/audit_watch.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index ad9c168..f209448 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -372,15 +372,20 @@ static int audit_get_nd(struct audit_watch *watch, struct
path *parent)
}
/* Associate the given rule with an existing parent.
- * Caller must hold audit_filter_mutex. */
+ * Caller must hold audit_filter_mutex.
+ * Consumes parent reference. */
static void audit_add_to_parent(struct audit_krule *krule,
- struct audit_parent *parent)
+ struct audit_parent *parent,
+ int new)
{
struct audit_watch *w, *watch = krule->watch;
int watch_found = 0;
BUG_ON(!mutex_is_locked(_filter_mutex));
+ if (new)
+ goto not_found;
+
list_for_each_entry(w, >watches, wlist) {
if (strcmp(watch->path, w->path))
continue;
@@ -396,12 +401,15 @@ static void audit_add_to_parent(struct audit_krule *krule,
break;
}
+not_found:
if (!watch_found) {
- audit_get_parent(parent);
watch->parent = parent;
list_add(>wlist, >watches);
- }
+ } else
+ /* match get in audit_find_parent or audit_init_parent */
+ audit_put_parent(parent);
+
list_add(>rlist, >rules);
}
@@ -413,6 +421,7 @@ int audit_add_watch(struct audit_krule *krule, struct
list_head **list)
struct audit_parent *parent;
struct path parent_path;
int h, ret = 0;
+ int new = 0;
mutex_unlock(_filter_mutex);
@@ -433,12 +442,10 @@ int audit_add_watch(struct audit_krule *krule, struct
list_head **list)
ret = PTR_ERR(parent);
goto error;
}
+ new = 1;
}
- audit_add_to_parent(krule, parent);
-
- /* match get in audit_find_parent or audit_init_parent */
- audit_put_parent(parent);
+ audit_add_to_parent(krule, parent, new);
h = audit_hash_ino((u32)watch->ino);
*list = _inode_hash[h];
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] audit: remove redundant watch refcount
Remove extra layer of audit_{get,put}_watch() calls.
Signed-off-by: Richard Guy Briggs
---
kernel/audit_watch.c |5 +
kernel/auditfilter.c |7 ---
2 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index f209448..c707afb 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -203,7 +203,6 @@ int audit_to_watch(struct audit_krule *krule, char *path,
int len, u32 op)
if (IS_ERR(watch))
return PTR_ERR(watch);
- audit_get_watch(watch);
krule->watch = watch;
return 0;
@@ -306,7 +305,6 @@ static void audit_update_watch(struct audit_parent *parent,
* new watch.
*/
audit_put_watch(nentry->rule.watch);
- audit_get_watch(nwatch);
nentry->rule.watch = nwatch;
list_add(>rule.rlist, >rules);
list_add_rcu(>list,
_inode_hash[h]);
@@ -392,8 +390,7 @@ static void audit_add_to_parent(struct audit_krule *krule,
watch_found = 1;
- /* put krule's and initial refs to temporary watch */
- audit_put_watch(watch);
+ /* put krule's ref to temporary watch */
audit_put_watch(watch);
audit_get_watch(w);
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index facd704..5675916 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -563,8 +563,6 @@ exit_nofree:
return entry;
exit_free:
- if (entry->rule.watch)
- audit_put_watch(entry->rule.watch); /* matches initial get */
if (entry->rule.tree)
audit_put_tree(entry->rule.tree); /* that's the temporary one */
audit_free_rule(entry);
@@ -942,8 +940,6 @@ static inline int audit_add_rule(struct audit_entry *entry)
return 0;
error:
- if (watch)
- audit_put_watch(watch); /* tmp watch, matches initial get */
return err;
}
@@ -951,7 +947,6 @@ error:
static inline int audit_del_rule(struct audit_entry *entry)
{
struct audit_entry *e;
- struct audit_watch *watch = entry->rule.watch;
struct audit_tree *tree = entry->rule.tree;
struct list_head *list;
int ret = 0;
@@ -992,8 +987,6 @@ static inline int audit_del_rule(struct audit_entry *entry)
mutex_unlock(_filter_mutex);
out:
- if (watch)
- audit_put_watch(watch); /* match initial get */
if (tree)
audit_put_tree(tree); /* that's the temporary one */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] audit: remove extra audit_get_parent()
There appears to be an extra parent reference taken. Remove it.
Signed-off-by: Richard Guy Briggs
---
kernel/audit_watch.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index c707afb..eb53bc7 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -462,7 +462,6 @@ void audit_remove_watch_rule(struct audit_krule *krule)
audit_remove_watch(watch);
if (list_empty(>watches)) {
- audit_get_parent(parent);
fsnotify_destroy_mark(>mark, audit_watch_group);
audit_put_parent(parent);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] audit: rename audit_log_remove_rule to disambiguate for trees
Rename audit_log_remove_rule() to audit_tree_log_remove_rule() to avoid
confusion with watch and mark rule removal/changes.
Signed-off-by: Richard Guy Briggs
---
kernel/audit_tree.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
index ace72ed..866d403 100644
--- a/kernel/audit_tree.c
+++ b/kernel/audit_tree.c
@@ -450,7 +450,7 @@ static int tag_chunk(struct inode *inode, struct audit_tree
*tree)
return 0;
}
-static void audit_log_remove_rule(struct audit_krule *rule)
+static void audit_tree_log_remove_rule(struct audit_krule *rule)
{
struct audit_buffer *ab;
@@ -477,7 +477,7 @@ static void kill_rules(struct audit_tree *tree)
list_del_init(>rlist);
if (rule->tree) {
/* not a half-baked one */
- audit_log_remove_rule(rule);
+ audit_tree_log_remove_rule(rule);
rule->tree = NULL;
list_del_rcu(>list);
list_del(>rule.list);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] audit: cull redundancy in audit_rule_change
Re-factor audit_rule_change() to reduce the amount of code redundancy and
simplify the logic.
Signed-off-by: Richard Guy Briggs
---
kernel/auditfilter.c | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 4a11697..e3378a4 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1064,30 +1064,24 @@ int audit_rule_change(int type, __u32 portid, int seq,
void *data,
int err = 0;
struct audit_entry *entry;
+ entry = audit_data_to_entry(data, datasz);
+ if (IS_ERR(entry))
+ return PTR_ERR(entry);
+
switch (type) {
case AUDIT_ADD_RULE:
- entry = audit_data_to_entry(data, datasz);
- if (IS_ERR(entry))
- return PTR_ERR(entry);
-
err = audit_add_rule(entry);
audit_log_rule_change("add_rule", >rule, !err);
- if (err)
- audit_free_rule(entry);
break;
case AUDIT_DEL_RULE:
- entry = audit_data_to_entry(data, datasz);
- if (IS_ERR(entry))
- return PTR_ERR(entry);
-
err = audit_del_rule(entry);
audit_log_rule_change("remove_rule", >rule, !err);
- audit_free_rule(entry);
break;
- default:
- return -EINVAL;
}
+ if (err || type == AUDIT_DEL_RULE)
+ audit_free_rule(entry);
+
return err;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Driver for talking to PLX PEX8xxx PCIe switch over I2C
Hi Wolfram,
Thanks a lot for your review and comments. I understand and will
update with those APIs and send out a V2.
Thanks & Best Regards,
Rajat Jain
On Wed, Oct 1, 2014 at 11:34 PM, Wolfram Sang wrote:
>
>> I understand and agree. In fact in the internal version of this driver
>> (that I have not yet sent out for review), we do have APIs added
>> similar to what you mention above. Currently I have APIs that:
>> - Enable / Disable PCIe links.
>> - Change the upstream port.
>> - Enable / Disable Non-transparent mode etc.
>
> Now, that sounds better to me...
>
>> However, I did not send them all out for review because I don't have
>> the hardware to try and test them out on ALL the supported devices
>> (also would require considerable amount of time). I have tested those
>> APIs on PEX8713 only, because for e.g.I only have PEX8713 in a HW that
>> connects to 2 CPUs at the same time.
>
> That is a common problem to not have enough hardware to test. You could
> ask on the PCI mailing list for testers. The solution usually lies in
> showing the code rather than not showing the code.
>
>> the switch. Yes, I agree that we can have another layer of abstraction
>> so that we have:
>>
>> - The Core logic code (that knows "How do we want the switch to behave")
>> - A PEX8xxx driver (that knows "which registers to program")
>> - A PEX8xxx I2C driver ("How to program those registers") - this driver.
>>
>> I do understand that your suggestion is to include and bundle the
>> latter two into this same driver.
>
> It definately should be this way. Nobody else than the PEX8xxx driver
> should be able to send I2C messeges to the device! And this is
> absolutely standard, the logic how to talk to a device knows also how to
> prepare the I2C messages. One reason where it could be factored out is
> if there are multiple ways of transportation possible, like I2C or SPI.
>
>> However since the possibilities
>> (about which APIs to provide) are too much and not enough hardware to
>> test it, would it be acceptable if I include those APIs, but support
>> them for only 1 device (and return error for others)?
>
> Start with what YOU need and show us (all of it). From there, we can
> decide: do we start with one driver and factor out later, do we start
> with a sub-subsystem right away, etc... And there is still the question
> what APIs you provide, how they are implemented and if we really should
> have them in-kernel. I think that question will be more interesting for
> Bjorn because I don't really know much about switches in the PCI world.
>
>> with those APIs, I feel exposing the Read/Write APIs will be useful -
>> because what core logic wants to achieve can be highly device and
>> platform specific.
>
> That could also be solved by fixup-callbacks, but we'd need to see the
> core to tell, really.
>
>> Also, a sysfs interface for this switch is proving
>> to be a very helpful development aid :-) (personal experience :-))
>
> Sure, but such development aids don't need to be upstream. Especially if
> they create ABI such as sysfs-entries.
>
> Thanks and regards,
>
>Wolfram
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 04/15] ACPI: Document ACPI device specific properties
On Thursday, October 02, 2014 04:36:54 PM Mika Westerberg wrote:
> On Thu, Oct 02, 2014 at 02:46:30PM +0200, Arnd Bergmann wrote:
> > On Thursday 02 October 2014 15:15:08 Mika Westerberg wrote:
[cut]
>
> Putting everything to a single package results this:
>
> Package () { "pwms", Package () {"led-red", ^PWM0, 0, 10,
> "led-green", ^PWM0, 1, 10 }}
>
> But I think the below looks better:
I agree.
> Package () { "pwms", Package () {^PWM0, 0, 10, ^PWM0, 1, 10 }}
> Package () { "pwm-names", Package () {"led-red", "led-green"}}
>
> and it is trivial to match with the corresponding DT fragment.
>
> > }
> >
> > vs.
> >
> > pwm-slave {
> > pwms = < 0 10>, < 1 20>;
> > pwm-names = "led-red", "led-green";
> > };
> >
>
> I don't have strong feelings which way it should be. The current
> implementation limits references so that you can have only integer
> arguments, like {ref0, int, int, ref1, int} but if people think it is
> better to allow strings there as well, it can be changed.
>
> I would like to get comments from Darren and Rafael about this, though.
In my opinion there needs to be a "canonical" representation of the
binding that people always can expect to work. It seems reasonable to
use the one exactly matching the DT representation for that.
In addition to that we can add other representations that the code will
also parse correctly as alternatives. In the future.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fixed all coding style issues for drivers/staging/media/lirc/
On Fri, 2014-10-03 at 02:58 +0300, Antti Palosaari wrote:
> On 10/02/2014 07:45 PM, Joe Perches wrote:
> > On Thu, 2014-10-02 at 10:29 -0300, Mauro Carvalho Chehab wrote:
> >> Em Wed, 01 Oct 2014 21:40:02 -0700 Amber Thrall
> >> escreveu:
> >>> Fixed various coding style issues, including strings over 80 characters
> >>> long and many
> >>> deprecated printk's have been replaced with proper methods.
> > []
> >>> diff --git a/drivers/staging/media/lirc/lirc_imon.c
> >>> b/drivers/staging/media/lirc/lirc_imon.c
> > []
> >>> @@ -623,8 +623,8 @@ static void imon_incoming_packet(struct imon_context
> >>> *context,
> >>> if (debug) {
> >>> dev_info(dev, "raw packet: ");
> >>> for (i = 0; i < len; ++i)
> >>> - printk("%02x ", buf[i]);
> >>> - printk("\n");
> >>> + dev_info(dev, "%02x ", buf[i]);
> >>> + dev_info(dev, "\n");
> >>> }
> >>
> >> This is wrong, as the second printk should be printk_cont.
> >>
> >> The best here would be to change all above to use %*ph.
> >> So, just:
> >>
> >>dev_debug(dev, "raw packet: %*ph\n", len, buf);
> >
> > Not quite.
> >
> > %*ph is length limited and only useful for lengths < 30 or so.
> > Even then, it's pretty ugly.
> >
> > print_hex_dump_debug() is generally better.
>
> That is place where you print 8 debug bytes, which are received remote
> controller code. IMHO %*ph format is just what you like in that case.
Hi Antti.
I stand by my statement as I only looked at the
patch snippet itself, not any function real code.
In the actual code, there's a test above it:
if (len != 8) {
dev_warn(dev, "imon %s: invalid incoming packet size (len = %d,
intf%d)\n",
__func__, len, intf);
return;
}
So in my opinion, this would be better/smaller as:
dev_dbg(dev, "raw packet: %8ph\n", urb->transfer_buffer);
> Why print_hex_dump_debug() is better? IIRC it could not be even
> controlled like those dynamic debug printings.
Nope, it is. (from printk.h)
#if defined(CONFIG_DYNAMIC_DEBUG)
#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
groupsize, buf, len, ascii)\
dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
groupsize, buf, len, ascii)
#else
#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
groupsize, buf, len, ascii)\
print_hex_dump(KERN_DEBUG, prefix_str, prefix_type, rowsize,\
groupsize, buf, len, ascii)
#endif /* defined(CONFIG_DYNAMIC_DEBUG) */
It prints multiple lines when the length is > 16.
It prints the ascii along with the hex if desired.
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ACPI and power management fixes for final 3.17
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm+acpi-3.17-final to receive ACPI and power management fixes for final v3.17 with top-most commit abcadddc85a4c9595b0a5ede34f2ee876fe4155f Merge branches 'pm-cpufreq' and 'acpi-video' on top of commit fe82dcec644244676d55a1384c958d5f67979adb Linux 3.17-rc7 These are three regression fixes (cpufreq core, pcc-cpufreq, i915 / ACPI) and one trivial fix for a callback return value mismatch in the cpufreq integrator driver. Specifics: - A recent cpufreq core fix went too far and introduced a regression in the system suspend code path. Fix from Viresh Kumar. - An ACPI-related commit in the i915 driver that fixed backlight problems for some Thinkpads inadvertently broke a Dell machine (in 3.16). Fix from Aaron Lu. - The pcc-cpufreq driver was broken during the 3.15 cycle by a commit that put wait_event() under a spinlock by mistake. Fix that (Rafael J Wysocki). - The return value type of integrator_cpufreq_remove() is void, but should be int. Fix from Arnd Bergmann. Thanks! --- Aaron Lu (1): ACPI / i915: Update the condition to ignore firmware backlight change request Arnd Bergmann (1): cpufreq: integrator: fix integrator_cpufreq_remove return type Rafael J. Wysocki (1): cpufreq: pcc-cpufreq: Fix wait_event() under spinlock Viresh Kumar (1): cpufreq: update 'cpufreq_suspended' after stopping governors --- drivers/cpufreq/cpufreq.c | 7 --- drivers/cpufreq/integrator-cpufreq.c | 4 ++-- drivers/cpufreq/pcc-cpufreq.c | 2 +- drivers/gpu/drm/i915/intel_opregion.c | 16 +++- 4 files changed, 18 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] i2c: exynos5: Add Kconfig dependencies
On Tue, Sep 16, 2014 at 03:03:18PM +0530, Naveen Krishna Chatradhi wrote: > The i2c-exynos5.c driver can be reused for the HSI2C controller > on Exynos7 SoCs from Samsung. > > This patch adds the Kconfig dependency to choose i2c-exynos5.c > for CONFIG_ARCH_EXYNOS7. > > Signed-off-by: Naveen Krishna Chatradhi Folded this one into the previous one. signature.asc Description: Digital signature
Re: [PATCH 1/2] i2c: exynos: add support for HSI2C module on Exynos7
On Tue, Sep 16, 2014 at 03:03:17PM +0530, Naveen Krishna Chatradhi wrote: > The HSI2C module on Exynos7 differs in the transfer status > bits. Transfer status bits were moved to INT_ENABLE and > INT_STATUS registers > > This patch adds support for the HSI2C module on Exynos7. > 1. Implementes a "hw" field in the variant struct to distinguish >the hardware. > 2. Updates the dt-new compatible in dt-binding documenation > > Signed-off-by: Naveen Krishna Chatradhi > Cc: Wolfram Sang Applied to for-next, thanks! signature.asc Description: Digital signature
Re: [PATCH] i2c: qup: Fix order of runtime pm initialization
On Mon, Sep 29, 2014 at 05:00:51PM -0500, Andy Gross wrote: > The runtime pm calls need to be done before populating the children via the > i2c_add_adapter call. If this is not done, a child can run into issues trying > to do i2c read/writes due to the pm_runtime_sync failing. > > Signed-off-by: Andy Gross Applied to for-current, thanks! signature.asc Description: Digital signature
Re: [dm-devel] dm-raid: add RAID discard support
> "Neil" == NeilBrown writes: Neil> I plan to submit this to Linus tomorrow, hopefully for 3.7, unless Neil> there are complaints. It is in my for-next branch now. Acked-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/4] i2c: add support for Diolan DLN-2 USB-I2C adapter
Hi,
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 2ac87fa..6afc17e 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -1021,4 +1021,14 @@ config SCx200_ACB
> This support is also available as a module. If so, the module
> will be called scx200_acb.
>
> +config I2C_DLN2
> + tristate "Diolan DLN-2 USB I2C adapter"
> + depends on MFD_DLN2
> + help
> + If you say yes to this option, support will be included for Diolan
> + DLN2, a USB to I2C interface.
> +
> + This driver can also be built as a module. If so, the module
> + will be called i2c-dln2.
> +
Please keep to the existing sorting.
> endmenu
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 49bf07e..3118fea 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -100,5 +100,6 @@ obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
> obj-$(CONFIG_I2C_PCA_ISA)+= i2c-pca-isa.o
> obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o
> obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
> +obj-$(CONFIG_I2C_DLN2) += i2c-dln2.o
Ditto!
> +static int dln2_i2c_enable(struct dln2_i2c *dln2, bool enable)
> +{
> + int ret;
> + u16 cmd;
> +
> + if (enable)
> + cmd = DLN2_I2C_ENABLE;
> + else
> + cmd = DLN2_I2C_DISABLE;
Ternary operator?
> +
> + ret = dln2_transfer(dln2->pdev, cmd, >port, sizeof(dln2->port),
> + NULL, NULL);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int dln2_i2c_set_frequency(struct dln2_i2c *dln2, u32 freq)
Here you have 'set_frequency'...
> +{
> + int ret;
> + struct tx_data {
> + u8 port;
> + __le32 freq;
> + } __packed tx;
> +
> + tx.port = dln2->port;
> + tx.freq = cpu_to_le32(freq);
> +
> + ret = dln2_transfer(dln2->pdev, DLN2_I2C_SET_FREQUENCY, , sizeof(tx),
> + NULL, NULL);
> + if (ret < 0)
> + return ret;
> +
> + dln2->freq = freq;
> +
> + return 0;
> +}
> +
> +static int dln2_i2c_get_freq(struct dln2_i2c *dln2, u16 cmd, u32 *res)
... here 'get_freq'. Please keep it consistent.
> +{
> + int ret;
> + __le32 freq;
> + unsigned len = sizeof(freq);
> +
> + ret = dln2_transfer(dln2->pdev, cmd, >port, sizeof(dln2->port),
> + , );
> + if (ret < 0)
> + return ret;
> + if (len < sizeof(freq))
> + return -EPROTO;
> +
> + *res = le32_to_cpu(freq);
> +
> + return 0;
> +}
...
> +
> +static int dln2_i2c_xfer(struct i2c_adapter *adapter,
> + struct i2c_msg *msgs, int num)
> +{
> + struct dln2_i2c *dln2 = i2c_get_adapdata(adapter);
> + struct i2c_msg *pmsg;
> + int i;
> +
> + for (i = 0; i < num; i++) {
> + int ret;
> +
> + pmsg = [i];
> +
> + if (pmsg->len > DLN2_I2C_MAX_XFER_SIZE)
> + return -EINVAL;
Rather -EOPNOTSUPP. And we should add a warning here since I2C transfers
can be bigger than 256 byte and this is a flaw of the controller.
> +
> + if (pmsg->flags & I2C_M_RD) {
> + ret = dln2_i2c_read(dln2, pmsg->addr, pmsg->buf,
> + pmsg->len);
> + if (ret < 0)
> + return ret;
> +
> + pmsg->len = ret;
> + } else {
> + ret = dln2_i2c_write(dln2, pmsg->addr, pmsg->buf,
> + pmsg->len);
> + if (ret != pmsg->len)
> + return -EPROTO;
> + }
> + }
> +
> + return num;
> +}
> +
Thanks,
Wolfram
signature.asc
Description: Digital signature
CPSW bug with AM437x SK
Hi Mugunthan, I noticed that *really* rarely I get the skb panic below. What I have here is an AM437x SK running v3.17-rc6, with NFS root. Once booted, then I run cyclictest and hackbench (this one in an infinite loop) an eventually this will trigger. File system is mounted as read-only and another board (BBB) is also mounting the exact same NFS root also as read-only. It takes a while to reproduce but it is the second time I managed to reproduce with the exact same setup. .config attached. [ 260.881326] skbuff: skb_over_panic: text:c0605aac len:100 put:100 head: (null) data: (null) tail:0x64 end:0x0 dev:- [ 260.892732] [ cut here ] [ 260.897590] kernel BUG at net/core/skbuff.c:100! [ 260.902441] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 260.907820] Modules linked in: xhci_hcd snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap snd_soc_evm snd_soc_tlv320aic3x snd_soc_core dwc3 snd_compress omapdrm snd_pcm_dmaengine snd_pcm snd_timer snd fb_sys_fops lis3lv02d_i2c panel_dpi matrix_keypad lis3lv02d dwc3_omap input_polldev soundcore [ 260.935072] CPU: 0 PID: 8997 Comm: hackbench Not tainted 3.17.0-rc6-00456-gd8da063-dirty #223 [ 260.944015] task: ead16d80 ti: ec084000 task.ti: ec084000 [ 260.949693] PC is at skb_panic+0x64/0x70 [ 260.953824] LR is at vprintk_emit+0x258/0x5e0 [ 260.958386] pc : []lr : []psr: 600f0013 [ 260.958386] sp : ec085db8 ip : ec085d20 fp : ec085dec [ 260.970435] r10: r9 : e8881ac0 r8 : 0001 [ 260.975909] r7 : c087e79c r6 : r5 : 0064 r4 : [ 260.982747] r3 : ead16d80 r2 : r1 : edfb5544 r0 : 006a [ 260.989599] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 260.997090] Control: 10c5387d Table: a91c0059 DAC: 0015 [ 261.003116] Process hackbench (pid: 8997, stack limit = 0xec084248) [ 261.009674] Stack: (0xec085db8 to 0xec086000) [ 261.014233] 5da0: 0064 [ 261.022817] 5dc0: 0064 ea9ed240 0064 0064 [ 261.031393] 5de0: ec085e0c ec085df0 c0565edc c0648cf0 0064 e8881cac e893e1c0 [ 261.039955] 5e00: ec085e7c ec085e10 c0605aac c0565e8c ec085e38 0003 c064e674 e893e254 [ 261.048537] 5e20: ec085e80 ec085ea0 e893e4d4 0001 0064 ece0e840 [ 261.057108] 5e40: c00899e0 ece0e840 e893f940 0064 [ 261.065686] 5e60: 0064 0064 bed59b48 ec085edc ec085e80 c055b364 c0605954 [ 261.074259] 5e80: c018b704 ec085ee4 0064 ece0e840 c0089d60 ec085e3c ec085ea0 [ 261.082843] 5ea0: ec085ee8 0001 ec085ef0 [ 261.091397] 5ec0: ec085f78 ec085f44 ec085ee0 c014c42c c055b294 [ 261.099953] 5ee0: bed59b48 0064 e893f940 ec085e80 [ 261.108502] 5f00: ead16d80 0064 [ 261.117089] 5f20: e893f940 e893f940 bed59b48 ec085f78 ec085f74 ec085f48 [ 261.125662] 5f40: c014cf70 c014c3ac 0001 c016a9d8 e893f940 e893f940 [ 261.134242] 5f60: 0064 bed59b48 ec085fa4 ec085f78 c014d564 c014ce64 [ 261.142843] 5f80: 0064 00024c6c bed59b48 0004 c000efc4 ec084000 ec085fa8 [ 261.151417] 5fa0: c000ed40 c014d524 0064 00024c6c 000c bed59b48 0064 0014 [ 261.159992] 5fc0: 0064 00024c6c bed59b48 0004 0004 00024c50 000221ac [ 261.168555] 5fe0: bed59b44 000113a1 b6f204d6 600f0030 000c [ 261.177168] [] (skb_panic) from [] (skb_put+0x5c/0x60) [ 261.184415] [] (skb_put) from [] (unix_stream_sendmsg+0x164/0x390) [ 261.192712] [] (unix_stream_sendmsg) from [] (sock_aio_write+0xdc/0xfc) [ 261.201475] [] (sock_aio_write) from [] (do_sync_write+0x8c/0xb4) [ 261.209697] [] (do_sync_write) from [] (vfs_write+0x118/0x1c0) [ 261.217652] [] (vfs_write) from [] (SyS_write+0x4c/0xa0) [ 261.225054] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x48) [ 261.232988] Code: e58d4008 e58de00c e59f0008 ebfff48e (e7f001f2) [ 261.239378] ---[ end trace d64258d586f40104 ]--- -- balbi # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.17.0-rc6 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup #
[PATCH 1/3] tools/perf: Fix error message
Sometimes, eg: with a stripped vmlinux, we can open the file but
cannot load any symbols from it. Update error message accordingly
so the users can better understand the error.
Signed-off-by: Sukadev Bhattiprolu
---
tools/perf/util/map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b709059..c478092 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -267,7 +267,7 @@ int map__load(struct map *map, symbol_filter_t filter)
pr_warning("%s with build id %s not found",
name, sbuild_id);
} else
- pr_warning("Failed to open %s", name);
+ pr_warning("Failed to load symbols for DSO %s", name);
pr_warning(", continuing without symbols\n");
return -1;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] tools/perf: Rename variables for clarity
The dso__load* functions return the number symbols they were able
to load or -1 in case of error.
But it is a bit confusing to determine 'if (err > 0)' indicates success
or failure and we have to step several functions deep to find that out.
Rename the variable 'err' so it is hopefully easier to understand.
Signed-off-by: Sukadev Bhattiprolu
---
tools/perf/util/symbol.c | 50
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index be84f7a..9b66e27 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1467,7 +1467,7 @@ int dso__load_vmlinux(struct dso *dso, struct map *map,
const char *vmlinux, bool vmlinux_allocated,
symbol_filter_t filter)
{
- int err = -1;
+ int nsyms = -1;
struct symsrc ss;
char symfs_vmlinux[PATH_MAX];
enum dso_binary_type symtab_type;
@@ -1485,10 +1485,10 @@ int dso__load_vmlinux(struct dso *dso, struct map *map,
if (symsrc__init(, dso, symfs_vmlinux, symtab_type))
return -1;
- err = dso__load_sym(dso, map, , , filter, 0);
+ nsyms = dso__load_sym(dso, map, , , filter, 0);
symsrc__destroy();
- if (err > 0) {
+ if (nsyms > 0) {
if (dso->kernel == DSO_TYPE_GUEST_KERNEL)
dso->binary_type = DSO_BINARY_TYPE__GUEST_VMLINUX;
else
@@ -1498,13 +1498,13 @@ int dso__load_vmlinux(struct dso *dso, struct map *map,
pr_debug("Using %s for symbols\n", symfs_vmlinux);
}
- return err;
+ return nsyms;
}
int dso__load_vmlinux_path(struct dso *dso, struct map *map,
symbol_filter_t filter)
{
- int i, err = 0;
+ int i, nsyms = 0;
char *filename;
pr_debug("Looking at the vmlinux_path (%d entries long)\n",
@@ -1512,19 +1512,19 @@ int dso__load_vmlinux_path(struct dso *dso, struct map
*map,
filename = dso__build_id_filename(dso, NULL, 0);
if (filename != NULL) {
- err = dso__load_vmlinux(dso, map, filename, true, filter);
- if (err > 0)
+ nsyms = dso__load_vmlinux(dso, map, filename, true, filter);
+ if (nsyms > 0)
goto out;
free(filename);
}
for (i = 0; i < vmlinux_path__nr_entries; ++i) {
- err = dso__load_vmlinux(dso, map, vmlinux_path[i], false,
filter);
- if (err > 0)
+ nsyms = dso__load_vmlinux(dso, map, vmlinux_path[i], false,
filter);
+ if (nsyms > 0)
break;
}
out:
- return err;
+ return nsyms;
}
static int find_matching_kcore(struct map *map, char *dir, size_t dir_sz)
@@ -1634,7 +1634,7 @@ proc_kallsyms:
static int dso__load_kernel_sym(struct dso *dso, struct map *map,
symbol_filter_t filter)
{
- int err;
+ int nsyms;
const char *kallsyms_filename = NULL;
char *kallsyms_allocated_filename = NULL;
/*
@@ -1663,9 +1663,9 @@ static int dso__load_kernel_sym(struct dso *dso, struct
map *map,
}
if (!symbol_conf.ignore_vmlinux && vmlinux_path != NULL) {
- err = dso__load_vmlinux_path(dso, map, filter);
- if (err > 0)
- return err;
+ nsyms = dso__load_vmlinux_path(dso, map, filter);
+ if (nsyms > 0)
+ return nsyms;
}
/* do not try local files if a symfs was given */
@@ -1679,25 +1679,25 @@ static int dso__load_kernel_sym(struct dso *dso, struct
map *map,
kallsyms_filename = kallsyms_allocated_filename;
do_kallsyms:
- err = dso__load_kallsyms(dso, kallsyms_filename, map, filter);
- if (err > 0)
+ nsyms = dso__load_kallsyms(dso, kallsyms_filename, map, filter);
+ if (nsyms > 0)
pr_debug("Using %s for symbols\n", kallsyms_filename);
free(kallsyms_allocated_filename);
- if (err > 0 && !dso__is_kcore(dso)) {
+ if (nsyms > 0 && !dso__is_kcore(dso)) {
dso->binary_type = DSO_BINARY_TYPE__KALLSYMS;
dso__set_long_name(dso, "[kernel.kallsyms]", false);
map__fixup_start(map);
map__fixup_end(map);
}
- return err;
+ return nsyms;
}
static int dso__load_guest_kernel_sym(struct dso *dso, struct map *map,
symbol_filter_t filter)
{
- int err;
+ int nsyms;
const char *kallsyms_filename = NULL;
struct machine *machine;
char path[PATH_MAX];
@@ -1715,10 +1715,10 @@ static int dso__load_guest_kernel_sym(struct dso *dso,
struct map *map,
* Or use file guest_kallsyms inputted by user on commandline
[PATCH 3/3] tools/perf: Fix error reporting
If user explicitly specifies a vmlinux or kallsyms file on the command
line and the specified file doesn't yield any symbols, print a warning
message.
$ perf report -kallsyms
No kernel symbols in the vmlinux 'allsyms'?
Failed to load symbols for DSO [kernel.kallsyms], continuing
without symbols
This could help user better recognize the typo -kallsyms v. --kallsyms.
It would also help if the user points to a stripped/invalid vmlinux or
an invalid kallsyms.
With a stripped vmlinux:
$ perf report -k /tmp/vmlinux
No kernel symbols in the vmlinux '/tmp/vmlinux'?
Failed to load symbols for DSO [kernel.kallsyms], continuing
without symbols
and with perf top
$ perf top -k /tmp/vmlinux
No kernel symbols in the vmlinux '/tmp/vmlinux'?
/tmp/vmlinux with build id f43f4e78d3afac6492dcae52cd756394247997d6
not found, continuing without symbols
Signed-off-by: Sukadev Bhattiprolu
---
tools/perf/util/symbol.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 9b66e27..ad5baa4 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1658,8 +1658,13 @@ static int dso__load_kernel_sym(struct dso *dso, struct
map *map,
}
if (!symbol_conf.ignore_vmlinux && symbol_conf.vmlinux_name != NULL) {
- return dso__load_vmlinux(dso, map, symbol_conf.vmlinux_name,
+ nsyms = dso__load_vmlinux(dso, map, symbol_conf.vmlinux_name,
false, filter);
+ if (nsyms <= 0) {
+ pr_warning("No kernel symbols in the vmlinux '%s'?\n",
+ symbol_conf.vmlinux_name);
+ }
+ return nsyms;
}
if (!symbol_conf.ignore_vmlinux && vmlinux_path != NULL) {
@@ -1682,6 +1687,10 @@ do_kallsyms:
nsyms = dso__load_kallsyms(dso, kallsyms_filename, map, filter);
if (nsyms > 0)
pr_debug("Using %s for symbols\n", kallsyms_filename);
+ else if (symbol_conf.kallsyms_name) {
+ pr_warning("No kernel symbols in the kallsyms '%s'?\n",
+ kallsyms_filename);
+ }
free(kallsyms_allocated_filename);
if (nsyms > 0 && !dso__is_kcore(dso)) {
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [compiler/gcc4] a9f180345f5: -100.0% last_state.is_incomplete_run
On Tue, Sep 30, 2014 at 1:14 AM, Fengguang Wu wrote:
> Hi Steven,
>
> FYI, we noticed that your commit a9f180345f5378ac87d80ed0bea55ba421d83859
> ("compiler/gcc4: Make quirk for asm_volatile_goto() unconditional") fixed
> a number of machine boot failures in our LKP test farm. This is really
> helpful!
> Our gcc version is 4.9.1 (Debian 4.9.1-11).
Hey cool, that's good news!
I rather wish we could find the root cause of the miscompiles, though,
so we could conditionalize the quirk on something again. I'm terrible
at debugging GCC behavior, though, so I'm not the right person for it.
- Steven
>
> 569d6557ab957d6 a9f180345f5378ac87d80ed0b
> --- -
> %stddev%change %stddev
> \ | /
> 1 ± 0%-100.0% 0 ± 0%
> lkp-st02/dd-write/5m-11HDD-RAID5-cfq-btrfs-100dd
> 1 ± 0%-100.0% 0 ± 0% TOTAL
> dmesg.kernel_BUG_at_fs/nfs/pagelist.c
>
> 569d6557ab957d6 a9f180345f5378ac87d80ed0b
> --- -
> 1 ± 0%-100.0% 0 ± 0%
> lkp-st02/dd-write/5m-11HDD-RAID5-cfq-btrfs-100dd
> 1 ± 0%-100.0% 0 ± 0% TOTAL
> dmesg.Kernel_panic-not_syncing:Fatal_exception
>
> 569d6557ab957d6 a9f180345f5378ac87d80ed0b
> --- -
> 1 ± 0%-100.0% 0 ± 0%
> lkp-st02/dd-write/5m-11HDD-RAID5-cfq-btrfs-100dd
> 1 ± 0%-100.0% 0 ± 0% TOTAL dmesg.invalid_opcode
>
> 569d6557ab957d6 a9f180345f5378ac87d80ed0b
> --- -
> 1 ± 0%-100.0% 0 ± 0% ivb42/will-it-scale/futex4
> 1 ± 0%-100.0% 0 ± 0%
> ivb44/fsmark/1x-1t-1HDD-xfs-4M-60G-NoSync
> 1 ± 0%-100.0% 0 ± 0%
> ivb44/fsmark/1x-64t-1BRD_48G-btrfs-4M-40G-fsyncBeforeClose
> 1 ± 0%-100.0% 0 ± 0% lkp-bdw01/blogbench/1SSD-btrfs
> 1 ± 0%-100.0% 0 ± 0%
> lkp-hsw01/vm-scalability/300s-anon-rx-rand-mt
> 1 ± 0%-100.0% 0 ± 0% lkp-sbx04/will-it-scale/futex3
> 1 ± 0%-100.0% 0 ± 0%
> lkp-sbx04/will-it-scale/page_fault3
> 1 ± 0%-100.0% 0 ± 0%
> lkp-st02/dd-write/5m-11HDD-RAID5-cfq-btrfs-100dd
> 8 ± 0%-100.0% 0 ± 0% TOTAL last_state.is_incomplete_run
>
> 569d6557ab957d6 a9f180345f5378ac87d80ed0b
> --- -
> 1 ± 0%-100.0% 0 ± 0% ivb42/will-it-scale/futex4
> 1 ± 0%-100.0% 0 ± 0%
> ivb44/fsmark/1x-1t-1HDD-xfs-4M-60G-NoSync
> 1 ± 0%-100.0% 0 ± 0%
> ivb44/fsmark/1x-64t-1BRD_48G-btrfs-4M-40G-fsyncBeforeClose
> 1 ± 0%-100.0% 0 ± 0% lkp-bdw01/blogbench/1SSD-btrfs
> 1 ± 0%-100.0% 0 ± 0%
> lkp-hsw01/vm-scalability/300s-anon-rx-rand-mt
> 1 ± 0%-100.0% 0 ± 0% lkp-sbx04/will-it-scale/futex3
> 1 ± 0%-100.0% 0 ± 0%
> lkp-sbx04/will-it-scale/page_fault3
> 1 ± 0%-100.0% 0 ± 0%
> lkp-st02/dd-write/5m-11HDD-RAID5-cfq-btrfs-100dd
> 8 ± 0%-100.0% 0 ± 0% TOTAL last_state.booting
>
> Thanks,
> Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] i2c: designware: Add support for AMD I2C controller
On Tue, Sep 30, 2014 at 01:04:52PM +0300, Mika Westerberg wrote: > This is second iteration of the patch series. First version is here: > > http://patchwork.ozlabs.org/patch/390694/ > http://patchwork.ozlabs.org/patch/390695/ > > In order to get source clock to the core driver we need some way of > creating it in the first place. For Intel LPSS it is done in > drivers/acpi/acpi_lpss.c but that is not applicable for AMD I2C host > controller which is too different from private parts to the LPSS one. > > We solve this by creating the clock in ACPI parts of the platform driver > when we detect the AMD I2C host controller. Doing this requires small > refactoring to be done to the probe() which is what patches [1-2/3] are > doing. > > Changes to the previous version: > * Rebased on top of i2c/for-next branch > * New patch defaulting ACPI probe to fast mode > * Instead of direct dependency to COMMON_CLK we depend on (ACPI && >COMMON_CLK) || ACPI. (suggested by Wolfram) > > Carl, can you test that this still works on your machine? Yes, Carl that would be helpful. Patches look good to me. Thanks! signature.asc Description: Digital signature
Re: [PATCH] i2c: rk3x: fix 0 length write transfers
On Wed, Oct 01, 2014 at 10:40:41AM -0700, Alexandru M Stan wrote: > i2cdetect -q was broken (everything was a false positive, and no transfers > were > actually being sent over i2c). The way it works is by sending a 0 length write > request and checking for NACK. This patch fixes the 0 length writes and > actually > sends them. > > Reported-by: Doug Anderson > Signed-off-by: Alexandru M Stan Applied to for-current, thanks! signature.asc Description: Digital signature
Re: [PATCH] i2c: rk3x: fix 0 length write transfers
> Reviewed-By: Max Schwarz > Tested-By: Max Schwarz Checkpatch says: WARNING: 'Tested-by:' is the preferred signature form Same 'Reviewed-by:' signature.asc Description: Digital signature
[PATCH] block: disable entropy contributions from nonrot devices
Introduce queue_flags_set_nonrot_clear_add_random() and convert all
block drivers that set QUEUE_FLAG_NONROT over to using it instead.
Historically, all block devices have automatically made entropy
contributions. But as previously stated in commit e2e1a148 ("block: add
sysfs knob for turning off disk entropy contributions"):
- On SSD disks, the completion times aren't as random as they
are for rotational drives. So it's questionable whether they
should contribute to the random pool in the first place.
- Calling add_disk_randomness() has a lot of overhead.
There are more reliable sources for randomness than non-rotational block
devices. From a security perspective it is better to err on the side of
caution than to allow entropy contributions from unreliable "random"
sources.
Signed-off-by: Mike Snitzer
---
drivers/block/mtip32xx/mtip32xx.c |2 +-
drivers/block/nbd.c |2 +-
drivers/block/null_blk.c |2 +-
drivers/block/nvme-core.c |2 +-
drivers/block/rsxx/dev.c |2 +-
drivers/block/skd_main.c |2 +-
drivers/block/zram/zram_drv.c |2 +-
drivers/ide/ide-disk.c|2 +-
drivers/md/bcache/super.c |2 +-
drivers/mmc/card/queue.c |2 +-
drivers/mtd/mtd_blkdevs.c |2 +-
drivers/s390/block/scm_blk.c |2 +-
drivers/s390/block/xpram.c|2 +-
drivers/scsi/sd.c |2 +-
include/linux/blkdev.h|6 ++
15 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 5c8e7fe..0de2620 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3950,7 +3950,7 @@ skip_create_disk:
goto start_service_thread;
/* Set device limits. */
- set_bit(QUEUE_FLAG_NONROT, >queue->queue_flags);
+ queue_flags_set_nonrot_clear_add_random(dd->queue);
blk_queue_max_segments(dd->queue, MTIP_MAX_SG);
blk_queue_physical_block_size(dd->queue, 4096);
blk_queue_max_hw_sectors(dd->queue, 0x);
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index fb31b8e..8dbb842 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -846,7 +846,7 @@ static int __init nbd_init(void)
/*
* Tell the block layer that we are not a rotational device
*/
- queue_flag_set_unlocked(QUEUE_FLAG_NONROT, disk->queue);
+ queue_flags_set_nonrot_clear_add_random(disk->queue);
disk->queue->limits.discard_granularity = 512;
disk->queue->limits.max_discard_sectors = UINT_MAX;
disk->queue->limits.discard_zeroes_data = 0;
diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index 00d469c..8d6eb15 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -517,7 +517,7 @@ static int null_add_dev(void)
}
nullb->q->queuedata = nullb;
- queue_flag_set_unlocked(QUEUE_FLAG_NONROT, nullb->q);
+ queue_flags_set_nonrot_clear_add_random(nullb->q);
disk = nullb->disk = alloc_disk_node(1, home_node);
if (!disk) {
diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c
index 02351e2..8bf69ae 100644
--- a/drivers/block/nvme-core.c
+++ b/drivers/block/nvme-core.c
@@ -1915,7 +1915,7 @@ static struct nvme_ns *nvme_alloc_ns(struct nvme_dev
*dev, unsigned nsid,
goto out_free_ns;
ns->queue->queue_flags = QUEUE_FLAG_DEFAULT;
queue_flag_set_unlocked(QUEUE_FLAG_NOMERGES, ns->queue);
- queue_flag_set_unlocked(QUEUE_FLAG_NONROT, ns->queue);
+ queue_flags_set_nonrot_clear_add_random(ns->queue);
blk_queue_make_request(ns->queue, nvme_make_request);
ns->dev = dev;
ns->queue->queuedata = ns;
diff --git a/drivers/block/rsxx/dev.c b/drivers/block/rsxx/dev.c
index 2839d37..dc5b965 100644
--- a/drivers/block/rsxx/dev.c
+++ b/drivers/block/rsxx/dev.c
@@ -306,7 +306,7 @@ int rsxx_setup_dev(struct rsxx_cardinfo *card)
blk_queue_max_hw_sectors(card->queue, blkdev_max_hw_sectors);
blk_queue_physical_block_size(card->queue, RSXX_HW_BLK_SIZE);
- queue_flag_set_unlocked(QUEUE_FLAG_NONROT, card->queue);
+ queue_flags_set_nonrot_clear_add_random(card->queue);
if (rsxx_discard_supported(card)) {
queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, card->queue);
blk_queue_max_discard_sectors(card->queue,
diff --git a/drivers/block/skd_main.c b/drivers/block/skd_main.c
index 8fcdcfb..ba528db 100644
--- a/drivers/block/skd_main.c
+++ b/drivers/block/skd_main.c
@@ -4425,7 +4425,7 @@ static int skd_cons_disk(struct skd_device *skdev)
q->limits.max_discard_sectors = UINT_MAX >> 9;
q->limits.discard_zeroes_data = 1;
queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, q);
-
Kontaktieren DHL für die Lieferung Ihrer Scheck
Grüße an Sie Ich bin sicher, dass diese E-Mail würde Ihnen kommen als eine Überraschung, da wir noch nie getroffen haben, bevor und Sie würden auch fragen, warum ich beschlossen, Sie unter den zahlreichen Internet-Nutzer in der Welt wählte, genau kann ich nicht sagen, warum ich habe euch erwählt aber nicht besorgt sein, denn ich komme in Frieden und etwas sehr Positives ist im Begriff, Ihr Leben jetzt und für das Leben der anderen durch Sie geschehen, wenn nur Sie sorgfältig lesen und verdauen die Nachricht unten. Bevor ich weiter bewegen, erlauben Sie mir, Ihnen ein wenig von meiner Biografie, ich bin Mutter Mrs. Patricia Ernest, 87 Jahre alte Frau und die Frau des verstorbenen Sir Thompson, Ernest,, der am Montag bei einem Flugzeugabsturz starb den 7. September 1998 15.22 Uhr GMT NL, während sie von New York nach Genf fliegen. Bitte beachten Sie folgende Website für weitere Informationen. http://www.cnn.com/WORLD/9809/swissair.victims.list/index.html Nach dem Tod meines Mannes wurde ich den Kopf seines Investitionen und jetzt, wo ich bin alt und schwach ich haben beschlossen, den Rest meines Lebens in meinem Ranch zu verbringen, bevor ich endlich die Welt zu verlassen, aber vor dem Tod meines Mannes hatten wir einen Plan, um die letzten Tage unseres Lebens zu verwenden, um die Hälfte von dem, was wir für die weniger Privilegien und Nächstenliebe Häuser und die andere Hälfte für uns selbst, Familienmitglieder und enge Freunde arbeitete spenden, und es ist so schade, dass mein Mann ist nicht mehr am Leben heute, dies mit mir zu tun, und ich bin sehr schwach und alt jetzt, daher habe ich beschlossen, diese philanthropische Arbeit im Namen meiner verstorbenen Mannes zu tun. Derzeit habe ich fast die Hälfte unseres Vermögens auf mehrere Häuser und Nächstenliebe, einige der weniger Privileg in verschiedenen countries.Despite wollte die Vereinbarung zwischen meinem verstorbenen Mann und ich, die Hilfe für die Benachteiligten zu geben, haben wir vereinbart, auch Unterstützung für eine Render Einzel wir nicht vor im Leben zu treffen haben aufgrund der Tatsache, als wir noch jung waren wir im Leben eines anonymen Hilfe von einem einzelnen wussten wir nicht, und das haben wir nicht in der Lage, bis heute wissen, haben wir die Auswirkungen von solchen Geste bekam empfangen machte uns zu elbe zu tun. Leider muss ich Ihnen mitteilen, dass Sie nie die Chance haben, mich zu kennen, weil ich gerade abgeschlossen, die die mein Mann und ich auf vor seinem plötzlichen Tod vereinbarte Abtretung und Sie zufällig der Begünstigte der letzten sein wird, daher brauche ich Sie zu mir durch die Annahme unseres Angebots einen Gefallen zu tun. Ich einige hinterlegten Fonds in Höhe von 1.800.000,00 (eine Million achthunderttausend Euro) mit DHL NL vor vier Wochen, um an Sie zu liefern, aber ich war sehr krank, so konnte ich keine E-Mail senden Sie bis heute. was Sie jetzt noch tun müssen, ist die DHL-Kurier SERVICE NL so bald wie möglich kontaktieren, zu wissen, wann sie Ihr Paket liefern, um Ihre Informationen you.for, die ich für die Bereitstellung von Lade, Versicherungsprämien und die Unbedenklichkeitsbescheinigung Fee der Scheck bezahlt haben die zeigen, dass es nicht ein Drug Money oder soll Terroranschlag in Ihrem Land zu sponsern Sie haben die DHL EXPRESS NL für die Lieferung Ihrer Check mit diesen Informationen unten jetzt zu kontaktieren; Ansprechpartner: Herr Greg Cohen E-Mail-Adresse: dhlexpress...@aim.com Adresse: DHL EXPRESS SERVICE CENTRE, Terminalweg 36 3821 AJ Amersfoort Niederlande Auch hier sind Sie nicht für die Bereitstellung von Lade, die Versicherungsprämie und die Unbedenklichkeitsbescheinigung Fee der Scheck zu bezahlen, weil ich schon für sie bezahlt, das einzige Geld, das Sie erwartet, dass sie zahlen, ist 1160 für die Sicherheit Haltung der Prüfung so far.I würde die Gebühr bezahlt haben, aber das Unternehmen darauf bestanden, dass ich nicht, weil sie nicht wissen, wann Sie Kontakt mit ihnen und Widerrede Wut oder weitere cost.You zu vermeiden sind, um die folgenden Informationen, um sie erneut zu bestätigen, um jede Fehler zu vermeiden auf der Liefer. Postanschrift: Volle Namen: Direkte Telefonnummer: Alter: Unten ist die Sicherheit Haltung Code: (CFR / 45-300-07) für Ihre Entwürfe, sind Sie so bald auch präsentieren, um sie für die Überprüfung vor Anlieferung, versuchen, sie zu kontaktieren, wenn Sie diese Mail erhalten keine weiteren zu vermeiden, delay.Be auch mitgeteilt, dass ich nicht mehr meine E-Mails lesen werden oder das Surfen im Internet, wie ich völlig von der Außenwelt zu meiner Ranch in diesem Moment habe ich nichts mit Autos, E-Mails und anderen Luxus zu tun im Ruhestand,, jede weitere Korrespondenz sollte an den Kurierdienst für die Lieferung von Ihren Scheck an Sie weitergeleitet werden. Mit freundlichen Grüßen, Frau Patricia Ernes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More
Re: [PATCH] Fixed all coding style issues for drivers/staging/media/lirc/
On 10/02/2014 07:45 PM, Joe Perches wrote:
On Thu, 2014-10-02 at 10:29 -0300, Mauro Carvalho Chehab wrote:
Em Wed, 01 Oct 2014 21:40:02 -0700 Amber Thrall
escreveu:
Fixed various coding style issues, including strings over 80 characters long
and many
deprecated printk's have been replaced with proper methods.
[]
diff --git a/drivers/staging/media/lirc/lirc_imon.c
b/drivers/staging/media/lirc/lirc_imon.c
[]
@@ -623,8 +623,8 @@ static void imon_incoming_packet(struct imon_context
*context,
if (debug) {
dev_info(dev, "raw packet: ");
for (i = 0; i < len; ++i)
- printk("%02x ", buf[i]);
- printk("\n");
+ dev_info(dev, "%02x ", buf[i]);
+ dev_info(dev, "\n");
}
This is wrong, as the second printk should be printk_cont.
The best here would be to change all above to use %*ph.
So, just:
dev_debug(dev, "raw packet: %*ph\n", len, buf);
Not quite.
%*ph is length limited and only useful for lengths < 30 or so.
Even then, it's pretty ugly.
print_hex_dump_debug() is generally better.
That is place where you print 8 debug bytes, which are received remote
controller code. IMHO %*ph format is just what you like in that case.
Why print_hex_dump_debug() is better? IIRC it could not be even
controlled like those dynamic debug printings.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NTFS: Remove bogus space.
Hi Andrew,
Forgot to say that this patch is from Andrea Gilmini originally (I had to re-do
it as it is an old patch and the line numbers had changed)...
Best regards,
Anton
On 3 Oct 2014, at 00:44, Anton Altaparmakov wrote:
> fs/ntfs/debug.c:124: WARNING: space prohibited between function name and
> open parenthesis '('
>
> Signed-off-by: Andrea Gelmini
> Signed-off-by: Anton Altaparmakov
> ---
> Hi Andrew,
>
> Can you please take this simple patch and push it to Linus at some point?
>
> Thanks a lot in advance!
>
> Best regards,
>
> Anton
> --
> Anton Altaparmakov (replace at with @)
> Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
> Linux NTFS maintainer, http://www.linux-ntfs.org/
>
> diff --git a/fs/ntfs/debug.c b/fs/ntfs/debug.c
> index dd6103c..825a54e 100644
> --- a/fs/ntfs/debug.c
> +++ b/fs/ntfs/debug.c
> @@ -112,7 +112,7 @@ void __ntfs_error(const char *function, const struct
> super_block *sb,
> /* If 1, output debug messages, and if 0, don't. */
> int debug_msgs = 0;
>
> -void __ntfs_debug (const char *file, int line, const char *function,
> +void __ntfs_debug(const char *file, int line, const char *function,
> const char *fmt, ...)
> {
> struct va_format vaf;
--
Anton Altaparmakov (replace at with @)
University of Cambridge Information Services, Roger Needham Building
7 JJ Thomson Avenue, Cambridge, CB3 0RB, UK
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] NTFS: Remove bogus space.
fs/ntfs/debug.c:124: WARNING: space prohibited between function name and
open parenthesis '('
Signed-off-by: Andrea Gelmini
Signed-off-by: Anton Altaparmakov
---
Hi Andrew,
Can you please take this simple patch and push it to Linus at some point?
Thanks a lot in advance!
Best regards,
Anton
--
Anton Altaparmakov (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
diff --git a/fs/ntfs/debug.c b/fs/ntfs/debug.c
index dd6103c..825a54e 100644
--- a/fs/ntfs/debug.c
+++ b/fs/ntfs/debug.c
@@ -112,7 +112,7 @@ void __ntfs_error(const char *function, const struct
super_block *sb,
/* If 1, output debug messages, and if 0, don't. */
int debug_msgs = 0;
-void __ntfs_debug (const char *file, int line, const char *function,
+void __ntfs_debug(const char *file, int line, const char *function,
const char *fmt, ...)
{
struct va_format vaf;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: update include path for mpssd
sysfs.c includes mpssd.h which includes virtio_ids.h. sysfs.c doesn't have the proper include flags set to use the latest headers, so this causes a build error if the system headers are too old. Signed-off-by: Peter Foley Cc: rdun...@infradead.org Cc: linux-...@vger.kernel.org Cc: sudeep.d...@intel.com Cc: nikhil@intel.com Cc: ashutosh.di...@intel.com Cc: a...@linux-foundation.org Cc: gre...@linuxfoundation.org Cc: harshavardhan.r.khar...@intel.com Cc: caz.yokoy...@intel.com Cc: dasaratharaman.chandramo...@intel.com Cc: jkos...@suse.cz --- Resending with missing CC to Documentation maintainer Documentation/mic/mpssd/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/mic/mpssd/Makefile b/Documentation/mic/mpssd/Makefile index 505d84f..0f31568 100644 --- a/Documentation/mic/mpssd/Makefile +++ b/Documentation/mic/mpssd/Makefile @@ -6,7 +6,7 @@ mpssd-objs := mpssd.o sysfs.o # Tell kbuild to always build the programs always := $(hostprogs-y) -HOSTCFLAGS_mpssd.o += -I$(objtree)/usr/include -I$(srctree)/tools/include +HOSTCFLAGS += -I$(objtree)/usr/include -I$(srctree)/tools/include ifdef DEBUG HOSTCFLAGS += -DDEBUG=$(DEBUG) -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support
On Tue, Sep 30, 2014 at 09:15:55AM +0200, Luis R. Rodriguez wrote: > Can you provide an example code path hit here? I'll certainly like to address > that as well. I managed to enable built-in driver support on top of this series, I'll send them as part of the next series but I suspect we'll want to discuss blacklist/whitelist a bit more there. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: update include path for mpssd
sysfs.c includes mpssd.h which includes virtio_ids.h. sysfs.c doesn't have the proper include flags set to use the latest headers, so this causes a build error if the system headers are too old. Signed-off-by: Peter Foley Cc: rdun...@infradead.org Cc: linux-...@vger.kernel.org Cc: sudeep.d...@intel.com Cc: nikhil@intel.com Cc: ashutosh.di...@intel.com Cc: a...@linux-foundation.org Cc: gre...@linuxfoundation.org Cc: harshavardhan.r.khar...@intel.com Cc: caz.yokoy...@intel.com Cc: dasaratharaman.chandramo...@intel.com --- Documentation/mic/mpssd/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/mic/mpssd/Makefile b/Documentation/mic/mpssd/Makefile index 505d84f..0f31568 100644 --- a/Documentation/mic/mpssd/Makefile +++ b/Documentation/mic/mpssd/Makefile @@ -6,7 +6,7 @@ mpssd-objs := mpssd.o sysfs.o # Tell kbuild to always build the programs always := $(hostprogs-y) -HOSTCFLAGS_mpssd.o += -I$(objtree)/usr/include -I$(srctree)/tools/include +HOSTCFLAGS += -I$(objtree)/usr/include -I$(srctree)/tools/include ifdef DEBUG HOSTCFLAGS += -DDEBUG=$(DEBUG) -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support
On Tue, Sep 30, 2014 at 09:21:59AM +0200, Luis R. Rodriguez wrote: > On Mon, Sep 29, 2014 at 05:26:01PM -0400, Tejun Heo wrote: > > Hello, Luis. > > > > On Mon, Sep 29, 2014 at 11:22:08PM +0200, Luis R. Rodriguez wrote: > > > > > + /* For now lets avoid stupid bug reports */ > > > > > + if (!strcmp(bus->name, "pci") || > > > > > + !strcmp(bus->name, "pci_express") || > > > > > + !strcmp(bus->name, "hid") || > > > > > + !strcmp(bus->name, "sdio") || > > > > > + !strcmp(bus->name, "gameport") || > > > > > + !strcmp(bus->name, "mmc") || > > > > > + !strcmp(bus->name, "i2c") || > > > > > + !strcmp(bus->name, "platform") || > > > > > + !strcmp(bus->name, "usb")) > > > > > + return true; > > > > > > > > Ugh... things like this tend to become permanent. Do we really need > > > > this? And how are we gonna find out what's broken why w/o bug > > > > reports? > > > > > > Yeah... well we have two options, one is have something like this to > > > at least make it generally useful or remove this and let folks who > > > care start fixing async for all modules. The downside to removing > > > this is it makes async probe pretty much useless on most systems > > > right now, it would mean systemd would have to probably consider > > > the list above if they wanted to start using this without expecting > > > systems to not work. > > > > So, I'd much prefer blacklist approach if something like this is a > > necessity. That way, we'd at least know what doesn't work. > > For buses? Or do you mean you'd want to wait until we have a decent > list of drivers with the sync probe flag set? If the later it may take > a while to get that list for this to be somewhat useful. OK I'm removing this part and it works well for me now on my laptop and an AMD server without a white list, so all the junk above will be removed in the next series. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: staging: rtl8723au: core: Fix "'foo * bar' should be 'foo *bar'" errors
Fix checkpatch.pl "'foo * bar' should be 'foo *bar'" errors
Signed-off-by: Greg Donald
---
drivers/staging/rtl8723au/core/rtw_ap.c| 2 +-
drivers/staging/rtl8723au/core/rtw_led.c | 3 ++-
drivers/staging/rtl8723au/core/rtw_mlme.c | 2 +-
drivers/staging/rtl8723au/core/rtw_security.c | 27 +-
drivers/staging/rtl8723au/core/rtw_wlan_util.c | 2 +-
5 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c
b/drivers/staging/rtl8723au/core/rtw_ap.c
index 6b4092f..4c3d4c8 100644
--- a/drivers/staging/rtl8723au/core/rtw_ap.c
+++ b/drivers/staging/rtl8723au/core/rtw_ap.c
@@ -1819,7 +1819,7 @@ void rtw_ap_restore_network(struct rtw_adapter *padapter)
{
struct mlme_priv *mlmepriv = >mlmepriv;
struct mlme_ext_priv *pmlmeext = >mlmeextpriv;
- struct sta_priv * pstapriv = >stapriv;
+ struct sta_priv *pstapriv = >stapriv;
struct sta_info *psta;
struct security_priv *psecuritypriv = >securitypriv;
struct list_head *phead, *plist, *ptmp;
diff --git a/drivers/staging/rtl8723au/core/rtw_led.c
b/drivers/staging/rtl8723au/core/rtw_led.c
index 989cda2..fa3dcff 100644
--- a/drivers/staging/rtl8723au/core/rtw_led.c
+++ b/drivers/staging/rtl8723au/core/rtw_led.c
@@ -51,7 +51,8 @@ void BlinkWorkItemCallback23a(struct work_struct *work)
/* Description: */
/* Reset status of led_8723a object. */
/* */
-void ResetLedStatus23a(struct led_8723a * pLed) {
+void ResetLedStatus23a(struct led_8723a *pLed)
+{
pLed->CurrLedState = RTW_LED_OFF; /* Current LED state. */
pLed->bLedOn = false; /* true if LED is ON, false if LED is OFF. */
diff --git a/drivers/staging/rtl8723au/core/rtw_mlme.c
b/drivers/staging/rtl8723au/core/rtw_mlme.c
index 1f60064..00e7ad0 100644
--- a/drivers/staging/rtl8723au/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723au/core/rtw_mlme.c
@@ -1766,7 +1766,7 @@ exit:
return ret;
}
-int rtw_set_auth23a(struct rtw_adapter * adapter,
+int rtw_set_auth23a(struct rtw_adapter *adapter,
struct security_priv *psecuritypriv)
{
struct cmd_obj *pcmd;
diff --git a/drivers/staging/rtl8723au/core/rtw_security.c
b/drivers/staging/rtl8723au/core/rtw_security.c
index 76371ae..b488622 100644
--- a/drivers/staging/rtl8723au/core/rtw_security.c
+++ b/drivers/staging/rtl8723au/core/rtw_security.c
@@ -30,12 +30,12 @@ struct arc4context
u8 state[256];
};
-static void arcfour_init(struct arc4context*parc4ctx, u8 * key, u32
key_len)
+static void arcfour_init(struct arc4context *parc4ctx, u8 *key, u32 key_len)
{
u32 t, u;
u32 keyindex;
u32 stateindex;
- u8 * state;
+ u8 *state;
u32 counter;
state = parc4ctx->state;
@@ -62,7 +62,7 @@ static u32 arcfour_byte( struct arc4context
*parc4ctx)
u32 x;
u32 y;
u32 sx, sy;
- u8 * state;
+ u8 *state;
state = parc4ctx->state;
x = (parc4ctx->x + 1) & 0xff;
@@ -78,8 +78,8 @@ static u32 arcfour_byte( struct arc4context
*parc4ctx)
}
static void arcfour_encrypt( struct arc4context *parc4ctx,
- u8 * dest,
- u8 * src,
+ u8 *dest,
+ u8 *src,
u32 len)
{
u32 i;
@@ -221,7 +221,7 @@ void rtw_wep_decrypt23a(struct rtw_adapter *padapter,
u8 keyindex;
struct rx_pkt_attrib *prxattrib = >attrib;
struct security_priv *psecuritypriv = >securitypriv;
- struct sk_buff * skb = precvframe->pkt;
+ struct sk_buff *skb = precvframe->pkt;
pframe = skb->data;
@@ -266,7 +266,7 @@ void rtw_wep_decrypt23a(struct rtw_adapter *padapter,
/* 3 = TKIP related = */
-static u32 secmicgetuint32(u8 * p)
+static u32 secmicgetuint32(u8 *p)
/* Convert from Byte[] to u32 in a portable way */
{
s32 i;
@@ -280,7 +280,7 @@ static u32 secmicgetuint32(u8 * p)
return res;
}
-static void secmicputuint32(u8 * p, u32 val)
+static void secmicputuint32(u8 *p, u32 val)
/* Convert from long to Byte[] in a portable way */
{
long i;
@@ -304,7 +304,7 @@ static void secmicclear(struct mic_data *pmicdata)
}
-void rtw_secmicsetkey23a(struct mic_data *pmicdata, u8 * key)
+void rtw_secmicsetkey23a(struct mic_data *pmicdata, u8 *key)
{
/* Set the key */
@@ -340,7 +340,7 @@ void rtw_secmicappend23abyte23a(struct mic_data *pmicdata,
u8 b)
}
-void rtw_secmicappend23a(struct mic_data *pmicdata, u8 * src, u32 nbytes)
+void rtw_secmicappend23a(struct mic_data *pmicdata, u8 *src, u32 nbytes)
{
/* This is simple */
@@ -352,7 +352,7 @@ void rtw_secmicappend23a(struct mic_data *pmicdata, u8 *
src, u32 nbytes)
}
-void rtw_secgetmic23a(struct mic_data *pmicdata, u8 * dst)
+void rtw_secgetmic23a(struct mic_data *pmicdata, u8 *dst)
{
/* Append the minimum padding */
@@ -374,7 +374,8 @@
mmotm 2014-10-02-16-22 uploaded
The mm-of-the-moment snapshot 2014-10-02-16-22 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 3.17-rc7: (patches marked "*" will be included in linux-next) origin.patch i-need-old-gcc.patch arch-alpha-kernel-systblss-remove-debug-check.patch * ocfs2-dlm-should-put-mle-when-goto-kill-in-dlm_assert_master_handler.patch * mm-memcontrol-do-not-iterate-uninitialized-memcgs.patch * maintainers-change-git-url-for-mpc5xxx-tree.patch * perf-fix-perf-bug-in-fork.patch * mm-page_alloc-fix-zone-allocation-fairness-on-up.patch * mm-migrate-close-race-between-migration-completion-and-mprotect.patch * mm-numa-do-not-mark-ptes-pte_numa-when-splitting-huge-pages.patch * mn10300-use-kbuild-logic-to-include-asm-generic-sectionsh.patch * cris-use-kbuild-logic-to-include-asm-generic-sectionsh.patch * fs-cifs-remove-obsolete-__constant.patch * fs-cifs-filec-replace-countsize-kzalloc-by-kcalloc.patch * fs-cifs-smb2filec-replace-countsize-kzalloc-by-kcalloc.patch * efi-bgrt-add-error-handling-inform-the-user-when-ignoring-the-bgrt.patch * fs-notify-groupc-make-fsnotify_final_destroy_group-static.patch * fsnotify-dont-put-user-context-if-it-was-never-assigned.patch * kernel-posix-timersc-code-clean-up.patch * kernel-posix-timersc-code-clean-up-checkpatch-fixes.patch * input-route-kbd-leds-through-the-generic-leds-layer.patch * input-route-kbd-leds-through-the-generic-leds-layer-fix.patch * input-route-kbd-leds-through-the-generic-leds-layer-fix-2.patch * kernel-add-support-for-gcc-5.patch * kernel-add-support-for-gcc-5-checkpatch-fixes.patch * m32r-use-kbuild-logic-to-include-asm-generic-sectionsh.patch * m32r-remove-deprecated-irqf_disabled.patch * use-find_get_page_flags-to-mark-page-accessed-as-it-is-no-longer-marked-later-on.patch * score-use-kbuild-logic-to-include-asm-generic-sectionsh.patch * score-remove-deprecated-irqf_disabled.patch * fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch * fs-ocfs2-stack_userc-fix-typo-in-ocfs2_control_release.patch * ocfs2-dlm-refactor-error-handling-in-dlm_alloc_ctxt.patch * ocfs2-fix-shift-left-operations-overflow.patch * ocfs2-call-o2quo_exit-if-malloc-failed-in-o2net_init.patch * ocfs2-dlm-call-dlm_lockres_put-without-resource-spinlock.patch * o2dlm-fix-null-pointer-dereference-in-o2dlm_blocking_ast_wrapper.patch * o2dlm-fix-null-pointer-dereference-in-o2dlm_blocking_ast_wrapper-checkpatch-fixes.patch * ocfs2-remove-unused-code-in-dlm_new_lockres.patch * fs-ocfs2-dlm-dlmdebugc-use-seq_open_private-not-seq_open.patch * fs-ocfs2-cluster-netdebugc-use-seq_open_private-not-seq_open.patch * fs-ocfs2-dlmgluec-use-__seq_open_private-not-seq_open.patch * ocfs2-dont-fire-quorum-before-connection-established.patch *
Re: [PATCH 00/13 v10] omap 8250 based UART + DMA
* Tony Lindgren | 2014-10-02 09:43:39 [-0700]: >Looks good to me. For the patches that do not yet have my acks, please >feel free to add: > >Reviewed-by: Tony Lindgren >Tested-by: Tony Lindgren Thanks. >It's probably best that I queue the .dts changes separately though >to avoid pointless merge conflicts. Yeah. There is no real dependency on them except that you need them at some point :) >Regards, > >Tony Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: staging: lustre: Fix "'foo* bar' should be 'foo *bar'" errors
Fix checkpatch.pl "'foo* bar' should be 'foo *bar'" errors
Signed-off-by: Greg Donald
---
drivers/staging/lustre/lustre/include/dt_object.h | 2 +-
drivers/staging/lustre/lustre/include/lu_object.h | 4 ++--
drivers/staging/lustre/lustre/include/lustre_lib.h | 2 +-
drivers/staging/lustre/lustre/include/lustre_net.h | 2 +-
drivers/staging/lustre/lustre/include/obd_class.h | 2 +-
drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +-
drivers/staging/lustre/lustre/llite/statahead.c | 2 +-
drivers/staging/lustre/lustre/obdclass/llog_obd.c | 2 +-
drivers/staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c | 2 +-
drivers/staging/lustre/lustre/ptlrpc/pinger.c | 2 +-
10 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/dt_object.h
b/drivers/staging/lustre/lustre/include/dt_object.h
index 212ebae..c2e7622 100644
--- a/drivers/staging/lustre/lustre/include/dt_object.h
+++ b/drivers/staging/lustre/lustre/include/dt_object.h
@@ -617,7 +617,7 @@ struct dt_index_operations {
int(*load)(const struct lu_env *env,
const struct dt_it *di, __u64 hash);
int (*key_rec)(const struct lu_env *env,
- const struct dt_it *di, void* key_rec);
+ const struct dt_it *di, void *key_rec);
} dio_it;
};
diff --git a/drivers/staging/lustre/lustre/include/lu_object.h
b/drivers/staging/lustre/lustre/include/lu_object.h
index 6015ee5..2ddb2b0 100644
--- a/drivers/staging/lustre/lustre/include/lu_object.h
+++ b/drivers/staging/lustre/lustre/include/lu_object.h
@@ -1120,7 +1120,7 @@ struct lu_context_key {
};
#define LU_KEY_INIT(mod, type) \
- static void* mod##_key_init(const struct lu_context *ctx, \
+ static void *mod##_key_init(const struct lu_context *ctx, \
struct lu_context_key *key) \
{\
type *value; \
@@ -1137,7 +1137,7 @@ struct lu_context_key {
#define LU_KEY_FINI(mod, type) \
static void mod##_key_fini(const struct lu_context *ctx,\
- struct lu_context_key *key, void* data) \
+ struct lu_context_key *key, void *data) \
{ \
type *info = data;\
\
diff --git a/drivers/staging/lustre/lustre/include/lustre_lib.h
b/drivers/staging/lustre/lustre/include/lustre_lib.h
index 12c7590..bf13563 100644
--- a/drivers/staging/lustre/lustre/include/lustre_lib.h
+++ b/drivers/staging/lustre/lustre/include/lustre_lib.h
@@ -85,7 +85,7 @@ void target_send_reply(struct ptlrpc_request *req, int rc,
int fail_id);
/* client.c */
-int client_sanobd_setup(struct obd_device *obddev, struct lustre_cfg* lcfg);
+int client_sanobd_setup(struct obd_device *obddev, struct lustre_cfg *lcfg);
struct client_obd *client_conn2cli(struct lustre_handle *conn);
struct md_open_data;
diff --git a/drivers/staging/lustre/lustre/include/lustre_net.h
b/drivers/staging/lustre/lustre/include/lustre_net.h
index 0a024d3..d4da243 100644
--- a/drivers/staging/lustre/lustre/include/lustre_net.h
+++ b/drivers/staging/lustre/lustre/include/lustre_net.h
@@ -2951,7 +2951,7 @@ void ptlrpcd_decref(void);
* procfs output related functions
* @{
*/
-const char* ll_opcode2str(__u32 opcode);
+const char *ll_opcode2str(__u32 opcode);
#if defined (CONFIG_PROC_FS)
void ptlrpc_lprocfs_register_obd(struct obd_device *obd);
void ptlrpc_lprocfs_unregister_obd(struct obd_device *obd);
diff --git a/drivers/staging/lustre/lustre/include/obd_class.h
b/drivers/staging/lustre/lustre/include/obd_class.h
index 882e40b..4a29261 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -414,7 +414,7 @@ do {
\
#define EXP_MD_COUNTER_INCREMENT(exp, op)
#endif
-static inline int lprocfs_nid_ldlm_stats_init(struct nid_stat* tmp)
+static inline int lprocfs_nid_ldlm_stats_init(struct nid_stat *tmp)
{
/* Always add in ldlm_stats */
tmp->nid_ldlm_stats = lprocfs_alloc_stats(LDLM_LAST_OPC - LDLM_FIRST_OPC
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index a8bcc51..061483f 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -2398,7 +2398,7 @@ char *ll_get_fsname(struct super_block *sb, char *buf,
int buflen)
return buf;
}
-static char* ll_d_path(struct dentry
Re: [PATCH v3 0/5] enhance DMA CMA on x86
2014-10-03 7:03 GMT+09:00 Peter Hurley : > On 10/02/2014 12:41 PM, Konrad Rzeszutek Wilk wrote: >> On Tue, Sep 30, 2014 at 09:49:54PM -0400, Peter Hurley wrote: >>> On 09/30/2014 07:45 PM, Thomas Gleixner wrote: >>> Which is different than if the plan is to ship production units for x86; >>> then a general purpose solution will be required. >>> >>> As to the good design of a general purpose solution for allocating and >>> mapping huge order pages, you are certainly more qualified to help Akinobu >>> than I am. > > What Akinobu's patches intend to support is: > > phys_addr = dma_alloc_coherent(dev, 64 * 1024 * 1024, _addr, > GFP_KERNEL); > > which raises three issues: > > 1. Where do coherent blocks of this size come from? > 2. How to prevent fragmentation of these reserved blocks over time by >existing DMA users? > 3. Is this support generically required across all iommu implementations on > x86? > > Questions 1 and 2 are non-trivial, in the general case, otherwise the page > allocator would already do this. Simply dropping in the contiguous memory > allocator doesn't work because CMA does not have the same policy and > performance > as the page allocator, and is already causing performance regressions even > in the absence of huge page allocations. Could you take a look at the patches I sent? Can they fix these issues? https://lkml.org/lkml/2014/9/28/110 With these patches, normal alloc_pages() is used for allocation first and dma_alloc_from_contiguous() is used as a fallback. > So that's why I raised question 3; is making the necessary compromises to > support > 64MB coherent DMA allocations across all x86 iommu implementations actually > required? > > Prior to Akinobu's patches, the use of CMA by x86 iommu configurations was > designed to be limited to testing configurations, as the introductory > commit states: > > commit 0a2b9a6ea93650b8a00f9fd5ee8fdd25671e2df6 > Author: Marek Szyprowski > Date: Thu Dec 29 13:09:51 2011 +0100 > > X86: integrate CMA with DMA-mapping subsystem > > This patch adds support for CMA to dma-mapping subsystem for x86 > architecture that uses common pci-dma/pci-nommu implementation. This > allows to test CMA on KVM/QEMU and a lot of common x86 boxes. > > Signed-off-by: Marek Szyprowski > Signed-off-by: Kyungmin Park > CC: Michal Nazarewicz > Acked-by: Arnd Bergmann > > > Which brings me to my suggestion: if support for huge coherent DMA is > required only for a special test platform, then could not this support > be specific to a new iommu configuration, namely iommu=cma, which would > get initialized much the same way that iommu=calgary is now. > > The code for such a iommu configuration would mostly duplicate > arch/x86/kernel/pci-swiotlb.c and the CMA support would get removed from > the other x86 iommu implementations. I'm not sure I read correctly, though. Can boot option 'cma=0' also help avoiding CMA from IOMMU implementation? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 5/7] soc: qcom: Add Shared Memory Driver
On 09/29/14 17:34, Bjorn Andersson wrote: > + > +#define GET_RX_CHANNEL_INFO(channel, param) \ > + (channel->rx_info_word ? \ > + channel->rx_info_word->param : \ > + channel->rx_info->param) > + > +#define GET_TX_CHANNEL_INFO(channel, param) \ > + (channel->rx_info_word ? \ > + channel->tx_info_word->param : \ > + channel->tx_info->param) > + > +#define SET_RX_CHANNEL_INFO(channel, param, value) \ > + (channel->rx_info_word ? \ > + (channel->rx_info_word->param = value) : \ > + (channel->rx_info->param = value)) > + > +#define SET_TX_CHANNEL_INFO(channel, param, value) \ > + (channel->rx_info_word ? \ Drive-by review: Should this be tx_info_word? Given that it works I wonder why not just have a flag indicating if we should use word aligned read/write vs. byte aligned. > + (channel->tx_info_word->param = value) : \ > + (channel->tx_info->param = value)) > + -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RESEND][TRIVIAL] treewide: fix occurrences of "the the "
On Thu, Oct 02, 2014 at 10:15:03PM +0200, Michael Opdenacker wrote: > Fix all occurrences of "the the ", and occasionally "in in ", > in the source code, comments and documentation. > > The replacement couldn't be automated because sometimes > the first "the" was meant to be another word. > > Example: "according the the" > meaning: "according to the" > > Note that I sometimes took the opportunity to fix > other spelling issues or typos in the same sentences, > and to reformat some comments impacted by the changes. > > I also fixed a few checkpatch errors in the same > lines, but not all of them (should be addressed by > separate patches). > > Signed-off-by: Michael Opdenacker > Reviewed-by: rdun...@infradead.org > --- > tools/thermal/tmon/pid.c | 2 +- > 225 files changed, 266 insertions(+), 266 deletions(-) > > diff --git a/tools/thermal/tmon/pid.c b/tools/thermal/tmon/pid.c > index fd7e9e9d6f4a..1aa7faa0e0e0 100644 > --- a/tools/thermal/tmon/pid.c > +++ b/tools/thermal/tmon/pid.c > @@ -38,7 +38,7 @@ > > /** > * PID (Proportional-Integral-Derivative) controller is commonly used in > - * linear control system, consider the the process. > + * linear control system, consider the process. On Tmon behalf: Acked-by: Eduardo Valentin > * G(s) = U(s)/E(s) > * kp = proportional gain > * ki = integral gain > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] thermal: core: fix: Initialize the max_state variable to 0
Hello Lukasz, On Wed, Sep 24, 2014 at 10:27:11AM +0200, Lukasz Majewski wrote: > Pointer to the uninitialized max_state variable is passed to get the > maximal cooling state. > For CPU cooling device (cpu_cooling.c) the cpufreq_get_max_state() is > called, which even when error occurs will return the max_state variable > unchanged. > Since error for ->get_max_state() is not checked, the automatically Good that you added a fix in your series for this. > allocated value of max_state is used for (upper > max_state) comparison. > For any possible max_state value it is very unlikely that it will be less > than upper. > As a consequence, the cooling device is bind even without the backed > cpufreq table initialized. > > This initialization will prevent from accidental binding trip points to > cpu freq cooling frequencies when cpufreq driver itself is not yet fully > initialized. Although I agree with the fix, as long as we also include a check for the .get_max_state return value, I believe the problem you are describing is about initialization sequence. In general, I believe we need a better sequencing between thermal and cpufreq subsystems. One way out is to include a check for cpufreq driver in the thermal driver, and return -EPROBE_DEFER when cpufreq is not ready. > > Signed-off-by: Lukasz Majewski > --- > drivers/thermal/thermal_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c > index 454884a..747618a 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -927,7 +927,7 @@ int thermal_zone_bind_cooling_device(struct > thermal_zone_device *tz, > struct thermal_instance *pos; > struct thermal_zone_device *pos1; > struct thermal_cooling_device *pos2; > - unsigned long max_state; > + unsigned long max_state = 0; > int result; > > if (trip >= tz->trips || (trip < 0 && trip != THERMAL_TRIPS_NONE)) > -- > 2.0.0.rc2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] thermal: core: fix: Check return code of the ->get_max_state() callback
On Wed, Sep 24, 2014 at 10:27:12AM +0200, Lukasz Majewski wrote: > Without this check it was possible to execute cooling device binding code > even when wrong max cooling state was read. > > Signed-off-by: Lukasz Majewski Acked-by: Eduardo Valentin Rui, are you taking these patches? Do you prefer me to collect them? Cheers Eduardo > --- > drivers/thermal/thermal_core.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c > index 747618a..8a4dc35 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -928,7 +928,7 @@ int thermal_zone_bind_cooling_device(struct > thermal_zone_device *tz, > struct thermal_zone_device *pos1; > struct thermal_cooling_device *pos2; > unsigned long max_state = 0; > - int result; > + int result, ret; > > if (trip >= tz->trips || (trip < 0 && trip != THERMAL_TRIPS_NONE)) > return -EINVAL; > @@ -945,7 +945,9 @@ int thermal_zone_bind_cooling_device(struct > thermal_zone_device *tz, > if (tz != pos1 || cdev != pos2) > return -EINVAL; > > - cdev->ops->get_max_state(cdev, _state); > + ret = cdev->ops->get_max_state(cdev, _state); > + if (ret) > + return ret; > > /* lower default 0, upper default max_state */ > lower = lower == THERMAL_NO_LIMIT ? 0 : lower; > -- > 2.0.0.rc2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: serial: cp210x: Add Silicon Labs 358x VID and PID.
On Thu, Oct 02, 2014 at 05:38:17PM -0400, Nathaniel Ting wrote:
> From: Nathaniel Ting
>
> Enable Silicon Labs Ember VID chips to enumerate with the cp210x usb serial
> driver. EM358x devices operating with the Ember Z-Net 5.1.2 stack may now
> connect to host PCs over a USB serial link.
>
> Signed-off-by: Nathaniel Ting
> ---
> drivers/usb/serial/cp210x.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index e4bb622..ce81fa8 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -154,6 +154,7 @@ static const struct usb_device_id id_table[] = {
> { USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
> { USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
> { USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */
> +{ USB_DEVICE(0x1BA4, 0x0002) }, /* Silicon Labs 358x factory default
> */
Your whitespace is corrupted here, making the patch impossible to apply
:(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] USB: serial: cp210x: Add Silicon Labs 358x VID and PID.
From: Nathaniel Ting
Enable Silicon Labs Ember VID chips to enumerate with the cp210x usb serial
driver. EM358x devices operating with the Ember Z-Net 5.1.2 stack may now
connect to host PCs over a USB serial link.
Signed-off-by: Nathaniel Ting
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index e4bb622..ce81fa8 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -154,6 +154,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
{ USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
{ USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */
+{ USB_DEVICE(0x1BA4, 0x0002) }, /* Silicon Labs 358x factory default */
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
{ USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
{ USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
-- 1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] enhance DMA CMA on x86
On 10/02/2014 12:41 PM, Konrad Rzeszutek Wilk wrote: > On Tue, Sep 30, 2014 at 09:49:54PM -0400, Peter Hurley wrote: >> On 09/30/2014 07:45 PM, Thomas Gleixner wrote: >>> Whether the proposed patchset is the correct solution to support it is >>> a completely different question. >> >> This patchset has been in mainline since 3.16 and has already caused >> regressions, so the question of whether this is the correct solution has >> already been answered. >> >>> So either you stop this right now and help Akinobu to find the proper >>> solution >> >> If this is only a test platform for ARM parts then I don't think it >> unreasonable to suggest forking x86 swiotlb support into a iommu=cma > > Not sure what you mean by 'forking x86 swiotlb' ? As in have SWIOTLB > work under ARM? No, that's not what I meant. >> selector that gets DMA mapping working for this test platform and doesn't >> cause a bunch of breakage. > > I think you might want to take a look at the IOMMU_DETECT macros > and enable CMA there only if the certain devices are available. > > That way the normal flow of detecting which IOMMU to use is still present > and will turn of CMA if there is no device that would use it. > >> >> Which is different than if the plan is to ship production units for x86; >> then a general purpose solution will be required. >> >> As to the good design of a general purpose solution for allocating and >> mapping huge order pages, you are certainly more qualified to help Akinobu >> than I am. What Akinobu's patches intend to support is: phys_addr = dma_alloc_coherent(dev, 64 * 1024 * 1024, _addr, GFP_KERNEL); which raises three issues: 1. Where do coherent blocks of this size come from? 2. How to prevent fragmentation of these reserved blocks over time by existing DMA users? 3. Is this support generically required across all iommu implementations on x86? Questions 1 and 2 are non-trivial, in the general case, otherwise the page allocator would already do this. Simply dropping in the contiguous memory allocator doesn't work because CMA does not have the same policy and performance as the page allocator, and is already causing performance regressions even in the absence of huge page allocations. So that's why I raised question 3; is making the necessary compromises to support 64MB coherent DMA allocations across all x86 iommu implementations actually required? Prior to Akinobu's patches, the use of CMA by x86 iommu configurations was designed to be limited to testing configurations, as the introductory commit states: commit 0a2b9a6ea93650b8a00f9fd5ee8fdd25671e2df6 Author: Marek Szyprowski Date: Thu Dec 29 13:09:51 2011 +0100 X86: integrate CMA with DMA-mapping subsystem This patch adds support for CMA to dma-mapping subsystem for x86 architecture that uses common pci-dma/pci-nommu implementation. This allows to test CMA on KVM/QEMU and a lot of common x86 boxes. Signed-off-by: Marek Szyprowski Signed-off-by: Kyungmin Park CC: Michal Nazarewicz Acked-by: Arnd Bergmann Which brings me to my suggestion: if support for huge coherent DMA is required only for a special test platform, then could not this support be specific to a new iommu configuration, namely iommu=cma, which would get initialized much the same way that iommu=calgary is now. The code for such a iommu configuration would mostly duplicate arch/x86/kernel/pci-swiotlb.c and the CMA support would get removed from the other x86 iommu implementations. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hrtimer deadlock caused by nohz_full
I think this might be the bug I reported here
https://bugzilla.kernel.org/show_bug.cgi?id=84131
On 2 October 2014 19:24, Dave Jones wrote:
> On Fri, Sep 26, 2014 at 01:46:59AM +0200, Frederic Weisbecker wrote:
>
> > > > [] hrtimer_try_to_cancel+0x58/0x1f0
> > > > [] hrtimer_cancel+0x1a/0x30
> > > > [] tick_nohz_restart+0x17/0x90
> > > > [] __tick_nohz_full_check+0xc8/0xe0
> > > > [] nohz_full_kick_work_func+0xe/0x10
> > > > [] irq_work_run_list+0x4f/0x70
> > > > [] irq_work_run+0x2a/0x60
> > > > [] update_process_times+0x5b/0x70
> > > > [] tick_sched_handle.isra.21+0x25/0x60
> > > > [] tick_sched_timer+0x41/0x60
> > > > [] __run_hrtimer+0x81/0x480
> > > > [] ? tick_sched_do_timer+0x90/0x90
> > > > [] hrtimer_interrupt+0x107/0x260
> > > > [] local_apic_timer_interrupt+0x34/0x60
> > > > [] smp_apic_timer_interrupt+0x3f/0x60
> > > > [] apic_timer_interrupt+0x6f/0x80
> > >
> > > hrtimer_interrupt
> > > tick_sched_timer
> > > tick_sched_handle
> > > update_process_times
> > > irq_work_run
> > > irq_work_run_list
> > >nohz_full_kick_work_func
> > > __tick_nohz_full_check
> > >tick_nohz_restart
> > > hrtimer_cancel
> > >
> > > And that hrtimer_cancel is:
> > >
> > > static void tick_nohz_restart(struct tick_sched *ts, ktime_t now)
> > > {
> > >hrtimer_cancel(>sched_timer);
> > >
> > > Now, that's really bad because we are in the timer callback of
> > > ts->sched_timer. So hrtimer_cancel will loop forever waiting for the
> > > callback to complete.
> > >
> > > Frederic !?!?
> >
> > Right, this patchset fixes it: "[PATCH 0/8] nohz: Fix nohz kick irq work
> on tick v3"
> >
> > I was about to make the pull request, the branch is acked by peterz.
> > Would you like to pull it? It's all merge window material.
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > nohz/fixes-v3
>
> I'm now hitting this with such regularity that it's preventing me from
> tracking down other bugs. Can we get this merged soon please ?
>
> Dave
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] of: Add a function to read 64-bit arrays
Implement of_property_read_u64_array() for reading 64-bit arrays.
This is needed for e.g. reading the valid link frequencies in the smiapp
driver.
Signed-off-by: Sakari Ailus
---
Hi,
While the smiapp (found in drivers/media/i2c/smiapp/) OF support which needs
this isn't in yet, other drivers such as mt9v032 which would be reading the
valid link frequency control values will need reading arrays. This might
make it to v4l2-of.c in the end.
drivers/of/base.c | 44
include/linux/of.h |3 +++
2 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d8574ad..35e24f4 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1214,6 +1214,41 @@ int of_property_read_u32_array(const struct device_node
*np,
EXPORT_SYMBOL_GPL(of_property_read_u32_array);
/**
+ * of_property_read_u64_array - Find and read an array of 64 bit integers
+ * from a property.
+ *
+ * @np:device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ * @out_values:pointer to return value, modified only if return value
is 0.
+ * @sz:number of array elements to read
+ *
+ * Search for a property in a device node and read 64-bit value(s) from
+ * it. Returns 0 on success, -EINVAL if the property does not exist,
+ * -ENODATA if property does not have a value, and -EOVERFLOW if the
+ * property data isn't large enough.
+ *
+ * The out_values is modified only if a valid u32 value can be decoded.
+ */
+int of_property_read_u64_array(const struct device_node *np,
+ const char *propname, u64 *out_value, size_t sz)
+{
+ const __be32 *val = of_find_property_value_of_size(
+ np, propname, sz * sizeof(*out_value));
+
+ if (IS_ERR(val))
+ return PTR_ERR(val);
+
+ while (sz--) {
+ *out_value = of_read_number(val, 2);
+ out_value++;
+ val += 2;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_property_read_u64_array);
+
+/**
* of_property_read_u64 - Find and read a 64 bit integer from a property
* @np:device node from which the property value is to be read.
* @propname: name of the property to be searched.
@@ -1229,14 +1264,7 @@ EXPORT_SYMBOL_GPL(of_property_read_u32_array);
int of_property_read_u64(const struct device_node *np, const char *propname,
u64 *out_value)
{
- const __be32 *val = of_find_property_value_of_size(np, propname,
- sizeof(*out_value));
-
- if (IS_ERR(val))
- return PTR_ERR(val);
-
- *out_value = of_read_number(val, 2);
- return 0;
+ return of_property_read_u64_array(np, propname, out_value, 1);
}
EXPORT_SYMBOL_GPL(of_property_read_u64);
diff --git a/include/linux/of.h b/include/linux/of.h
index 6c4363b..e84533f 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -263,6 +263,9 @@ extern int of_property_read_u32_array(const struct
device_node *np,
size_t sz);
extern int of_property_read_u64(const struct device_node *np,
const char *propname, u64 *out_value);
+extern int of_property_read_u64_array(const struct device_node *np,
+ const char *propname, u64 *out_value,
+ size_t sz);
extern int of_property_read_string(struct device_node *np,
const char *propname,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acct: fix build warning when ACCT_VERSION != 3
On Thu, Oct 02, 2014 at 02:09:45PM -0700, Andrew Morton wrote: > On Thu, 2 Oct 2014 00:06:53 +0100 Luis Henriques > wrote: > > > struct pid_namespace *ns is used only when ACCT_VERSION is 3. > > > > kernel/acct.c:475:24: warning: unused variable 'ns' [-Wunused-variable] > > > > Signed-off-by: Luis Henriques > > --- > > kernel/acct.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/kernel/acct.c b/kernel/acct.c > > index b4c667d22e79..5f277f5c5e29 100644 > > --- a/kernel/acct.c > > +++ b/kernel/acct.c > > @@ -472,7 +472,9 @@ static void do_acct_process(struct bsd_acct_struct > > *acct) > > acct_t ac; > > unsigned long flim; > > const struct cred *orig_cred; > > +#if ACCT_VERSION == 3 > > struct pid_namespace *ns = acct->ns; > > +#endif > > struct file *file = acct->file; > > > > /* > > It's always a good idea to check linux-next. This has been addressed by > http://ozlabs.org/~akpm/mmots/broken-out/acct-eliminate-compile-warning.patch > http://ozlabs.org/~akpm/mmots/broken-out/acct-eliminate-compile-warning-fix.patch > > Ah, awesome! I missed these patches. Thanks Andrew. Cheers, -- Luís -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq v3.17-rc7 error: "cpufreq: cpufreq_resume: Failed to start governor for policy: f6909a00"
Rafael J. Wysocki schreef op do 02-10-2014 om 19:34 [+0200]:
> On Thursday, October 02, 2014 06:33:28 PM Paul Bolle wrote:
> > On Thu, 2014-10-02 at 18:38 +0200, Rafael J. Wysocki wrote:
> > > Can you please try linux-pm.git/linux-next? There's a commit from Viresh
> > > in
> > > there with a chance to fix this and which I'm going to push to Linus
> > > shortly?
> >
> > Do you mean b1b12babe3b72cfb08b875245e5a5d7c2747c772 ("cpufreq: update
> > 'cpufreq_suspended' after stopping governors")? Does that require
> > anything else from that tree? It doesn't matter much, but if possible I
> > would prefer to add as few patches as I can get away with.
>
> Yes, that's the commit. It should work alone too.
Applies and builds cleanly on top of v3.17-rc7. Light testing (two
suspend and resume cycles and one hibernate and thaw cycle) doesn't
trigger the error.
So that commit works for this ThinkPad X41 too, it seems.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] audit fsnotify cleanups for watches and trees
This is a collection of patches to clean up some issues discovered while implementing audit by exe path. They compile and have been lightly tested. I'd be interested in feedback about approaches or details or grossly misunderstanding some fundamental concepts. Thanks! Richard Guy Briggs (7): audit: put rule existence check in canonical order audit: cull redundancy in audit_rule_change audit: eliminate string copy for new tree rules audit: optimize add to parent skipping needless search and consuming parent ref audit: remove redundant watch refcount audit: remove extra audit_get_parent() audit: rename audit_log_remove_rule to disambiguate for trees kernel/audit_tree.c | 13 +++-- kernel/audit_watch.c | 29 - kernel/auditfilter.c | 34 +++--- 3 files changed, 34 insertions(+), 42 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
