[PATCH] bpf: Put perf_events check ahead of bpf prog
When we add a kprobe point and record events by perf, the execution path of all threads on each cpu will enter this point, but perf may only record events on a particular thread or cpu at this kprobe point, a check on call-perf_events list filters out the threads which perf is not recording. Currently, bpf_prog will be entered at the beginning of kprobe_perf_func() before the above check, which makes bpf_prog be executed in every threads including determined not to be recorded threads. A simple test can demonstrate this: 'bpf_prog_on_write.o' contains a bpf prog which outputs to trace buffer when it is entered. Run a background thread 'another-dd' and 'dd' simultaneously, but only record 'dd' thread by perf. The result shows all threads trigger bpf_prog. $ another-dd if=/dev/zero of=test1 bs=4k count=100 $ perf record -v --event bpf_prog_on_write.o -- dd if=/dev/zero of=test2 bs=4k count=3 $ cat /sys/kernel/debug/tracing/trace another-dd-1007 [000] d... 120.225835: : generic_perform_write: tgid=1007, pid=1007 another-dd-1007 [000] d... 120.227123: : generic_perform_write: tgid=1007, pid=1007 [repeat many times...] another-dd-1007 [000] d... 120.412395: : generic_perform_write: tgid=1007, pid=1007 another-dd-1007 [000] d... 120.412524: : generic_perform_write: tgid=1007, pid=1007 dd-1009 [000] d... 120.413080: : generic_perform_write: tgid=1009, pid=1009 dd-1009 [000] d... 120.414846: : generic_perform_write: tgid=1009, pid=1009 dd-1009 [000] d... 120.415013: : generic_perform_write: tgid=1009, pid=1009 another-dd-1007 [000] d... 120.416128: : generic_perform_write: tgid=1007, pid=1007 another-dd-1007 [000] d... 120.416295: : generic_perform_write: tgid=1007, pid=1007 This patch moves the check on perf_events list ahead and skip running bpf_prog on threads perf not care. After this patch: $ another-dd if=/dev/zero of=test1 bs=4k count=100 $ perf record -v --event bpf_prog_on_write.o -- dd if=/dev/zero of=test2 bs=4k count=3 $ cat /sys/kernel/debug/tracing/trace dd-994 [000] d...46.386754: : generic_perform_write: tgid=994, pid=994 dd-994 [000] d...46.389167: : generic_perform_write: tgid=994, pid=994 dd-994 [000] d...46.389551: : generic_perform_write: tgid=994, pid=994 Signed-off-by: He Kuang heku...@huawei.com --- kernel/trace/trace_kprobe.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c index d0ce590..5600df8 100644 --- a/kernel/trace/trace_kprobe.c +++ b/kernel/trace/trace_kprobe.c @@ -1141,13 +1141,13 @@ kprobe_perf_func(struct trace_kprobe *tk, struct pt_regs *regs) int size, __size, dsize; int rctx; - if (prog !trace_call_bpf(prog, regs)) - return; - head = this_cpu_ptr(call-perf_events); if (hlist_empty(head)) return; + if (prog !trace_call_bpf(prog, regs)) + return; + dsize = __get_data_size(tk-tp, regs); __size = sizeof(*entry) + tk-tp.size + dsize; size = ALIGN(__size + sizeof(u32), sizeof(u64)); @@ -1176,13 +1176,13 @@ kretprobe_perf_func(struct trace_kprobe *tk, struct kretprobe_instance *ri, int size, __size, dsize; int rctx; - if (prog !trace_call_bpf(prog, regs)) - return; - head = this_cpu_ptr(call-perf_events); if (hlist_empty(head)) return; + if (prog !trace_call_bpf(prog, regs)) + return; + dsize = __get_data_size(tk-tp, regs); __size = sizeof(*entry) + tk-tp.size + dsize; size = ALIGN(__size + sizeof(u32), sizeof(u64)); -- 1.8.5.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/
[PATCH v2] dell-laptop: Check return value of all SMBIOS calls and do not cache hwswitch state
Make sure that return value of all SMBIOS calls are properly checked and
do not continue of processing (received) information if call failed.
Also do not chache hwswitch wireless state as it can be changed at runtime
(e.g from userspace smbios applications).
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
Changes since v1:
* Call clear_buffer before each sequential SMBIOS call (we expect zero-filled
buffer)
* Do not cache hwswitch state as it can be modified at runtime by userspace
* simplify some conditions
---
drivers/platform/x86/dell-laptop.c | 173 ++--
1 file changed, 127 insertions(+), 46 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 35758cb..99f28d3 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -308,12 +308,15 @@ static const struct dmi_system_id dell_quirks[]
__initconst = {
static struct calling_interface_buffer *buffer;
static DEFINE_MUTEX(buffer_mutex);
-static int hwswitch_state;
+static void clear_buffer(void)
+{
+ memset(buffer, 0, sizeof(struct calling_interface_buffer));
+}
static void get_buffer(void)
{
mutex_lock(buffer_mutex);
- memset(buffer, 0, sizeof(struct calling_interface_buffer));
+ clear_buffer();
}
static void release_buffer(void)
@@ -547,21 +550,41 @@ static int dell_rfkill_set(void *data, bool blocked)
int disable = blocked ? 1 : 0;
unsigned long radio = (unsigned long)data;
int hwswitch_bit = (unsigned long)data - 1;
+ int hwswitch;
+ int status;
+ int ret;
get_buffer();
+
+ dell_send_request(buffer, 17, 11);
+ ret = buffer-output[0];
+ status = buffer-output[1];
+
+ if (ret != 0)
+ goto out;
+
+ clear_buffer();
+
+ buffer-input[0] = 0x2;
dell_send_request(buffer, 17, 11);
+ ret = buffer-output[0];
+ hwswitch = buffer-output[1];
/* If the hardware switch controls this radio, and the hardware
switch is disabled, always disable the radio */
- if ((hwswitch_state BIT(hwswitch_bit))
- !(buffer-output[1] BIT(16)))
+ if (ret == 0 (hwswitch BIT(hwswitch_bit))
+ (status BIT(0)) !(status BIT(16)))
disable = 1;
+ clear_buffer();
+
buffer-input[0] = (1 | (radio8) | (disable 16));
dell_send_request(buffer, 17, 11);
+ ret = buffer-output[0];
+ out:
release_buffer();
- return 0;
+ return dell_smi_error(ret);
}
/* Must be called with the buffer held */
@@ -571,6 +594,7 @@ static void dell_rfkill_update_sw_state(struct rfkill
*rfkill, int radio,
if (status BIT(0)) {
/* Has hw-switch, sync sw_state to BIOS */
int block = rfkill_blocked(rfkill);
+ clear_buffer();
buffer-input[0] = (1 | (radio 8) | (block 16));
dell_send_request(buffer, 17, 11);
} else {
@@ -580,23 +604,43 @@ static void dell_rfkill_update_sw_state(struct rfkill
*rfkill, int radio,
}
static void dell_rfkill_update_hw_state(struct rfkill *rfkill, int radio,
- int status)
+ int status, int hwswitch)
{
- if (hwswitch_state (BIT(radio - 1)))
+ if (hwswitch (BIT(radio - 1)))
rfkill_set_hw_state(rfkill, !(status BIT(16)));
}
static void dell_rfkill_query(struct rfkill *rfkill, void *data)
{
+ int radio = ((unsigned long)data 0xF);
+ int hwswitch;
int status;
+ int ret;
get_buffer();
+
dell_send_request(buffer, 17, 11);
+ ret = buffer-output[0];
status = buffer-output[1];
- dell_rfkill_update_hw_state(rfkill, (unsigned long)data, status);
+ if (ret != 0 || !(status BIT(0))) {
+ release_buffer();
+ return;
+ }
+
+ clear_buffer();
+
+ buffer-input[0] = 0x2;
+ dell_send_request(buffer, 17, 11);
+ ret = buffer-output[0];
+ hwswitch = buffer-output[1];
release_buffer();
+
+ if (ret != 0)
+ return;
+
+ dell_rfkill_update_hw_state(rfkill, radio, status, hwswitch);
}
static const struct rfkill_ops dell_rfkill_ops = {
@@ -608,13 +652,27 @@ static struct dentry *dell_laptop_dir;
static int dell_debugfs_show(struct seq_file *s, void *data)
{
+ int hwswitch_state;
+ int hwswitch_ret;
int status;
+ int ret;
get_buffer();
+
dell_send_request(buffer, 17, 11);
+ ret = buffer-output[0];
status = buffer-output[1];
+
+ clear_buffer();
+
+ buffer-input[0] = 0x2;
+ dell_send_request(buffer, 17, 11);
+ hwswitch_ret = buffer-output[0];
+ hwswitch_state = buffer-output[1];
+
release_buffer();
+ seq_printf(s, return:\t%d\n,
Re: [RFC PATCH 1/3] perf probe: Init symbol as kprobe if any pev is kprobe
On 2015/6/27 15:29, Masami Hiramatsu wrote:
On 2015/06/25 19:37, Wang Nan wrote:
Before this patch, add_perf_probe_events() init symbol maps only for
uprobe if the first pev passed to it is a uprobe event. However, with
the incoming BPF uprobe support, now it will be possible to pass an
array with combined kprobe and uprobe events to add_perf_probe_events().
This description is not correct. Actually, add_perf_probe_events already
supports mix of uprobes and kprobes. However, from the command line syntax
constrains the first elements of the probe_event arrays must be kprobes.
So, if the array starts with uprobes, no kprobes should be there.
This patch check all pevs instead of the first one, and init kernel
symbol if any events is not uprobe.
Anyway, I prefer to call init_symbol_maps() with false :)
I also prefer false, so I try to find whether all events are uprobe
instead
of init_symbol_maps(true).
So for this patch only commit message needs to be corrected, the code is
no problem, right?
Thank you.
Thank you,
Signed-off-by: Wang Nan wangn...@huawei.com
---
tools/perf/util/probe-event.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index b386d2f..a2b3026 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2802,8 +2802,21 @@ int cleanup_perf_probe_event(struct perf_probe_event
*pev)
int add_perf_probe_events(struct perf_probe_event *pevs, int npevs, bool
cleanup)
{
int i, ret;
+ bool user_only = true;
- ret = init_symbol_maps(pevs-uprobes);
+ /* If any pev is kprobe, init kernel symbols. */
+ for (i = 0; i npevs; i++) {
+ if (!pevs[i].uprobes) {
+ user_only = false;
+ break;
+ }
+ }
+
+ /*
+* Compiler can drop user_only:
+* ret = init_symbol_maps(i = npevs);
+*/
+ ret = init_symbol_maps(user_only);
if (ret 0)
return ret;
--
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] x86, espfix: init espfix on the boot cpu side
On Fri, Jun 26, 2015 at 05:33:22PM +0800, Zhu Guihua wrote: The following lockdep warning occurrs when running with latest kernel: [3.178000] [ cut here ] [3.183000] WARNING: CPU: 128 PID: 0 at kernel/locking/lockdep.c:2755 lockdep_trace_alloc+0xdd/0xe0() [3.193000] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) [3.199000] Modules linked in: [3.203000] CPU: 128 PID: 0 Comm: swapper/128 Not tainted 4.1.0-rc3 #70 [3.221000] 2d6601fb3e6d4e4c 88086fd5fc38 81773f0a [3.23] 88086fd5fc90 88086fd5fc78 8108c85a [3.238000] 88086fd6 0092 88086fd6 00d0 [3.246000] Call Trace: [3.249000] [81773f0a] dump_stack+0x4c/0x65 [3.255000] [8108c85a] warn_slowpath_common+0x8a/0xc0 [3.261000] [8108c8e5] warn_slowpath_fmt+0x55/0x70 [3.268000] [810ee24d] lockdep_trace_alloc+0xdd/0xe0 [3.274000] [811cda0d] __alloc_pages_nodemask+0xad/0xca0 [3.281000] [810ec7ad] ? __lock_acquire+0xf6d/0x1560 [3.288000] [81219c8a] alloc_page_interleave+0x3a/0x90 [3.295000] [8121b32d] alloc_pages_current+0x17d/0x1a0 [3.301000] [811c869e] ? __get_free_pages+0xe/0x50 [3.308000] [811c869e] __get_free_pages+0xe/0x50 [3.314000] [8102640b] init_espfix_ap+0x17b/0x320 [3.32] [8105c691] start_secondary+0xf1/0x1f0 [3.327000] ---[ end trace 1b3327d9d6a1d62c ]--- As we alloc pages with GFP_KERNEL in init_espfix_ap() which is called before enabled local irq, and the lockdep sub-system considers this behaviour as allocating memory with GFP_FS with local irq disabled, then trigger the warning as mentioned about. So we allocate them on the boot CPU side when the target CPU is bringing up by the primary CPU, and hand them over to the secondary CPU. Signed-off-by: Zhu Guihua zhugh.f...@cn.fujitsu.com --- v2: -allocate espfix stack pages when the targert CPU is bringing up by the primary CPU -commit messages changed v1: -Alloc the page on the node the target CPU is on. RFC v2: -Let the boot up routine init the espfix stack for the target cpu after it booted. Looks ok to me and it works on the 16-node NUMA guest I was triggering the splat with. hpa, is that what you had in mind? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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: [all better] Re: regression: massive trouble with fpu rework
On Sat, 2015-06-27 at 10:25 +0200, Ingo Molnar wrote:
* Mike Galbraith umgwanakikb...@gmail.com wrote:
On Sat, 2015-06-27 at 08:25 +0200, Mike Galbraith wrote:
Hi Ingo,
My i7-4790 box is having one hell of a time with this merge window, is
dead in the water.
BIOS setting Limit CPUID Maximum upsets new fpu code mightily.
Ok, that's interesting. Mind explaining it a bit more verbosely - which
setting is
causing what?
That BIOS setting is annotated with the helpful text Disabled for
Windows XP. It makes box say interesting things during boot, like...
x86/fpu: XSTATE_CPUID missing!
..or with HEAD, it triggers warning..
if (boot_cpu_data.cpuid_level XSTATE_CPUID) {
WARN_ON_FPU(1);
return;
}
..and all kinds of bad juju follows. I have no idea what the thing does
beyond what I can interpolate from the word 'limit'.
This would suggest sensitivity on CPUID details, i.e. that doing
fpu__init_system() before other CPU init sequences is causing the bug.
Does the patch below perhaps make a difference? (I'd suggest to apply it
_without_
the other patch I sent.)
Yup, that made it not care about the BIOS setting.. again.
Thanks,
Ingo
arch/x86/kernel/cpu/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 9fc5e3d9d9c8..922c5e0cea4c 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -742,7 +742,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86
*c)
cpu_detect(c);
get_cpu_vendor(c);
get_cpu_cap(c);
- fpu__init_system(c);
if (this_cpu-c_early_init)
this_cpu-c_early_init(c);
@@ -754,6 +753,7 @@ static void __init early_identify_cpu(struct cpuinfo_x86
*c)
this_cpu-c_bsp_init(c);
setup_force_cpu_cap(X86_FEATURE_ALWAYS);
+ fpu__init_system(c);
}
void __init early_cpu_init(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/
Re: [PATCH net-next] test_bpf: extend tests for 32-bit endianness conversion
On 06/26/2015 05:25 PM, Xi Wang wrote: Currently ALU_END_FROM_BE 32 and ALU_END_FROM_LE 32 do not test if the upper bits of the result are zeros (the arm64 JIT had such bugs). Extend the two tests to catch this. Cc: Alexei Starovoitov a...@plumgrid.com Signed-off-by: Xi Wang xi.w...@gmail.com Thanks for extending the test suite! Acked-by: Daniel Borkmann dan...@iogearbox.net -- 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: [all better] Re: regression: massive trouble with fpu rework
On Sat, Jun 27, 2015 at 10:55:28AM +0200, Mike Galbraith wrote: Yup, that made it not care about the BIOS setting.. again. Does it say x86/fpu: Legacy x87 FPU detected. with Ingo's patch? Or do you see that x86/fpu: Enabled xstate features... print out from the end of fpu__init_system_xstate()? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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.14 00/17] 3.14.46-stable review
On Fri, Jun 26, 2015 at 06:08:22PM -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.46 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon Jun 29 01:08:13 UTC 2015. Anything received after that time might be too late. Compiled and booted on x86_32. No errors in dmesg. regards sudip -- 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 3/9] irqchip / GIC: Add GIC version support in ACPI MADT
On 06/23/2015 12:45 AM, Lorenzo Pieralisi wrote:
On Fri, Jun 19, 2015 at 09:46:06AM +0100, Hanjun Guo wrote:
[...]
+
+static int __init
+match_gic_redist(struct acpi_subtable_header *header, const unsigned long end)
+{
+ return 0;
+}
+static bool __init acpi_gic_redist_is_present(void)
+{
+ int count;
+
+ /* scan MADT table to find if we have redistributor entries */
+ count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR,
+ match_gic_redist, 0);
+
+ /* has at least one GIC redistributor entry */
+ if (count 0)
+ return true;
+ else
+ return false;
+}
return count 0;
What about systems where the redistributor data is in the GICC subtable ? Do
you treat them as GIC V2 :) ?
On a side note, having to define an empty function like match_gic_redist is
horrible.
I wonder whether it is not better to refactor map_madt_entry(), create
a MADT subtable iterator out of it and make that code generic, instead
of being forced to add these useless MADT handlers just to count
entries, it is not the first I noticed.
After digging into the code, it seems that we need more discussion for
this comment, you suggested that refactor map_madt_entry() and create
a MADT subtable iterator out of it, but we still need a handler
to handle each subtable entry, right? then it will become another
version of acpi_parse_entries() in drivers/acpi/table.c, and no
improvement to code, did I miss something?
Thanks
Hanjun
--
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/
regression: massive trouble with fpu rework
Hi Ingo, My i7-4790 box is having one hell of a time with this merge window, is dead in the water. The netconsole log below is v4.1-7254-gc13c81006314, but trouble begins at bisected point much earlier. If I turn off kvm, such that I can kinda sorta boot, systemd says many services enter failed state, box is pretty much a doorstop. Though I can get to a prompt, I can't login. If kvm is enabled, it explodes as soon as it autoloads (wtf does it do that when it's not being used?) Bisecting to the beginning of my woes takes me to the below. Before that, it doesn't matter if kvm is enabled or not, all is well. Below the current gripage with kvm disabled, find the kvm explosion, and another explosion as I approach the beginning of my box's woes. 067051ccd209623cb56152cf4cb06616ee2bcc5c is the first bad commit commit 067051ccd209623cb56152cf4cb06616ee2bcc5c Author: Ingo Molnar mi...@kernel.org Date: Sat Apr 25 08:27:44 2015 +0200 x86/fpu: Do system-wide setup from fpu__detect() fpu__cpu_init() is called on every CPU, so it is the wrong place to call fpu__init_system() from. Call it from fpu__detect(): this is early CPU init code, but we already have CPU features detected, so we can call the system-wide FPU init code from here. Reviewed-by: Borislav Petkov b...@alien8.de Cc: Andy Lutomirski l...@amacapital.net Cc: Dave Hansen dave.han...@linux.intel.com Cc: Fenghua Yu fenghua...@intel.com Cc: H. Peter Anvin h...@zytor.com Cc: Linus Torvalds torva...@linux-foundation.org Cc: Oleg Nesterov o...@redhat.com Cc: Peter Zijlstra pet...@infradead.org Cc: Thomas Gleixner t...@linutronix.de Signed-off-by: Ingo Molnar mi...@kernel.org :04 04 b85f9a16eea19a4ec974c00ea53144a3d11d4e99 697905b73e3f8931a28588c728da3ab1a7289afa M arch git bisect start # good: [cfe3eceb7a2eb91284d5605c5315249bb165e9d3] Merge branch 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good cfe3eceb7a2eb91284d5605c5315249bb165e9d3 # bad: [650ec5a6bd5df4ab0c9ef38d05b94cd82fb99ad8] Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad 650ec5a6bd5df4ab0c9ef38d05b94cd82fb99ad8 # bad: [c4d6ee6e2e52ec604cc1d76877791f8e8f5c79b5] x86/fpu: Remove failure paths from fpstate-alloc low level functions git bisect bad c4d6ee6e2e52ec604cc1d76877791f8e8f5c79b5 # good: [db2b1d3ad1cdae9f268d6db54b6127b09933da3d] x86/fpu: Use 'struct fpu' in fpstate_alloc_init() git bisect good db2b1d3ad1cdae9f268d6db54b6127b09933da3d # good: [e9dbfd673a9cc9d3ef90e3ea4e136a833dab3674] x86/fpu: Move legacy check to fpu__init_system_xstate() git bisect good e9dbfd673a9cc9d3ef90e3ea4e136a833dab3674 # bad: [7218e8b723dc9ceb71cf2fbd3d019e9e11b7d3cf] x86/fpu: Factor out fpu__init_system_generic() git bisect bad 7218e8b723dc9ceb71cf2fbd3d019e9e11b7d3cf # good: [064e51e3c8aee6cfb03ab75e9f9551db3924eb07] x86/fpu: Clean up eager_fpu_init() and rename it to fpu__ctx_switch_init() git bisect good 064e51e3c8aee6cfb03ab75e9f9551db3924eb07 # good: [3960fccf2e22c3b3d61bd5a45b6172e66e660d8b] x86/fpu: Call fpu__init_cpu_ctx_switch() from fpu__init_cpu() git bisect good 3960fccf2e22c3b3d61bd5a45b6172e66e660d8b # bad: [7202ab46f7392265c1ecbf03f600393bf32a8bdf] x86/fpu: Remove fpu__init_cpu_ctx_switch() call from fpu__init_system() git bisect bad 7202ab46f7392265c1ecbf03f600393bf32a8bdf # bad: [067051ccd209623cb56152cf4cb06616ee2bcc5c] x86/fpu: Do system-wide setup from fpu__detect() git bisect bad 067051ccd209623cb56152cf4cb06616ee2bcc5c # first bad commit: [067051ccd209623cb56152cf4cb06616ee2bcc5c] x86/fpu: Do system-wide setup from fpu__detect() [2.411280] [ cut here ] [2.412198] WARNING: CPU: 3 PID: 1 at ./arch/x86/include/asm/fpu/internal.h:366 copy_kernel_to_xregs.part.8+0x1e/0x27() [2.413132] Modules linked in: [2.414003] CPU: 3 PID: 1 Comm: init Tainted: GW 4.1.0-master #279 [2.414872] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013 [2.415745] 817f8db8 88040c91fea8 8159726c 0001 [2.416633] 88040c91fee8 81052bca [2.417524] 88040ca18600 88040ca18600 7f77d5254148 [2.418411] Call Trace: [2.419286] [8159726c] dump_stack+0x45/0x57 [2.420159] [81052bca] warn_slowpath_common+0x8a/0xc0 [2.421017] [81052cba] warn_slowpath_null+0x1a/0x20 [2.421860] [81591bf5] copy_kernel_to_xregs.part.8+0x1e/0x27 [2.422702] [8100dfe9] fpu__restore+0xf9/0x100 [2.423536] [810045c3] do_device_not_available+0x33/0x40 [2.424356] [8159f178] device_not_available+0x18/0x20 [2.425159] ---[ end trace cb88537fdc8fa202 ]--- [2.426492] [ cut here ] [2.427289] WARNING: CPU: 3 PID: 1 at
I am waiting your details information to proceed the transaction
Good day, I am Mr. Nasa Jirma , I currently hold the post as the Audit Account Manager of our bank in Ouagadougou Branch, Burkina-Faso. I got your contact from a reliable web directory. We can see actually that the world is a very small place to meet people but what matters most for me is to transact with a person with full trust. I have developed the trust on you after one week of fasting and praying. Due to the trust, I made up my mind to disclose this confidential business to you. We are imposition to reclaim and inherit the sum of US ($10.5) Million without any trouble, from a dormant account which remains unclaimed since 7years the owner died. This is a U.S Dollar’s account and the beneficiary died without trace of his family to claim the fund. Upon my personal audit investigation into the details of the account, I find out that the deceased is from West Germany, which makes it possible for you as a foreigner no matter your country to lay claim on the balance as the Foreign Business Partner or Extended Relative to the deceased. Your integrity and trustworthiness will make us succeed without any risk. Please if you think that the amount is too much to be transferred into your account, you have the right to ask our bank to transfer the fund into your account bit by bit after approval or you double the account. Once this fund is transferred into your account, we will share the fund accordingly. 40%, for you, 60%, for me, if you are interested to help without disappointment or breach of trust, please reply me with your full details. 1. YOUR FULL NAME:. 2. YOUR CONTACT TELEPHONE NUMBER:.. 3. YOUR AGE:... 4. YOUR SEX:. 5. YOUR OCCUPATIONS:. 6. YOUR COUNTRY AND CITY:.. 7. YOUR PASSPORT OR IDENTITY CARD: 8. YOUR FAX NUMBER. so that I will guide you on the proper banking guidelines to follow for the claim. After the transfer, I will fly to your country for sharing according to our agreement. Assurance: Note that this transaction will never in any way harm or foiled your good post or reputation in your country, because everything will follow legal process. I am looking forward to hear from you soonest. Contact me with my PRIVATE Email mrnasaji...@hotmail.com Yours faithfully, Mr Nasa Jirma -- 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: [all better] Re: regression: massive trouble with fpu rework
* Mike Galbraith umgwanakikb...@gmail.com wrote: On Sat, 2015-06-27 at 08:25 +0200, Mike Galbraith wrote: Hi Ingo, My i7-4790 box is having one hell of a time with this merge window, is dead in the water. BIOS setting Limit CPUID Maximum upsets new fpu code mightily. Ok, that's interesting. Mind explaining it a bit more verbosely - which setting is causing what? This would suggest sensitivity on CPUID details, i.e. that doing fpu__init_system() before other CPU init sequences is causing the bug. Does the patch below perhaps make a difference? (I'd suggest to apply it _without_ the other patch I sent.) Thanks, Ingo arch/x86/kernel/cpu/common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 9fc5e3d9d9c8..922c5e0cea4c 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -742,7 +742,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c) cpu_detect(c); get_cpu_vendor(c); get_cpu_cap(c); - fpu__init_system(c); if (this_cpu-c_early_init) this_cpu-c_early_init(c); @@ -754,6 +753,7 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c) this_cpu-c_bsp_init(c); setup_force_cpu_cap(X86_FEATURE_ALWAYS); + fpu__init_system(c); } void __init early_cpu_init(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/
Re: [RFC PATCH 1/3] perf probe: Init symbol as kprobe if any pev is kprobe
Hi Wang,
On 2015/06/27 16:34, Wangnan (F) wrote:
On 2015/6/27 15:29, Masami Hiramatsu wrote:
On 2015/06/25 19:37, Wang Nan wrote:
Before this patch, add_perf_probe_events() init symbol maps only for
uprobe if the first pev passed to it is a uprobe event. However, with
the incoming BPF uprobe support, now it will be possible to pass an
array with combined kprobe and uprobe events to add_perf_probe_events().
This description is not correct. Actually, add_perf_probe_events already
supports mix of uprobes and kprobes. However, from the command line syntax
constrains the first elements of the probe_event arrays must be kprobes.
So, if the array starts with uprobes, no kprobes should be there.
This patch check all pevs instead of the first one, and init kernel
symbol if any events is not uprobe.
Anyway, I prefer to call init_symbol_maps() with false :)
I also prefer false, so I try to find whether all events are uprobe
instead
of init_symbol_maps(true).
So for this patch only commit message needs to be corrected, the code is
no problem, right?
No, I meant you just need to change one line, as below.
- ret = init_symbol_maps(pevs-uprobes);
+ ret = init_symbol_maps(false);
That's enough, I don't like to introduce a bool flag and loop.
Thanks,
Thank you.
Thank you,
Signed-off-by: Wang Nan wangn...@huawei.com
---
tools/perf/util/probe-event.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index b386d2f..a2b3026 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2802,8 +2802,21 @@ int cleanup_perf_probe_event(struct perf_probe_event
*pev)
int add_perf_probe_events(struct perf_probe_event *pevs, int npevs, bool
cleanup)
{
int i, ret;
+ bool user_only = true;
- ret = init_symbol_maps(pevs-uprobes);
+ /* If any pev is kprobe, init kernel symbols. */
+ for (i = 0; i npevs; i++) {
+ if (!pevs[i].uprobes) {
+ user_only = false;
+ break;
+ }
+ }
+
+ /*
+* Compiler can drop user_only:
+* ret = init_symbol_maps(i = npevs);
+*/
+ ret = init_symbol_maps(user_only);
if (ret 0)
return ret;
--
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research Development Group
E-mail: masami.hiramatsu...@hitachi.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/
Re: lockdep issue booting v4.1 upstream kernel with 64 x86_64 CPUs
On Fri, Jun 26, 2015 at 06:38:20PM -0700, Michel Lespinasse wrote: Hi Peter, I am getting a minor issue trying to boot a lockdep enabled x86_64 kernel with 64 CPUs. The kernel boots the first 64 CPUs without issues, but then complains that lockdep wants to allocate memory while start_secondary - init_espfix_ap has IRQs disabled: Does that help: https://lkml.kernel.org/r/1435311202-13248-1-git-send-email-zhugh.f...@cn.fujitsu.com ? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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/
PROJECT FUNDING/DEBT FINANCING
Greetings, We are an Investment company that invites you to partner with us and benefit in our new Loan and Project funding program. We offer flexible loans and funding for various projects by passing the usual rigorous procedures.This Funding program allows a client to enjoy low interest payback for as low as 3 - 4% per annum for a period of 7-8 years. We can approve a loan/funding for up to USD 500,000,000.00 or more depending on the nature of business. We are currently funding for: * Starting up a Franchise * Business Acquisition * Business Expansion * Commercial Real Estate purchase * Contract Execution We are open to having a good business relationship with you. If you think you have a solid background and idea of making good profit in any venture, please do not hesitate to contact us for possible business co-operation. Sincerely, El-Shaban -- 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 4.0 00/22] 4.0.7-stable review
On 06/26/2015 06:08 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.0.7 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon Jun 29 01:08:46 UTC 2015. Anything received after that time might be too late. Build results: total: 124 pass: 124 fail: 0 Qemu test results: total: 30 pass: 30 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. 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/
Re: [PATCH] staging: lustre: obdclass: fix macro coding style issue in uuid.c
On Sat, 2015-06-27 at 06:36 +0100, Vasiliy Korchagin wrote:
This patch fixes the checkpatch.pl error:
ERROR: Macros with complex values should be enclosed in parentheses
+#define CONSUME(val, ptr) (val) = consume(sizeof(val), (ptr))
by expanding it as this macro is used only once.
[]
Notes:
Here is another version with macro expansion. Inline function expansion
doesn't
seem like a good idea to me as it would make things overcomplicated.
It looks like it'd be simpler to use vsprintf extension %pU
---
drivers/staging/lustre/lustre/obdclass/uuid.c | 34 +--
1 file changed, 1 insertion(+), 33 deletions(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/uuid.c
b/drivers/staging/lustre/lustre/obdclass/uuid.c
index ff0a01b..b0b0157 100644
--- a/drivers/staging/lustre/lustre/obdclass/uuid.c
+++ b/drivers/staging/lustre/lustre/obdclass/uuid.c
@@ -43,40 +43,8 @@
#include ../include/obd_support.h
#include ../include/obd_class.h
-
-static inline __u32 consume(int nob, __u8 **ptr)
-{
- __u32 value;
-
- LASSERT(nob = sizeof(value));
-
- for (value = 0; nob 0; --nob)
- value = (value 8) | *((*ptr)++);
- return value;
-}
-
-#define CONSUME(val, ptr) (val) = consume(sizeof(val), (ptr))
-
-static void uuid_unpack(class_uuid_t in, __u16 *uu, int nr)
-{
- __u8 *ptr = in;
-
- LASSERT(nr * sizeof(*uu) == sizeof(class_uuid_t));
-
- while (nr-- 0)
- CONSUME(uu[nr], ptr);
-}
-
void class_uuid_unparse(class_uuid_t uu, struct obd_uuid *out)
{
- /* uu as an array of __u16's */
- __u16 uuid[sizeof(class_uuid_t) / sizeof(__u16)];
-
- CLASSERT(ARRAY_SIZE(uuid) == 8);
-
- uuid_unpack(uu, uuid, ARRAY_SIZE(uuid));
- sprintf(out-uuid, %04x%04x-%04x-%04x-%04x-%04x%04x%04x,
- uuid[0], uuid[1], uuid[2], uuid[3],
- uuid[4], uuid[5], uuid[6], uuid[7]);
+ sprintf(out-uuid, %pU, uu);
}
EXPORT_SYMBOL(class_uuid_unparse);
--
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] net: via: VIA_RHINE and VIA_VELOCITY should depend on HAS_DMA
On Fri, Jun 26, 2015 at 9:21 PM, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: Hello. On 6/26/2015 3:08 PM, Geert Uytterhoeven wrote: If NO_DMA=y: ERROR: dma_sync_single_for_cpu [drivers/net/ethernet/via/via-rhine.ko] undefined! ERROR: dma_set_mask [drivers/net/ethernet/via/via-rhine.ko] undefined! ERROR: dma_mapping_error [drivers/net/ethernet/via/via-rhine.ko] undefined! ERROR: dma_map_single [drivers/net/ethernet/via/via-rhine.ko] undefined! ERROR: dma_alloc_coherent [drivers/net/ethernet/via/via-rhine.ko] undefined! ERROR: dma_free_coherent [drivers/net/ethernet/via/via-rhine.ko] undefined! ERROR: dma_unmap_single [drivers/net/ethernet/via/via-rhine.ko] undefined! ERROR: dma_map_page [drivers/net/ethernet/via/via-velocity.ko] undefined! ERROR: dma_sync_single_for_cpu [drivers/net/ethernet/via/via-velocity.ko] undefined! ERROR: dma_free_coherent [drivers/net/ethernet/via/via-velocity.ko] undefined! ERROR: dma_unmap_single [drivers/net/ethernet/via/via-velocity.ko] undefined! ERROR: dma_map_single [drivers/net/ethernet/via/via-velocity.ko] undefined! ERROR: dma_alloc_coherent [drivers/net/ethernet/via/via-velocity.ko] undefined! Before, the symbols depended implicitly on HAS_DMA through PCI or USE_OF. Add explicit dependencies on HAS_DMA to fix this. Fixes: commit b7d3282a245f4428 (net: via/Kconfig: replace USE_OF with OF_???) Fixes: b7d3282a245f (net: via/Kconfig: replace USE_OF with OF_???) Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org WBR, Sergei Yes, I can confirm it. If HAS_DMA is not defined the build is broken. Your patch fixes the issue. Thanks, Antonio -- 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:irq/urgent] pinctrl/st: Fix race in installing chained IRQ handler
Hello Thomas, On 06/26/2015 09:45 PM, tip-bot for Thomas Gleixner wrote: Commit-ID: 1b11b0cb799e5f82ca6391a23eaa8f41c7466cc0 Gitweb: http://git.kernel.org/tip/1b11b0cb799e5f82ca6391a23eaa8f41c7466cc0 Author: Thomas Gleixner t...@linutronix.de AuthorDate: Sun, 21 Jun 2015 20:16:15 +0200 Committer: Thomas Gleixner t...@linutronix.de CommitDate: Thu, 25 Jun 2015 11:57:09 +0200 pinctrl/st: Fix race in installing chained IRQ handler Fix a race where a pending interrupt could be received and the handler called before the handler's data has been setup, by converting to irq_set_chained_handler_and_data(). Search and conversion was done with coccinelle: @@ expression E1, E2, E3; @@ ( -if (irq_set_chained_handler(E1, E3) != 0) - BUG(); | -irq_set_chained_handler(E1, E3); ) -irq_set_handler_data(E1, E2); +irq_set_chained_handler_and_data(E1, E3, E2); @@ expression E1, E2, E3; @@ ( -if (irq_set_chained_handler(E1, E3) != 0) - BUG(); ... | -irq_set_chained_handler(E1, E3); ... ) -irq_set_handler_data(E1, E2); +irq_set_chained_handler_and_data(E1, E3, E2); Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Thomas Gleixner t...@linutronix.de Cc: Julia Lawall julia.law...@lip6.fr Cc: Srinivas Kandagatla srinivas.kandaga...@gmail.com Cc: Maxime Coquelin maxime.coque...@st.com Cc: Patrice Chotard patrice.chot...@st.com Cc: Linus Walleij linus.wall...@linaro.org Cc: linux-arm-ker...@lists.infradead.org Cc: ker...@stlinux.com Cc: linux-g...@vger.kernel.org --- drivers/pinctrl/pinctrl-st.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/pinctrl-st.c b/drivers/pinctrl/pinctrl-st.c index 65bf73b..10e9c4e8 100644 --- a/drivers/pinctrl/pinctrl-st.c +++ b/drivers/pinctrl/pinctrl-st.c @@ -1661,8 +1661,8 @@ static int st_pctl_probe_dt(struct platform_device *pdev, if (IS_ERR(info-irqmux_base)) return PTR_ERR(info-irqmux_base); - irq_set_chained_handler(irq, st_gpio_irqmux_handler); - irq_set_handler_data(irq, info); + irq_set_chained_handler_and_data(irq, st_gpio_irqmux_handler, +info); } I cannot test the patch before Monday, but it looks good to me: Acked-by: Maxime Coquelin maxime.coque...@st.com Thanks! Maxime -- 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] platform: x86: Deletion of checks before backlight_device_unregister()
On Fri, 26 Jun 2015, Darren Hart wrote: On Thu, Nov 27, 2014 at 07:13:10PM +0100, Julia Lawall wrote: On Mon, 24 Nov 2014, SF Markus Elfring wrote: This issue was detected by using the Coccinelle software. What script was used ? A semantic patch approach which I published on the mailing lists in March is in action on my software development system for a while. Is it in scripts/coccinelle ? Not yet. I hope that the involved update suggestions got sufficient positive feedback to integrate five scripts there. The current scripts are very complicated, involving the interaction between multiple scripts and a database, and I think they are not very suitable for make coccicheck. Also, the idea of removing the null checks is not appropriate in all contexts. Perhaps it could be possible to add a script to the Linux kernel that handles a number of common cases for which removing the null test is widely considered to be desirable. julia Julia, do you have any particular objection to this specific patch? I didn't see a reason to prevent it going in. Sorry if I was unclear. If there is no problem with the current patch, I have no objection to it. I don't think that the semantic patch that caused this patch to be generated is suitable for inclusion in the Linux kernel. julia -- 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: rename_rev.pl: review script for whitespace changes
On Fri, Jun 26, 2015 at 04:15:24PM +0300, Dan Carpenter wrote: I've sent my review script out a few times before but we have some new reviewers in staging who maybe haven't tried them. Thanks Dan. It will be of great help. regards sudip -- 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 4.1 00/11] 4.1.1-stable review
On Fri, Jun 26, 2015 at 06:09:03PM -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.1.1 release. There are 11 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon Jun 29 01:08:53 UTC 2015. Anything received after that time might be too late. Compiled and booted on x86_32. No errors in dmesg. regards sudip -- 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: regression: massive trouble with fpu rework
* Mike Galbraith umgwanakikb...@gmail.com wrote:
Hi Ingo,
My i7-4790 box is having one hell of a time with this merge window, is
dead in the water. The netconsole log below is v4.1-7254-gc13c81006314,
but trouble begins at bisected point much earlier. If I turn off kvm,
such that I can kinda sorta boot, systemd says many services enter
failed state, box is pretty much a doorstop. Though I can get to a
prompt, I can't login. If kvm is enabled, it explodes as soon as it
autoloads (wtf does it do that when it's not being used?)
Bisecting to the beginning of my woes takes me to the below. Before
that, it doesn't matter if kvm is enabled or not, all is well. Below
the current gripage with kvm disabled, find the kvm explosion, and
another explosion as I approach the beginning of my box's woes.
067051ccd209623cb56152cf4cb06616ee2bcc5c is the first bad commit
commit 067051ccd209623cb56152cf4cb06616ee2bcc5c
Author: Ingo Molnar mi...@kernel.org
Date: Sat Apr 25 08:27:44 2015 +0200
x86/fpu: Do system-wide setup from fpu__detect()
fpu__cpu_init() is called on every CPU, so it is the wrong place
to call fpu__init_system() from. Call it from fpu__detect():
this is early CPU init code, but we already have CPU features detected,
so we can call the system-wide FPU init code from here.
Reviewed-by: Borislav Petkov b...@alien8.de
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Fenghua Yu fenghua...@intel.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Thomas Gleixner t...@linutronix.de
Signed-off-by: Ingo Molnar mi...@kernel.org
Just as a quick workaround, if you add back a per CPU init fpu__init_system()
call, as per the disgusting hack below, do things get happier?
( You might trigger a few WARN_ON_ONCE() whinges, especially if you have
CONFIG_X86_DEBUG_FPU=y, but those should be one-time warnings that are not
fatal. )
Totally untested, unfortunately.
My theory of the bug is that there is something that needs to be set up per
CPU,
which is a side effect of fpu__init_system(), and which the new fpu__init_cpu()
does not capture. If this patch helps then the real fix would be to figure out
that side effect.
Thanks,
Ingo
arch/x86/kernel/fpu/init.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index fc878fee6a51..421babb08fe6 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -4,6 +4,9 @@
#include asm/fpu/internal.h
#include asm/tlbflush.h
+#undef __init
+#define __init
+
/*
* Initialize the TS bit in CR0 according to the style of context-switches
* we are using:
@@ -44,13 +47,18 @@ static void fpu__init_cpu_generic(void)
/*
* Enable all supported FPU features. Called when a CPU is brought online:
*/
-void fpu__init_cpu(void)
+static void __fpu__init_cpu(void)
{
fpu__init_cpu_generic();
fpu__init_cpu_xstate();
fpu__init_cpu_ctx_switch();
}
+void fpu__init_cpu(void)
+{
+ fpu__init_system(NULL);
+}
+
/*
* The earliest FPU detection code.
*
@@ -267,13 +275,14 @@ static void __init fpu__init_system_ctx_switch(void)
*/
void __init fpu__init_system(struct cpuinfo_x86 *c)
{
- fpu__init_system_early_generic(c);
+ if (c)
+ fpu__init_system_early_generic(c);
/*
* The FPU has to be operational for some of the
* later FPU init activities:
*/
- fpu__init_cpu();
+ __fpu__init_cpu();
/*
* But don't leave CR0::TS set yet, as some of the FPU setup
--
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/
[all better] Re: regression: massive trouble with fpu rework
On Sat, 2015-06-27 at 08:25 +0200, Mike Galbraith wrote: Hi Ingo, My i7-4790 box is having one hell of a time with this merge window, is dead in the water. BIOS setting Limit CPUID Maximum upsets new fpu code mightily. -Mike -- 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] x86, msr: Allow read access to /dev/cpu/X/msr
* Prarit Bhargava pra...@redhat.com wrote: Customers write system monitoring software for single systems as well as clusters. In load-balancing software it is useful to know how busy a core is. Unfortunately the only way to get this data is to run as root, or use setcap to allow userspace access for particular programs. Both of these options are clunky at best. This patch allows read access to the msr dev files which should be okay. No damage can be done by reading the MSR values and it allows non-root users to run system monitoring software. The turbostat code specifically checks for CAP_SYS_RAWIO, which it shouldn't have to and I've removed that code. Additionally I've modified the turbostat man page to remove documentation about configuring CAP_SYS_RAW_IO. Note: Write access to msr is still restricted with this patch. Cc: H. Peter Anvin h...@zytor.com Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: x...@kernel.org Cc: Len Brown len.br...@intel.com Cc: Prarit Bhargava pra...@redhat.com Cc: Dasaratharaman Chandramouli dasaratharaman.chandramo...@intel.com Signed-off-by: Prarit Bhargava pra...@redhat.com --- arch/x86/kernel/msr.c | 11 --- tools/power/x86/turbostat/turbostat.8 |8 tools/power/x86/turbostat/turbostat.c | 17 - 3 files changed, 8 insertions(+), 28 deletions(-) So what's wrong with exposing them as a simplified PMU driver? That way we only expose the ones we want to - plus tooling can use all the rich perf features that can be used around this. (sampling, counting, call chains, etc.) 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] bpf: Put perf_events check ahead of bpf prog
On 2015/06/27 15:44, He Kuang wrote: When we add a kprobe point and record events by perf, the execution path of all threads on each cpu will enter this point, but perf may only record events on a particular thread or cpu at this kprobe point, a check on call-perf_events list filters out the threads which perf is not recording. Currently, bpf_prog will be entered at the beginning of kprobe_perf_func() before the above check, which makes bpf_prog be executed in every threads including determined not to be recorded threads. A simple test can demonstrate this: 'bpf_prog_on_write.o' contains a bpf prog which outputs to trace buffer when it is entered. Run a background thread 'another-dd' and 'dd' simultaneously, but only record 'dd' thread by perf. The result shows all threads trigger bpf_prog. $ another-dd if=/dev/zero of=test1 bs=4k count=100 $ perf record -v --event bpf_prog_on_write.o -- dd if=/dev/zero of=test2 bs=4k count=3 $ cat /sys/kernel/debug/tracing/trace another-dd-1007 [000] d... 120.225835: : generic_perform_write: tgid=1007, pid=1007 another-dd-1007 [000] d... 120.227123: : generic_perform_write: tgid=1007, pid=1007 [repeat many times...] another-dd-1007 [000] d... 120.412395: : generic_perform_write: tgid=1007, pid=1007 another-dd-1007 [000] d... 120.412524: : generic_perform_write: tgid=1007, pid=1007 dd-1009 [000] d... 120.413080: : generic_perform_write: tgid=1009, pid=1009 dd-1009 [000] d... 120.414846: : generic_perform_write: tgid=1009, pid=1009 dd-1009 [000] d... 120.415013: : generic_perform_write: tgid=1009, pid=1009 another-dd-1007 [000] d... 120.416128: : generic_perform_write: tgid=1007, pid=1007 another-dd-1007 [000] d... 120.416295: : generic_perform_write: tgid=1007, pid=1007 This patch moves the check on perf_events list ahead and skip running bpf_prog on threads perf not care. After this patch: $ another-dd if=/dev/zero of=test1 bs=4k count=100 $ perf record -v --event bpf_prog_on_write.o -- dd if=/dev/zero of=test2 bs=4k count=3 $ cat /sys/kernel/debug/tracing/trace dd-994 [000] d...46.386754: : generic_perform_write: tgid=994, pid=994 dd-994 [000] d...46.389167: : generic_perform_write: tgid=994, pid=994 dd-994 [000] d...46.389551: : generic_perform_write: tgid=994, pid=994 This looks nice :) Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com Thank you! Signed-off-by: He Kuang heku...@huawei.com --- kernel/trace/trace_kprobe.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c index d0ce590..5600df8 100644 --- a/kernel/trace/trace_kprobe.c +++ b/kernel/trace/trace_kprobe.c @@ -1141,13 +1141,13 @@ kprobe_perf_func(struct trace_kprobe *tk, struct pt_regs *regs) int size, __size, dsize; int rctx; - if (prog !trace_call_bpf(prog, regs)) - return; - head = this_cpu_ptr(call-perf_events); if (hlist_empty(head)) return; + if (prog !trace_call_bpf(prog, regs)) + return; + dsize = __get_data_size(tk-tp, regs); __size = sizeof(*entry) + tk-tp.size + dsize; size = ALIGN(__size + sizeof(u32), sizeof(u64)); @@ -1176,13 +1176,13 @@ kretprobe_perf_func(struct trace_kprobe *tk, struct kretprobe_instance *ri, int size, __size, dsize; int rctx; - if (prog !trace_call_bpf(prog, regs)) - return; - head = this_cpu_ptr(call-perf_events); if (hlist_empty(head)) return; + if (prog !trace_call_bpf(prog, regs)) + return; + dsize = __get_data_size(tk-tp, regs); __size = sizeof(*entry) + tk-tp.size + dsize; size = ALIGN(__size + sizeof(u32), sizeof(u64)); -- Masami HIRAMATSU Linux Technology Research Center, System Productivity Research Dept. Center for Technology Innovation - Systems Engineering Hitachi, Ltd., Research Development Group E-mail: masami.hiramatsu...@hitachi.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/
[RFC] perf tools: Add hugetlbfs memory recognition
Maps for JIT is helpful for symbols-parsing for anon-executable-memory.
What we need to do is to add (START, SIZE, symbolname) to /tmp/perf-%d.map
(%d = pid of process), and perf would parse symbol located in this area
according to /tmp/perf-%d.map. It works well for normal mmap.
However, when we alloc such memory from hugetlbfs by the following code:
..
fd = open(/mnt/huge/hugepagefile, O_CREAT | O_RDWR, 0755);
if (fd 0) {
perror(Open failed);
exit(1);
}
addr = mmap(ADDR, LENGTH, PROT_READ | PROT_WRITE | \
PROT_EXEC, MAP_SHARED, fd, 0);
..
where hugetlbfs is mounted in /mnt/huge. Symbols could not be parsed correctly:
#perf report
86.96% 0.00% hugepage-mmap hugepagefile [.] 0xffe0005c
86.96% 0.00% hugepage-mmap hugepagefile [.] 0xffe000ac
This is because such mmap area's file backed is /mnt/huge/hugepagefile, a
node
in pseudo filesystem, it is useless for symbol-parsing. so wo had better
recognize
such hugetlbfs area, and rename it's filename to /tmp/perf-%d.map, just as
anon-memory
and no_dso_memory do.
This patch imports a new function named is_hugetlb_memory to check if this
memory
is from hugetlbfs. If true, change its name.
After this patch:
#perf report
86.96% 0.00% hugepage-mmap perf-182.map[.] 0x0020005c
86.96% 0.00% hugepage-mmap perf-182.map[.] 0x002000ac
We can add maps info to perf-182.map for further symbols-parsing.
Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
tools/perf/util/map.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b5a5e9c..796db08 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -15,6 +15,7 @@
#include debug.h
#include machine.h
#include linux/string.h
+#include sys/mman.h
static void __maps__insert(struct maps *maps, struct map *map);
@@ -43,6 +44,11 @@ static inline int is_android_lib(const char *filename)
!strncmp(filename, /system/lib, 11);
}
+static inline int is_hugetlb_memory(u32 flags)
+{
+ return flags MAP_HUGETLB;
+}
+
static inline bool replace_android_lib(const char *filename, char *newfilename)
{
const char *libname;
@@ -151,12 +157,13 @@ struct map *map__new(struct machine *machine, u64 start,
u64 len,
if (map != NULL) {
char newfilename[PATH_MAX];
struct dso *dso;
- int anon, no_dso, vdso, android;
+ int anon, no_dso, vdso, android, hugetlb;
android = is_android_lib(filename);
anon = is_anon_memory(filename);
vdso = is_vdso_map(filename);
no_dso = is_no_dso_memory(filename);
+ hugetlb = is_hugetlb_memory(flags);
map-maj = d_maj;
map-min = d_min;
@@ -165,7 +172,7 @@ struct map *map__new(struct machine *machine, u64 start,
u64 len,
map-prot = prot;
map-flags = flags;
- if ((anon || no_dso) type == MAP__FUNCTION) {
+ if ((anon || no_dso || hugetlb) type == MAP__FUNCTION) {
snprintf(newfilename, sizeof(newfilename),
/tmp/perf-%d.map, pid);
filename = newfilename;
}
--
1.8.3.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: [RFC] perf tools: Add hugetlbfs memory recognition
On 2015/6/27 16:49, Hou Pengyang wrote:
Maps for JIT is helpful for symbols-parsing for anon-executable-memory.
What we need to do is to add (START, SIZE, symbolname) to /tmp/perf-%d.map
(%d = pid of process), and perf would parse symbol located in this area
according to /tmp/perf-%d.map. It works well for normal mmap.
However, when we alloc such memory from hugetlbfs by the following code:
..
fd = open(/mnt/huge/hugepagefile, O_CREAT | O_RDWR, 0755);
if (fd 0) {
perror(Open failed);
exit(1);
}
addr = mmap(ADDR, LENGTH, PROT_READ | PROT_WRITE | \
PROT_EXEC, MAP_SHARED, fd, 0);
..
where hugetlbfs is mounted in /mnt/huge. Symbols could not be parsed correctly:
#perf report
86.96% 0.00% hugepage-mmap hugepagefile [.] 0xffe0005c
86.96% 0.00% hugepage-mmap hugepagefile [.] 0xffe000ac
This is because such mmap area's file backed is /mnt/huge/hugepagefile, a node
in pseudo filesystem, it is useless for symbol-parsing. so wo had better
recognize
such hugetlbfs area, and rename it's filename to /tmp/perf-%d.map, just as
anon-memory
and no_dso_memory do.
This patch imports a new function named is_hugetlb_memory to check if this
memory
is from hugetlbfs. If true, change its name.
After this patch:
#perf report
86.96% 0.00% hugepage-mmap perf-182.map[.] 0x0020005c
86.96% 0.00% hugepage-mmap perf-182.map[.] 0x002000ac
We can add maps info to perf-182.map for further symbols-parsing.
Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
tools/perf/util/map.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b5a5e9c..796db08 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -15,6 +15,7 @@
#include debug.h
#include machine.h
#include linux/string.h
+#include sys/mman.h
static void __maps__insert(struct maps *maps, struct map *map);
@@ -43,6 +44,11 @@ static inline int is_android_lib(const char *filename)
!strncmp(filename, /system/lib, 11);
}
+static inline int is_hugetlb_memory(u32 flags)
+{
+ return flags MAP_HUGETLB;
+}
There is something about MAP_HUGETLB.
In this patch, we check if a mmap area is hugetlbfs area by MAP_HUGETLB,
a bit in MMAP2 event.
However, if mmap area is hugetlb related, MAP_HUGETLB does not always
appear. Because, there are two ways generating MMAP2 event.
1) when a new vm_area_struct is created, its info would be exported
as a MMAP2 event.
2) perf reads /proc/pid/maps for generating MMAP2 event.
MAP_HUGETLB appears if MMAP2 event is generated on situation 1),
while not on situation 2).
This is because on situation 2), perf reads /proc/pid/maps, which
contains only PROT_READ/WRITE/EXEC, MAP_SHARED/MAP_PRIVATE, while more
details appear in /proc/pid/smaps, such as MAP_HUGETLB.
So I wonder if there is a need to read /proc/pid/smaps instead of
/proc/pid/maps to generate MMAP2 event. Or we should solve the problem
by another way?
Thanks!
+
static inline bool replace_android_lib(const char *filename, char
*newfilename)
{
const char *libname;
@@ -151,12 +157,13 @@ struct map *map__new(struct machine *machine, u64 start,
u64 len,
if (map != NULL) {
char newfilename[PATH_MAX];
struct dso *dso;
- int anon, no_dso, vdso, android;
+ int anon, no_dso, vdso, android, hugetlb;
android = is_android_lib(filename);
anon = is_anon_memory(filename);
vdso = is_vdso_map(filename);
no_dso = is_no_dso_memory(filename);
+ hugetlb = is_hugetlb_memory(flags);
map-maj = d_maj;
map-min = d_min;
@@ -165,7 +172,7 @@ struct map *map__new(struct machine *machine, u64 start,
u64 len,
map-prot = prot;
map-flags = flags;
- if ((anon || no_dso) type == MAP__FUNCTION) {
+ if ((anon || no_dso || hugetlb) type == MAP__FUNCTION) {
snprintf(newfilename, sizeof(newfilename),
/tmp/perf-%d.map, pid);
filename = newfilename;
}
--
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 v2] perf tools: don't adjust symbols in vDSO
Commit 922d0e4d9f04 (perf tools: Adjust symbols in VDSO) changed the
ELF symbol parsing so that the vDSO is treated the same as ET_EXEC and
ET_REL binaries despite being an ET_DYN. This was a partial workaround
to deal with older x86 vDSOs being prelinked at a high address that
didn't correspond to the map, so using object-relative offsets and
adding the base of the map allowed symbol resolution to succeed.
Unfortunately, this causes objdump not to produce any output in
conjunction with perf annotate, which cheerfully passes the absolute
address of the map symbol.
This patch fixes the problem by avoiding adjustment of vDSO symbols and
instead setting the map-pgoff field to correspond to the virtual load
address specified in the vDSO ELF header.
Cc: Vladimir Nikulichev n...@tbricks.com
Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Andy Lutomirski l...@amacapital.net
Reported-by: Kristina Martsenko kristina.martse...@arm.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
v1-v2: Adjust map-pgoff in ELF loader to avoid breaking symbol lookup
on older kernels.
tools/perf/util/map.c| 5 ++---
tools/perf/util/symbol-elf.c | 9 -
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index a14f08f41686..6ba38293be88 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -173,10 +173,9 @@ struct map *map__new(struct machine *machine, u64 start,
u64 len,
filename = newfilename;
}
- if (vdso) {
- pgoff = 0;
+ if (vdso)
dso = vdso__dso_findnew(machine, thread);
- } else
+ else
dso = __dsos__findnew(machine-user_dsos, filename);
if (dso == NULL)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a7ab6063e038..83f8ba232575 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -706,7 +706,6 @@ int symsrc__init(struct symsrc *ss, struct dso *dso, const
char *name,
GElf_Shdr shdr;
ss-adjust_symbols = (ehdr.e_type == ET_EXEC ||
ehdr.e_type == ET_REL ||
- dso__is_vdso(dso) ||
elf_section_by_name(elf, ehdr, shdr,
.gnu.prelink_undo,
NULL) != NULL);
@@ -824,6 +823,14 @@ int dso__load_sym(struct dso *dso, struct map *map,
sec = syms_ss-symtab;
shdr = syms_ss-symshdr;
+ /*
+* Older x86 kernels prelink the vDSO at a high address, so
+* we need to reflect that in map-pgoff in order to talk to
+* objdump.
+*/
+ if (dso__is_vdso(dso))
+ map-pgoff = shdr.sh_addr - shdr.sh_offset;
+
if (runtime_ss-opdsec)
opddata = elf_rawdata(runtime_ss-opdsec, NULL);
--
2.1.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: [alsa-devel] [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec
On 2015-06-27 00:49, Henrique de Moraes Holschuh wrote: On Fri, 26 Jun 2015, Hui Wang wrote: Again, I'm on a X121e, and that has only a single physical LED for signaling the power state. The mute button is behind key combination of the keyboard. Jan There is no reason to change a power button to a reset button after accessing the acpi device SSMS, the SSMS is for the mute led instead of the power management. I think it is better you login to the lenovo website and look for the latest BIOS image, then upgrade the BIOS on your machine to see if it can solve the problem or not. Hmm, I think I am missing something here. Please explain _in detail_ what you mean with changing a power button to a reset button by acessing the SSMS ACPI method in a X121e. Are we trigering a bug somewhere that crashes the x121e and causes it to reboot? Well, there aren't much details to describe in this case: When this patch is applied and I press the power button, the device performs a hard reset. It doesn't reveal if the kernel crashes catastrophically, causing a triple fault or so, or if the firmware decides to reset the platform. Reverting the patch or preventing its effect via a quirk filter like I posted [1] makes the issue go away. Jan [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-June/078284.html signature.asc Description: OpenPGP digital signature
Re: [PATCH] mfd: 880m80x: Make use of BIT() macro
On Saturday 27 June 2015 11:06 AM, Krzysztof Kozlowski wrote: 2015-06-26 22:08 GMT+09:00 Vaibhav Hiremath vaibhav.hirem...@linaro.org: Instead of hard coding the shift for bit definition, use BIT() macro. I am not convinced that such change improves anything in existing code. IMHO (1 n) is quite readable and obvious. The obviousness of it, is the same as obviousness of BIT(n). However I know that Lee Jones likes the BIT() so it's up to him :) . In the same time you are cleaning a little the indentation in defines which is nice, but messes with main change. It is difficult to find the exact differences, to review it. Can you split the patch into two commits - one for BIT (if this is desired by Lee Jones) and one for white space clean up? White spaces changes are not much... Thanks, Vaibhav -- 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: [GIT PULL] workqueue changes for v4.2-rc1
* Linus Torvalds torva...@linux-foundation.org wrote: On Fri, Jun 26, 2015 at 9:01 AM, Tejun Heo t...@kernel.org wrote: Ooh, it isn't in mainline yet but pulling rcu tree will cause a silent conflict with this pull request which leads to build failure. I tend to try to do a full make allmodconfig build between all pull requests (although I can optimize that a bit for very targeted pull requests), so hopefully I'll notice and remember your note. But just in case: The two colliding commits are. 5b95e1af8d17 (workqueue: wq_pool_mutex protects the attrs-installation) eeacf8982637 (rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()) The former adds rcu_lockdep_assert() usage and the latter renames and flips it. It can be resolved by renaming and negating the conditions in the new usage. it would be great if when I get the RCU pull request that introduces that renaming, whoever sends it to me could remind me about it. I'm assuming the pull request will come through Ingo. Ingo? Yeah. There was some discussion about how to warn about RCU failures precisely, so I think Paul yanked the new style RCU warnings for the time being. When/if they come back I'll be careful and will remind you of semantic conflicts. 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] x86, msr: Allow read access to /dev/cpu/X/msr
* Ingo Molnar mi...@kernel.org wrote:
So what's wrong with exposing them as a simplified PMU driver?
That way we only expose the ones we want to - plus tooling can use all the
rich
perf features that can be used around this. (sampling, counting, call chains,
etc.)
See below code from Andy that exposes a single MSR via perf. At the core of the
PMU driver is a single rdmsrl():
+static void aperfmperf_event_start(struct perf_event *event, int flags)
+{
+ u64 now;
+
+ rdmsrl(event-hw.event_base, now);
+ local64_set(event-hw.prev_count, now);
+}
Now I think what we really want is to expose not a single MSR but multiple MSRs
in
a single driver, i.e. don't have one PMU driver per MSR, but have a driver that
allows the exposure of select MSRs as counters.
There should also be a maker/family/model filter mechanism, so that certain
MSRs
are only exposed on models that are known to support them, etc.
Thanks,
Ingo
- Forwarded message from Andy Lutomirski l...@kernel.org -
Date: Tue, 28 Apr 2015 14:25:37 -0700
From: Andy Lutomirski l...@kernel.org
To: Len Brown len.br...@intel.com, Peter Zijlstra pet...@infradead.org,
linux-kernel@vger.kernel.org linux-kernel@vger.kernel.org
Cc: Paul Mackerras pau...@samba.org, Ingo Molnar mi...@redhat.com, Arnaldo
Carvalho de Melo a...@kernel.org, Andy Lutomirski l...@kernel.org
Subject: [RFC] x86, perf: Add an aperfmperf driver
Signed-off-by: Andy Lutomirski l...@kernel.org
---
This driver seems a little bit silly, but I can imagine it being useful. For
example, I think that turbostat could do some of its work without being
root if we had a driver like this.
Thoughts? Would it make sense at all? Did I wire it up right? This is
the only PMU driver I've ever written, and it could have any number of
issues.
arch/x86/kernel/cpu/Makefile| 2 +
arch/x86/kernel/cpu/perf_event_aperfmperf.c | 119
2 files changed, 121 insertions(+)
create mode 100644 arch/x86/kernel/cpu/perf_event_aperfmperf.c
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 80091ae54c2b..fadc822efc90 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -45,6 +45,8 @@ obj-$(CONFIG_PERF_EVENTS_INTEL_UNCORE)+=
perf_event_intel_uncore.o \
perf_event_intel_uncore_snb.o \
perf_event_intel_uncore_snbep.o \
perf_event_intel_uncore_nhmex.o
+obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_aperf_mperf.o
+obj-$(CONFIG_CPU_SUP_AMD) += perf_event_aperf_mperf.o
endif
diff --git a/arch/x86/kernel/cpu/perf_event_aperfmperf.c
b/arch/x86/kernel/cpu/perf_event_aperfmperf.c
new file mode 100644
index ..6e6d113bd9ce
--- /dev/null
+++ b/arch/x86/kernel/cpu/perf_event_aperfmperf.c
@@ -0,0 +1,119 @@
+#include linux/perf_event.h
+
+#define APERFMPERF_EVENT_APERF 0
+#define APERFMPERF_EVENT_MPERF 1
+
+PMU_EVENT_ATTR_STRING(aperf, evattr_aperf, event=0x00);
+PMU_EVENT_ATTR_STRING(mperf, evattr_mperf, event=0x01);
+static struct attribute *events_attrs[] = {
+ evattr_aperf.attr.attr,
+ evattr_mperf.attr.attr,
+ NULL,
+};
+static struct attribute_group events_attr_group = {
+ .name = events,
+ .attrs = events_attrs,
+};
+
+PMU_FORMAT_ATTR(event, config:0-63);
+static struct attribute *format_attrs[] = {
+ format_attr_event.attr,
+ NULL,
+};
+static struct attribute_group format_attr_group = {
+ .name = format,
+ .attrs = format_attrs,
+};
+
+static const struct attribute_group *attr_groups[] = {
+ events_attr_group,
+ format_attr_group,
+ NULL,
+};
+
+static int aperfmperf_event_init(struct perf_event *event)
+{
+ if (event-attr.type != event-pmu-type)
+ return -ENOENT;
+
+ if (event-attr.config != APERFMPERF_EVENT_APERF
+ event-attr.config != APERFMPERF_EVENT_MPERF)
+ return -ENOENT;
+
+ if (event-attr.config1 != 0)
+ return -ENOENT;
+
+ /* no sampling */
+ if (event-hw.sample_period)
+ return -EINVAL;
+
+ /* unsupported modes and filters */
+ if (event-attr.exclude_user ||
+ event-attr.exclude_kernel ||
+ event-attr.exclude_hv ||
+ event-attr.exclude_idle ||
+ event-attr.exclude_host ||
+ event-attr.exclude_guest ||
+ event-attr.freq ||
+ event-attr.sample_period) /* no sampling */
+ return -EINVAL;
+
+ event-hw.idx = -1;
+ event-hw.event_base = (event-attr.config == APERFMPERF_EVENT_APERF ?
+ MSR_IA32_APERF : MSR_IA32_MPERF);
+
+ return 0;
+}
+
+static void aperfmperf_event_update(struct perf_event *event)
+{
+ u64 prev;
+ u64 now;
+
+
Re: [PATCH] perf tools: don't adjust symbols in vDSO
On Fri, Jun 26, 2015 at 04:44:14PM +0100, Andy Lutomirski wrote: On Fri, Jun 26, 2015 at 8:29 AM, Will Deacon will.dea...@arm.com wrote: On Fri, Jun 26, 2015 at 04:18:59PM +0100, Andy Lutomirski wrote: On Fri, Jun 26, 2015 at 7:58 AM, Will Deacon will.dea...@arm.com wrote: (CC'ing Andy, since the removal of VDSO_PRELINK is user-visible here) What arch is this? I removed VDSO_PRELINK entirely from x86 a while back, and now x86's vdso has a base address of 0 before relocations, and everything works just fine. I think this is only x86, since it's the removal of VDSO_PRELINK that has changed things. (Except one ancient glibc, which fails if the vdso is relocated at all. We no longer support that version of glibc unless you turn off the vdso entirely.) The problem is that perf expects to objdump portions of the vdso using --start-address=foo and --stop-address=bar, but these addresses have changed from being offset by VDSO_PRELINK to 0x0. Thankfully, it looks like perf tool was always broken in this regard, but I figured you might like to be aware of the issue. I guess perf just needs to add on the load address of the vdso .text section to its relative addresses before passing them to objdump. Given that we've randomized the vdso load address on x86 for years, I don't see how perf ever worked here. There was a brief period during which we actually loaded the vdso at the address VDSO_PRELINK, but that's long gone. The symbol resolution works by applying the vdso symbol offset to the [vdso] vma base, but perf annotate had indeed been broken the whole time. Is there a patch I should be looking at? I've cooked something, so I'll send it out now. Will -- 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 4.0 00/22] 4.0.7-stable review
On Fri, Jun 26, 2015 at 06:08:42PM -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.0.7 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Compiled and booted on x86_32. No errors in dmesg. regards sudip -- 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.10 0/5] 3.10.82-stable review
On Fri, Jun 26, 2015 at 06:08:23PM -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.82 release. There are 5 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon Jun 29 01:07:49 UTC 2015. Anything received after that time might be too late. Compiled and booted on x86_32. No errors in dmesg. regards sudip -- 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] timer: Fix unsafe cpu variable access in migrate_timers
From: Jan Kiszka jan.kis...@siemens.com migrate_timers is invoked with preemption enabled. Therefore we have to get/put the cpu-local variable tvec_bases like before commit 0eeda71bc3. This fixes BUG: using smp_processor_id() in preemptible [] code: bash/4917 caller is debug_smp_processor_id+0x17/0x19 CPU: 0 PID: 4917 Comm: bash Not tainted 4.1.0-dbg+ #97 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014 880038674040 880002e6fb98 815356a0 0002 880002e6fbc8 8130c16f 88003fd8d500 d500 0003 880002e6fbd8 Call Trace: [815356a0] dump_stack+0x4f/0x7b [8130c16f] check_preemption_disabled+0xdd/0xef [8130c198] debug_smp_processor_id+0x17/0x19 [810a9b37] timer_cpu_notify+0x4f/0x112 [8106718b] notifier_call_chain+0x4c/0x71 [810671be] __raw_notifier_call_chain+0xe/0x10 [810484b6] __cpu_notify+0x20/0x37 [810484e0] cpu_notify+0x13/0x15 [81048591] cpu_notify_nofail+0xe/0x16 [8152efb2] _cpu_down+0x178/0x268 [8108bc3a] ? trace_hardirqs_on+0xd/0xf [8152f0ca] cpu_down+0x28/0x3c [813cbdb9] cpu_subsys_offline+0x14/0x16 [813c779d] device_offline+0x7d/0xb1 [813c78a2] online_store+0x48/0x68 [813c5544] dev_attr_store+0x18/0x22 [811dac6c] sysfs_kf_write+0x49/0x51 [811da139] kernfs_fop_write+0x105/0x158 [8116c54f] __vfs_write+0x28/0xbd [812ab014] ? security_file_permission+0x23/0x90 [8116ccb2] vfs_write+0xb2/0x169 [8116d717] SyS_write+0x4a/0x91 [8153d12e] entry_SYSCALL_64_fastpath+0x12/0x76 triggered when offlining a CPU, e.g. via sysfs. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- kernel/time/timer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 520499d..c826178 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1566,7 +1566,7 @@ static void migrate_timers(int cpu) BUG_ON(cpu_online(cpu)); old_base = per_cpu_ptr(tvec_bases, cpu); - new_base = this_cpu_ptr(tvec_bases); + new_base = get_cpu_var(tvec_bases); /* * The caller is globally serialized and nobody else * takes two locks at once, deadlock is not possible. @@ -1590,6 +1590,7 @@ static void migrate_timers(int cpu) spin_unlock(old_base-lock); spin_unlock_irq(new_base-lock); + put_cpu_var(tvec_bases); } static int timer_cpu_notify(struct notifier_block *self, -- 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 4.1 00/11] 4.1.1-stable review
On 06/26/2015 06:09 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.1.1 release. There are 11 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon Jun 29 01:08:53 UTC 2015. Anything received after that time might be too late. Build results: total: 124 pass: 124 fail: 0 Qemu test results: total: 31 pass: 31 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. 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/
Re: [PATCH][RFC] usbhid: enable autosuspend for internal devices
On Fri, 26 Jun 2015, Greg Kroah-Hartman wrote:
I thought udev used a whitelist of devices known to work okay with
autosuspend. Does it really turn on autosuspend for _every_ USB HID
device that is marked as removable?
Yes, it had a tiny whitelist of 3-4 devices, and then would turn on
autosuspend for anything not marked as removable or unknown. Look at
/usr/lib/udev/rules.d/42-usb-hid-pm.rules on your system for them, it's
these lines:
ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb,
ATTR{../removable}==removable, GOTO=usb_hid_pm_end
ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb,
ATTR{../removable}==unknown, GOTO=usb_hid_pm_end
(Come to think of it, given the bug in the hub driver, no device
attached directly to the root hub will _ever_ be marked as removable
AFAICS. So maybe that bug is masking possible regressions.)
Maybe that's the issue, don't know, it would be good to figure out as
upstream udev just deleted that whole rules file :)
Last time we were testing this, autosuspend for USB HID devices was quite
a disaster.
Do you have any idea whether udev developers tested the autosuspend on by
default for USB HID devices on reasonable set of devices?
The culrpits that I remember from top of my head (it's been long time
ago):
- the LEDs for suspended device go off. This is very confusing at least on
keyboards, and brings really bad user experience
- many keyboards were losing first keystroke when waking up from suspend.
We've been debugging this with Alan, and never root-caused it to a
problem in our code, it seems to be the property of the HW
I really do want to keep the autosuspend disabled by default on USB HID
devices (at least keyboards), and enable it based on whitelist. If udev is
not going to do this any more, I am afraid we'll have to move the default
into the kernel.
--
Jiri Kosina
SUSE Labs
--
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: Crypto Fixes for 4.2
On Fri, Jun 26, 2015 at 01:07:02PM -0700, Linus Torvalds wrote: On Fri, Jun 26, 2015 at 3:22 AM, Herbert Xu herb...@gondor.apana.org.au wrote: * Kill testmgr warning for gcm-aes-aesni. Hmm. You killed one of the warnings, but the setkey one remains. alg: aead: setkey failed on test 1 for rfc4106-gcm-aesni: flags=0 Expected? I wanted to explore a more complete fix with delaying the testing until all built-in registrations are complete but it turned out to be too complicated for now. So I think Tadeusz's patch is the simplest fix for 4.2. Could you please test it to see if it makes your warning go away? Just in case you're running into something else that happens to look the same. Here is his patch again with a corrected changelog. Thanks! ---8--- From: Tadeusz Struk tadeusz.st...@intel.com Subject: crypto: aesni - fix failing setkey for rfc4106-gcm-aesni rfc4106(gcm(aes)) uses ctr(aes) to generate hash key. ctr(aes) needs chainiv, but the chainiv gets initialized after aesni_intel when both are statically linked so the setkey fails. This patch forces aesni_intel to be initialized after chainiv. Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com --- arch/x86/crypto/aesni-intel_glue.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c index ebcb981d..cb630a8 100644 --- a/arch/x86/crypto/aesni-intel_glue.c +++ b/arch/x86/crypto/aesni-intel_glue.c @@ -1537,7 +1537,7 @@ static void __exit aesni_exit(void) crypto_fpu_exit(); } -module_init(aesni_init); +late_initcall(aesni_init); module_exit(aesni_exit); MODULE_DESCRIPTION(Rijndael (AES) Cipher Algorithm, Intel AES-NI instructions optimized); -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] gpu/drm/amdgpu: Fix build when CONFIG_DEBUG_FS is not set
If the CONFIG_DEBUG_FS is not selected, compilation of the
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c provides two warnings that
amdgpu_debugfs_regs_init and amdgpu_debugfs_regs_cleanup are used but
never defined. And as result:
ERROR: amdgpu_debugfs_regs_cleanup [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
undefined!
ERROR: amdgpu_debugfs_regs_init [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
undefined!
^
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index fec487d..6896798 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2000,5 +2000,10 @@ int amdgpu_debugfs_init(struct drm_minor *minor)
void amdgpu_debugfs_cleanup(struct drm_minor *minor)
{
}
+#else
+static int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
+{
+ return 0;
+}
+static void amdgpu_debugfs_regs_cleanup(struct amdgpu_device *adev) { }
#endif
--
2.4.4.410.gc71d752
--
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 1/3] perf probe: Init symbol as kprobe if any pev is kprobe
On 2015/06/25 19:37, Wang Nan wrote:
Before this patch, add_perf_probe_events() init symbol maps only for
uprobe if the first pev passed to it is a uprobe event. However, with
the incoming BPF uprobe support, now it will be possible to pass an
array with combined kprobe and uprobe events to add_perf_probe_events().
This description is not correct. Actually, add_perf_probe_events already
supports mix of uprobes and kprobes. However, from the command line syntax
constrains the first elements of the probe_event arrays must be kprobes.
So, if the array starts with uprobes, no kprobes should be there.
This patch check all pevs instead of the first one, and init kernel
symbol if any events is not uprobe.
Anyway, I prefer to call init_symbol_maps() with false :)
Thank you,
Signed-off-by: Wang Nan wangn...@huawei.com
---
tools/perf/util/probe-event.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index b386d2f..a2b3026 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2802,8 +2802,21 @@ int cleanup_perf_probe_event(struct perf_probe_event
*pev)
int add_perf_probe_events(struct perf_probe_event *pevs, int npevs, bool
cleanup)
{
int i, ret;
+ bool user_only = true;
- ret = init_symbol_maps(pevs-uprobes);
+ /* If any pev is kprobe, init kernel symbols. */
+ for (i = 0; i npevs; i++) {
+ if (!pevs[i].uprobes) {
+ user_only = false;
+ break;
+ }
+ }
+
+ /*
+ * Compiler can drop user_only:
+ * ret = init_symbol_maps(i = npevs);
+ */
+ ret = init_symbol_maps(user_only);
if (ret 0)
return ret;
--
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research Development Group
E-mail: masami.hiramatsu...@hitachi.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/
Re: [PATCH] bpf: Put perf_events check ahead of bpf prog
On 6/26/15 11:44 PM, He Kuang wrote: @@ -1141,13 +1141,13 @@ kprobe_perf_func(struct trace_kprobe *tk, struct pt_regs *regs) int size, __size, dsize; int rctx; - if (prog !trace_call_bpf(prog, regs)) - return; - head = this_cpu_ptr(call-perf_events); if (hlist_empty(head)) return; + if (prog !trace_call_bpf(prog, regs)) + return; I considered doing that before placing it where it is now. There were some issues with this approach. Trying to remember. I'm traveling at the moment. Will elaborate next week. -- 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] staging: board: Add dependency on CLKDEV_LOOKUP
On Sat, Jun 27, 2015 at 4:39 AM, Guenter Roeck li...@roeck-us.net wrote:
The code depends on CLKDEV_LOOKUP since commit 225d68d852f1 (staging:
board: Add support for devices with complex dependencies).
Related build error (powerpc:allmodconfig):
drivers/built-in.o: In function `.board_staging_register_clock':
(.init.text+0x1d8e0): undefined reference to `.clk_add_alias'
Fixes: 225d68d852f1 (staging: board: Add support for devices
with complex dependencies)
Cc: Geert Uytterhoeven geert+rene...@glider.be
Signed-off-by: Guenter Roeck li...@roeck-us.net
See also
[PATCH v2] staging: make board support depend on OF_IRQ and CLKDEV_LOOKUP
https://lkml.org/lkml/2015/6/20/215
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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: platform: x86: Deletion of checks before backlight_device_unregister()
Julia, do you have any particular objection to this specific patch? I didn't see a reason to prevent it going in. Thanks for your interest around this concrete update suggestion. * Would you like to distinguish the consequences a bit more for results from the application of the semantic patch language? * Where do you prefer to store special extensions for Coccinelle's script collection Regards, Markus -- 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/
HELLO DEAR
-- I am very sorry If I interfere into your privacy,i will like to get acquainted with you. I will appreciate if granted this Privilege to know you more. Get back to me for formal introduction ,waiting earnestly to read from you. ( ezzahzuw...@hotmail.com ) Ezzah -- 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] timer: Fix unsafe cpu variable access in migrate_timers
On Sat, Jun 27, 2015 at 01:19:24PM +0200, Jan Kiszka wrote: Oh, there is a fix already. It's just the same: both implicitly disable preemption via get_cpu_ptr/var, look at the macros. Ah, yes. /me goes to the coffee machine to make eyes open. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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 v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device
Hi Lina, On Sat, Jun 27, 2015 at 6:05 AM, Lina Iyer lina.i...@linaro.org wrote: Hi Ohad, Any comments? Sorry, I was under the impression the discussion with Bjorn is still open. Like Bjorn, I'm not so sure too we want to bind a specific lock to the RAW capability since this is not a lock-specific hardware detail. As far as I can see, the hardware-specific differences (if any) are at the vendor level and not at the lock level, therefore it might make more sense to add the caps member to hwspinlock_device rather than to the hwspinlock struct (Jeffrey commented about this too). Thanks, Ohad. -- 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] bpf: Use correct #ifdef controller for trace_call_bpf()
Commit e1abf2cc8d5d80b41c4419368ec743ccadbb131e (bpf: Fix the build on BPF_SYSCALL=y !CONFIG_TRACING kernels, make it more configurable) updated the building condition of bpf_trace.o from CONFIG_BPF_SYSCALL to CONFIG_BPF_EVENT, but the corresponding #ifdef controller in ftrace_event.h for trace_call_bpf() is not changed. Which, in theory, is incorrect. With current Kconfigs, we can create a .config with CONFIG_BPF_SYSCALL=y and CONFIG_BPF_EVENT=n by unselecting CONFIG_KPROBE_EVENT and selecting CONFIG_BPF_SYSCALL. With these options, trace_call_bpf() will be defined as an extern function, but if anyone calls it a symbol missing error will be trigger since bpf_trace.o is not build. This patch changes the #ifdef controller for trace_call_bpf() from CONFIG_BPF_SYSCALL to CONFIG_BPF_EVENT. I'll show its correctness: Before this patch: BPF_SYSCALL BPF_EVENT trace_call_bpf bpf_trace.o y y normal compiled n n inline not compiled y n normal not compiled (incorrect) n y impossible (BPF_EVENT depends on BPF_SYSCALL) After this patch: BPF_SYSCALL BPF_EVENT trace_call_bpf bpf_trace.o y y normal compiled n n inline not compiled y n inline not compiled (fixed) n y impossible (BPF_EVENT depends on BPF_SYSCALL) So this patch doesn't break thing. QED. Signed-off-by: Wang Nan wangn...@huawei.com --- include/linux/ftrace_event.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h index f9ecf63..68cf311 100644 --- a/include/linux/ftrace_event.h +++ b/include/linux/ftrace_event.h @@ -553,7 +553,7 @@ event_trigger_unlock_commit_regs(struct ftrace_event_file *file, event_triggers_post_call(file, tt); } -#ifdef CONFIG_BPF_SYSCALL +#ifdef CONFIG_BPF_EVENT unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx); #else static inline unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx) -- 1.8.3.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/
[PATCH] staging: comedi: adl_pci9118: Delete an unnecessary check before the function call pci_dev_put
From: Markus Elfring elfr...@users.sourceforge.net
Date: Sat, 27 Jun 2015 13:50:43 +0200
The pci_dev_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
---
drivers/staging/comedi/drivers/adl_pci9118.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
index fb3043d..19b5806 100644
--- a/drivers/staging/comedi/drivers/adl_pci9118.c
+++ b/drivers/staging/comedi/drivers/adl_pci9118.c
@@ -1717,8 +1717,7 @@ static void pci9118_detach(struct comedi_device *dev)
pci9118_reset(dev);
comedi_pci_detach(dev);
pci9118_free_dma(dev);
- if (pcidev)
- pci_dev_put(pcidev);
+ pci_dev_put(pcidev);
}
static struct comedi_driver adl_pci9118_driver = {
--
2.4.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/
[RFC PATCH v9 49/50 -fix] perf probe: Init symbol as kprobe if any event is kprobe
Before this patch, add_perf_probe_events() init symbol maps only for
uprobe if the first 'struct perf_probe_event' passed to it is a uprobe
event. This is a trick because 'perf probe''s command line syntax
constrains the first elements of the probe_event arrays must be kprobes
if there is one.
However, with the incoming BPF uprobe support, the constrain is not
hold since 'perf record' will also probe on k/u probes through BPF
object, and is possible to pass an array with kprobe but the first
element is uprobe.
This patch init symbol maps for kprobes even if all of events are
uprobes, because the extra cost should be small enough.
Signed-off-by: Wang Nan wangn...@huawei.com
---
tools/perf/util/probe-event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index ea08015..e74ca8f 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2804,7 +2804,7 @@ int add_perf_probe_events(struct perf_probe_event *pevs,
int npevs,
{
int i, ret;
- ret = init_symbol_maps(pevs-uprobes);
+ ret = init_symbol_maps(false);
if (ret 0)
return ret;
--
1.8.3.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 v3 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k
On Saturday 27 June 2015 13:34:30 Gabriele Mazzotta wrote: Hi Pali, I've just noticed an issue with this patch. See the comment here below. Gabriele On Wednesday 29 April 2015 13:41:26 Pali Rohár wrote: @@ -750,8 +777,8 @@ static int __init i8k_init_hwmon(void) if (err = 0) i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN2; - i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, i8k, NULL, - i8k_groups); + i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, dell-smm, + NULL, i8k_groups); dell-smm is not a valid name, see hwmon_device_register_with_groups() for more info (dash not allowed). Because of this, the driver can't be loaded. How it is possible? It worked fine on my tested dell machine... And now I see, I probably tested this change with older kernel version (ubuntu/3.13) which did not have that check for invalid characters... Renaming dell-smm to dell_smm should fix this problem, right? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/4] x86/setup: introduce setup_bultin_cmdline
sorry, forgot to add version to this patch, please skip this patch.
2015-06-27 19:46 GMT+06:00 Alexander Kuleshov kuleshovm...@gmail.com:
This patch introduces the setup_builtin_cmdline function which appends or
overrides boot_command_line with the builtin_cmdline if CONFIG_CMDLINE_BOOL
is set.
Previously this functional was in the setup_arch, but we need to move
it for getting actual command line as early as possible in the
arch/x86/kernel/head{32,64}.c for the earlyprintk setup.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
arch/x86/include/asm/setup.h | 2 +-
arch/x86/kernel/setup.c | 29 +
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 11af24e..70dfa61 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -124,8 +124,8 @@ asmlinkage void __init i386_start_kernel(void);
#else
asmlinkage void __init x86_64_start_kernel(char *real_mode);
asmlinkage void __init x86_64_start_reservations(char *real_mode_data);
-
#endif /* __i386__ */
+void __init setup_builtin_cmdline(void);
#endif /* _SETUP */
#else
#define RESERVE_BRK(name,sz) \
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d3b95b8..e528f12 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -847,6 +847,22 @@ dump_kernel_offset(struct notifier_block *self, unsigned
long v, void *p)
return 0;
}
+void __init setup_builtin_cmdline(void)
+{
+#ifdef CONFIG_CMDLINE_BOOL
+#ifdef CONFIG_CMDLINE_OVERRIDE
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+#else
+ if (builtin_cmdline[0]) {
+ /* append boot loader cmdline to builtin */
+ strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
+ strlcat(builtin_cmdline, boot_command_line,
COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, builtin_cmdline,
COMMAND_LINE_SIZE);
+ }
+#endif
+#endif
+}
+
/*
* Determine if we were loaded by an EFI loader. If so, then we have also
been
* passed the efi memmap, systab, etc., so we should use these data
structures
@@ -975,2 +991,2 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = __pa_symbol(__bss_start);
bss_resource.end = __pa_symbol(__bss_stop)-1;
-#ifdef CONFIG_CMDLINE_BOOL
-#ifdef CONFIG_CMDLINE_OVERRIDE
- strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-#else
- if (builtin_cmdline[0]) {
- /* append boot loader cmdline to builtin */
- strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
- strlcat(builtin_cmdline, boot_command_line,
COMMAND_LINE_SIZE);
- strlcpy(boot_command_line, builtin_cmdline,
COMMAND_LINE_SIZE);
- }
-#endif
-#endif
+ setup_builtin_cmdline();
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
--
2.4.4.410.gc71d752
--
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 v7] dma: Add Xilinx AXI Direct Memory Access Engine driver support
On Wed, Jun 24, 2015 at 05:12:13PM +, Appana Durga Kedareswara Rao wrote: where is the hardware addr programmed? I can see you are using sg list passed for porgramming one side of a transfer where is other side programmed? The actual programming happens in the start_transfer(I mean in issue_pending) API There are two modes All the h/w addresses are configured in the start_transfer API. In simple transfer Mode the below write triggers the transfer dma_ctrl_write(chan, XILINX_DMA_REG_BTT, hw-control XILINX_DMA_MAX_TRANS_LEN); In SG Mode the below write triggers the transfer. dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC, tail-phys); There are two Channels MM2S (Memory to device) and S2MM (Device to Memory) channel. -- In MM2S case we need to configure the SOF (Start of frame) for the first BD and we need to set EOF(end of frame) for the last BD -- For S2MM case no need to configure SOF and EOF. Once we got the IOC interrupt will call mark the cookie as complete and will Call the user callback. There users checks for the data. Please let me know if you are not clear. No sorry am not... I asked how the device address in configured. For both MM2S S2MM you are using sg for memory address, where are you getting device adress, are you assuming/hardcoding or getting somehow, if so how? no dma_slave_config handler? No need of this callback earlier in the dma_slave_config we are doing terminate_all Now we have a separate API for that so no need to have this call back. The question was on parameters -- ~Vinod -- 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/2] staging: wilc1000: One function call less in mac_ioctl() after error detection
From: Markus Elfring elfr...@users.sourceforge.net
Date: Sat, 27 Jun 2015 16:00:59 +0200
The kfree() function was called in two cases by the mac_ioctl() function
during error handling even if the passed variable did not contain a pointer
for a valid data item.
* This implementation detail could be improved by the introduction
of another jump label.
* Drop an unnecessary initialisation for the variable buff then.
Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
---
drivers/staging/wilc1000/linux_wlan.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c
b/drivers/staging/wilc1000/linux_wlan.c
index 2aa8d9b..f492310 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -2351,16 +2351,13 @@ int mac_close(struct net_device *ndev)
int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
{
-
- u8 *buff = NULL;
+ u8 *buff;
s8 rssi;
u32 size = 0, length = 0;
perInterface_wlan_t *nic;
struct WILC_WFI_priv *priv;
s32 s32Error = WILC_SUCCESS;
-
-
/* struct iwreq *wrq = (struct iwreq *) req;// tony moved to case
SIOCSIWPRIV */
#ifdef USE_WIRELESS
nic = netdev_priv(ndev);
@@ -2405,7 +2402,7 @@ int mac_ioctl(struct net_device *ndev, struct ifreq *req,
int cmd)
if (copy_to_user(wrq-u.data.pointer, buff,
size)) {
PRINT_ER(%s: failed to copy data to
user buffer\n, __func__);
s32Error = -EFAULT;
- goto done;
+ goto free_buffer;
}
}
}
@@ -2420,8 +2417,9 @@ int mac_ioctl(struct net_device *ndev, struct ifreq *req,
int cmd)
}
}
-done:
+free_buffer:
kfree(buff);
+done:
return s32Error;
}
--
2.4.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/
[RFC PATCH v9 01/50 -fix] tracing, perf: Implement BPF programs attached to uprobes
By copying BPF related operation to uprobe processing path, this patch
allow users attach BPF programs to uprobes like what they are already
doing on kprobes.
After this patch, users are allowed to use PERF_EVENT_IOC_SET_BPF on a
uprobe perf event. Which make it possible to profile user space programs
and kernel events together using BPF.
Because of this patch, CONFIG_BPF_EVENT should be selected by
CONFIG_UPROBE_EVENT to ensure trace_call_bpf() is compiled even if
KPROBE_EVENT is not set.
Signed-off-by: Wang Nan wangn...@huawei.com
Acked-by: Alexei Starovoitov a...@plumgrid.com
---
This patch fixes a building error found by buildlbot that, if
CONFIG_BPF_EVENT is not set, following error occures:
kernel/built-in.o: In function `__uprobe_perf_func':
trace_uprobe.c:(.text+0xd6403): undefined reference to `trace_call_bpf'
---
include/linux/ftrace_event.h | 5 +
kernel/events/core.c | 4 ++--
kernel/trace/Kconfig | 2 +-
kernel/trace/trace_uprobe.c | 5 +
4 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 68cf311..d40272a 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -254,6 +254,7 @@ enum {
TRACE_EVENT_FL_USE_CALL_FILTER_BIT,
TRACE_EVENT_FL_TRACEPOINT_BIT,
TRACE_EVENT_FL_KPROBE_BIT,
+ TRACE_EVENT_FL_UPROBE_BIT,
};
/*
@@ -268,6 +269,7 @@ enum {
* USE_CALL_FILTER - For ftrace internal events, don't use file filter
* TRACEPOINT- Event is a tracepoint
* KPROBE- Event is a kprobe
+ * UPROBE- Event is a uprobe
*/
enum {
TRACE_EVENT_FL_FILTERED = (1 TRACE_EVENT_FL_FILTERED_BIT),
@@ -278,8 +280,11 @@ enum {
TRACE_EVENT_FL_USE_CALL_FILTER = (1
TRACE_EVENT_FL_USE_CALL_FILTER_BIT),
TRACE_EVENT_FL_TRACEPOINT = (1 TRACE_EVENT_FL_TRACEPOINT_BIT),
TRACE_EVENT_FL_KPROBE = (1 TRACE_EVENT_FL_KPROBE_BIT),
+ TRACE_EVENT_FL_UPROBE = (1 TRACE_EVENT_FL_UPROBE_BIT),
};
+#define TRACE_EVENT_FL_UKPROBE (TRACE_EVENT_FL_KPROBE | TRACE_EVENT_FL_UPROBE)
+
struct ftrace_event_call {
struct list_headlist;
struct ftrace_event_class *class;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 9e0773d..18835de 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6775,8 +6775,8 @@ static int perf_event_set_bpf_prog(struct perf_event
*event, u32 prog_fd)
if (event-tp_event-prog)
return -EEXIST;
- if (!(event-tp_event-flags TRACE_EVENT_FL_KPROBE))
- /* bpf programs can only be attached to kprobes */
+ if (!(event-tp_event-flags TRACE_EVENT_FL_UKPROBE))
+ /* bpf programs can only be attached to u/kprobes */
return -EINVAL;
prog = bpf_prog_get(prog_fd);
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 3b9a48a..1153c43 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -434,7 +434,7 @@ config UPROBE_EVENT
config BPF_EVENTS
depends on BPF_SYSCALL
- depends on KPROBE_EVENT
+ depends on KPROBE_EVENT || UPROBE_EVENT
bool
default y
help
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 6dd022c..0b580bd 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -1095,11 +1095,15 @@ static void __uprobe_perf_func(struct trace_uprobe *tu,
{
struct ftrace_event_call *call = tu-tp.call;
struct uprobe_trace_entry_head *entry;
+ struct bpf_prog *prog = call-prog;
struct hlist_head *head;
void *data;
int size, esize;
int rctx;
+ if (prog !trace_call_bpf(prog, regs))
+ return;
+
esize = SIZEOF_TRACE_ENTRY(is_ret_probe(tu));
size = esize + tu-tp.size + dsize;
@@ -1289,6 +1293,7 @@ static int register_uprobe_event(struct trace_uprobe *tu)
return -ENODEV;
}
+ call-flags = TRACE_EVENT_FL_UPROBE;
call-class-reg = trace_uprobe_register;
call-data = tu;
ret = trace_add_event_call(call);
--
1.8.3.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 v3 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k
On Saturday 27 June 2015 14:47:16 Pali Rohár wrote: On Saturday 27 June 2015 13:34:30 Gabriele Mazzotta wrote: Hi Pali, I've just noticed an issue with this patch. See the comment here below. Gabriele On Wednesday 29 April 2015 13:41:26 Pali Rohár wrote: @@ -750,8 +777,8 @@ static int __init i8k_init_hwmon(void) if (err = 0) i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN2; - i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, i8k, NULL, - i8k_groups); + i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, dell-smm, + NULL, i8k_groups); dell-smm is not a valid name, see hwmon_device_register_with_groups() for more info (dash not allowed). Because of this, the driver can't be loaded. How it is possible? It worked fine on my tested dell machine... And now I see, I probably tested this change with older kernel version (ubuntu/3.13) which did not have that check for invalid characters... Renaming dell-smm to dell_smm should fix this problem, right? Yes, everything works just fine with the underscore. -- 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 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k
On Saturday 27 June 2015 14:55:40 Gabriele Mazzotta wrote: On Saturday 27 June 2015 14:47:16 Pali Rohár wrote: On Saturday 27 June 2015 13:34:30 Gabriele Mazzotta wrote: Hi Pali, I've just noticed an issue with this patch. See the comment here below. Gabriele On Wednesday 29 April 2015 13:41:26 Pali Rohár wrote: @@ -750,8 +777,8 @@ static int __init i8k_init_hwmon(void) if (err = 0) i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN2; - i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, i8k, NULL, - i8k_groups); + i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, dell-smm, + NULL, i8k_groups); dell-smm is not a valid name, see hwmon_device_register_with_groups() for more info (dash not allowed). Because of this, the driver can't be loaded. How it is possible? It worked fine on my tested dell machine... And now I see, I probably tested this change with older kernel version (ubuntu/3.13) which did not have that check for invalid characters... Renaming dell-smm to dell_smm should fix this problem, right? Yes, everything works just fine with the underscore. Ok, will you send patch for this small fix? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[PATCH] hwmon: (dell-smm-hwon) Use a valid name attribute
As per Documentation/hwmon/sysfs-interface, hwmon name attributes must
not include '-', so replace 'dell-smm' with 'dell_smm'.
Fixes: 039ae58503f3 (hwmon: Allow to compile dell-smm-hwmon driver without
/proc/i8k)
Signed-off-by: Gabriele Mazzotta gabriele@gmail.com
---
drivers/hwmon/dell-smm-hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index 2a80882..37c16af 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -777,7 +777,7 @@ static int __init i8k_init_hwmon(void)
if (err = 0)
i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN2;
- i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, dell-smm,
+ i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, dell_smm,
NULL, i8k_groups);
if (IS_ERR(i8k_hwmon_dev)) {
err = PTR_ERR(i8k_hwmon_dev);
--
2.1.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/
[PATCH 2/4 v13] x86/setup: handle builtin command line as early as possible
This patch adds the call of the setup_builtin_cmdline to
handle builtin command line before we will setup earlyprintk.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
arch/x86/kernel/head32.c | 1 +
arch/x86/kernel/head64.c | 1 +
arch/x86/kernel/setup.c | 2 --
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/head32.c b/arch/x86/kernel/head32.c
index 2911ef3..92e8b5f 100644
--- a/arch/x86/kernel/head32.c
+++ b/arch/x86/kernel/head32.c
@@ -31,6 +31,7 @@ static void __init i386_default_early_setup(void)
asmlinkage __visible void __init i386_start_kernel(void)
{
+ setup_builtin_cmdline();
cr4_init_shadow();
sanitize_boot_params(boot_params);
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 5a46681..d255430 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -172,6 +172,7 @@ asmlinkage __visible void __init x86_64_start_kernel(char *
real_mode_data)
copy_bootdata(__va(real_mode_data));
+ setup_builtin_cmdline();
/*
* Load microcode early on BSP.
*/
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index e528f12..fc381ec 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,2 +991,2 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = __pa_symbol(__bss_start);
bss_resource.end = __pa_symbol(__bss_stop)-1;
- setup_builtin_cmdline();
-
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
--
2.4.4.410.gc71d752
--
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/4 v13] x86/earlyprintk: setup earlyprintk as early as possible
The earlyprintk is usable only after the setup_early_printk will
be executed. We pass 'earlyprintk' through the kernel command line, so it
will be usable only after the 'parse_early_param' will be executed. This means
that we have usable earlyprintk only during early boot, kernel decompression
and after call of the 'parse_early_param', but sometimes it is very useful to
know what occurs between. The earlyprintk can allow us to know what occurs after
kernel decompression and before parse_early_param will be called.
This patch provides following stuff:
1. Thi patch introduces the setup_earlyprintk_console function,
which called arch/x86/kernel/hhead{32,64}.c, parses kernel command line,
tries to find 'earlyprintk' option and calls setup_early_printk depending
on the result.
2. As setup_earlyprintk_console setups earlyprintk very early, we can't
use all console devices for now, but only serial and vga. There is
earlyprintk_late variable which determines ability to setup earlyprintk
for the certain device.
3. Call of the lockdep_init added to the arch/x86/kernel/head{32,64}.c
to prevent call of the register_console before the initialization of lockdep.
In other way there we will get:
[ 0.00] WARNING: lockdep init error! lock-(console_sem).lock was
acquiredbefore lockdep_init
[ 0.00] Call stack leading to lockdep invocation was:
[ 0.00] [] save_stack_trace+0x2f/0x50
[ 0.00] [] __lock_acquire+0xa2c/0xf00
[ 0.00] [] lock_acquire+0xdb/0x2b0
[ 0.00] [] _raw_spin_lock_irqsave+0x53/0x90
[ 0.00] [] down+0x16/0x50
[ 0.00] [] console_lock+0x19/0x60
[ 0.00] [] register_console+0x116/0x350
[ 0.00] [] setup_early_printk+0x165/0x467
[ 0.00] [] setup_early_serial_console+0x56/0x58
[ 0.00] [] x86_64_start_kernel+0xce/0x110
[ 0.00] [] 0x
[ 0.00]
This patch adds lockdep_init to the arch/x86/kernel/head{32,64}.c, but
not removed it from the init/main.c, because there is a couple of architectures
which have support of the lockdep, but do not call lockdep_init in their
architecture-dependent code.
4. As setup_earlyprintk_console can be called twice: from the
setup_earlyprintk_console and parse_early_param, additional
check added to the really early consoles.
Tested it with qemu, so early_printk() is usable and prints to serial
console right after setup_early_printk function called.
We will not see earlyprintk messages in the dmesg buffer, because
it is too early to initialized log_buf.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
arch/x86/include/asm/setup.h | 6 ++
arch/x86/kernel/early_printk.c | 42 +++---
arch/x86/kernel/head32.c | 8
arch/x86/kernel/head64.c | 7 +++
4 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 70dfa61..695f251 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -126,0 +126,0 @@ asmlinkage void __init x86_64_start_kernel(char *real_mode);
asmlinkage void __init x86_64_start_reservations(char *real_mode_data);
#endif /* __i386__ */
void __init setup_builtin_cmdline(void);
+#ifdef CONFIG_EARLY_PRINTK
+/* used by arch/x86/kernel/head{32,64}.c */
+extern int __init setup_earlyprintk_console(void);
+#else
+static inline int __init setup_earlyprintk_console(void) { return 0; }
+#endif /* CONFIG_EARLY_PRINTK */
#endif /* _SETUP */
#else
#define RESERVE_BRK(name,sz) \
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 89427d8..cc47bce 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -329,6 +329,15 @@ static inline void early_console_register(struct console
*con, int keep_early)
register_console(early_console);
}
+/*
+ * Setup of earlyprintk is probably too early now. The setup_early_printk
+ * can be called from two places: from setup_earlyprintk_console and
+ * parse_early_param. In first case it is too early to setup earlyprintk
+ * for some devices as efi, pciserial and etc., but it can be set for
+ * vga and serial.
+ */
+static bool earlyprintk_late = 1;
+
static int __init setup_early_printk(char *buf)
{
int keep;
@@ -342,47 +351,66 @@ static int __init setup_early_printk(char *buf)
keep = (strstr(buf, keep) != NULL);
while (*buf != '\0') {
- if (!strncmp(buf, serial, 6)) {
+ if (!strncmp(buf, serial, 6)
+ early_serial_console.index == -1) {
buf += 6;
early_serial_init(buf);
early_console_register(early_serial_console, keep);
if (!strncmp(buf, ,ttyS, 5))
buf += 5;
}
- if (!strncmp(buf, ttyS, 4)) {
+ if (!strncmp(buf, ttyS, 4)
+
[PATCH 4/4 v13] x86/earlyprintk: add some early_printk for tests
This patch is only for test of the full patch series. It provides
a couple calls of the early_printk function.
[Only for testing]
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
arch/x86/kernel/setup.c | 1 +
init/main.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index fc381ec..488b1ba 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -878,6 +878,7 @@ void __init setup_builtin_cmdline(void)
void __init setup_arch(char **cmdline_p)
{
+ early_printk(Beginning of the x86 specific setup\n);
memblock_reserve(__pa_symbol(_text),
(unsigned long)__bss_stop - (unsigned long)_text);
diff --git a/init/main.c b/init/main.c
index c599aea..deeb2a2 100644
--- a/init/main.c
+++ b/init/main.c
@@ -499,6 +499,8 @@ asmlinkage __visible void __init start_kernel(void)
char *command_line;
char *after_dashes;
+ early_printk(start_kernel from init/main.c started to work\n);
+
/*
* Need to run as early as possible, to initialize the
* lockdep hash:
--
2.4.4.410.gc71d752
--
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 session: Fill in the missing freeing a session after an error occur
In some cases some sessions aren't freed.
For example, a session is allocated and then
if an error occur, just a error value is returned
without freeing the session. So allocating and freeing
session have to be matched as a pair even if an error occur.
Signed-off-by: taeung treeze.tae...@gmail.com
---
tools/perf/builtin-inject.c | 7 ---
tools/perf/builtin-kmem.c | 4 ++--
tools/perf/builtin-kvm.c| 16
tools/perf/builtin-mem.c| 17 ++---
tools/perf/builtin-report.c | 6 --
5 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 52ec66b..01b0649 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -630,12 +630,13 @@ int cmd_inject(int argc, const char **argv, const char
*prefix __maybe_unused)
if (inject.session == NULL)
return -1;
- if (symbol__init(inject.session-header.env) 0)
- return -1;
+ ret = symbol__init(inject.session-header.env);
+ if (ret 0)
+ goto out_delete;
ret = __cmd_inject(inject);
+out_delete:
perf_session__delete(inject.session);
-
return ret;
}
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 950f296..23b1faa 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -1916,7 +1916,7 @@ int cmd_kmem(int argc, const char **argv, const char
*prefix __maybe_unused)
if (!perf_evlist__find_tracepoint_by_name(session-evlist,
kmem:kmalloc)) {
pr_err(errmsg, slab, slab);
- return -1;
+ goto out_delete;
}
}
@@ -1927,7 +1927,7 @@ int cmd_kmem(int argc, const char **argv, const char
*prefix __maybe_unused)
kmem:mm_page_alloc);
if (evsel == NULL) {
pr_err(errmsg, page, page);
- return -1;
+ goto out_delete;
}
kmem_page_size = pevent_get_page_size(evsel-tp_format-pevent);
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 74878cd..5fa96a0 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -1061,8 +1061,10 @@ static int read_events(struct perf_kvm_stat *kvm)
symbol__init(kvm-session-header.env);
- if (!perf_session__has_traces(kvm-session, kvm record))
- return -EINVAL;
+ if (!perf_session__has_traces(kvm-session, kvm record)) {
+ ret = -EINVAL;
+ goto out_delete;
+ }
/*
* Do not use 'isa' recorded in kvm_exit tracepoint since it is not
@@ -1070,9 +1072,15 @@ static int read_events(struct perf_kvm_stat *kvm)
*/
ret = cpu_isa_config(kvm);
if (ret 0)
- return ret;
+ goto out_delete;
- return perf_session__process_events(kvm-session);
+ ret = perf_session__process_events(kvm-session);
+ if (ret 0)
+ goto out_delete;
+
+out_delete:
+ perf_session__delete(kvm-session);
+ return ret;
}
static int parse_target_str(struct perf_kvm_stat *kvm)
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index da2ec06..8b6d473 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -135,24 +135,27 @@ static int report_raw_events(struct perf_mem *mem)
if (mem-cpu_list) {
ret = perf_session__cpu_bitmap(session, mem-cpu_list,
mem-cpu_bitmap);
- if (ret)
+ if (ret) {
+ ret = err;
goto out_delete;
+ }
}
- if (symbol__init(session-header.env) 0)
- return -1;
+ ret = symbol__init(session-header.env);
+ if (ret 0)
+ goto out_delete;
printf(# PID, TID, IP, ADDR, LOCAL WEIGHT, DSRC, SYMBOL\n);
err = perf_session__process_events(session);
if (err)
- return err;
-
- return 0;
+ ret = err;
+ else
+ ret = 0;
out_delete:
perf_session__delete(session);
- return err;
+ return ret;
}
static int report_events(int argc, const char **argv, struct perf_mem *mem)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 32626ea..610d056 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -828,8 +828,10 @@ repeat:
if (report.header || report.header_only) {
perf_session__fprintf_info(session, stdout,
report.show_full_info);
- if (report.header_only)
- return 0;
+ if
Re: [GIT PULL] ext4 changes for 4.2-rc1
On Sat, Jun 27, 2015 at 12:02:37AM -0400, Theodore Ts'o wrote: I would tend to agree. The weird thing though is that I haven't seen this problem myself, despite running multiple regression tests before I sent the pull request, as well as running it on my laptop and doing kernel compiles with make -j16 and reading e-mail (I'm typing this e-mail on a 4.1 kernel merged with the ext4 patches for this merge window, so I have this commit running in my development laptop, and it hasn't triggered for me). Update: I've been able to reproduce the crash using a post merge kernel (of course, I had to use CONFIG_SLUB since CONFIG_SLAB is busted) a single time. Unfortunately, I've not been able to reproduce it reliably so I can't speak to whether reverting 2143c1965a76 will fix things. But it does seem very likely. - Ted -- 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 2/5] usb: gadget: configfs: pass UDC name via usb_gadget_driver struct
Hi Krzysztof,
On Tue, Jun 23, 2015 at 9:54 AM, Krzysztof Opasiak
k.opas...@samsung.com wrote:
Hello,
On 06/23/2015 12:01 AM, Ruslan Bilovol wrote:
Now when udc-core supports binding to specific UDC by passing
its name via 'udc_name' member of usb_gadget_driver struct,
switch to this generic approach.
Tested-by: Maxime Ripard maxime.rip...@free-electrons.com
Signed-off-by: Ruslan Bilovol ruslan.bilo...@gmail.com
---
drivers/usb/gadget/configfs.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index c42765b..efad021 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -54,7 +54,6 @@ struct gadget_info {
struct list_head string_list;
struct list_head available_func;
- const char *udc_name;
#ifdef CONFIG_USB_OTG
struct usb_otg_descriptor otg;
#endif
@@ -230,21 +229,21 @@ static ssize_t gadget_dev_desc_bcdUSB_store(struct
gadget_info *gi,
static ssize_t gadget_dev_desc_UDC_show(struct gadget_info *gi, char
*page)
{
- return sprintf(page, %s\n, gi-udc_name ?: );
+ return sprintf(page, %s\n, gi-composite.gadget_driver.udc_name
?: );
}
static int unregister_gadget(struct gadget_info *gi)
{
int ret;
- if (!gi-udc_name)
+ if (!gi-composite.gadget_driver.udc_name)
return -ENODEV;
ret = usb_gadget_unregister_driver(gi-composite.gadget_driver);
if (ret)
return ret;
- kfree(gi-udc_name);
- gi-udc_name = NULL;
+ kfree(gi-composite.gadget_driver.udc_name);
+ gi-composite.gadget_driver.udc_name = NULL;
return 0;
}
@@ -267,14 +266,16 @@ static ssize_t gadget_dev_desc_UDC_store(struct
gadget_info *gi,
if (ret)
goto err;
} else {
- if (gi-udc_name) {
+ if (gi-composite.gadget_driver.udc_name) {
You are using this very long if condition in a few places, maybe it would be
more suitable to define a macro or inline function for this? Something like
gadget_dev_bound() or gadget_dev_is_active() or some other more suitable
name.
Yes, it makes sense, since there are 11 places where this long access
to udc_name is used.
However, it is used not only in if conditions but also for changing
udc_name, so need to add some getters/setters, something like
#define gi_to_udc_name(gi)
((gi)-composite.gadget_driver.udc_name)
#define gi_set_udc_name(gi,name)
((gi)-composite.gadget_driver.udc_name = (name))
Best regards,
Ruslan
--
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] hwmon: (dell-smm-hwon) Use a valid name attribute
On 06/27/2015 06:22 AM, Gabriele Mazzotta wrote: As per Documentation/hwmon/sysfs-interface, hwmon name attributes must not include '-', so replace 'dell-smm' with 'dell_smm'. Fixes: 039ae58503f3 (hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k) Signed-off-by: Gabriele Mazzotta gabriele@gmail.com Applied. Pali, would be great if you can send me an Acked-by: before I send the pull request to Linus. 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/
Re: [PATCH v7] dma: Add Xilinx AXI Direct Memory Access Engine driver support
On Sat, Jun 27, 2015 at 5:40 PM, Vinod Koul vinod.k...@intel.com wrote: [...] Please let me know if you are not clear. No sorry am not... I asked how the device address in configured. For both MM2S S2MM you are using sg for memory address, where are you getting device adress, are you assuming/hardcoding or getting somehow, if so how? As the name says, one end is memory (MM) and the other end is an AXI4 Stream Bus (S) which has no concept of memory address. So yes, it is hardcoded at design time. -- 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: lockdep issue booting v4.1 upstream kernel with 64 x86_64 CPUs
On Sat, Jun 27, 2015 at 03:32:40AM -0700, Michel Lespinasse wrote: Yes, tried this successfully both with 64 and 64 CPUs, this does get rid of the lockdep warning for me. Thanks, I'll add your Tested-by to the patch. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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] timer: Fix unsafe cpu variable access in migrate_timers
On Sat, Jun 27, 2015 at 11:55:49AM +0200, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com migrate_timers is invoked with preemption enabled. Therefore we have to get/put the cpu-local variable tvec_bases like before commit 0eeda71bc3. This fixes BUG: using smp_processor_id() in preemptible [] code: bash/4917 caller is debug_smp_processor_id+0x17/0x19 CPU: 0 PID: 4917 Comm: bash Not tainted 4.1.0-dbg+ #97 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014 880038674040 880002e6fb98 815356a0 0002 880002e6fbc8 8130c16f 88003fd8d500 d500 0003 880002e6fbd8 Call Trace: [815356a0] dump_stack+0x4f/0x7b [8130c16f] check_preemption_disabled+0xdd/0xef [8130c198] debug_smp_processor_id+0x17/0x19 [810a9b37] timer_cpu_notify+0x4f/0x112 [8106718b] notifier_call_chain+0x4c/0x71 [810671be] __raw_notifier_call_chain+0xe/0x10 [810484b6] __cpu_notify+0x20/0x37 [810484e0] cpu_notify+0x13/0x15 [81048591] cpu_notify_nofail+0xe/0x16 [8152efb2] _cpu_down+0x178/0x268 [8108bc3a] ? trace_hardirqs_on+0xd/0xf [8152f0ca] cpu_down+0x28/0x3c [813cbdb9] cpu_subsys_offline+0x14/0x16 [813c779d] device_offline+0x7d/0xb1 [813c78a2] online_store+0x48/0x68 [813c5544] dev_attr_store+0x18/0x22 [811dac6c] sysfs_kf_write+0x49/0x51 [811da139] kernfs_fop_write+0x105/0x158 [8116c54f] __vfs_write+0x28/0xbd [812ab014] ? security_file_permission+0x23/0x90 [8116ccb2] vfs_write+0xb2/0x169 [8116d717] SyS_write+0x4a/0x91 [8153d12e] entry_SYSCALL_64_fastpath+0x12/0x76 triggered when offlining a CPU, e.g. via sysfs. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- kernel/time/timer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 520499d..c826178 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1566,7 +1566,7 @@ static void migrate_timers(int cpu) BUG_ON(cpu_online(cpu)); old_base = per_cpu_ptr(tvec_bases, cpu); - new_base = this_cpu_ptr(tvec_bases); + new_base = get_cpu_var(tvec_bases); Hmm, tglx's version doesn't disable preemtion around it: http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/urgentid=24bfcb100959c8641a627b5604d967243f8f240c -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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: [all better] Re: regression: massive trouble with fpu rework
On Sat, 2015-06-27 at 11:37 +0200, Borislav Petkov wrote: On Sat, Jun 27, 2015 at 10:55:28AM +0200, Mike Galbraith wrote: Yup, that made it not care about the BIOS setting.. again. Does it say x86/fpu: Legacy x87 FPU detected. with Ingo's patch? Nope. Or do you see that x86/fpu: Enabled xstate features... print out from the end of fpu__init_system_xstate()? [0.00] x86/fpu: xstate_offset[2]: 0240, xstate_sizes[2]: 0100 [0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers' [0.00] x86/fpu: Enabled xstate features 0x7, context size is 0x340 bytes, using 'standard' format. [0.00] x86/fpu: Using 'eager' FPU context switches. -- 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] timer: Fix unsafe cpu variable access in migrate_timers
On 2015-06-27 13:00, Borislav Petkov wrote: On Sat, Jun 27, 2015 at 11:55:49AM +0200, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com migrate_timers is invoked with preemption enabled. Therefore we have to get/put the cpu-local variable tvec_bases like before commit 0eeda71bc3. This fixes BUG: using smp_processor_id() in preemptible [] code: bash/4917 caller is debug_smp_processor_id+0x17/0x19 CPU: 0 PID: 4917 Comm: bash Not tainted 4.1.0-dbg+ #97 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014 880038674040 880002e6fb98 815356a0 0002 880002e6fbc8 8130c16f 88003fd8d500 d500 0003 880002e6fbd8 Call Trace: [815356a0] dump_stack+0x4f/0x7b [8130c16f] check_preemption_disabled+0xdd/0xef [8130c198] debug_smp_processor_id+0x17/0x19 [810a9b37] timer_cpu_notify+0x4f/0x112 [8106718b] notifier_call_chain+0x4c/0x71 [810671be] __raw_notifier_call_chain+0xe/0x10 [810484b6] __cpu_notify+0x20/0x37 [810484e0] cpu_notify+0x13/0x15 [81048591] cpu_notify_nofail+0xe/0x16 [8152efb2] _cpu_down+0x178/0x268 [8108bc3a] ? trace_hardirqs_on+0xd/0xf [8152f0ca] cpu_down+0x28/0x3c [813cbdb9] cpu_subsys_offline+0x14/0x16 [813c779d] device_offline+0x7d/0xb1 [813c78a2] online_store+0x48/0x68 [813c5544] dev_attr_store+0x18/0x22 [811dac6c] sysfs_kf_write+0x49/0x51 [811da139] kernfs_fop_write+0x105/0x158 [8116c54f] __vfs_write+0x28/0xbd [812ab014] ? security_file_permission+0x23/0x90 [8116ccb2] vfs_write+0xb2/0x169 [8116d717] SyS_write+0x4a/0x91 [8153d12e] entry_SYSCALL_64_fastpath+0x12/0x76 triggered when offlining a CPU, e.g. via sysfs. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- kernel/time/timer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 520499d..c826178 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1566,7 +1566,7 @@ static void migrate_timers(int cpu) BUG_ON(cpu_online(cpu)); old_base = per_cpu_ptr(tvec_bases, cpu); -new_base = this_cpu_ptr(tvec_bases); +new_base = get_cpu_var(tvec_bases); Hmm, tglx's version doesn't disable preemtion around it: http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/urgentid=24bfcb100959c8641a627b5604d967243f8f240c Oh, there is a fix already. It's just the same: both implicitly disable preemption via get_cpu_ptr/var, look at the macros. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k
Hi Pali, I've just noticed an issue with this patch. See the comment here below. Gabriele On Wednesday 29 April 2015 13:41:26 Pali Rohár wrote: This patch splits CONFIG_I8K compile option to SENSORS_DELL_SMM and CONFIG_I8K. Option SENSORS_DELL_SMM is now used to enable compilation of dell-smm-hwmon driver and old CONFIG_I8K option to enable /proc/i8k interface in driver. So this change allows to compile dell-smm-hwmon driver without legacy /proc/i8k interface which is needed only for old Dell Inspirion models or for userspace i8kutils package. For backward compatibility when CONFIG_I8K is enabled then also SENSORS_DELL_SMM is enabled and so driver dell-smm-hwmon (with /proc/i8k) is compiled. Signed-off-by: Pali Rohár pali.ro...@gmail.com --- arch/x86/Kconfig | 25 +++ drivers/hwmon/Kconfig | 11 +++ drivers/hwmon/Makefile |2 +- drivers/hwmon/dell-smm-hwmon.c | 150 ++-- 4 files changed, 106 insertions(+), 82 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 226d569..7b756b3 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1055,24 +1055,19 @@ config TOSHIBA Say N otherwise. config I8K - tristate Dell laptop support + tristate Dell i8k legacy laptop support select HWMON + select SENSORS_DELL_SMM ---help--- - This adds a driver to safely access the System Management Mode - of the CPU on the Dell Inspiron 8000. The System Management Mode - is used to read cpu temperature and cooling fan status and to - control the fans on the I8K portables. + This option enables legacy /proc/i8k userspace interface in hwmon + dell-smm-hwmon driver. Character file /proc/i8k reports bios version, + temperature and allows controlling fan speeds of Dell laptops via + System Management Mode. For old Dell laptops (like Dell Inspiron 8000) + it reports also power and hotkey status. For fan speed control is + needed userspace package i8kutils. - This driver has been tested only on the Inspiron 8000 but it may - also work with other Dell laptops. You can force loading on other - models by passing the parameter `force=1' to the module. Use at - your own risk. - - For information on utilities to make use of this driver see the - I8K Linux utilities web site at: - http://people.debian.org/~dz/i8k/ - - Say Y if you intend to run this kernel on a Dell Inspiron 8000. + Say Y if you intend to run this kernel on old Dell laptops or want to + use userspace package i8kutils. Say N otherwise. config X86_REBOOTFIXUPS diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 25d9e72..714f92a 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -371,6 +371,17 @@ config SENSORS_DS1621 This driver can also be built as a module. If so, the module will be called ds1621. +config SENSORS_DELL_SMM + tristate Dell laptop SMM BIOS hwmon driver + depends on X86 DMI + help + This hwmon driver adds support for reporting temperature of different + sensors and controls the fans on Dell laptops via System Management + Mode provided by Dell BIOS. + + When option I8K is also enabled this driver provides legacy /proc/i8k + userspace interface for i8kutils package. + config SENSORS_DA9052_ADC tristate Dialog DA9052/DA9053 ADC depends on PMIC_DA9052 diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 51533ac..6cacd0f 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -49,6 +49,7 @@ obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o obj-$(CONFIG_SENSORS_DA9055)+= da9055-hwmon.o +obj-$(CONFIG_SENSORS_DELL_SMM) += dell-smm-hwmon.o obj-$(CONFIG_SENSORS_DME1737)+= dme1737.o obj-$(CONFIG_SENSORS_DS620) += ds620.o obj-$(CONFIG_SENSORS_DS1621) += ds1621.o @@ -156,7 +157,6 @@ obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o obj-$(CONFIG_SENSORS_W83L786NG) += w83l786ng.o obj-$(CONFIG_SENSORS_WM831X) += wm831x-hwmon.o obj-$(CONFIG_SENSORS_WM8350) += wm8350-hwmon.o -obj-$(CONFIG_I8K)+= dell-smm-hwmon.o obj-$(CONFIG_PMBUS) += pmbus/ diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c index 65d314b..2a80882 100644 --- a/drivers/hwmon/dell-smm-hwmon.c +++ b/drivers/hwmon/dell-smm-hwmon.c @@ -81,7 +81,7 @@ static uint i8k_fan_max = I8K_FAN_HIGH; MODULE_AUTHOR(Massimo Dal Zotto (d...@debian.org)); MODULE_AUTHOR(Pali Rohár pali.ro...@gmail.com); -MODULE_DESCRIPTION(Driver for accessing SMM BIOS on Dell laptops); +MODULE_DESCRIPTION(Dell laptop SMM BIOS hwmon driver); MODULE_LICENSE(GPL);
[PATCH v2] bpf: Use correct #ifdef controller for trace_call_bpf()
Commit e1abf2cc8d5d80b41c4419368ec743ccadbb131e (bpf: Fix the build on BPF_SYSCALL=y !CONFIG_TRACING kernels, make it more configurable) updated the building condition of bpf_trace.o from CONFIG_BPF_SYSCALL to CONFIG_BPF_EVENTS, but the corresponding #ifdef controller in ftrace_event.h for trace_call_bpf() is not changed. Which, in theory, is incorrect. With current Kconfigs, we can create a .config with CONFIG_BPF_SYSCALL=y and CONFIG_BPF_EVENTS=n by unselecting CONFIG_KPROBE_EVENT and selecting CONFIG_BPF_SYSCALL. With these options, trace_call_bpf() will be defined as an extern function, but if anyone calls it a symbol missing error will be trigger since bpf_trace.o is not build. This patch changes the #ifdef controller for trace_call_bpf() from CONFIG_BPF_SYSCALL to CONFIG_BPF_EVENTS. I'll show its correctness: Before this patch: BPF_SYSCALL BPF_EVENTS trace_call_bpf bpf_trace.o y y normal compiled n n inline not compiled y n normal not compiled (incorrect) n y impossible (BPF_EVENTS depends on BPF_SYSCALL) After this patch: BPF_SYSCALL BPF_EVENTS trace_call_bpf bpf_trace.o y y normal compiled n n inline not compiled y n inline not compiled (fixed) n y impossible (BPF_EVENTS depends on BPF_SYSCALL) So this patch doesn't break thing. QED. Signed-off-by: Wang Nan wangn...@huawei.com --- v1 is incorrect: lost the 'S' in 'CONFIG_BPF_EVENTS'. Please ignore it. --- include/linux/ftrace_event.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h index f9ecf63..ec48c92 100644 --- a/include/linux/ftrace_event.h +++ b/include/linux/ftrace_event.h @@ -553,7 +553,7 @@ event_trigger_unlock_commit_regs(struct ftrace_event_file *file, event_triggers_post_call(file, tt); } -#ifdef CONFIG_BPF_SYSCALL +#ifdef CONFIG_BPF_EVENTS unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx); #else static inline unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx) -- 1.8.3.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/
[PATCH v2] x86/Kconfig.debug: make X86_VERBOSE_BOOTUP depends on EARLY_PRINTK
The X86_VERBOSE_BOOTUP enables informational output during the decompression stage with the earlyprintk. If CONFIG_EARLY_PRINTK is not set, there are no reasons to make CONFIG_X86_VERBOSE_BOOTUP possible for the configuration. Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- Changes since v1: * style fixes; --- arch/x86/Kconfig.debug | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index a15893d..71438bf 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -22,14 +22,6 @@ config STRICT_DEVMEM If in doubt, say Y. -config X86_VERBOSE_BOOTUP - bool Enable verbose x86 bootup info messages - default y - ---help--- - Enables the informational output from the decompression stage - (e.g. bzImage) of the boot. If you disable this you will still - see errors. Disable this if you want silent bootup. - config EARLY_PRINTK bool Early printk if EXPERT default y @@ -43,6 +35,15 @@ config EARLY_PRINTK with klogd/syslogd or the X server. You should normally N here, unless you want to debug such a crash. +config X86_VERBOSE_BOOTUP + bool Enable verbose x86 bootup info messages + default y + depends on EARLY_PRINTK + ---help--- + Enables the informational output from the decompression stage + (e.g. bzImage) of the boot. If you disable this you will still + see errors. Disable this if you want silent bootup. + config EARLY_PRINTK_DBGP bool Early printk via EHCI debug port depends on EARLY_PRINTK PCI -- 2.4.4.410.gc71d752 -- 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] platform: x86: Deletion of checks before backlight_device_unregister()
On Fri, Jun 26, 2015 at 04:06:55PM -0700, Darren Hart wrote: Julia, do you have any particular objection to this specific patch? I didn't see a reason to prevent it going in. I hate these patches... We're saying these functions have sanity checks so let's pass nonsense values to them, it's fine. It makes the code harder to understand. There is no way for a human being to remember the complete list of functions with sanity checks and which don't have sanity checks. Markus has introduced quite a few bugs as well (people have so far managed to catch his bugs before they were committed). He so far has resisted any suggestion that he should manually review his patches before sending them. Btw do have a scripts/coccinelle/free/ifnullfree.cocci which removes checks before kfree, debugfs_remove, debugfs_remove_recursive, and usb_free_urb. regards, dan carpenter -- 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: drm/mgag200: doesn't work in panic context
On Sat, Jun 27, 2015 at 03:52:56PM +0200, Daniel Vetter wrote: Hm, what do you mean by fixing this in the allocator? I've made some rough sketch of the problem space in http://www.x.org/wiki/DRMJanitors/ under Make panic handling work. Problem is that the folks which know what to do (drm hackers) have zero incentive to fix it (since if you blow up a drm driver any kind of fbcon panic handling is hopeless anyway). Ok, silly question: switching the GPU output to the simplest, supported-by-all-GPUs mode before panicking is not that easy too, right? Or does that mean, one needs to reinit GPU in order to even show something... Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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 2/2] dma: Add Xilinx AXI Central Direct Memory Access Engine driver support
On Wed, Jun 24, 2015 at 05:12:12PM +, Appana Durga Kedareswara Rao wrote:
Please *fix* you MUA to wrap lines properly
+
+ if (cfg-reset)
+ return xilinx_cdma_chan_reset(chan);
Why do you want to reset this externally, that sounds bad to me
If someone (client driver) want to reset the controller externally. It will
be useful right?
And why would they want to do that? There might be some other clients using
other channels, doesnt sound good design to me. What is the motivation
here...
+
+ if (cfg-coalesc = XILINX_CDMA_COALESCE_MAX) {
+ reg = ~XILINX_CDMA_XR_COALESCE_MASK;
+ reg |= cfg-coalesc XILINX_CDMA_COALESCE_SHIFT;
+ }
Can you explain what coalesc means here?
Coalesc means interrupt threshold
This value is used for setting the interrupt threshold. When IOC (interrupt
on complete) interrupt events occur, an internal counter
Counts down from the Interrupt Threshold setting. When the count reaches
zero, an interrupt out is generated by the DMA engine.
This will be useful in case of SG transfer.
IIUC, on IOC controller will count this threshold and then generate
interrupt out?
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any
attachments. Delete this email message and any attachments immediately.
Thats cute!
--
~Vinod
--
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/2] staging: wilc1000: Deletion of two unnecessary checks
From: Markus Elfring elfr...@users.sourceforge.net Further update suggestions were taken into account after a patch was applied from static source code analysis. Markus Elfring (2): Delete unnecessary checks before two function calls One function call less in mac_ioctl() after error detection drivers/staging/wilc1000/linux_wlan.c | 17 + 1 file changed, 5 insertions(+), 12 deletions(-) -- 2.4.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/
[PATCH 1/2] staging: wilc1000: Delete unnecessary checks before two function calls
From: Markus Elfring elfr...@users.sourceforge.net
Date: Sat, 27 Jun 2015 15:56:57 +0200
The functions kfree() and release_firmware() test whether their argument
is NULL and then return immediately.
Thus the test around the calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
---
drivers/staging/wilc1000/linux_wlan.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c
b/drivers/staging/wilc1000/linux_wlan.c
index b352c50..2aa8d9b 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -2421,11 +2421,7 @@ int mac_ioctl(struct net_device *ndev, struct ifreq
*req, int cmd)
}
done:
-
- if (buff != NULL) {
- kfree(buff);
- }
-
+ kfree(buff);
return s32Error;
}
@@ -2707,8 +2703,7 @@ static void __exit exit_wilc_driver(void)
}
}
-
- if ((g_linux_wlan != NULL) g_linux_wlan-wilc_firmware != NULL) {
+ if (g_linux_wlan) {
release_firmware(g_linux_wlan-wilc_firmware);
g_linux_wlan-wilc_firmware = NULL;
}
--
2.4.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: [RFC PATCH 1/3] perf probe: Init symbol as kprobe if any pev is kprobe
On 2015/6/27 16:30, Masami Hiramatsu wrote:
Hi Wang,
On 2015/06/27 16:34, Wangnan (F) wrote:
On 2015/6/27 15:29, Masami Hiramatsu wrote:
On 2015/06/25 19:37, Wang Nan wrote:
Before this patch, add_perf_probe_events() init symbol maps only for
uprobe if the first pev passed to it is a uprobe event. However, with
the incoming BPF uprobe support, now it will be possible to pass an
array with combined kprobe and uprobe events to add_perf_probe_events().
This description is not correct. Actually, add_perf_probe_events already
supports mix of uprobes and kprobes. However, from the command line syntax
constrains the first elements of the probe_event arrays must be kprobes.
So, if the array starts with uprobes, no kprobes should be there.
This patch check all pevs instead of the first one, and init kernel
symbol if any events is not uprobe.
Anyway, I prefer to call init_symbol_maps() with false :)
I also prefer false, so I try to find whether all events are uprobe
instead
of init_symbol_maps(true).
So for this patch only commit message needs to be corrected, the code is
no problem, right?
No, I meant you just need to change one line, as below.
- ret = init_symbol_maps(pevs-uprobes);
+ ret = init_symbol_maps(false);
That's enough, I don't like to introduce a bool flag and loop.
Thanks,
Then basic structure of kernel map will be build even if all probe
points are
uprobes. It costs some memory. But sure, we can skip the loop.
Will post an updated version.
Thank you.
Thank you.
Thank you,
Signed-off-by: Wang Nan wangn...@huawei.com
---
tools/perf/util/probe-event.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index b386d2f..a2b3026 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2802,8 +2802,21 @@ int cleanup_perf_probe_event(struct perf_probe_event
*pev)
int add_perf_probe_events(struct perf_probe_event *pevs, int npevs, bool
cleanup)
{
int i, ret;
+ bool user_only = true;
- ret = init_symbol_maps(pevs-uprobes);
+ /* If any pev is kprobe, init kernel symbols. */
+ for (i = 0; i npevs; i++) {
+ if (!pevs[i].uprobes) {
+ user_only = false;
+ break;
+ }
+ }
+
+ /*
+* Compiler can drop user_only:
+* ret = init_symbol_maps(i = npevs);
+*/
+ ret = init_symbol_maps(user_only);
if (ret 0)
return ret;
--
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] n_tty: signal and flush atomically
When handling signalling char, claim the termios write lock before
signalling waiting readers and writers to prevent further i/o
before flushing the echo and output buffers. This prevents a
userspace signal handler which may output from racing the terminal
flush.
Reference: Bugzilla #99351 (Output truncated in ssh session after...)
Fixes: commit d2b6f44779d3 (n_tty: Fix signal handling flushes)
Reported-by: Filipe Brandenburger filbran...@google.com
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
drivers/tty/n_tty.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index c9c27f6..ee8bfac 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1108,19 +1108,29 @@ static void eraser(unsigned char c, struct tty_struct
*tty)
* Locking: ctrl_lock
*/
-static void isig(int sig, struct tty_struct *tty)
+static void __isig(int sig, struct tty_struct *tty)
{
- struct n_tty_data *ldata = tty-disc_data;
struct pid *tty_pgrp = tty_get_pgrp(tty);
if (tty_pgrp) {
kill_pgrp(tty_pgrp, sig, 1);
put_pid(tty_pgrp);
}
+}
- if (!L_NOFLSH(tty)) {
+static void isig(int sig, struct tty_struct *tty)
+{
+ struct n_tty_data *ldata = tty-disc_data;
+
+ if (L_NOFLSH(tty)) {
+ /* signal only */
+ __isig(sig, tty);
+
+ } else { /* signal and flush */
up_read(tty-termios_rwsem);
down_write(tty-termios_rwsem);
+ __isig(sig, tty);
+
/* clear echo buffer */
mutex_lock(ldata-output_lock);
ldata-echo_head = ldata-echo_tail = 0;
--
2.4.5
--
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 2/2] hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k
On Saturday 27 June 2015 15:01:34 Pali Rohár wrote: On Saturday 27 June 2015 14:55:40 Gabriele Mazzotta wrote: On Saturday 27 June 2015 14:47:16 Pali Rohár wrote: On Saturday 27 June 2015 13:34:30 Gabriele Mazzotta wrote: Hi Pali, I've just noticed an issue with this patch. See the comment here below. Gabriele On Wednesday 29 April 2015 13:41:26 Pali Rohár wrote: @@ -750,8 +777,8 @@ static int __init i8k_init_hwmon(void) if (err = 0) i8k_hwmon_flags |= I8K_HWMON_HAVE_FAN2; - i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, i8k, NULL, - i8k_groups); + i8k_hwmon_dev = hwmon_device_register_with_groups(NULL, dell-smm, + NULL, i8k_groups); dell-smm is not a valid name, see hwmon_device_register_with_groups() for more info (dash not allowed). Because of this, the driver can't be loaded. How it is possible? It worked fine on my tested dell machine... And now I see, I probably tested this change with older kernel version (ubuntu/3.13) which did not have that check for invalid characters... Renaming dell-smm to dell_smm should fix this problem, right? Yes, everything works just fine with the underscore. Ok, will you send patch for this small fix? OK, I'll do it shortly. -- 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/
imx: apf27: the board no longer boot with latest git kernel
Hi all, I've tested the lastest linus git kernel, and this kernel no longer boot on my armadeus apf27. The last line of the log are (after, the kernel is stalled) : [0.00] CPU identified as i.MX27, silicon rev 2.1 [0.00] Switching to timer-based delay loop, resolution 60ns [0.24] sched_clock: 32 bits at 16MHz, resolution 60ns, wraps every 129171917793ns [0.008172] clocksource mxc_timer1: mask: 0x max_cycles: 0x, max_idle_ns: 114963006693 ns [0.020252] Console: colour dummy device 80x30 [0.024894] Calibrating delay loop (skipped), value calculated using timer frequency.. I've done a bisect and the commit that raise this issue is : db2ae4b4f6b79bd11d6461d41bd0966b0006f20b ARM: imx: provide gpt device specific irq functions Do you also reproduce this issue please ? or may be I've missed to enable an new option ? Regards, Philippe -- 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/4] x86/setup: introduce setup_bultin_cmdline
This patch introduces the setup_builtin_cmdline function which appends or
overrides boot_command_line with the builtin_cmdline if CONFIG_CMDLINE_BOOL
is set.
Previously this functional was in the setup_arch, but we need to move
it for getting actual command line as early as possible in the
arch/x86/kernel/head{32,64}.c for the earlyprintk setup.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
arch/x86/include/asm/setup.h | 2 +-
arch/x86/kernel/setup.c | 29 +
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 11af24e..70dfa61 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -124,8 +124,8 @@ asmlinkage void __init i386_start_kernel(void);
#else
asmlinkage void __init x86_64_start_kernel(char *real_mode);
asmlinkage void __init x86_64_start_reservations(char *real_mode_data);
-
#endif /* __i386__ */
+void __init setup_builtin_cmdline(void);
#endif /* _SETUP */
#else
#define RESERVE_BRK(name,sz) \
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d3b95b8..e528f12 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -847,6 +847,22 @@ dump_kernel_offset(struct notifier_block *self, unsigned
long v, void *p)
return 0;
}
+void __init setup_builtin_cmdline(void)
+{
+#ifdef CONFIG_CMDLINE_BOOL
+#ifdef CONFIG_CMDLINE_OVERRIDE
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+#else
+ if (builtin_cmdline[0]) {
+ /* append boot loader cmdline to builtin */
+ strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
+ strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+ }
+#endif
+#endif
+}
+
/*
* Determine if we were loaded by an EFI loader. If so, then we have also been
* passed the efi memmap, systab, etc., so we should use these data structures
@@ -975,2 +991,2 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = __pa_symbol(__bss_start);
bss_resource.end = __pa_symbol(__bss_stop)-1;
-#ifdef CONFIG_CMDLINE_BOOL
-#ifdef CONFIG_CMDLINE_OVERRIDE
- strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-#else
- if (builtin_cmdline[0]) {
- /* append boot loader cmdline to builtin */
- strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
- strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
- strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
- }
-#endif
-#endif
+ setup_builtin_cmdline();
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
--
2.4.4.410.gc71d752
--
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 v13 0/4] x86/earlyprintk: setup serial earlyprintk as early as possible
The early_printk function is usable only after the setup_early_printk will
be executed. We pass 'earlyprintk' through the kernel command line. So, it
means that earlyprintk will be usable only after the 'parse_early_param'
will be executed or in another words earlyprintk is usable only during early
boot, kernel decompression and after call of the parse_early_param. But
there are many stuff after the kernel decompression and before the
parse_early_param will be called as memblock usage, early cpu initialization,
early ioremap initialization and etc... So earlyprintk allows us to see
what's going on there.
Changelog:
v13:
* do not setup pciserial from the arch/x86/kernel/head{32,64}.c, because
it uses ioremap and we can't do it really early;
* style fixes;
* patch for testing.
v12:
* all changes from the v11 are reverted
* setup_early_serial_console renamed to the setup_earlyprintk_console and
refactored. Now it checks 'earlyprintk=' in the kernel command line, set
earlyprintk_late variable to false. This variable allows to know, do we
can setup early console for the certain device.
v11:
* setup_log_buf moved to the arch/x86/kernel/head{32,64.c} from
the arch/x86/kernel/setup.c to setup early log_buf for the earlyprintl
* Update log_buf in the early_printk function
* Added additional patch for testing earlyprintk
v10:
* Removed style issues which are not related to the patchset.
v9:
* Add call of the lockdep_init to the arch/x86/kernel/head{32,64}.c
before the serial console initialization to prevent:
[ 0.00] WARNING: lockdep init error! lock-(console_sem).lock was
acquiredbefore lockdep_init
[ 0.00] Call stack leading to lockdep invocation was:
[ 0.00] [] save_stack_trace+0x2f/0x50
[ 0.00] [] __lock_acquire+0xa2c/0xf00
[ 0.00] [] lock_acquire+0xdb/0x2b0
[ 0.00] [] _raw_spin_lock_irqsave+0x53/0x90
[ 0.00] [] down+0x16/0x50
[ 0.00] [] console_lock+0x19/0x60
[ 0.00] [] register_console+0x116/0x350
[ 0.00] [] setup_early_printk+0x165/0x467
[ 0.00] [] setup_early_serial_console+0x56/0x58
[ 0.00] [] x86_64_start_kernel+0xce/0x110
[ 0.00] [] 0x
[ 0.00]
during early serial console initialization.
* Add additional check to the earlyprintk initialization to protect double
initialization
of the early_serial_console.
* Fixed comment.
v8:
* Fixed warning with the definition of the setup_early_serial_console in the
arch/x86/include/asm/setup.h
v7:
* Move setup_early_serial_console to the the arch/x86/include/setup.h
* Add ifdefs to prevent setup_serial_console if CONFIG_EARLY_PRINTK is not
set.
v6:
* Style fixes.
* Call of the suetp_builtin_cmdline moved to the separate patch.
v5:
* Call setup_builtin_cmdline instead of setup_cmdline
v4:
* Move setup_early_serial_console from the include/linux/printk.h to the
arch/x86/include/asm/serial.h, because this function is only for x86 now.
v3:
* Call setup_cmdline before setup_early_printk;
* setup_early_printk call wrapped with the setup_early_serial_console which
checks that 'serial' given to the earlyprintk command line option. This prevents
call of the setup_early_printk with the given pciserial/dbgp/efi, because they
are using early_ioremap.
v2:
* Comment added before the setup_early_printk call;
* Added information about testing to the commit message.
Alexander Kuleshov (4):
x86/setup: introduce setup_bultin_cmdline
x86/setup: handle builtin command line as early as possible
x86/earlyprintk: setup earlyprintk as early as possible
x86/earlyprintk: add some early_printk for tests
arch/x86/include/asm/setup.h | 8 +++-
arch/x86/kernel/early_printk.c | 42 +++---
arch/x86/kernel/head32.c | 9 +
arch/x86/kernel/head64.c | 8
arch/x86/kernel/setup.c| 30 +-
init/main.c| 2 ++
6 files changed, 78 insertions(+), 21 deletions(-)
--
2.4.4.410.gc71d752
--
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/4 v13] x86/setup: introduce setup_bultin_cmdline
This patch introduces the setup_builtin_cmdline function which appends or
overrides boot_command_line with the builtin_cmdline if CONFIG_CMDLINE_BOOL
is set.
Previously this functional was in the setup_arch, but we need to move
it for getting actual command line as early as possible in the
arch/x86/kernel/head{32,64}.c for the earlyprintk setup.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
arch/x86/include/asm/setup.h | 2 +-
arch/x86/kernel/setup.c | 29 +
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 11af24e..70dfa61 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -124,8 +124,8 @@ asmlinkage void __init i386_start_kernel(void);
#else
asmlinkage void __init x86_64_start_kernel(char *real_mode);
asmlinkage void __init x86_64_start_reservations(char *real_mode_data);
-
#endif /* __i386__ */
+void __init setup_builtin_cmdline(void);
#endif /* _SETUP */
#else
#define RESERVE_BRK(name,sz) \
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d3b95b8..e528f12 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -847,6 +847,22 @@ dump_kernel_offset(struct notifier_block *self, unsigned
long v, void *p)
return 0;
}
+void __init setup_builtin_cmdline(void)
+{
+#ifdef CONFIG_CMDLINE_BOOL
+#ifdef CONFIG_CMDLINE_OVERRIDE
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+#else
+ if (builtin_cmdline[0]) {
+ /* append boot loader cmdline to builtin */
+ strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
+ strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+ }
+#endif
+#endif
+}
+
/*
* Determine if we were loaded by an EFI loader. If so, then we have also been
* passed the efi memmap, systab, etc., so we should use these data structures
@@ -975,2 +991,2 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = __pa_symbol(__bss_start);
bss_resource.end = __pa_symbol(__bss_stop)-1;
-#ifdef CONFIG_CMDLINE_BOOL
-#ifdef CONFIG_CMDLINE_OVERRIDE
- strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-#else
- if (builtin_cmdline[0]) {
- /* append boot loader cmdline to builtin */
- strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
- strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
- strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
- }
-#endif
-#endif
+ setup_builtin_cmdline();
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
--
2.4.4.410.gc71d752
--
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: drm/mgag200: doesn't work in panic context
On Fri, Jun 26, 2015 at 8:30 PM, Luck, Tony tony.l...@intel.com wrote: I'm here to report two panics which hang forever (the machine cannot reboot). It is because mgag200 doesn't work in panic context. It sleeps and allocates memory non-atomically. This is the same for all drm drivers, the drm atomic handling with fbcon/fbdev is totally broken. It would be serious work to fix this properly. It's a serious problem when a server crashes ... even worse when it hangs while doing so because we have to rely on some other agent to notice the hung server and go poke it with a stick. If it is too hard to fix all of the drivers, is it possible to attack this in the allocator? Hm, what do you mean by fixing this in the allocator? I've made some rough sketch of the problem space in http://www.x.org/wiki/DRMJanitors/ under Make panic handling work. Problem is that the folks which know what to do (drm hackers) have zero incentive to fix it (since if you blow up a drm driver any kind of fbcon panic handling is hopeless anyway). The other problem is is that this is a serious effort with tons of little things all over to consider. My gut estimate is that probably it'll take something of the order of a man year to fix this for real. David Herrmann has supplied parts of the required puzzle to actually be able to somewhat reliably show panics on drm modesetting drivers, but that didn't contain any of the work to make fbdev not totally suck at panic handling first. And I guess for general distros and servers that's needed - developers simply disable all of fbdev to be able to debug kms hangs. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: imx: apf27: the board no longer boot with latest git kernel
Hi Fabio, On 27/06/15 19:05, Fabio Estevam wrote: Hi Philippe, On Sat, Jun 27, 2015 at 10:21 AM, Philippe Reynestrem...@gmail.com wrote: Hi all, I've tested the lastest linus git kernel, and this kernel no longer boot on my armadeus apf27. The last line of the log are (after, the kernel is stalled) : [0.00] CPU identified as i.MX27, silicon rev 2.1 [0.00] Switching to timer-based delay loop, resolution 60ns [0.24] sched_clock: 32 bits at 16MHz, resolution 60ns, wraps every 129171917793ns [0.008172] clocksource mxc_timer1: mask: 0x max_cycles: 0x, max_idle_ns: 114963006693 ns [0.020252] Console: colour dummy device 80x30 [0.024894] Calibrating delay loop (skipped), value calculated using timer frequency.. I've done a bisect and the commit that raise this issue is : db2ae4b4f6b79bd11d6461d41bd0966b0006f20b ARM: imx: provide gpt device specific irq functions Do you also reproduce this issue please ? or may be I've missed to enable an new option ? I don't have access to a mx27 board at the moment, but I am wondering if the change below would fix the problem: I've got one, and I can do the test. --- a/drivers/clocksource/timer-imx-gpt.c +++ b/drivers/clocksource/timer-imx-gpt.c @@ -528,6 +528,7 @@ static void __init imx6dl_timer_init_dt(struct device_node * } CLOCKSOURCE_OF_DECLARE(imx1_timer, fsl,imx1-gpt, imx1_timer_init_dt); +CLOCKSOURCE_OF_DECLARE(imx27_timer, fsl,imx27-gpt, imx1_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx21_timer, fsl,imx21-gpt, imx21_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx31_timer, fsl,imx31-gpt, imx31_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx25_timer, fsl,imx25-gpt, imx31_timer_init_dt); I've looked the code in drivers/clocksource/timer-imx-gpt.c, in the definition of imx_gpt_type, there is : GPT_TYPE_IMX21, /* i.MX21/27 */ So I've done a little change in your patch, I've used imx21_timer_init_dt for imx27 : --- a/drivers/clocksource/timer-imx-gpt.c +++ b/drivers/clocksource/timer-imx-gpt.c @@ -529,6 +529,7 @@ static void __init imx6dl_timer_init_dt(struct device_node *np) CLOCKSOURCE_OF_DECLARE(imx1_timer, fsl,imx1-gpt, imx1_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx21_timer, fsl,imx21-gpt, imx21_timer_init_dt); +CLOCKSOURCE_OF_DECLARE(imx27_timer, fsl,imx27-gpt, imx21_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx31_timer, fsl,imx31-gpt, imx31_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx25_timer, fsl,imx25-gpt, imx31_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx50_timer, fsl,imx50-gpt, imx31_timer_init_dt); I've tested it, and it works fine, now my apf27 (imx27) boot without any issue. So good catch, thanks a lot for this patch. I may send a patch on lkml if you want. Regards, Fabio Estevam Regards, Philippe -- 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: imx: apf27: the board no longer boot with latest git kernel
On Sat, Jun 27, 2015 at 2:26 PM, Philippe Reynes trem...@gmail.com wrote: I've looked the code in drivers/clocksource/timer-imx-gpt.c, in the definition of imx_gpt_type, there is : GPT_TYPE_IMX21, /* i.MX21/27 */ So I've done a little change in your patch, I've used imx21_timer_init_dt for imx27 : --- a/drivers/clocksource/timer-imx-gpt.c +++ b/drivers/clocksource/timer-imx-gpt.c @@ -529,6 +529,7 @@ static void __init imx6dl_timer_init_dt(struct device_node *np) CLOCKSOURCE_OF_DECLARE(imx1_timer, fsl,imx1-gpt, imx1_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx21_timer, fsl,imx21-gpt, imx21_timer_init_dt); +CLOCKSOURCE_OF_DECLARE(imx27_timer, fsl,imx27-gpt, imx21_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx31_timer, fsl,imx31-gpt, imx31_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx25_timer, fsl,imx25-gpt, imx31_timer_init_dt); CLOCKSOURCE_OF_DECLARE(imx50_timer, fsl,imx50-gpt, imx31_timer_init_dt); I've tested it, and it works fine, now my apf27 (imx27) boot without any issue. So good catch, thanks a lot for this patch. Excellent :-) I may send a patch on lkml if you want. Yes, please submit a formal patch. I thought it was imx1_timer_init_dt because in imx27.dtsi we have: compatible = fsl,imx27-gpt, fsl,imx1-gpt; So I am wondering if this is correct or it should be compatible = fsl,imx27-gpt, fsl,imx21-gpt; instead? Regards, Fabio Estevam -- 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] bdi: Remove inline keyword from exported I_BDEV() implementation
On 06/26/2015 05:58 AM, Geert Uytterhoeven wrote: With gcc 3.4.6/4.1.2/4.2.4 (not with 4.4.7/4.6.4/4.8.4): CC fs/block_dev.o include/linux/fs.h:804: warning: ‘I_BDEV’ declared inline after being called include/linux/fs.h:804: warning: previous declaration of ‘I_BDEV’ was here Commit a212b105b07d75b4 (bdi: make inode_to_bdi() inline) added a caller of I_BDEV() in a header file, exposing the bogus inline on the exported implementation. Drop the inline keyword to fix this. Added, thanks. -- Jens Axboe -- 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: [GIT PULL] Block driver pull request for 4.2
On 06/26/2015 03:20 PM, Davidlohr Bueso wrote: On Thu, 2015-06-25 at 08:37 -0600, Jens Axboe wrote: - Code consolidation and cleanups from Christoph. Andrew, it seems your fix for gcc never went in. I am hitting it in Linus' tree. https://urldefense.proofpoint.com/v1/url?u=http://www.spinics.net/lists/mm-commits/msg111293.htmlk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=3JMVyziIyZtZ5cv9eWNLwQ%3D%3D%0Am=%2Bik4Oo0rVdzlSM1PjOl%2BTRY22oM%2Bk3eJbVGPs9yYnks%3D%0As=73fcc4527d5299d9bbfa3a09663b2ae753b2a4712a5f4f312e52364a33cdc80a Not sure why Andrew hasn't sent it in yet. Andrew, you planning on doing that, I did see it get queued up? If not, I can funnel it through my tree for 4.2. -- Jens Axboe -- 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: fix bogus EFAULT error from SG_IO ioctl
On 06/26/2015 03:44 AM, Paolo Bonzini wrote: Whenever blk_fill_sghdr_rq fails, its errno code is ignored and changed to EFAULT. This can cause very confusing errors: $ sg_persist -k /dev/sda persistent reservation in: pass through os error: Bad address The fix is trivial, just propagate the return value from blk_fill_sghdr_rq. Added, thanks. -- Jens Axboe -- 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: [GIT PULL] (xen) stable/for-jens-4.2
On 06/23/2015 06:33 PM, Konrad Rzeszutek Wilk wrote: Hey Jens, Please git pull the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-4.2 in your 'for-4.2/drivers' branch. It is late - for which I am terrible sorry! The patches have been sitting in my branch for two weeks - except the last patch which was a fix and is now part of the branch. Please git pull at your convience. Pulled, thanks. But really, should be sent in before the last -rc of the previous window... Thankfully this isn't that large. -- Jens Axboe -- 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: drm/mgag200: doesn't work in panic context
On Sat, Jun 27, 2015 at 4:12 PM, Borislav Petkov b...@alien8.de wrote: On Sat, Jun 27, 2015 at 03:52:56PM +0200, Daniel Vetter wrote: Hm, what do you mean by fixing this in the allocator? I've made some rough sketch of the problem space in http://www.x.org/wiki/DRMJanitors/ under Make panic handling work. Problem is that the folks which know what to do (drm hackers) have zero incentive to fix it (since if you blow up a drm driver any kind of fbcon panic handling is hopeless anyway). Ok, silly question: switching the GPU output to the simplest, supported-by-all-GPUs mode before panicking is not that easy too, right? Anything that resembles doing a modeset (and the precise mode is totally irrelevant) will be almost impossible: There's clocks to tune, various links to train, a bunch of sidebind communication and all that takes time, needs to happen in a very precise order and also needs lots of mutexes (crossing subsystems sometimes even) to avoid trampling on maybe the thread that just died and caused the panic. In short you need specially-written codepaths for panic, which means only the most minimal thing has a chance to even work. fbdev/fbcon and the current drm panic handler are anything but that. Doing a full modeset isn't it either. Heck even the just updating the displayed buffer might need massive reconfiguration of the memory fetch watermarks if e.g. the screen is display high bpc yuv and you want to display the rgb fbcon buffer. And if you'd just try to take what's currently being displayed there's the annoying problem that often providing a cpu-contiguous view of that needs a vmalloc area, if not first moving the buffer around a bit in vram with the copy engine. That all involves lots of really complex code. Or does that mean, one needs to reinit GPU in order to even show something... If the gpu is runtime suspended, then yes you'd get to even init the entire thing first before you can display anything. fbdev panic handling was designed for a world where you'd bash a few values into a few registers and never wait for the CRTC to reach stable timings and output a useful signal. Which could all happen very much after the kernel made it's dying sigh. Display hw has long stopped being this simple and display drivers also. The only vestige is that we still call the display pipeline object in drm CRTC for cathode ray tube controller ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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/
f_op-read seems to be always NULL since Linux 4.1
Hello!
Given is a module like the following snippet running fine w/ Linux 4.0
and ext4 fs - but doesn't work w/ Linux 4.1 because f-f_op-read is not
defined any more (= NULL). Is this the intended behavior now?
vfs_read(f, buf, 128, f-f_pos) works fine.
module.c
#include linux/module.h
#include linux/kernel.h
#include linux/fs.h
#include asm/uaccess.h
int init_module(void)
{
struct file *f;
char buf[128];
mm_segment_t fs;
int i;
int len=128;
for(i=0;ilen;i++)
buf[i] = 0;
printk(KERN_INFO My module is loaded\n);
f = filp_open(/etc/fedora-release, O_RDONLY, 0);
if(f == NULL)
printk(KERN_ALERT filp_open error!!.\n);
else{
fs = get_fs();
set_fs(get_ds());
if (f-f_op-read) {
f-f_op-read(f, buf, len, f-f_pos);
printk(KERN_INFO buf:%s\n,buf);
}
else {
printk(KERN_INFO No read method\n);
}
set_fs(fs);
}
filp_close(f,NULL);
return 0;
}
void cleanup_module(void)
{
printk(KERN_INFO My module is unloaded\n);
}
---
Makefile:
---
obj-m += module.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
Regards,
Andreas
--
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: platform: x86: Deletion of checks before backlight_device_unregister()
There is no way for a human being to remember the complete list of functions with sanity checks and which don't have sanity checks. I understand also this software development challenge. Markus has introduced quite a few bugs as well I have only found other opinions about specific update suggestions. Which of such bugs are real mistakes? Are you looking for a better consensus? (people have so far managed to catch his bugs before they were committed). Would you like to refer to any concrete software developers? He so far has resisted any suggestion that he should manually review his patches before sending them. I am performing source code review to some degree. My approach does partly not fit to your expectations. Regards, Markus -- 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: f_op-read seems to be always NULL since Linux 4.1
On Sat, Jun 27, 2015 at 7:32 PM, Andreas Hartmann andihartm...@01019freenet.de wrote: Hello! Given is a module like the following snippet running fine w/ Linux 4.0 and ext4 fs - but doesn't work w/ Linux 4.1 because f-f_op-read is not defined any more (= NULL). Is this the intended behavior now? See __vfs_read(). Your module most not rely on such internals. -- Thanks, //richard -- 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/4] x86/setup: introduce setup_bultin_cmdline
On Sat, Jun 27, 2015 at 4:54 PM, Alexander Kuleshov
kuleshovm...@gmail.com wrote:
sorry, forgot to add version to this patch, please skip this patch.
You may, for example, supply --subject-prefix=PATCH v13 to git
format-patch command to create a nice version token.
One comment below.
2015-06-27 19:46 GMT+06:00 Alexander Kuleshov kuleshovm...@gmail.com:
This patch introduces the setup_builtin_cmdline function which appends or
overrides boot_command_line with the builtin_cmdline if CONFIG_CMDLINE_BOOL
is set.
Previously this functional was in the setup_arch, but we need to move
it for getting actual command line as early as possible in the
arch/x86/kernel/head{32,64}.c for the earlyprintk setup.
I already once wrote you that commit message is not reflecting the
contents of the patch. Please, align, i.e. remove second paragraph and
add a line that there is no functional change.
Please, read carefully what others comment.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
arch/x86/include/asm/setup.h | 2 +-
arch/x86/kernel/setup.c | 29 +
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 11af24e..70dfa61 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -124,8 +124,8 @@ asmlinkage void __init i386_start_kernel(void);
#else
asmlinkage void __init x86_64_start_kernel(char *real_mode);
asmlinkage void __init x86_64_start_reservations(char *real_mode_data);
-
#endif /* __i386__ */
+void __init setup_builtin_cmdline(void);
#endif /* _SETUP */
#else
#define RESERVE_BRK(name,sz) \
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d3b95b8..e528f12 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -847,6 +847,22 @@ dump_kernel_offset(struct notifier_block *self,
unsigned long v, void *p)
return 0;
}
+void __init setup_builtin_cmdline(void)
+{
+#ifdef CONFIG_CMDLINE_BOOL
+#ifdef CONFIG_CMDLINE_OVERRIDE
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+#else
+ if (builtin_cmdline[0]) {
+ /* append boot loader cmdline to builtin */
+ strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
+ strlcat(builtin_cmdline, boot_command_line,
COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, builtin_cmdline,
COMMAND_LINE_SIZE);
+ }
+#endif
+#endif
+}
+
/*
* Determine if we were loaded by an EFI loader. If so, then we have also
been
* passed the efi memmap, systab, etc., so we should use these data
structures
@@ -975,2 +991,2 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = __pa_symbol(__bss_start);
bss_resource.end = __pa_symbol(__bss_stop)-1;
-#ifdef CONFIG_CMDLINE_BOOL
-#ifdef CONFIG_CMDLINE_OVERRIDE
- strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-#else
- if (builtin_cmdline[0]) {
- /* append boot loader cmdline to builtin */
- strlcat(builtin_cmdline, , COMMAND_LINE_SIZE);
- strlcat(builtin_cmdline, boot_command_line,
COMMAND_LINE_SIZE);
- strlcpy(boot_command_line, builtin_cmdline,
COMMAND_LINE_SIZE);
- }
-#endif
-#endif
+ setup_builtin_cmdline();
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
--
2.4.4.410.gc71d752
--
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/
--
With Best Regards,
Andy Shevchenko
--
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] x86: PCI-Calgary: Deletion of an unnecessary check before the function call free_tce_table
From: Markus Elfring elfr...@users.sourceforge.net
Date: Sat, 22 Nov 2014 12:55:28 +0100
The free_tce_table() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
Looks good to me
Acked-by: Jon Mason jdma...@kudzu.us
---
arch/x86/kernel/pci-calgary_64.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kernel/pci-calgary_64.c
b/arch/x86/kernel/pci-calgary_64.c
index 0497f71..d22a386 100644
--- a/arch/x86/kernel/pci-calgary_64.c
+++ b/arch/x86/kernel/pci-calgary_64.c
@@ -1476,8 +1476,7 @@ cleanup:
for (--bus; bus = 0; --bus) {
struct calgary_bus_info *info = bus_info[bus];
- if (info-tce_space)
- free_tce_table(info-tce_space);
+ free_tce_table(info-tce_space);
}
return -ENOMEM;
}
--
2.1.3
Do the chances increase to integrate this update suggestion
into another source code repository?
Regards,
Markus
--
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 4.1 00/11] 4.1.1-stable review
On Fri, Jun 26, 2015 at 11:07:11PM -0700, Guenter Roeck wrote: On 06/26/2015 06:09 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.1.1 release. There are 11 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon Jun 29 01:08:53 UTC 2015. Anything received after that time might be too late. Build results: total: 124 pass: 124 fail: 0 Qemu test results: total: 31 pass: 31 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Yeah, I didn't break anything! thanks for reporting all of these for all 4 trees, much appreciated. 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/
