Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
>>> Vladimir 'φ-coder/phcoder' Serbinenko 10/23/13 7:02 PM >>> >>> >> GrUB - which iiuc stays in memory >> after transferring control - could export its file system support to its >> descendants). > >Xen shouldn't need to load any file after multiboot2 entry point. The >needed files would already be in memory with pointers to them passed. I should have said "to its chainloaded descendants". >If you insist on being able to load directly from EFI, then IMO the best >way is to have a PE executable with one of sections containing Xen and >code which would load remaining files to memory and call common entry point. I think you've been told before - this is what has been working already for quite some time. Jan -- 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: Deadlock in BPF JIT functions when running upowerd?
On Wed, Oct 23, 2013 at 11:25:13PM -0700, Eric Dumazet wrote: > On Wed, 2013-10-23 at 18:17 -0700, Darrick J. Wong wrote: > > Hi, > > > > I've been observing a softlockup with 3.11.6 and 3.12-rc6. It looks like > > there's a deadlock occurring on purge_lock in __purge_vmap_area_lazy(). In > > short, the BPF JIT code has been changed[1] to call set_memory_r[ow]() when > > compiling and freeing JIT bytecode memory. It seems that it's possible for > > upowerd to be compiling some BPF program and call __purge_vmap_area_lazy, > > then > > the timer interrupt comes in (due to the IPI?) and a softirq calls > > bpf_jit_free, which also calls __purge_vmap_area_lazy. > > > > I'm not really sure who's at fault here--is this a BPF bug? > > > > [1] 314beb9bcabfd6b4542ccbced2402af2c6f6142a > > "x86: bpf_jit_comp: secure bpf jit against spraying attacks" > > > > --D > > > > Here's what 3.11.6 spits out; the 3.12-rc6 message has the same traceback. > > > > [ 52.370437] BUG: soft lockup - CPU#3 stuck for 22s! [upowerd:8359] > > [ 52.370440] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat_ipv4 > > xt_conntrack xt_CHECKSUM iptable_mangle fuse tun microcode nfsd nfs_acl > > exportfs auth_rpcgss nfs lockd sunrpc af_packet xt_physdev xt_hl ip6t_rt > > nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT xt_sctp xt_limit xt_tcpudp > > xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ip6table_filter > > ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat > > nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables > > sch_fq_codel bridge stp llc lpc_ich mfd_core loop bcache dm_crypt > > zlib_deflate libcrc32c firewire_ohci firewire_core usb_storage mpt2sas > > scsi_transport_sas raid_class > > [ 52.370471] CPU: 3 PID: 8359 Comm: upowerd Not tainted 3.11.6-60-flax #1 > > [ 52.370472] Hardware name: OEM OEM/131-GT-E767, BIOS 6.00 PG 08/25/2011 > > [ 52.370474] task: 8806621f9700 ti: 88064b6a task.ti: > > 88064b6a > > [ 52.370475] RIP: 0010:[] [] > > _raw_spin_lock+0x32/0x40 > > [ 52.370480] RSP: 0018:88067fc63c10 EFLAGS: 0297 > > [ 52.370481] RAX: 0061 RBX: 88065a318600 RCX: > > > > [ 52.370483] RDX: 0062 RSI: 88067fc63ce0 RDI: > > 81ea42bc > > [ 52.370484] RBP: 88067fc63c10 R08: 81cdd608 R09: > > > > [ 52.370485] R10: 88067fc6d8e0 R11: R12: > > 88067fc63b88 > > [ 52.370486] R13: 816b7a47 R14: 88067fc63c10 R15: > > 88067fc63cd8 > > [ 52.370487] FS: 7f55fff297c0() GS:88067fc6() > > knlGS: > > [ 52.370488] CS: 0010 DS: ES: CR0: 80050033 > > [ 52.370489] CR2: 7f55fff47000 CR3: 00065dd1 CR4: > > 07e0 > > [ 52.370490] Stack: > > [ 52.370491] 88067fc63cb0 811955fd 0096 > > 0347 > > [ 52.370494] 03c1 0001 > > > > [ 52.370496] 0033 88067fc63c58 88067fc63c58 > > 0001 > > [ 52.370499] Call Trace: > > [ 52.370500] > > [ 52.370501] [] __purge_vmap_area_lazy+0x12d/0x4c0 > > [ 52.370507] [] vm_unmap_aliases+0x17c/0x190 > > [ 52.370512] [] change_page_attr_set_clr+0xb4/0x4a0 > > [ 52.370516] [] ? irq_exit+0x7e/0xb0 > > [ 52.370519] [] ? smp_irq_work_interrupt+0x34/0x40 > > [ 52.370522] [] set_memory_rw+0x2f/0x40 > > [ 52.370525] [] bpf_jit_free+0x2c/0x40 > > [ 52.370528] [] sk_filter_release_rcu+0x1a/0x30 > > [ 52.370532] [] rcu_process_callbacks+0x1e2/0x5b0 > > [ 52.370535] [] ? enqueue_hrtimer+0x39/0xf0 > > [ 52.370537] [] __do_softirq+0xe0/0x2f0 > > [ 52.370541] [] call_softirq+0x1c/0x30 > > [ 52.370543] [] do_softirq+0x55/0x90 > > [ 52.370545] [] irq_exit+0x8e/0xb0 > > [ 52.370547] [] smp_apic_timer_interrupt+0x4a/0x60 > > [ 52.370549] [] apic_timer_interrupt+0x67/0x70 > > [ 52.370550] > > [ 52.370552] [] ? > > default_send_IPI_mask_allbutself_phys+0xb4/0xe0 > > [ 52.370559] [] ? handle_pte_fault+0x567/0x920 > > [ 52.370561] [] ? > > rbt_memtype_copy_nth_element+0xc0/0xc0 > > [ 52.370563] [] physflat_send_IPI_allbutself+0x17/0x20 > > [ 52.370566] [] native_send_call_func_ipi+0x72/0x80 > > [ 52.370568] [] ? > > rbt_memtype_copy_nth_element+0xc0/0xc0 > > [ 52.370570] [] smp_call_function_many+0x1f4/0x290 > > [ 52.370572] [] smp_call_function+0x3a/0x60 > > [ 52.370574] [] ? > > rbt_memtype_copy_nth_element+0xc0/0xc0 > > [ 52.370576] [] on_each_cpu+0x38/0x80 > > [ 52.370578] [] flush_tlb_kernel_range+0x6d/0x70 > > [ 52.370581] [] __purge_vmap_area_lazy+0x446/0x4c0 > > [ 52.370584] [] ? ext4_file_open+0x75/0x1b0 > > [ 52.370586] [] vm_unmap_aliases+0x17c/0x190 > > [ 52.370590] [] change_page_attr_set_clr+0xb4/0x4a0 > > [ 52.370592] [] ? map_vm_area+0x32/0x50 > > [ 52.370595
Re: [GIT PULL 00/16] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > The following changes since commit aa30a2e03a453aad9fd96c3f2d4a82c3497674e5: > > Merge tag 'perf-core-for-mingo' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > (2013-10-23 09:45:50 +0200) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux > tags/perf-core-for-mingo > > for you to fetch changes up to c1fb5651bb40f9efaf32d280f39e06df7e352673: > > perf tools: Show progress on histogram collapsing (2013-10-23 15:48:24 > -0300) > > > perf/core improvements and fixes: > > . Show progress on histogram collapsing, that can take a long time, from > Namhyung Kim. > > . Support "$vars" meta argument syntax for local variables, allowing > asking for all possible variables at a given probe point to be > collected when it hits, from Masami Hiramatsu. > > . Address the root cause of that 'perf sched' stack initialization build > slowdown, by programmatically setting a big array after moving the > global variable back to the stack. Fix from Adrian Hunter. > > . Do not repipe attributes to a perf.data file in 'perf inject', > fix from Adrian Hunter > > . Change the procps visible command-name of invididual benchmark tests > plus cleanups, from Ingo Molnar. > > . Do not accept parse_tag_value() overflow, fix from Adrian Hunter. > > . Validate that mmap_pages is not too big. From Adrian Hunter. > > . Fix non-debug build, from Adrian Hunter > > . Clarify the "sample parsing" test entry. > > . Consider PERF_SAMPLE_TRANSACTION in the "sample parsing" test. > > Signed-off-by: Arnaldo Carvalho de Melo > > > Adrian Hunter (7): > perf sched: Make struct perf_sched sched a local variable > perf sched: Optimize build time > perf script: Make perf_script a local variable > perf inject: Do not repipe attributes to a perf.data file > perf tools: Do not accept parse_tag_value() overflow > perf evlist: Validate that mmap_pages is not too big > perf tools: Fix non-debug build > > Arnaldo Carvalho de Melo (5): > perf test: Clarify the "sample parsing" test entry > perf test: Consider PERF_SAMPLE_TRANSACTION in the "sample parsing" test > perf tools: Stop using 'self' in some more places > perf ui: Rename ui_progress to ui_progress_ops > perf ui progress: Per progress bar state > > Ingo Molnar (1): > perf bench: Change the procps visible command-name of invididual > benchmark tests plus cleanups > > Masami Hiramatsu (2): > perf probe: Support "$vars" meta argument syntax for local variables > perf probe: Find fentry mcount fuzzed parameter location > > Namhyung Kim (1): > perf tools: Show progress on histogram collapsing > > tools/perf/Makefile.perf | 1 + > tools/perf/builtin-annotate.c | 6 +- > tools/perf/builtin-bench.c| 239 > +++--- > tools/perf/builtin-diff.c | 7 +- > tools/perf/builtin-inject.c | 27 +++-- > tools/perf/builtin-report.c | 24 ++-- > tools/perf/builtin-sched.c| 44 +++ > tools/perf/builtin-script.c | 40 --- > tools/perf/builtin-top.c | 4 +- > tools/perf/config/Makefile| 4 + > tools/perf/tests/hists_link.c | 2 +- > tools/perf/tests/sample-parsing.c | 4 +- > tools/perf/ui/gtk/gtk.h | 2 +- > tools/perf/ui/gtk/progress.c | 20 ++-- > tools/perf/ui/gtk/setup.c | 2 +- > tools/perf/ui/progress.c | 32 +++-- > tools/perf/ui/progress.h | 19 +-- > tools/perf/ui/tui/progress.c | 15 +-- > tools/perf/ui/tui/setup.c | 3 +- > tools/perf/ui/tui/tui.h | 6 + > tools/perf/util/build-id.c| 6 +- > tools/perf/util/evlist.c | 14 ++- > tools/perf/util/hist.c| 23 ++-- > tools/perf/util/hist.h| 3 +- > tools/perf/util/probe-event.c | 1 - > tools/perf/util/probe-finder.c| 133 ++--- > tools/perf/util/probe-finder.h| 1 + > tools/perf/util/session.c | 24 ++-- > tools/perf/util/sort.c| 124 ++-- > tools/perf/util/strfilter.c | 46 > tools/perf/util/thread.c | 72 ++-- > tools/perf/util/util.c| 2 + > 32 files changed, 560 insertions(+), 390 deletions(-) > create mode 100644 tools/perf/ui/tui/tui.h Pulled, thanks Arnaldo! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux
Re: [PATCH] kernel/modsign_certificate.S: use real contents instead of macro GLOBAL()
Am 24.10.2013 08:26, schrieb Chen Gang: > On 10/24/2013 02:03 PM, Richard Weinberger wrote: > Anyway, maybe it is also the tool chain's bug (so I include related arc > tool chain guys in this mail). That's exactly my point. Before you blindly patch the kernel just to make it somehow build you need to find the root cause. Do you even have an ARC board to test the kernel? 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/
[PATCH v2] Input: add regulator haptic driver
From: Hyunhee Kim
Date: Wed, 9 Oct 2013 16:21:36 +0900
Subject: [PATCH] tizenw: add regulator haptic driver
Signed-off-by: Hyunhee Kim
Signed-off-by: Kyungmin Park
Acked-by: Aristeu Rozanski
---
drivers/input/misc/Kconfig| 10 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/regulator-haptic.c | 183
+
3 files changed, 194 insertions(+)
create mode 100644 drivers/input/misc/regulator-haptic.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index bb698e1..21b4d5b 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -82,6 +82,16 @@ config INPUT_ARIZONA_HAPTICS
To compile this driver as a module, choose M here: the
module will be called arizona-haptics.
+config INPUT_REGULATOR_HAPTIC
+ tristate "support haptics on/off using regulator"
+ select INPUT_FF_MEMLESS
+ help
+ Say Y to enable support for the haptic module. Haptic can be
+ enabled/disabled by regulator.
+
+ To compile this driver as a module, choose M here: the
+ module will be called regulator-haptic.
+
config INPUT_BMA150
tristate "BMA150/SMB380 acceleration sensor support"
depends on I2C
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index d7fc17f..106f0bc 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_INPUT_ADXL34X_I2C) +=
adxl34x-i2c.o
obj-$(CONFIG_INPUT_ADXL34X_SPI)+= adxl34x-spi.o
obj-$(CONFIG_INPUT_APANEL) += apanel.o
obj-$(CONFIG_INPUT_ARIZONA_HAPTICS)+= arizona-haptics.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
obj-$(CONFIG_INPUT_ATI_REMOTE2)+= ati_remote2.o
obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o
obj-$(CONFIG_INPUT_BFIN_ROTARY)+= bfin_rotary.o
diff --git a/drivers/input/misc/regulator-haptic.c
b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 000..c9588d5
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,183 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ *
+ * Author: Hyunhee Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct regulator_haptic {
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct work_struct work;
+ bool enabled;
+ struct regulator *regulator;
+ struct mutex mutex;
+ int level;
+};
+
+static void regulator_haptic_toggle(struct regulator_haptic *haptic, bool
enable)
+{
+ int ret;
+
+ mutex_lock(&haptic->mutex);
+ if (enable && !haptic->enabled) {
+ haptic->enabled = true;
+ ret = regulator_enable(haptic->regulator);
+ if (ret)
+ dev_err(haptic->dev, "failed to enable
regulator\n");
+ } else if (!enable && haptic->enabled) {
+ haptic->enabled = false;
+ ret = regulator_disable(haptic->regulator);
+ if (ret)
+ dev_err(haptic->dev, "failed to disable
regulator\n");
+ }
+ mutex_unlock(&haptic->mutex);
+}
+
+static void regulator_haptic_work(struct work_struct *work)
+{
+ struct regulator_haptic *haptic = container_of(work,
+ struct
regulator_haptic,
+ work);
+ if (haptic->level)
+ regulator_haptic_toggle(haptic, true);
+ else
+ regulator_haptic_toggle(haptic, false);
+
+}
+
+static int regulator_haptic_play(struct input_dev *input, void *data,
+ struct ff_effect *effect)
+{
+ struct regulator_haptic *haptic = input_get_drvdata(input);
+
+ haptic->level = effect->u.rumble.strong_magnitude;
+ if (!haptic->level)
+ haptic->level = effect->u.rumble.weak_magnitude;
+ schedule_work(&haptic->work);
+
+ return 0;
+}
+
+static void regulator_haptic_close(struct input_dev *input)
+{
+ struct regulator_haptic *haptic = input_get_drvdata(input);
+
+ cancel_work_sync(&haptic->work);
+ regulator_haptic_toggle(haptic, false);
+}
+
+static int regulator_haptic_probe(struct platform_device *pdev)
+{
+ struct regulator_haptic *haptic;
+ struct input_dev *input_dev;
+ int error;
+
+ haptic = devm_kzalloc(&pdev->dev, sizeof(*haptic), GFP_KERNEL);
+ if (!haptic) {
+ dev_err(&pdev->dev, "unable to allocate memory for
haptic\n");
+ return -ENOMEM;
+ }
+
+ input_dev = input_allocate_device();
+
+ if (!input_dev) {
+
Re: [PATCH] kernel/modsign_certificate.S: use real contents instead of macro GLOBAL()
On 10/24/2013 02:03 PM, Richard Weinberger wrote: > On Thu, Oct 24, 2013 at 7:31 AM, Chen Gang wrote: >> For some architectures, tool chain is not smart enough to recognize the >> macro with multiple lines (e.g. arc tool chain), and for common ".S" >> file, this kind of macro is also rarely used. > > Does not "not smart enough" mean than the said toolchain is broken/buggy > or is the kernel using an unsupported notation? > Hmm... maybe my comments is not quite precise, what I want to say is: - another architectures tool chain (e.g. arm-linux-gnueabi-) support it. but our tool chain (arc-elf32-) will cause issue. - in kernel source, excluding "arch/" sub directory, excep this file and one x86 drivers, no one use macro in this way, now. and in "arch/arc/" sub-directory, no one use macro in this way, too. the related find command: "find | grep "\.S$" | grep -v "/arch/" | grep -v "Documentation" | xargs grep define" So at least, for kernel itself, better change the using way (only 2 areas use the macro, and the macro only contents 2 lines, so it is acceptable enough to expand it). Anyway, maybe it is also the tool chain's bug (so I include related arc tool chain guys in this mail). Thanks. >> So expand the related contents of macro to let it pass compiling (can >> use "arc-elf32-objdump -x" to know about it). >> >> The related error (allmodconfig for arc): >> >> LD init/built-in.o >> kernel/built-in.o: In function `load_module_signing_keys': >> kernel/modsign_pubkey.c:66: undefined reference to >> `modsign_certificate_list' >> kernel/modsign_pubkey.c:71: undefined reference to >> `modsign_certificate_list_end' >> kernel/modsign_pubkey.c:67: undefined reference to >> `modsign_certificate_list_end' >> >> The related tool chain information: >> >> [root@gchenlinux linux-next]# arc-elf32-as -v >> GNU assembler version 2.23.2 (arc-elf32) using BFD version (GNU Binutils) >> 2.23.2 >> [root@gchenlinux linux-next]# arc-elf32-ld -v >> GNU ld (GNU Binutils) 2.23.2 >> [root@gchenlinux linux-next]# arc-elf32-gcc -v >> Using built-in specs. >> COLLECT_GCC=arc-elf32-gcc >> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arc-elf32/4.8.0/lto-wrapper >> Target: arc-elf32 >> Configured with: ../gcc/configure --without-header --disable-nls >> --enable-language=c --disable-threads --disable-shared --enable-werror=no >> target_configargs=enable_vtable_verify=yes --target=arc-elf32 >> --with-cpu=arc700 : (reconfigured) ../gcc/configure --disable-nls >> --enable-language=c --disable-threads --disable-shared --enable-werror=no >> target_configargs=enable_vtable_verify=yes --target=arc-elf32 >> --with-cpu=arc700 : (reconfigured) ../gcc/configure --without-header >> --disable-nls --enable-language=c --disable-threads --disable-shared >> --enable-werror=no target_configargs=enable_vtable_verify=yes >> --target=arc-elf32 --with-cpu=arc700 --disable-multilib >> --with-headers=../newlib/newlib/libc/include >> Thread model: single >> gcc version 4.8.0 (GCC) >> >> >> Signed-off-by: Chen Gang >> --- >> kernel/modsign_certificate.S | 10 -- >> 1 files changed, 4 insertions(+), 6 deletions(-) >> >> diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S >> index 4a9a86d..1967dcd 100644 >> --- a/kernel/modsign_certificate.S >> +++ b/kernel/modsign_certificate.S >> @@ -1,12 +1,10 @@ >> #include >> >> -#define GLOBAL(name) \ >> - .globl VMLINUX_SYMBOL(name);\ >> - VMLINUX_SYMBOL(name): >> - >> .section ".init.data","aw" >> >> -GLOBAL(modsign_certificate_list) >> + .globl VMLINUX_SYMBOL(modsign_certificate_list) >> +VMLINUX_SYMBOL(modsign_certificate_list): >> .incbin "signing_key.x509" >> .incbin "extra_certificates" >> -GLOBAL(modsign_certificate_list_end) >> + .globl VMLINUX_SYMBOL(modsign_certificate_list_end) >> +VMLINUX_SYMBOL(modsign_certificate_list_end): >> -- >> 1.7.7.6 >> -- >> 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/ > > > -- Chen Gang -- 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: Deadlock in BPF JIT functions when running upowerd?
On Wed, 2013-10-23 at 18:17 -0700, Darrick J. Wong wrote: > Hi, > > I've been observing a softlockup with 3.11.6 and 3.12-rc6. It looks like > there's a deadlock occurring on purge_lock in __purge_vmap_area_lazy(). In > short, the BPF JIT code has been changed[1] to call set_memory_r[ow]() when > compiling and freeing JIT bytecode memory. It seems that it's possible for > upowerd to be compiling some BPF program and call __purge_vmap_area_lazy, then > the timer interrupt comes in (due to the IPI?) and a softirq calls > bpf_jit_free, which also calls __purge_vmap_area_lazy. > > I'm not really sure who's at fault here--is this a BPF bug? > > [1] 314beb9bcabfd6b4542ccbced2402af2c6f6142a > "x86: bpf_jit_comp: secure bpf jit against spraying attacks" > > --D > > Here's what 3.11.6 spits out; the 3.12-rc6 message has the same traceback. > > [ 52.370437] BUG: soft lockup - CPU#3 stuck for 22s! [upowerd:8359] > [ 52.370440] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat_ipv4 > xt_conntrack xt_CHECKSUM iptable_mangle fuse tun microcode nfsd nfs_acl > exportfs auth_rpcgss nfs lockd sunrpc af_packet xt_physdev xt_hl ip6t_rt > nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT xt_sctp xt_limit xt_tcpudp > xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ip6table_filter > ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat > nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables sch_fq_codel > bridge stp llc lpc_ich mfd_core loop bcache dm_crypt zlib_deflate libcrc32c > firewire_ohci firewire_core usb_storage mpt2sas scsi_transport_sas raid_class > [ 52.370471] CPU: 3 PID: 8359 Comm: upowerd Not tainted 3.11.6-60-flax #1 > [ 52.370472] Hardware name: OEM OEM/131-GT-E767, BIOS 6.00 PG 08/25/2011 > [ 52.370474] task: 8806621f9700 ti: 88064b6a task.ti: > 88064b6a > [ 52.370475] RIP: 0010:[] [] > _raw_spin_lock+0x32/0x40 > [ 52.370480] RSP: 0018:88067fc63c10 EFLAGS: 0297 > [ 52.370481] RAX: 0061 RBX: 88065a318600 RCX: > > [ 52.370483] RDX: 0062 RSI: 88067fc63ce0 RDI: > 81ea42bc > [ 52.370484] RBP: 88067fc63c10 R08: 81cdd608 R09: > > [ 52.370485] R10: 88067fc6d8e0 R11: R12: > 88067fc63b88 > [ 52.370486] R13: 816b7a47 R14: 88067fc63c10 R15: > 88067fc63cd8 > [ 52.370487] FS: 7f55fff297c0() GS:88067fc6() > knlGS: > [ 52.370488] CS: 0010 DS: ES: CR0: 80050033 > [ 52.370489] CR2: 7f55fff47000 CR3: 00065dd1 CR4: > 07e0 > [ 52.370490] Stack: > [ 52.370491] 88067fc63cb0 811955fd 0096 > 0347 > [ 52.370494] 03c1 0001 > > [ 52.370496] 0033 88067fc63c58 88067fc63c58 > 0001 > [ 52.370499] Call Trace: > [ 52.370500] > [ 52.370501] [] __purge_vmap_area_lazy+0x12d/0x4c0 > [ 52.370507] [] vm_unmap_aliases+0x17c/0x190 > [ 52.370512] [] change_page_attr_set_clr+0xb4/0x4a0 > [ 52.370516] [] ? irq_exit+0x7e/0xb0 > [ 52.370519] [] ? smp_irq_work_interrupt+0x34/0x40 > [ 52.370522] [] set_memory_rw+0x2f/0x40 > [ 52.370525] [] bpf_jit_free+0x2c/0x40 > [ 52.370528] [] sk_filter_release_rcu+0x1a/0x30 > [ 52.370532] [] rcu_process_callbacks+0x1e2/0x5b0 > [ 52.370535] [] ? enqueue_hrtimer+0x39/0xf0 > [ 52.370537] [] __do_softirq+0xe0/0x2f0 > [ 52.370541] [] call_softirq+0x1c/0x30 > [ 52.370543] [] do_softirq+0x55/0x90 > [ 52.370545] [] irq_exit+0x8e/0xb0 > [ 52.370547] [] smp_apic_timer_interrupt+0x4a/0x60 > [ 52.370549] [] apic_timer_interrupt+0x67/0x70 > [ 52.370550] > [ 52.370552] [] ? > default_send_IPI_mask_allbutself_phys+0xb4/0xe0 > [ 52.370559] [] ? handle_pte_fault+0x567/0x920 > [ 52.370561] [] ? rbt_memtype_copy_nth_element+0xc0/0xc0 > [ 52.370563] [] physflat_send_IPI_allbutself+0x17/0x20 > [ 52.370566] [] native_send_call_func_ipi+0x72/0x80 > [ 52.370568] [] ? rbt_memtype_copy_nth_element+0xc0/0xc0 > [ 52.370570] [] smp_call_function_many+0x1f4/0x290 > [ 52.370572] [] smp_call_function+0x3a/0x60 > [ 52.370574] [] ? rbt_memtype_copy_nth_element+0xc0/0xc0 > [ 52.370576] [] on_each_cpu+0x38/0x80 > [ 52.370578] [] flush_tlb_kernel_range+0x6d/0x70 > [ 52.370581] [] __purge_vmap_area_lazy+0x446/0x4c0 > [ 52.370584] [] ? ext4_file_open+0x75/0x1b0 > [ 52.370586] [] vm_unmap_aliases+0x17c/0x190 > [ 52.370590] [] change_page_attr_set_clr+0xb4/0x4a0 > [ 52.370592] [] ? map_vm_area+0x32/0x50 > [ 52.370595] [] ? __vmalloc_node_range+0x121/0x1f0 > [ 52.370597] [] ? bpf_jit_compile+0x105b/0x1200 > [ 52.370600] [] set_memory_ro+0x2f/0x40 > [ 52.370602] [] ? module_alloc+0x5a/0x60 > [ 52.370604] [] bpf_jit_compile+0xfcc/0x1200 > [ 52.370607] [] ? __kmalloc+0x18b/0x1f0
Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM
On Mon, Oct 21, 2013 at 8:16 AM, Vivek Goyal wrote: > On Fri, Oct 18, 2013 at 10:45:43PM -0700, Yinghai Lu wrote: > > > IIUC, you are trying to say that with new kernel old kexec-tools will fail > at a different failure point. I don't see why that is a problem. It still > fails. Yes, that could cause confusion. We already knew it would fail possible at most later, we should make it skip allocation during first kernel booting. > > [..] >> > You are not thinking about ease of use here for existing users. >> >> most existing user don't need to do anything. just with new kernel and >> old kexec tools. >> >> those system that did not work kexec before because XM is too big, they have >> to >> update kexec tools, and use ",high" >> >> Make it simple, less error. > > No, it is not that simple. Think from a distribution's perspective also. > We have the logic to scale reserved memory based on physical memory > present in the system. Now we are seeing bigger memory systems (which > would not have worked in the past). We still want to retain the existing > logic and not switch to crashkernel=x,high. One does not have to. It > makes life simpler. distribution should go with ",high" for 64 bit kernel and new kexec-tools. for 32bit kernel, you still can have ",high" or not, as ",high" is ignored. > > Same logic working both with smaller memory systems as well as large memory > systems. One should not have to choose a different command line because > there is more physical RAM present in the system. ",high" is working even on smaller memory sytem. > >> >> We already support above 4G, what is point for trying below 4G? > > Because it is not *required* to reserve memory above 4G. Because we want > same command line to work with both small memory systems as well as > large memory systems and we don't care whether memory is reserved below > 4G or above 4G. What does matter though that we don't have to worry about > switching command line option if it is large memory system. ",high" will work smaller or large memory system after you install new kexec tools. Again, for distribution, when new kernel is added, new kernel will all have ",high" and new kexec-tools get installed. Even we want to extend crashkernel=XM, then i would like to have it identical to crashkernel=XM,high instead. Thanks Yinghai -- 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: Perf Python Scripting Leaks Memory
On 23.10.2013 22:01, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 23, 2013 at 04:37:41PM +0200, Joseph Schuchart escreveu: >>We are using the Python scripting interface in perf to extract kernel >>events relevant for performance analysis of HPC codes. We noticed that the >>"perf script" call allocates a significant amount of memory (in the order >>of several 100 MiB) during it's run, e.g. 125 MiB for a 25 MiB input file: > > Thanks for the analysis and the bug fix! > > I asked Tom Zanussi and he kindly reviewed your patch and provided an > Acked-by tag for it, Tom, may I add a Reviewed-by: as well? > > Joseph, can I have your Signed-off-by: tag, as documented in: > > Documentation/SubmittingPatches > Thanks for your quick reply and sorry for not following the recommendations in the documentation. Signed-off-by: Joseph Schuchart Thanks! Joseph -- 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] kernel/modsign_certificate.S: use real contents instead of macro GLOBAL()
On Thu, Oct 24, 2013 at 7:31 AM, Chen Gang wrote: > For some architectures, tool chain is not smart enough to recognize the > macro with multiple lines (e.g. arc tool chain), and for common ".S" > file, this kind of macro is also rarely used. Does not "not smart enough" mean than the said toolchain is broken/buggy or is the kernel using an unsupported notation? > So expand the related contents of macro to let it pass compiling (can > use "arc-elf32-objdump -x" to know about it). > > The related error (allmodconfig for arc): > > LD init/built-in.o > kernel/built-in.o: In function `load_module_signing_keys': > kernel/modsign_pubkey.c:66: undefined reference to > `modsign_certificate_list' > kernel/modsign_pubkey.c:71: undefined reference to > `modsign_certificate_list_end' > kernel/modsign_pubkey.c:67: undefined reference to > `modsign_certificate_list_end' > > The related tool chain information: > > [root@gchenlinux linux-next]# arc-elf32-as -v > GNU assembler version 2.23.2 (arc-elf32) using BFD version (GNU Binutils) > 2.23.2 > [root@gchenlinux linux-next]# arc-elf32-ld -v > GNU ld (GNU Binutils) 2.23.2 > [root@gchenlinux linux-next]# arc-elf32-gcc -v > Using built-in specs. > COLLECT_GCC=arc-elf32-gcc > COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arc-elf32/4.8.0/lto-wrapper > Target: arc-elf32 > Configured with: ../gcc/configure --without-header --disable-nls > --enable-language=c --disable-threads --disable-shared --enable-werror=no > target_configargs=enable_vtable_verify=yes --target=arc-elf32 > --with-cpu=arc700 : (reconfigured) ../gcc/configure --disable-nls > --enable-language=c --disable-threads --disable-shared --enable-werror=no > target_configargs=enable_vtable_verify=yes --target=arc-elf32 > --with-cpu=arc700 : (reconfigured) ../gcc/configure --without-header > --disable-nls --enable-language=c --disable-threads --disable-shared > --enable-werror=no target_configargs=enable_vtable_verify=yes > --target=arc-elf32 --with-cpu=arc700 --disable-multilib > --with-headers=../newlib/newlib/libc/include > Thread model: single > gcc version 4.8.0 (GCC) > > > Signed-off-by: Chen Gang > --- > kernel/modsign_certificate.S | 10 -- > 1 files changed, 4 insertions(+), 6 deletions(-) > > diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S > index 4a9a86d..1967dcd 100644 > --- a/kernel/modsign_certificate.S > +++ b/kernel/modsign_certificate.S > @@ -1,12 +1,10 @@ > #include > > -#define GLOBAL(name) \ > - .globl VMLINUX_SYMBOL(name);\ > - VMLINUX_SYMBOL(name): > - > .section ".init.data","aw" > > -GLOBAL(modsign_certificate_list) > + .globl VMLINUX_SYMBOL(modsign_certificate_list) > +VMLINUX_SYMBOL(modsign_certificate_list): > .incbin "signing_key.x509" > .incbin "extra_certificates" > -GLOBAL(modsign_certificate_list_end) > + .globl VMLINUX_SYMBOL(modsign_certificate_list_end) > +VMLINUX_SYMBOL(modsign_certificate_list_end): > -- > 1.7.7.6 > -- > 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/ -- 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/3] switch_creds: Syscall to switch creds for file server ops
Andy Lutomirski writes:
> On 10/16/2013 08:52 PM, Eric W. Biederman wrote:
>> Al Viro writes:
>>
>>> On Wed, Oct 16, 2013 at 06:18:16PM -0700, Eric W. Biederman wrote:
>>>
That doesn't look bad but it does need capable(CAP_SETUID) &&
capable(CAP_SETGID) or possibly something a little more refined.
>>>
>>> D'oh
>>>
I don't think we want file descriptor passing to all of a sudden become
a grant of privilege, beyond what the passed fd can do.
>>>
>>> Definitely. And an extra ) to make it compile wouldn't hurt either...
>>
>> There also appears to need to be a check that we don't gain any
>> capabilities.
>>
>> We also need a check so that you don't gain any capabilities, and
>> possibly a few other things.
>
> Why? I like the user_ns part, but I'm not immediately seeing the issue
> with capabilities.
My reasoning was instead of making this syscall as generic as possible
start it out by only allowing the cases Jim cares about and working with
a model where you can't gain any permissions you couldn't gain
otherwise.
Although the fd -1 trick to revert to your other existing cred seems
reasonable.
>> So I suspect we want a check something like:
>>
>> if ((new_cred->securebits != current_cred->securebits) ||
>> (new_cred->cap_inheritable != current_cred->cap_inheritable) ||
>> (new_cred->cap_permitted != current_cred->cap_permitted) ||
>> (new_cred->cap_effective != current_cred->cap_effective) ||
>> (new_cred->cap_bset != current_cred->cap_bset) ||
>> (new_cred->jit_keyring != current_cred->jit_keyring) ||
>> (new_cred->session_keyring != current_cred->session_keyring) ||
>> (new_cred->process_keyring != current_cred->process_keyring) ||
>> (new_cred->thread_keyring != current_cred->thread_keyring) ||
>> (new_cred->request_keyring != current_cred->request_keyring) ||
>> (new_cred->security != current_cred->security) ||
>> (new_cred->user_ns != current_cred->user_ns)) {
>> return -EPERM;
>> }
>>
>
> I *really* don't like the idea of being able to use any old file
> descriptor. I barely care what rights the caller needs to have to
> invoke this -- if you're going to pass an fd that grants a capability
> (in the non-Linux sense of the work), please make sure that the sender
> actually wants that behavior.
>
> IOW, have a syscall to generate a special fd for this purpose. It's
> only a couple lines of code, and I think we'll really regret it if we
> fsck this up.
>
> (I will take it as a personal challenge to find at least one exploitable
> privilege escalation in this if an arbitrary fd works.)
If you can't switch to a uid or a gid you couldn't switch to otherwise
then the worst that can happen is an information leak. And information
leaks are rarely directly exploitable.
> Also... real_cred looks confusing. AFAICS it is used *only* for knfsd
> and faccessat. That is, current userspace can't see it. But now you'll
> expose various oddities. For example, AFAICS a capability-less process
> that's a userns owner can always use setuid. This will *overwrite*
> real_cred. Then you're screwed, especially if this happens by
> accident.
And doing in userland what faccessat, and knfsd do in the kernel is
exactly what is desired here. But maybe there are issues with that.
> That being said, Windows has had functions like this for a long time.
> Processes have a primary token and possibly an impersonation token. Any
> process can call ImpersonateLoggedOnUser (no privilege required) to
> impersonate the credentials of a token (which is special kind of fd).
> Similarly, any process can call RevertToSelf to undo it.
>
> Is there any actual problem with allowing completely unprivileged tasks
> to switch to one of these magic cred fds? That would avoid needing a
> "revert" operation.
If the permission model is this switching of credentials doesn't get you
anything you couldn't get some other way. That would seem to totally
rules out unprivileged processes switching these things.
> Another note: I think that there may be issues if the creator of a token
> has no_new_privs set and the user doesn't. Imagine a daemon that
> accepts one of these fds, impersonates it, and calls exec. This could
> be used to escape from no_new_privs land.
Which is why I was suggesting that we don't allow changing any field in
the cred except for uids and gids.
Eric
--
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: [BUG][PATCH] audit: audit_log_start running on auditd should not stop
On 10/24/2013 03:55 AM, Richard Guy Briggs wrote:
> On Tue, Oct 15, 2013 at 02:30:34PM +0800, Gao feng wrote:
>> Hi Toshiyuki-san,
>
> Toshiuki and Gao,
>
>> On 10/15/2013 12:43 PM, Toshiyuki Okajima wrote:
>>> The backlog cannot be consumed when audit_log_start is running on auditd
>>> even if audit_log_start calls wait_for_auditd to consume it.
>>> The situation is a deadlock because only auditd can consume the backlog.
>>> If the other process needs to send the backlog, it can be also stopped
>>> by the deadlock.
>>>
>>> So, audit_log_start running on auditd should not stop.
>>>
>>> You can see the deadlock with the following reproducer:
>>> # auditctl -a exit,always -S all
>>> # reboot
>
>> Hmm, I see, There may be other code paths that auditd can call
>> audit_log_start except
>> audit_log_config_change. so it's better to handle this problem in
>> audit_log_start.
>>
>> but current task is only meaningful when gfp_mask & __GFP_WAIT is true.
>> so maybe the below patch is what you want.
>
> I have been following this thread with interest. I like the general
> evolution of this patch. The first patch was a bit too abrupt, dropping
> too much, but this one makes much more sense. I would be tempted to
> make the reserve even bigger.
>
> I see that you should be using a kernel that has included commit
> 8ac1c8d5 (which made it into v3.12-rc3)
> audit: fix endless wait in audit_log_start()
> That was an obvious bug,
include or not include?
The problem is, if the audit_backlog_limit is 3, but there are 5 tasks
calling audit_log_start, so 2 tasks will wait auditd to consume
audit_skb_queue. if before auditd consumes skbs, somebody want to kill
auditd, and auditd will set the audit_pid to zero, this will triger an
audit message. so auditd will wait for himself. and this waiting is endless,
since auditd cann't consume audit_skb_queue any more.
the commit 8ac1c8d5 prevent this problem happening. because if once a task is
blocked over the audit_backlog_wait_time. the audit_backlog_wait_time will
be set to zero(audit_backlog_wait_overflow which is zero). so the other tasks
will not wait anymore. but I'm confused if this is what we expected? these
audit messages will lost once any task is blocked over audit_backlog_wait_time.
So, AFAIK if commit 8ac1c8d5 exist, this patch is not necessary, but
we still do something to fix the problem commit 8ac1c8d5 brings.
but I was still concerned about the cause of
> the initial wait. There are other fixes and ideas in the works that
> should alleviate some of the pressure to make the service more usable.
> https://lkml.org/lkml/2013/9/18/453
>
> I have tested with and without this v3 patch and I don't see any
> significant difference with the reproducer provided above. I'm also
> testing with a reproducer of the endless wait bug (readahead-collector).
>
> What are your expected results? What are your actual results in each
> case? How are they different?
>
>> diff --git a/kernel/audit.c b/kernel/audit.c
>> index 7b0e23a..10b4545 100644
>> --- a/kernel/audit.c
>> +++ b/kernel/audit.c
>> @@ -1095,7 +1095,9 @@ struct audit_buffer *audit_log_start(struct
>> audit_context
>> struct audit_buffer *ab = NULL;
>> struct timespec t;
>> unsigned intuninitialized_var(serial);
>> - int reserve;
>> + int reserve = 5; /* Allow atomic callers to go up to five
>> + entries over the normal backlog limit */
>> +
>> unsigned long timeout_start = jiffies;
>>
>> if (audit_initialized != AUDIT_INITIALIZED)
>> @@ -1104,11 +1106,12 @@ struct audit_buffer *audit_log_start(struct
>> audit_contex
>> if (unlikely(audit_filter_type(type)))
>> return NULL;
>>
>> - if (gfp_mask & __GFP_WAIT)
>> - reserve = 0;
>> - else
>> - reserve = 5; /* Allow atomic callers to go up to five
>> - entries over the normal backlog limit */
>> + if (gfp_mask & __GFP_WAIT) {
>> + if (audit_pid && audit_pid == current->pid)
>> + gfp_mask &= ~__GFP_WAIT;
>> + else
>> + reserve = 0;
>> + }
>>
>> while (audit_backlog_limit
>>&& skb_queue_len(&audit_skb_queue) > audit_backlog_limit +
>> reserv
>
> - RGB
>
> --
> Richard Guy Briggs
> Senior Software Engineer
> Kernel Security
> AMER ENG Base Operating Systems
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635
> Internal: (81) 32635
> Alt: +1.613.693.0684x3545
>
--
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: [3.11.4] Thunderbolt/PCI unplug oops in pci_pme_list_scan
On Tue, Oct 22, 2013 at 8:32 PM, Bjorn Helgaas wrote: > [+cc Yinghai] > > On Thu, Oct 17, 2013 at 7:59 AM, Andreas Noever > wrote: >> On Wed, Oct 16, 2013 at 10:21 PM, Bjorn Helgaas wrote: >>> On Tue, Oct 15, 2013 at 03:44:52AM +0100, Matthew Garrett wrote: On Mon, Oct 14, 2013 at 05:50:38PM -0600, Bjorn Helgaas wrote: > [+cc Rafael, Mika, Kirill, linux-pci] > > On Mon, Oct 14, 2013 at 4:47 PM, Andreas Noever > wrote: > > When I unplug the Thunderbolt ethernet adapter on my MacBookPro Linux > > crashes a few seconds later. Using > > echo 1 > /sys/bus/pci/devices/:08:00.0/remove > > to remove a bridge two levels above the device triggers the fault > > immediately: > > There have been significant changes in acpiphp related to Thunderbolt > since v3.11. Apple don't expose Thunderbolt via ACPI, so it appears as native PCIe. I'd be surprised if acpiphp makes a difference here. >>> >>> Yeah, you're right; I wasn't paying attention. >>> >>> We save a pci_dev pointer in the pci_pme_list, which of course has a >>> longer lifetime than the pci_dev itself, but we don't acquire a reference >>> on it, so I suspect the pci_dev got released before we got around to >>> doing the pci_pme_list_scan(). >>> >>> Andreas, can you try the patch below? It's against v3.12-rc2, but it >>> should apply to v3.11, too. >> >> I have tested your patch against 3.11 where it solves the problem. Thanks! >> >> Unfortunately I could not reproduce the problem in 3.12-rc5. I only >> get the following warning (and no crash): >> >> tg3 :0a:00.0: PME# disabled >> pcieport :09:00.0: PME# disabled >> pciehp :09:00.0:pcie24: unloading service driver pciehp >> pci_bus :0a: dev 00, dec refcount to 0 >> pci_bus :0a: dev 00, released physical slot 9 >> [ cut here ] >> WARNING: CPU: 0 PID: 122 at drivers/pci/pci.c:1430 >> pci_disable_device+0x84/0x90() >> Device pcieport >> disabling already-disabled device >> Modules linked in: >> btusb bluetooth joydev hid_apple bcm5974 nls_utf8 nls_cp437 hfsplus >> vfat fat snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp >> coretemp kvm_intel kvm cfg80211 uvcvideo crc32_pclmul crc32c_intel >> videobuf2_vmalloc ghash_clmulni_intel aesni_intel videobuf2_memops >> aes_x86_64 glue_helper videobuf2_core tg3 videodev lrw gf128mul >> ablk_helper iTCO_wdt hid_generic iTCO_vendor_support cryptd media >> applesmc input_polldev usbhid ptp microcode snd_hda_codec_cirrus hid >> pps_core libphy rfkill i2c_i801 pcspkr snd_hda_intel apple_gmux >> lib80211 snd_hda_codec acpi_cpufreq snd_hwdep snd_pcm snd_page_alloc >> snd_timer mei_me snd mei processor soundcore lpc_ich evdev mfd_core >> apple_bl ac battery ext4 crc16 mbcache jbd2 sd_mod ahci libahci libata >> xhci_hcd ehci_pci sdhci_pci ehci_hcd sdhci scsi_mod mmc_core >> usbcore usb_common nouveau mxm_wmi wmi ttm i915 video button >> i2c_algo_bit intel_agp intel_gtt drm_kms_helper drm i2c_core >> CPU: 0 PID: 122 Comm: kworker/u16:5 Not tainted 3.12.0-1-dirty #30 >> Hardware name: Apple Inc. MacBookPro10,1/Mac-C3EC7CD22292981F, BIOS >> MBP101.88Z.00EE.B03.1212211437 12/21/2012 >> Workqueue: sysfsd sysfs_schedule_callback_work >> 0009 88044c021c00 814c4288 88044c021c48 >> 88044c021c38 81061b7d 880458a5c000 8187c5c0 >> 880458a5c000 880458a5b098 88044c021c98 >> Call Trace: >> [] dump_stack+0x54/0x8d >> [] warn_slowpath_common+0x7d/0xa0 >> [] warn_slowpath_fmt+0x4c/0x50 >> [] ? do_pci_disable_device+0x52/0x60 >> [] ? acpi_pci_irq_disable+0x4c/0x8d >> [] pci_disable_device+0x84/0x90 >> [] pcie_portdrv_remove+0x1a/0x20 >> [] pci_device_remove+0x3b/0xb0 >> [] __device_release_driver+0x7f/0xf0 >> [] device_release_driver+0x23/0x30 >> [] bus_remove_device+0x108/0x180 >> [] device_del+0x135/0x1d0 >> [] pci_stop_bus_device+0x94/0xa0 >> [] pci_stop_bus_device+0x3b/0xa0 >> [] pci_stop_and_remove_bus_device+0x12/0x20 >> [] remove_callback+0x25/0x40 >> [] sysfs_schedule_callback_work+0x14/0x80 >> [] process_one_work+0x178/0x470 >> [] worker_thread+0x121/0x3a0 >> [] ? manage_workers.isra.21+0x2b0/0x2b0 >> [] kthread+0xc0/0xd0 >> [] ? kthread_create_on_node+0x120/0x120 >> [] ret_from_fork+0x7c/0xb0 >> [] ? kthread_create_on_node+0x120/0x120 >> ---[ end trace b39a15fa94fbb2a2 ]--- >> >> >> Bisection points to 928bea964827d7824b548c1f8e06eccbbc4d0d7d . > > This is "PCI: Delay enabling bridges until they're needed" by Yinghai. that double disabling should be addressed by: https://lkml.org/lkml/2013/4/25/608 [PATCH] PCI: Remove duplicate pci_disable_device for pcie port Thanks Yinghai -- 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 v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter
Vivek Goyal writes: > Hi Hatayama, > > So what information should I look for to prepare disable_cpu_apic=X in > kdump script? > > Is BSP processor info exported to user space somewhere? Or assuming that > processor 0 is BSP and corresponding apicid should be disabled in kdump > kernel is good enough? On x86 assuming that processor 0 is BSP should be good enough. Unless we starting getting SMP BIOSen playing games with us. > I am looking at /proc/cpuinfo and following 3 fields seem interesting. > > processor: 0 > apicid: 0 > initial apicid: 0 > > What's the difference between apicid and "initial apicid". I guess > initial apicid reflects the apicid number as set by firmware and then > kernel can overwrite it and new number would be reflected in "apicid"? Last I was current initial apicid is the apic id the hardware chooses and it tells you something about the topology of the processors in the system. The apicid is programmed by the BIOS so that the BSP can have apicid 0, and apicid's can be contiguous etc. In principle any piece of software can program apicids but there is no advantage. > If that's the case, then I guess we should be looking at "apicid" of > processor "0" and set that in disable_cpu_apic? Because that's the > number kdump kernel boot should see in apic upon boot. Restricting this to x86 and not Voyager that is correct. Linux cpu 0 is the processor we booted up on as is apparent lots of things special case the bootstrap processor so using a cpu hotplug remove to make it go away is silly. Still to handle cazy cpu hotplug I would recomend to simply force a single cpu if you can't find cpu 0. Eric -- 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 v4 2/3] Support for perf to probe into SDT markers:
(2013/10/23 14:05), Hemant Kumar wrote:
> This allows perf to probe into the sdt markers/notes present in
> the libraries and executables. We try to find the associated location
> and handle prelinking (since, stapsdt notes section is not allocated
> during runtime). Prelinking is handled with the help of base
> section which is allocated during runtime. This address can be compared
> with the address retrieved from the notes' description. If its different,
> we can take this difference and then add to the note's location.
>
> We can use existing '-a/--add' option to add events for sdt markers.
> Also, we can add multiple events at once using the same '-a' option.
>
> Usage:
> perf probe -x /lib64/libc.so.6 -a 'my_event=%libc:setjmp'
>
> Output:
> Added new event:
> libc:my_event(on 0x35981)
>
> You can now use it in all perf tools, such as:
>
> perf record -e libc:my_event -aR sleep 1
>
>
> Signed-off-by: Hemant Kumar Shaw
Almost! please check below comments :)
> static int convert_to_probe_trace_events(struct perf_probe_event *pev,
> struct probe_trace_event **tevs,
> int max_tevs, const char *target)
> @@ -1916,11 +1975,23 @@ static int convert_to_probe_trace_events(struct
> perf_probe_event *pev,
> struct symbol *sym;
> int ret = 0, i;
> struct probe_trace_event *tev;
> + char *buf;
> + unsigned long long addr;
>
> - /* Convert perf_probe_event with debuginfo */
> - ret = try_to_find_probe_trace_events(pev, tevs, max_tevs, target);
> - if (ret != 0)
> - return ret; /* Found in debuginfo or got an error */
> + if (pev->sdt) {
> + ret = -EBADF;
> + if (pev->uprobes)
> + ret = try_to_find_sdt_notes(pev, target);
> + if (ret)
> + return ret;
> + } else {
> + /* Convert perf_probe_event with debuginfo */
> + ret = try_to_find_probe_trace_events(pev, tevs, max_tevs,
> + target);
> + /* Found in debuginfo or got an error */
> + if (ret != 0)
> + return ret;
These "ret != 0" checkers can be merged.
[...]
> +int search_sdt_note(struct sdt_note *key, const char *target)
> +{
> + Elf *elf;
> + int fd, ret;
> + bool found = false;
> + struct sdt_note *pos = NULL;
> + LIST_HEAD(sdt_notes);
> +
> + fd = open(target, O_RDONLY);
> + if (fd < 0) {
> + pr_err("%s : %s\n", target, strerror(errno));
> + return -errno;
> + }
> +
> + symbol__elf_init();
> + elf = elf_begin(fd, PERF_ELF_C_READ_MMAP, NULL);
> + if (!elf) {
> + ret = -EBADF;
> + pr_debug("Can't read the elf of %s\n", target);
> + goto out_close;
> + }
> +
> + ret = construct_sdt_notes_list(elf, &sdt_notes);
> + if (ret)
> + goto out_end;
> +
> + /* Iterate through the notes and retrieve the required note */
> + list_for_each_entry(pos, &sdt_notes, note_list) {
> + if (!strcmp(key->name, pos->name) &&
> + !strcmp(key->provider, pos->provider)) {
> + adjust_note_addr(pos, key, elf);
> + found = true;
> + break;
> + }
> + }
> + if (!found) {
> + printf("%%%s:%s not found in %s!\n", key->provider, key->name,
> +target);
> + return -ENOENT;
Here, you skipped the closing process. maybe ret = -ENOENT is enough here.
> + }
> +
> +out_end:
> + elf_end(elf);
> +out_close:
> + close(fd);
> + ret = sdt_err(ret, target);
It seems the sdt_err is only for the return value of contruct_sdt_notes_list(),
thus it is better to integrate it.
> + if (!ret && list_empty(&sdt_notes))
> + ret = -ENOENT;
I think this can be removed, because it always be false (caught by previous
!found).
> + cleanup_sdt_note_list(&sdt_notes);
> + return ret;
> +}
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
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: [RFC PATCH] kernel/kallsyms.c: only show legal kernel symbol
On Thu, Oct 24, 2013 at 9:21 AM, Rusty Russell wrote: > Ming Lei writes: >> Address of non-module kernel symbol should always be located >> from CONFIG_PAGE_OFFSET on, so only show these legal kernel >> symbols in /proc/kallsyms. >> >> On ARM, some symbols(see below) may drop in relocatable code, so >> perf can't parse kernel symbols any more from /proc/kallsyms, this >> patch fixes the problem. >> >> t __vectors_start >> 0020 A cpu_v7_suspend_size >> 1000 t __stubs_start >> 1004 t vector_rst >> 1020 t vector_irq >> 10a0 t vector_dabt >> 1120 t vector_pabt >> 11a0 t vector_und >> 1220 t vector_addrexcptn >> 1224 t vector_fiq >> 1224 T vector_fiq_offset >> >> The issue can be fixed in scripts/kallsyms.c too, but looks this >> approach is easier. > > This fix looks hacky; if these symbols are not available, don't just > remove them from /proc/kallsyms, but don't put them in the kernel at > all. > > That way, they won't interfere with other kallsyms uses (eg. backtrace). Yes, I agree. > Or, better, figure out a smart way of excluding them by knowing why > these symbol addresses are wrong. Actually the problem is caused by commit b9b32bf70f2(ARM: use linker magic for vectors and vector stubs), maybe Russell can figure out a smart way to exclude these symbols. Thanks, -- Ming Lei -- 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: vt6656: fix two coding style issues
This patchset fixes two coding style issues reported by checkpatch.pl in drivers/staging/vt6656, one warning and one error Johannes Löthberg (2): Staging: vt6656: fix a brace coding style issue in power.c Staging: vt6656: fix code indenting error in power.c drivers/staging/vt6656/power.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 1.8.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Staging: vt6656: fix a brace coding style issue in power.c
This patch fixes a brace warning in power.c found by checkpatch.pl
Signed-off-by: Johannes Löthberg
---
drivers/staging/vt6656/power.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/vt6656/power.c b/drivers/staging/vt6656/power.c
index edc8975..3002061 100644
--- a/drivers/staging/vt6656/power.c
+++ b/drivers/staging/vt6656/power.c
@@ -233,9 +233,8 @@ void PSvSendPSPOLL(struct vnt_private *pDevice)
pTxPacket->cbPayloadLen = 0;
/* log failure if sending failed */
- if (csMgmt_xmit(pDevice, pTxPacket) != CMD_STATUS_PENDING) {
+ if (csMgmt_xmit(pDevice, pTxPacket) != CMD_STATUS_PENDING)
DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO "Send PS-Poll packet
failed..\n");
- }
}
/*
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Staging: vt6656: fix code indenting error in power.c
This patch fixes a code indentation error found by checkpatch.pl where a line was indented with spaces instead of tabs Signed-off-by: Johannes Löthberg --- drivers/staging/vt6656/power.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6656/power.c b/drivers/staging/vt6656/power.c index 3002061..a14a2bf 100644 --- a/drivers/staging/vt6656/power.c +++ b/drivers/staging/vt6656/power.c @@ -268,7 +268,7 @@ int PSbSendNullPacket(struct vnt_private *pDevice) + sizeof(struct vnt_tx_mgmt)); flags = WLAN_SET_FC_FTYPE(WLAN_TYPE_DATA) | -WLAN_SET_FC_FSTYPE(WLAN_FSTYPE_NULL); + WLAN_SET_FC_FSTYPE(WLAN_FSTYPE_NULL); if (pDevice->bEnablePSMode) flags |= WLAN_SET_FC_PWRMGT(1); -- 1.8.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel/modsign_certificate.S: use real contents instead of macro GLOBAL()
For some architectures, tool chain is not smart enough to recognize the macro with multiple lines (e.g. arc tool chain), and for common ".S" file, this kind of macro is also rarely used. So expand the related contents of macro to let it pass compiling (can use "arc-elf32-objdump -x" to know about it). The related error (allmodconfig for arc): LD init/built-in.o kernel/built-in.o: In function `load_module_signing_keys': kernel/modsign_pubkey.c:66: undefined reference to `modsign_certificate_list' kernel/modsign_pubkey.c:71: undefined reference to `modsign_certificate_list_end' kernel/modsign_pubkey.c:67: undefined reference to `modsign_certificate_list_end' The related tool chain information: [root@gchenlinux linux-next]# arc-elf32-as -v GNU assembler version 2.23.2 (arc-elf32) using BFD version (GNU Binutils) 2.23.2 [root@gchenlinux linux-next]# arc-elf32-ld -v GNU ld (GNU Binutils) 2.23.2 [root@gchenlinux linux-next]# arc-elf32-gcc -v Using built-in specs. COLLECT_GCC=arc-elf32-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arc-elf32/4.8.0/lto-wrapper Target: arc-elf32 Configured with: ../gcc/configure --without-header --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 : (reconfigured) ../gcc/configure --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 : (reconfigured) ../gcc/configure --without-header --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 --disable-multilib --with-headers=../newlib/newlib/libc/include Thread model: single gcc version 4.8.0 (GCC) Signed-off-by: Chen Gang --- kernel/modsign_certificate.S | 10 -- 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S index 4a9a86d..1967dcd 100644 --- a/kernel/modsign_certificate.S +++ b/kernel/modsign_certificate.S @@ -1,12 +1,10 @@ #include -#define GLOBAL(name) \ - .globl VMLINUX_SYMBOL(name);\ - VMLINUX_SYMBOL(name): - .section ".init.data","aw" -GLOBAL(modsign_certificate_list) + .globl VMLINUX_SYMBOL(modsign_certificate_list) +VMLINUX_SYMBOL(modsign_certificate_list): .incbin "signing_key.x509" .incbin "extra_certificates" -GLOBAL(modsign_certificate_list_end) + .globl VMLINUX_SYMBOL(modsign_certificate_list_end) +VMLINUX_SYMBOL(modsign_certificate_list_end): -- 1.7.7.6 -- 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] reiserfs: remove duplicate define
Hi Jan, Thank you for your review! On 10/23/2013 11:50 AM, Jan Kara wrote: > On Mon 21-10-13 09:54:57, Michael Opdenacker wrote: >> This patch removes a duplicate define in fs/reiserfs/reiserfs.h > Hum, so the duplicate define certainly isn't nice but it's really a > result of a namespace collision between return codes of two different (sets > of) functions. So deleting the duplicate isn't really solving the problem, > just hiding it. So I'd prefer more one of the following two solutions: > 1) Just ignore the problem. Reiserfs is mostly dead and this isn't likely to > cause any subtle issues. > 2) Prefix the return codes somehow so that those two error namespaces don't > clash. As a bonus you can convert defines to enums but I'm not sure that's > worth the bother (prefixing is a simple search & replace so that should be > trivial, well except for the CARRY_ON case). I like your second solution, adding a prefix to avoid collisions between two error namespaces, all the more as this looks like a good solution for similar issues that I found. Thanks again, Cheers, Michael. -- Michael Opdenacker, CEO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 -- 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] scripts/checkkconfig.py: find unused Kconfig parameters
This is the first version of a script to look for
Kconfig parameters which are still defined but no longer
used in the kernel source code.
The script may be extended in the future to perform
more checks. This explains why a rather generic name was chosen.
Several issues have already been reported and fixed
thanks to the use of this script. It is time to share it now!
Signed-off-by: Michael Opdenacker
---
scripts/checkkconfig.py | 131
1 file changed, 131 insertions(+)
create mode 100755 scripts/checkkconfig.py
diff --git a/scripts/checkkconfig.py b/scripts/checkkconfig.py
new file mode 100755
index 000..4155656
--- /dev/null
+++ b/scripts/checkkconfig.py
@@ -0,0 +1,131 @@
+#!/usr/bin/env python
+#
+# Copyright 2013 Free Electrons
+# Michael Opdenacker
+#
+# Look for issues in Kconfig files
+#
+# This first version supports:
+# - Looking for unused Kconfig parameters
+#
+# Usage: scripts/checkkconfig.py
+#
+# Licensed under the terms of the GNU GPL License version 2
+
+import fnmatch
+import os
+import subprocess
+
+
+# Parse Kconfig files
+
+
+def parse_kconfig(file):
+
+global has_select, choice_type, source_file
+
+current_param = ''
+in_choice = False
+
+with open(file, 'r') as f:
+ for line in f:
+words = line.split()
+
+if len(words) != 0:
+ key = words[0]
+
+ if len(words) == 1:
+
+ if key == 'choice':
+ in_choice = True
+ elif key == 'endchoice':
+ in_choice = False
+
+ elif len(words) > 1:
+
+ if key == 'config' or key == 'menuconfig':
+ current_param = words[1]
+
+ has_select[current_param] = False
+ choice_type[current_param] = in_choice
+ source_file[current_param] = file
+
+ elif key == 'select' and words[1] != '':
+
+ has_select[current_param] = True
+
+
+# Find occurrences of a parameter
+
+
+def count_param(param):
+
+global source_file, bad_params_in_file
+
+if os.path.isdir('.git'):
+ # Use git grep when available
+ count = subprocess.check_output('git grep ' + param + '| grep -v
defconfig | wc -l', shell=True)
+else:
+ # Fallback to regular grep
+ count = subprocess.check_output('grep -R ' + param + ' . | grep -v
defconfig | wc -l', shell=True)
+
+num = int(count.strip())
+
+if num == 1:
+ 'WARNING: parameter ' + param + ' is used nowhere'
+
+ file=source_file[param]
+
+ if bad_params_in_file.has_key(file):
+ bad_params_in_file[file].append(param)
+ else:
+ bad_params_in_file[file]=[param]
+
+
+
+# Main program
+
+
+global has_select, choice_type, source_file, bad_params_in_file
+
+has_select = dict()
+choice_type = dict()
+source_file = dict()
+bad_params_in_file = dict()
+
+kconfig_files = []
+
+for root, dirnames, filenames in os.walk('.'):
+for filename in fnmatch.filter(filenames, 'Kconfig*'):
+ kconfig_files.append(os.path.join(root, filename))
+
+print 'INFO: processing Kconfig files...'
+
+for f in kconfig_files:
+parse_kconfig(f)
+
+total = len(has_select)
+count = 0
+old_percentage = -1
+
+for param in has_select.keys():
+
+# Progress information... running the script can take hours!
+
+count += 1
+percentage = int((100*count)/total)
+
+if percentage > old_percentage:
+ print 'INFO: checking kconfig parameter %d / %d (%d %%)' % (count,
total, percentage)
+ old_percentage = percentage
+
+# Ignore parameters with select dependencies
+# Also ignore parameters inside 'choice ... endchoice'
+# All of them are valid, even if they have only one instance
+
+if not(has_select[param]) and not(choice_type[param]):
+ count_param(param)
+
+for file in bad_params_in_file.keys():
+print 'File: ' + file
+print bad_params_in_file[file]
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Does PHY UTMI data width belong to DWC2 or PHY binding?
Hi,
On Wednesday 23 October 2013 08:12 PM, Matt Porter wrote:
> On Tue, Oct 22, 2013 at 04:38:52PM -0500, Rob Herring wrote:
>> On 10/22/2013 06:25 AM, Matt Porter wrote:
>>> On Tue, Oct 22, 2013 at 12:48:29PM +0200, Matthijs Kooijman wrote:
Hi Kishon,
On Mon, Oct 21, 2013 at 02:57:26PM +0530, Kishon Vijay Abraham I wrote:
> I think it makes sense to keep the data width property in the dwc2 node
> itself.
> I mean it describes how the dwc2 IP is configured in that particular SoC
> (given
> that it can be either <8> or <16>).
If I'm reading the RT3052 datasheet correctly (GHWCFG4 register), the IP
can be configured for 8, 16 or 8 _and_ 16. In the latter case, the "8
and 16 supported" would make sense as a property of dwc2 (though this
value should be autodetectable through GHWCFG4), while the actual 8 or
16 supported by the PHY would make sense as property of a phy.
>>>
>>> There would be no value in adding a property for an already detectable
>>> value to dwc2's binding. To be honest, it's pretty much useless
>>> information due to the existence of the "8 and 16" option.
>>>
Note sure if this is really useful in practice as well, or if just
setting the actual width to use on dwc2 makes more sense...
>>>
>>> The GHWCFG4 information itself is not useful in practice, as described
>>> in the original thread: https://lkml.org/lkml/2013/10/10/477
>>>
>>> It's certainly useful in practice to have this width property in either
>>> the dwc2 or the phy binding. One can make a case for either. As I
>>> mentioned in the original post, if we put it in the phy binding we'll be
>>> updating the generic phy binding. We'll then need an api added into the
>>> generic phy framework to fetch the width of a phy.
>>>
>>> Both cases are doable and trivial, we just need the canonical decision
>>> from a DT maintainer as to where the property belongs. Given that they
>>> are in ARM ksummit, I'm not expecting to hear anything right this
>>> moment. :)
>>
>> The host can support both, so it is not a property of the host and is a
>> property of the phy. It is no different than what mode a SPI slave
>> requires or whether an i2c slave supports 8 or 10-bit addressing. Those
>> examples are all 1 to many rather than 1 to 1 where it doesn't really
>> matter, but the same logic applies.
>
> Makes good sense, thanks.
>
> In this case, given the PHY ownership of width, we can completely avoid
> any DT properties. The generic phy compliant BCM Kona phy driver can
> report via the generic phy framework that it is 8-bit wide. There's no
> support for this type of thing now but it's pretty trivial to add.
>
> I went ahead and did a quick proof-of-concept that adds a free-form
> phy attributes struct for the generic phy. Given that generic phys can
> be for any transmission technology this could be filled with a jumble
> unrelated and often unpopulated attributes over time. In any case, the
> below patch allows the phy provider to choose to specify utmi_width and
> a controller driver that cares can use phy_get_attrs() to fetch the
> optional phy attributes and use the utmi_width field if applicable.
>
> Kishon: I'll start a separate thread to discuss what approach you'd like
> to see in the generic phy framework to manage this.
>
> -Matt
>
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 6d72269..b763d7b 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -38,6 +38,14 @@ struct phy_ops {
> };
>
> /**
> + * struct phy_attrs - represents phy attributes
> + * @utmi_width: Data path width implemented by UTMI PHY
> + */
> +struct phy_attrs {
> + int utmi_width;
> +};
> +
> +/**
> * struct phy - represents the phy device
> * @dev: phy device
> * @id: id of the phy device
> @@ -51,6 +59,7 @@ struct phy {
> struct device dev;
> int id;
> const struct phy_ops*ops;
> + struct phy_attrs*attrs;
> struct phy_init_data*init_data;
> struct mutexmutex;
> int init_count;
> @@ -127,6 +136,9 @@ int phy_init(struct phy *phy);
> int phy_exit(struct phy *phy);
> int phy_power_on(struct phy *phy);
> int phy_power_off(struct phy *phy);
> +static inline struct phy_attrs *phy_get_attrs(struct phy *phy) {
> + return phy->attrs;
> +};
I'd prefer to have phy_set_bus_width and phy_get_bus_width instead.
Thanks
Kishon
> struct phy *phy_get(struct device *dev, const char *string);
> struct phy *devm_phy_get(struct device *dev, const char *string);
> void phy_put(struct phy *phy);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/63] Basic scheduler support for automatic NUMA balancing V8
Mel Gorman suse.de> writes: > > Weighing in at 63 patches makes the term "basic" in the series title is > a misnomer. > > This series still has roughly the same goals as previous versions. It > reduces overhead of automatic balancing through scan rate reduction > and the avoidance of TLB flushes. It selects a preferred node and moves > tasks towards their memory as well as moving memory toward their task. It > handles shared pages and groups related tasks together. Some problems such > as shared page interleaving and properly dealing with processes that are > larger than a node are being deferred. > > It is still based on 3.11 because that's what I was testing against. If > we can agree this should be merged to -tip for testing I'll rebase to deal > with any scheduler conflicts but for now I do not want to invalidate other > peoples testing. The only obvious thing that is missing is hotplug handling. > Peter is currently working on reducing [get|put]_online_cpus overhead so > that it can be added to migrate_swap. > > Peter, some of your patches are missing signed-offs-by -- 4-5, 43 and 55. > > Changelog since V7 > o THP migration race and pagetable insertion fixes > o Do no handle PMDs in batch > o Shared page migration throttling > o Various changes to how last nid/pid information is recorded > o False pid match sanity checks when joining NUMA task groups > o Adapt scan rate based on local/remote fault statistics > o Period retry of migration to preferred node > o Limit scope of system-wide search > o Schedule threads on the same node as process that created them > o Cleanup numa_group on exec > > Changelog since V6 > o Group tasks that share pages together > o More scan avoidance of VMAs mapping pages that are not likely to migrate > o cpunid conversion, system-wide searching of tasks to balance with > > Changelog since V6 > o Various TLB flush optimisations > o Comment updates > o Sanitise task_numa_fault callsites for consistent semantics > o Revert some of the scanning adaption stuff > o Revert patch that defers scanning until task schedules on another node > o Start delayed scanning properly > o Avoid the same task always performing the PTE scan > o Continue PTE scanning even if migration is rate limited > > Changelog since V5 > o Add __GFP_NOWARN for numa hinting fault count > o Use is_huge_zero_page > o Favour moving tasks towards nodes with higher faults > o Optionally resist moving tasks towards nodes with lower faults > o Scan shared THP pages > > Changelog since V4 > o Added code that avoids overloading preferred nodes > o Swap tasks if nodes are overloaded and the swap does not impair locality > > Changelog since V3 > o Correct detection of unset last nid/pid information > o Dropped nr_preferred_running and replaced it with Peter's load balancing > o Pass in correct node information for THP hinting faults > o Pressure tasks sharing a THP page to move towards same node > o Do not set pmd_numa if false sharing is detected > > Changelog since V2 > o Reshuffle to match Peter's implied preference for layout > o Reshuffle to move private/shared split towards end of series to make it > easier to evaluate the impact > o Use PID information to identify private accesses > o Set the floor for PTE scanning based on virtual address space scan rates > instead of time > o Some locking improvements > o Do not preempt pinned tasks unless they are kernel threads > > Changelog since V1 > o Scan pages with elevated map count (shared pages) > o Scale scan rates based on the vsz of the process so the sampling of the > task is independant of its size > o Favour moving towards nodes with more faults even if it's not the > preferred node > o Laughably basic accounting of a compute overloaded node when selecting > the preferred node. > o Applied review comments > > This series integrates basic scheduler support for automatic NUMA balancing. > It was initially based on Peter Ziljstra's work in "sched, numa, mm: > Add adaptive NUMA affinity support" but deviates too much to preserve > Signed-off-bys. As before, if the relevant authors are ok with it I'll > add Signed-off-bys (or add them yourselves if you pick the patches up). > There has been a tonne of additional work from both Peter and Rik van Riel. > > Some reports indicate that the performance is getting close to manual > bindings for some workloads but your mileage will vary. As before, the > intention is not to complete the work but to incrementally improve mainline > and preserve bisectability for any bug reports that crop up. > > Patch 1 is a monolithic dump of patches thare are destined for upstream that > this series indirectly depends upon. > > Patches 2-3 adds sysctl documentation and comment fixlets > > Patch 4 avoids accounting for a hinting fault if another thread handled the > fault in parallel > > Patches 5-6 avoid races with parallel THP migration and THP splits. > > Patch 7 corrects a THP NUMA
Re: [tpmdd-devel] [PATCH] tpm: MAINTAINERS: Add myself as tpm maintainer
> These would have been posted as patch numbers 8 through 13 in the > original series. > > I think what happened is at this point in the series module compile > broke. That is fixed now in the for-james pull, so the rest of the > series should be looked at. > > Peter's checkpatch clean up will create some minor conflicts, so I > should probably resend the lot after rebasing it. > If you rebase and resend I will commit to reviewing them. -- 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: Re: [tpmdd-devel] [PATCH] tpm: MAINTAINERS: Add myself as tpm maintainer
On Wed, Oct 23, 2013 at 11:01:19PM -0500, Ashley Lai wrote: > > > Agreed, there are still lots of patches to go before the subsystem > > meets the current kernel standard.. > > > > Speaking of which, has anyone looked at the rest of my series?? Shall > > I repost it? > > Jason, > Are you referring to the for-tpm branch on github? > https://github.com/jgunthorpe/linux/commits/for-tpm > Peter already submitted most of the patches to James from this branch. > Let us know which series need to be review. All of those patches in for-tpm have gone to James. However, the original series I posted included 5 additional patches that have received no comment, available on: https://github.com/jgunthorpe/linux/commits/tpm-devel Jason Gunthorpe: tpm: Pull everything related to /dev/tpmX into tpm-dev.c tpm: Pull everything related to sysfs into tpm-sysfs.c tpm: Create a tpm_class_ops structure and use it in the drivers tpm: Use the ops structure instead of a copy in tpm_vendor_specific tpm: Make tpm-dev allocate a per-file structure These would have been posted as patch numbers 8 through 13 in the original series. I think what happened is at this point in the series module compile broke. That is fixed now in the for-james pull, so the rest of the series should be looked at. Peter's checkpatch clean up will create some minor conflicts, so I should probably resend the lot after rebasing it. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] sched: Aggressive balance in domains whose groups share package resources
Hi Peter,
On 10/23/2013 03:53 AM, Peter Zijlstra wrote:
> On Mon, Oct 21, 2013 at 05:15:02PM +0530, Vaidyanathan Srinivasan wrote:
>> kernel/sched/fair.c | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 828ed97..bbcd96b 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5165,6 +5165,8 @@ static int load_balance(int this_cpu, struct rq
>> *this_rq,
>> {
>> int ld_moved, cur_ld_moved, active_balance = 0;
>> struct sched_group *group;
>> +struct sched_domain *child;
>> +int share_pkg_res = 0;
>> struct rq *busiest;
>> unsigned long flags;
>> struct cpumask *cpus = __get_cpu_var(load_balance_mask);
>> @@ -5190,6 +5192,10 @@ static int load_balance(int this_cpu, struct rq
>> *this_rq,
>>
>> schedstat_inc(sd, lb_count[idle]);
>>
>> +child = sd->child;
>> +if (child && child->flags & SD_SHARE_PKG_RESOURCES)
>> +share_pkg_res = 1;
>> +
>> redo:
>> if (!should_we_balance(&env)) {
>> *continue_balancing = 0;
>> @@ -5202,6 +5208,7 @@ redo:
>> goto out_balanced;
>> }
>>
>> +redo_grp:
>> busiest = find_busiest_queue(&env, group);
>> if (!busiest) {
>> schedstat_inc(sd, lb_nobusyq[idle]);
>> @@ -5292,6 +5299,11 @@ more_balance:
>> if (!cpumask_empty(cpus)) {
>> env.loop = 0;
>> env.loop_break = sched_nr_migrate_break;
>> +if (share_pkg_res &&
>> +cpumask_intersects(cpus,
>> +to_cpumask(group->cpumask)))
>
> sched_group_cpus()
>
>> +goto redo_grp;
>> +
>> goto redo;
>> }
>> goto out_balanced;
>> @@ -5318,9 +5330,15 @@ more_balance:
>> */
>> if (!cpumask_test_cpu(this_cpu,
>> tsk_cpus_allowed(busiest->curr))) {
>> +cpumask_clear_cpu(cpu_of(busiest), cpus);
>> raw_spin_unlock_irqrestore(&busiest->lock,
>> flags);
>> env.flags |= LBF_ALL_PINNED;
>> +if (share_pkg_res &&
>> +cpumask_intersects(cpus,
>> +to_cpumask(group->cpumask)))
>> +goto redo_grp;
>> +
>> goto out_one_pinned;
>> }
>
> Man this retry logic is getting annoying.. isn't there anything saner we
> can do?
Let me give this a thought and get back.
Regards
Preeti U Murthy
>
--
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: Re: [tpmdd-devel] [PATCH] tpm: MAINTAINERS: Add myself as tpm maintainer
> Agreed, there are still lots of patches to go before the subsystem > meets the current kernel standard.. > > Speaking of which, has anyone looked at the rest of my series?? Shall > I repost it? Jason, Are you referring to the for-tpm branch on github? https://github.com/jgunthorpe/linux/commits/for-tpm Peter already submitted most of the patches to James from this branch. Let us know which series need to be review. Thanks, --Ashley Lai -- 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] arc: kernel: kgdb: add default implementation for kgdb_roundup_cpus()
arc supports kgdb, but need update -- add function kgdb_roundup_cpus(),
or can not pass compiling. At present, add the simple generic one just
like other architectures(e.g. tile, mips ...).
The related error (with allmodconfig):
kernel/built-in.o: In function `kgdb_cpu_enter':
kernel/debug/debug_core.c:580: undefined reference to `kgdb_roundup_cpus'
Signed-off-by: Chen Gang
---
arch/arc/kernel/kgdb.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index a7698fb..a2ff5c5 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -196,6 +196,18 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long
ip)
instruction_pointer(regs) = ip;
}
+static void kgdb_call_nmi_hook(void *ignored)
+{
+ kgdb_nmicallback(raw_smp_processor_id(), NULL);
+}
+
+void kgdb_roundup_cpus(unsigned long flags)
+{
+ local_irq_enable();
+ smp_call_function(kgdb_call_nmi_hook, NULL, 0);
+ local_irq_disable();
+}
+
struct kgdb_arch arch_kgdb_ops = {
/* breakpoint instruction: TRAP_S 0x3 */
#ifdef CONFIG_CPU_BIG_ENDIAN
--
1.7.7.6
--
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: [f2fs-dev] [PATCH] f2fs: check all ones or zeros bitmap with integer data type for better mount performance
Hi Kim,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Wednesday, October 23, 2013 5:32 PM
> To: Chao Yu
> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-fsde...@vger.kernel.org;
> linux-kernel@vger.kernel.org; '谭姝'
> Subject: RE: [f2fs-dev] [PATCH] f2fs: check all ones or zeros bitmap with
> integer
> data type for better mount performance
>
> Hi,
>
> 2013-10-23 (수), 11:23 +0800, Chao Yu:
> > Hi, Kim:
> >
> > > -Original Message-
> > > From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> > > Sent: Tuesday, October 22, 2013 8:24 PM
> > > To: Chao Yu
> > > Cc: linux-f2fs-de...@lists.sourceforge.net;
> > > linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; 谭姝
> > > Subject: Re: [f2fs-dev] [PATCH] f2fs: check all ones or zeros bitmap
> > > with integer data type for better mount performance
> > >
> > > Hi,
> > >
> > > 2013-10-22 (화), 17:28 +0800, Chao Yu:
> > > > Previously, check_block_count check valid_map with bit data type
> > > > in common scenario that sit has all ones or zeros bitmap, it makes
> > > > low mount performance.
> > > > So let's check the special bitmap with integer data type instead
> > > > of the bit one.
> > > >
> > > > Signed-off-by: Tan Shu
> > > > Signed-off-by: Yu Chao
> > > > ---
> > > > fs/f2fs/segment.h | 13 +
> > > > 1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index
> > > > 7f94d78..d43ab9f 100644
> > > > --- a/fs/f2fs/segment.h
> > > > +++ b/fs/f2fs/segment.h
> > > > @@ -543,6 +543,7 @@ static inline void check_block_count(struct
> > > > f2fs_sb_info *sbi, {
> > > > struct f2fs_sm_info *sm_info = SM_I(sbi);
> > > > unsigned int end_segno = sm_info->segment_count - 1;
> > > > + int *valid_map = (int *)raw_sit->valid_map;
> > > > int valid_blocks = 0;
> > > > int i;
> > > >
> > > > @@ -552,6 +553,19 @@ static inline void check_block_count(struct
> > > > f2fs_sb_info *sbi,
> > > > /* check boundary of a given segment number */
> > > > BUG_ON(segno > end_segno);
> > > >
> > > > + /* check all ones or zeros valid_map */
> > > > + if (GET_SIT_VBLOCKS(raw_sit) == 0) {
> > > > + for (i = 0; i < SIT_VBLOCK_MAP_SIZE / sizeof(int); i++)
> > >
> > > We cannot guarantee all the time that SIT_VBLOCK_MAP_SIZE is
> > > multiple of sizeof(int).
> > Well, It's really large changes for f2fs if SIT_VBLOCK_MAP_SIZE value is
> > being
> modified.
>
> But, it can be changed.
> Please do not add any unnecessary assumption.
Got it, sorry for the unmeaning assumption.
>
> >
> > > How about using memcmp() with __u8?
> > Do you mean that we can alloc all zeros or ones memory in
> > SIT_VBLOCK_MAP_SIZE size, then memcmp() it with sit bitmap by __u8?
>
> Yap.
> Ah, but there is another one.
> It would be better to use find_next_bit_le() and find_next_zero_bit_le().
> Any idea?
Good point.
I try to use memcmp(bitmap, bitmap+1, size-1) and bitmap[0],
But yours got better performance and readable.
Thanks.
>
> >
> > >
> > > > + if (unlikely(valid_map[i] != 0))
> > > > + BUG();
> > > > + return;
> > > > + } else if (GET_SIT_VBLOCKS(raw_sit) == sbi->blocks_per_seg) {
> > > > + for (i = 0; i < SIT_VBLOCK_MAP_SIZE / sizeof(int); i++)
> > > > + if (unlikely(valid_map[i] != -1))
> > > > + BUG();
> > > > + return;
> > > > + }
> > > > +
> > > > /* check bitmap with valid block count */
> > > > for (i = 0; i < sbi->blocks_per_seg; i++)
> > > > if (f2fs_test_bit(i, raw_sit->valid_map))
> > > > ---
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe
> > > > linux-fsdevel" in the body of a message to
> > > > majord...@vger.kernel.org More majordomo info at
> > > > http://vger.kernel.org/majordomo-info.html
> > >
> > > --
> > > Jaegeuk Kim
> > > Samsung
> >
>
> --
> Jaegeuk Kim
> Samsung
--
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: Re: [tpmdd-devel] [PATCH] tpm: MAINTAINERS: Add myself as tpm maintainer
On Thu, Oct 24, 2013 at 01:10:28AM +0200, Peter Huewe wrote: > Thanks for the offer - I think I can handle the maintenance effort > itself, HOWEVER I would really like to see you sticking around here > as a reviewer, due to your experience, especially for the stuff I'm > submitting. Agreed, there are still lots of patches to go before the subsystem meets the current kernel standard.. Speaking of which, has anyone looked at the rest of my series?? Shall I repost it? Thanks, Jason -- 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] audit: remove useless code in audit_enable
Since kernel parameter is operated before
initcall, so the audit_initialized must be
AUDIT_UNINITIALIZED or DISABLED in audit_enable.
Signed-off-by: Gao feng
---
kernel/audit.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 50fdcba..b7269a4 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -927,17 +927,8 @@ static int __init audit_enable(char *str)
if (!audit_default)
audit_initialized = AUDIT_DISABLED;
- printk(KERN_INFO "audit: %s", audit_default ? "enabled" : "disabled");
-
- if (audit_initialized == AUDIT_INITIALIZED) {
- audit_enabled = audit_default;
- audit_ever_enabled |= !!audit_default;
- } else if (audit_initialized == AUDIT_UNINITIALIZED) {
- printk(" (after initialization)");
- } else {
- printk(" (until reboot)");
- }
- printk("\n");
+ printk(KERN_INFO "audit: %s\n", audit_default ?
+ "enabled (after initialization)" : "disabled (until reboot)");
return 1;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arc: kernel: add default extern variable 'screen_info' in "setup.c"
On 10/23/2013 09:47 PM, Vineet Gupta wrote:
> Apologies for top posting !
>
Not at all.
> NAK.
>
OK, thanks. At least this patch is incorrect.
> ARC will never have VGA console. You need to add !ARC to relevant Kconfig.
> However that approach is frowned upon in general. The current way to doing
> such things is to define a new Kconfig item which relevant arches can select.
Hmm... it seems necessary to discuss about the 2 fixing ways (which
already had a long discussion in ARM64):
- add !ARC in related place, just like another (almost 30-40%) architectures
done.
- add a new Kconfig item (e.g. HAVE_VGA_CONSOLE), and let the left (almost
50%) architectures which use VGA_CONSOLE to set it.
Catalin, Will, Geert (it seems also include you) prefer 2nd way, but I
prefer 1st, my reasons are below, please help check:
- 1st way need add some (10-20%) of architectures in one place, which belongs
to local wide.
2nd way will let the left (almost 50%) architectures need add
HAVE_VGA_CONSOLE in various place, which belongs to arch global wide.
- 1st way will let most (80-90%) of architectures don't care about VGA_CONSOLE
(50% need it, 30-40% already mark it in the same place).
2nd way will let 50% architectures care about VGA_CONSOLE (although can let
the left 10-20% architectures do nothing -- not care about it).
- 1st way is still easy, sustainable, and clear enough in local wide fixing
(although maybe it is not the best, or clearest way).
2nd way is also easy, sustainable and clear enough (maybe the best, or
clearest for 10-20% architectures), but it will let the fix in global wide
All together, if we can bear and sustainable, I always prefer to fix it
in local wide, not lead to arch global (especially 80-90% architectures
already followed 1st way).
BTW: for me, if less than 20% architectures need XXX, we can trigger
defining a new Kconfig item (e.g. HAVE_XXX), or just follow original
implementation.
Thanks.
>
> -Vineet
>
> From: Chen Gang [gang.c...@asianux.com]
> Sent: Wednesday, October 23, 2013 4:39 PM
> To: vgu...@synopsys.com; Arnd Bergmann; sachin.ka...@linaro.org; Paul
> Gortmaker; James Hogan
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH] arc: kernel: add default extern variable 'screen_info' in
> "setup.c"
>
> Add default 'screen_info' just like some of other architectures (e.g.
> cris, score, sh, tile), or can not pass compiling.
>
> The related error (with allmodconfig):
>
> drivers/built-in.o: In function `vgacon_save_screen':
> drivers/video/console/vgacon.c:1347: undefined reference to `screen_info'
> drivers/video/console/vgacon.c:1348: undefined reference to `screen_info'
> drivers/built-in.o: In function `vgacon_resize':
> drivers/video/console/vgacon.c:1314: undefined reference to `screen_info'
> drivers/video/console/vgacon.c:1315: undefined reference to `screen_info'
> drivers/built-in.o: In function `vgacon_switch':
> drivers/video/console/vgacon.c:820: undefined reference to `screen_info'
> drivers/built-in.o:drivers/video/console/vgacon.c:840: more undefined
> references to `screen_info' follow
>
>
> Signed-off-by: Chen Gang
> ---
> arch/arc/kernel/setup.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
> index 2c68bc7e..07130f3 100644
> --- a/arch/arc/kernel/setup.c
> +++ b/arch/arc/kernel/setup.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -37,6 +38,8 @@ struct task_struct *_current_task[NR_CPUS]; /* For stack
> switching */
>
> struct cpuinfo_arc cpuinfo_arc700[NR_CPUS];
>
> +struct screen_info screen_info;
> +
>
> void read_arc_build_cfg_regs(void)
> {
> --
> 1.7.7.6
>
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf: Fix library detection when building without libelf
When I attempt to build perf on a system with slang but without libelf, 'make' would wrongly complain that the slang library could not be found. It turns out that this was happening because we are not filtering -lelf from EXTLIBS early enough. As a result, the library test for slang (ditto for gtk, libaudit, etc) erroneously passes -lelf to try-cc, which of course fails on a system without libelf. This patch makes the filtering of -lelf from EXTLIBS occur right after testing for libelf support, so that the subsequent library tests will not erroneously pass -lelf to try-cc when building without libelf support. Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Signed-off-by: Patrick Palka --- tools/perf/Makefile| 2 -- tools/perf/config/Makefile | 4 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/perf/Makefile b/tools/perf/Makefile index 64c043b..94635c8 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -443,8 +443,6 @@ ifneq ($(OUTPUT),) endif ifdef NO_LIBELF -EXTLIBS := $(filter-out -lelf,$(EXTLIBS)) - # Remove ELF/DWARF dependent codes LIB_OBJS := $(filter-out $(OUTPUT)util/symbol-elf.o,$(LIB_OBJS)) LIB_OBJS := $(filter-out $(OUTPUT)util/dwarf-aux.o,$(LIB_OBJS)) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 5f6f9b3..1748767 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -174,6 +174,10 @@ else endif # SOURCE_LIBELF endif # NO_LIBELF +ifdef NO_LIBELF +EXTLIBS := $(filter-out -lelf,$(EXTLIBS)) +endif + ifndef NO_LIBELF CFLAGS += -DLIBELF_SUPPORT FLAGS_LIBELF=$(CFLAGS) $(LDFLAGS) $(EXTLIBS) -- 1.8.4.rc3 -- 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: Re: Re: Re: [PATCH] futex: Remove the owner check when waking task in handle_futex_death
Zhang Yi wrote on 2013/10/08 13:59:36: > Re: Re: Re: [PATCH] futex: Remove the owner check when waking task in > handle_futex_death > > Darren Hart wrote on 2013/09/27 23:32:27: > > > > Re: Re: [PATCH] futex: Remove the owner check when waking task in > > handle_futex_death > > > > > > > > The earlier patch cannot solve another problem: > > > The owner wakes the next waiter through normal unlocking which make the > > > futex value as zero, the waked task exits before actually locking the > > > mutex. > > > In this case, the owner doesn't call handle_futex_death() and the waked > > > task > > > doesn't call futex_wake() when they are dying. The rest waiters will still > > > block as the same. > > > > > > This is also the reason that I drop the owner and FUTEX_WAITERS check, > > > because the futex value can be zero at that time. > > > > > > > If the FUTEX_WAITERS bit is not set, there are no waiters, and thus no > > need to wake. I understand why you dropped the OWNER check, but I'm not > > following this one. Where would the futex word be set from having > > waiters to zero when there might still be waiters pending? > > > > > > -- > > Darren Hart > > Intel Open Source Technology Center > > Yocto Project - Linux Kernel > > > > > I have drawn a diagram as below: > >process1 | process2 >- > | thread1 | thread2 | thread3 >- > t1|pthread_mutex_lock: | | > | __lock=self| | > | | | > t2| |pthread_mutex_lock:| > | |__lock|=FUTEX_WAITERS > | | syscall futex_wait| > | | | > t3| | |pthrea_mutex_lock: > | | |__lock|=FUTEX_WAITERS > | | | syscall futex_wait > | | | > t4|pthread_mutex_unlock:| | > | __lock=0 | | > | syscall futex_wake | waked | > | | | > t5| exit|exit: | > | | handle_futex_death| > --- > t6| |pthread_mutex_lock:| > | |__lock=self|FUTEX_WAITERS > > 1, At time t4, in the unlocking process of glibc, it clears the FUTEX_WAITERS > bit before > calling futex_wake syscall. > > 2, At time t5, thread2 cannot know if the FUTEX_WAITERS bit was set. > > 3, Time t6 is expected but can never be true. Are there any questions? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] firmware, fix request_firmware_nowait() freeze with no uevent
On Wed, Oct 23, 2013 at 10:08 PM, Prarit Bhargava wrote: > > > On 10/23/2013 09:21 AM, Ming Lei wrote: >> On Wed, Oct 23, 2013 at 8:02 PM, Prarit Bhargava wrote: >> >>> >>> After all this I completely forgot the problem I'm trying to solve here. >>> The >>> issue is that with HOTPLUG & request_microcode_nowait(), if the microcode >>> image >>> is not found (that is the file is not found on disk), then EACH cpu waits 1 >>> minute and it takes 2 hours for a 120 cpu box to load the microcode module. >>> >>> Which is terrible... so HOTPLUG doesn't work here. >>> >>> Let me back up Ming and see if you have a better solution for me. I have a >>> system that does not have the x86 microcode loaded on disk. I use the >>> microcode >>> module which calls request_firmware_nowait() to load the microcode image >>> and I >>> want it done as fast as possible. The microcode loader does not have a >>> uevent >>> so I'm not waiting on userspace for completion. >>> >>> How do I avoid the 60 second delay/cpu introduced in the microcode path? I >>> don't see one. If I use HOTPLUG I'm waiting 60 seconds. If I use NOHOTPLUG >>> AFAICT the loading function never will return. AFAICT the same issue arises >>> with the dell_rbu code -- it appears to never load the dell_rbu firmware. >> >> As I said, the 60 second delay is from udev, so that is the root cause. > > Okay, so then my other option is to use NOHOTPLUG. I've correctly modified it > to return and not wait for a NULL uevent. The synchronization between the > cont > function return and the actual application of the firmware is done in the > driver > (in my 2/2 patch) where I've used a completion struct. ... Am I still missing > something at this point? If you plan to use NOHOTPLUG to stop sending uevent to user space, you need to make sure all distributions(include old ones) do not require the notification previously, and you'd better to explain the microcode upgrading principle in a bit detail so that we can make sure it won't break the loading protocol between kernel and user space, at least current code is using request_fimrware() and the uevent is surely sent to userspace, right? > > I also have to make that change to the dell_rbu code because it too, is broken > the same way. That is, I can load the dell_rbu module and it just hangs > without > applying the firmware. Because userspace does not handle the request and write fw data to driver, how can you expect the driver to apply firmware? Anyway, you need Cc dell_rbu guys to make sure the change. > I'll submit a new version of these patches and we can continue from there. > > P. >> >> There are some workarounds for your reference: >> > > These are workarounds for an issue that arises in the kernel. Sorry, I don't understand, the root cause is surely from udev. Thanks, -- Ming Lei -- 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 v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter
(2013/10/24 0:51), Vivek Goyal wrote: On Wed, Oct 23, 2013 at 09:05:06AM +0900, HATAYAMA Daisuke wrote: [..] Do you literally mean a human at each boot will have to configure the kdump configuration files for passing disable_cpu_apic? Or do you envision the setting of disable_cpu_apic being put into the kdump initialization scripts? thanks Jerry Nearer to the former case, but this is not what a human should do. It's a cumbersome task. I think, on fedora/RHEL system for example, kdump service should check at each boot automatically. Hi Hatayama, So what information should I look for to prepare disable_cpu_apic=X in kdump script? Is BSP processor info exported to user space somewhere? Or assuming that processor 0 is BSP and corresponding apicid should be disabled in kdump kernel is good enough? Yes, this patch set assumes that the processor 0 is BSP and there's no other BSP. Because this patch cares about only one BSP processor, the disabled_cpu_apicid variable has unsigned int, not mask. I think this assumption is reasonable since doing it rigorously requires additional processing between 1st and 2nd kernels just as I explained in previous mail. I am looking at /proc/cpuinfo and following 3 fields seem interesting. processor: 0 apicid : 0 initial apicid : 0 What's the difference between apicid and "initial apicid". I guess initial apicid reflects the apicid number as set by firmware and then kernel can overwrite it and new number would be reflected in "apicid"? If that's the case, then I guess we should be looking at "apicid" of processor "0" and set that in disable_cpu_apic? Because that's the number kdump kernel boot should see in apic upon boot. Yes, that's fully correct, and please see 10.4.6 Local APIC ID in Intel SPG for details. BTW, we can use cpuid instruction in user-space, too. It might be more flexible to use cpuid than looking up /proc/cpuinfo. Also, there's one corner case that if we hot-remove cpu0, we cannot look up /proc/cpuinfo to get cpu0 information since /proc/cpunifo displays *online* cpus only. We cannot use even cpuid instruction for offline cpu. So, to address this corner case, we need to prepare new interface to see cpu0 initial apicid which is always available. My idea is for example to introduce the following file in sysfs: /sys/devices/system/cpu/cpu0/initial_apicid Under the current implementation, cpu0 hot-remove is software one and kernel must start with cpu0 in boot time. It's enough to assign the value of initial APIC ID in the boot time. The one in boot_cpu_data? -- Thanks. HATAYAMA, Daisuke -- 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] kernel/kallsyms.c: only show legal kernel symbol
Ming Lei writes: > Address of non-module kernel symbol should always be located > from CONFIG_PAGE_OFFSET on, so only show these legal kernel > symbols in /proc/kallsyms. > > On ARM, some symbols(see below) may drop in relocatable code, so > perf can't parse kernel symbols any more from /proc/kallsyms, this > patch fixes the problem. > > t __vectors_start > 0020 A cpu_v7_suspend_size > 1000 t __stubs_start > 1004 t vector_rst > 1020 t vector_irq > 10a0 t vector_dabt > 1120 t vector_pabt > 11a0 t vector_und > 1220 t vector_addrexcptn > 1224 t vector_fiq > 1224 T vector_fiq_offset > > The issue can be fixed in scripts/kallsyms.c too, but looks this > approach is easier. This fix looks hacky; if these symbols are not available, don't just remove them from /proc/kallsyms, but don't put them in the kernel at all. That way, they won't interfere with other kallsyms uses (eg. backtrace). Or, better, figure out a smart way of excluding them by knowing why these symbol addresses are wrong. Thanks, Rusty. > Cc: Russell King > Cc: linux-arm-ker...@lists.infradead.org > Cc: Rusty Russell > Cc: Chen Gang > Signed-off-by: Ming Lei > --- > kernel/kallsyms.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c > index 3127ad5..184f271 100644 > --- a/kernel/kallsyms.c > +++ b/kernel/kallsyms.c > @@ -543,7 +543,7 @@ static int s_show(struct seq_file *m, void *p) > tolower(iter->type); > seq_printf(m, "%pK %c %s\t[%s]\n", (void *)iter->value, > type, iter->name, iter->module_name); > - } else > + } else if (iter->value >= CONFIG_PAGE_OFFSET) > seq_printf(m, "%pK %c %s\n", (void *)iter->value, > iter->type, iter->name); > return 0; > -- > 1.7.9.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/
Deadlock in BPF JIT functions when running upowerd?
Hi, I've been observing a softlockup with 3.11.6 and 3.12-rc6. It looks like there's a deadlock occurring on purge_lock in __purge_vmap_area_lazy(). In short, the BPF JIT code has been changed[1] to call set_memory_r[ow]() when compiling and freeing JIT bytecode memory. It seems that it's possible for upowerd to be compiling some BPF program and call __purge_vmap_area_lazy, then the timer interrupt comes in (due to the IPI?) and a softirq calls bpf_jit_free, which also calls __purge_vmap_area_lazy. I'm not really sure who's at fault here--is this a BPF bug? [1] 314beb9bcabfd6b4542ccbced2402af2c6f6142a "x86: bpf_jit_comp: secure bpf jit against spraying attacks" --D Here's what 3.11.6 spits out; the 3.12-rc6 message has the same traceback. [ 52.370437] BUG: soft lockup - CPU#3 stuck for 22s! [upowerd:8359] [ 52.370440] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat_ipv4 xt_conntrack xt_CHECKSUM iptable_mangle fuse tun microcode nfsd nfs_acl exportfs auth_rpcgss nfs lockd sunrpc af_packet xt_physdev xt_hl ip6t_rt nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT xt_sctp xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables sch_fq_codel bridge stp llc lpc_ich mfd_core loop bcache dm_crypt zlib_deflate libcrc32c firewire_ohci firewire_core usb_storage mpt2sas scsi_transport_sas raid_class [ 52.370471] CPU: 3 PID: 8359 Comm: upowerd Not tainted 3.11.6-60-flax #1 [ 52.370472] Hardware name: OEM OEM/131-GT-E767, BIOS 6.00 PG 08/25/2011 [ 52.370474] task: 8806621f9700 ti: 88064b6a task.ti: 88064b6a [ 52.370475] RIP: 0010:[] [] _raw_spin_lock+0x32/0x40 [ 52.370480] RSP: 0018:88067fc63c10 EFLAGS: 0297 [ 52.370481] RAX: 0061 RBX: 88065a318600 RCX: [ 52.370483] RDX: 0062 RSI: 88067fc63ce0 RDI: 81ea42bc [ 52.370484] RBP: 88067fc63c10 R08: 81cdd608 R09: [ 52.370485] R10: 88067fc6d8e0 R11: R12: 88067fc63b88 [ 52.370486] R13: 816b7a47 R14: 88067fc63c10 R15: 88067fc63cd8 [ 52.370487] FS: 7f55fff297c0() GS:88067fc6() knlGS: [ 52.370488] CS: 0010 DS: ES: CR0: 80050033 [ 52.370489] CR2: 7f55fff47000 CR3: 00065dd1 CR4: 07e0 [ 52.370490] Stack: [ 52.370491] 88067fc63cb0 811955fd 0096 0347 [ 52.370494] 03c1 0001 [ 52.370496] 0033 88067fc63c58 88067fc63c58 0001 [ 52.370499] Call Trace: [ 52.370500] [ 52.370501] [] __purge_vmap_area_lazy+0x12d/0x4c0 [ 52.370507] [] vm_unmap_aliases+0x17c/0x190 [ 52.370512] [] change_page_attr_set_clr+0xb4/0x4a0 [ 52.370516] [] ? irq_exit+0x7e/0xb0 [ 52.370519] [] ? smp_irq_work_interrupt+0x34/0x40 [ 52.370522] [] set_memory_rw+0x2f/0x40 [ 52.370525] [] bpf_jit_free+0x2c/0x40 [ 52.370528] [] sk_filter_release_rcu+0x1a/0x30 [ 52.370532] [] rcu_process_callbacks+0x1e2/0x5b0 [ 52.370535] [] ? enqueue_hrtimer+0x39/0xf0 [ 52.370537] [] __do_softirq+0xe0/0x2f0 [ 52.370541] [] call_softirq+0x1c/0x30 [ 52.370543] [] do_softirq+0x55/0x90 [ 52.370545] [] irq_exit+0x8e/0xb0 [ 52.370547] [] smp_apic_timer_interrupt+0x4a/0x60 [ 52.370549] [] apic_timer_interrupt+0x67/0x70 [ 52.370550] [ 52.370552] [] ? default_send_IPI_mask_allbutself_phys+0xb4/0xe0 [ 52.370559] [] ? handle_pte_fault+0x567/0x920 [ 52.370561] [] ? rbt_memtype_copy_nth_element+0xc0/0xc0 [ 52.370563] [] physflat_send_IPI_allbutself+0x17/0x20 [ 52.370566] [] native_send_call_func_ipi+0x72/0x80 [ 52.370568] [] ? rbt_memtype_copy_nth_element+0xc0/0xc0 [ 52.370570] [] smp_call_function_many+0x1f4/0x290 [ 52.370572] [] smp_call_function+0x3a/0x60 [ 52.370574] [] ? rbt_memtype_copy_nth_element+0xc0/0xc0 [ 52.370576] [] on_each_cpu+0x38/0x80 [ 52.370578] [] flush_tlb_kernel_range+0x6d/0x70 [ 52.370581] [] __purge_vmap_area_lazy+0x446/0x4c0 [ 52.370584] [] ? ext4_file_open+0x75/0x1b0 [ 52.370586] [] vm_unmap_aliases+0x17c/0x190 [ 52.370590] [] change_page_attr_set_clr+0xb4/0x4a0 [ 52.370592] [] ? map_vm_area+0x32/0x50 [ 52.370595] [] ? __vmalloc_node_range+0x121/0x1f0 [ 52.370597] [] ? bpf_jit_compile+0x105b/0x1200 [ 52.370600] [] set_memory_ro+0x2f/0x40 [ 52.370602] [] ? module_alloc+0x5a/0x60 [ 52.370604] [] bpf_jit_compile+0xfcc/0x1200 [ 52.370607] [] ? __kmalloc+0x18b/0x1f0 [ 52.370610] [] ? __kmalloc+0x36/0x1f0 [ 52.370612] [] ? sk_chk_filter+0x283/0x390 [ 52.370614] [] sk_attach_filter+0xfb/0x1b0 [ 52.370617] [] sock_setsockopt+0x4fd/0x900 [ 52.370620] [] ? fget_light+0x92/0x100 [ 52.370623] [] SyS_setsockopt+0xc
Re: [PATCH 1/3] switch_creds: Syscall to switch creds for file server ops
On 10/16/2013 08:52 PM, Eric W. Biederman wrote:
> Al Viro writes:
>
>> On Wed, Oct 16, 2013 at 06:18:16PM -0700, Eric W. Biederman wrote:
>>
>>> That doesn't look bad but it does need capable(CAP_SETUID) &&
>>> capable(CAP_SETGID) or possibly something a little more refined.
>>
>> D'oh
>>
>>> I don't think we want file descriptor passing to all of a sudden become
>>> a grant of privilege, beyond what the passed fd can do.
>>
>> Definitely. And an extra ) to make it compile wouldn't hurt either...
>
> There also appears to need to be a check that we don't gain any
> capabilities.
>
> We also need a check so that you don't gain any capabilities, and
> possibly a few other things.
Why? I like the user_ns part, but I'm not immediately seeing the issue
with capabilities.
>
> So I suspect we want a check something like:
>
> if ((new_cred->securebits != current_cred->securebits) ||
> (new_cred->cap_inheritable != current_cred->cap_inheritable) ||
> (new_cred->cap_permitted != current_cred->cap_permitted) ||
> (new_cred->cap_effective != current_cred->cap_effective) ||
> (new_cred->cap_bset != current_cred->cap_bset) ||
> (new_cred->jit_keyring != current_cred->jit_keyring) ||
> (new_cred->session_keyring != current_cred->session_keyring) ||
> (new_cred->process_keyring != current_cred->process_keyring) ||
> (new_cred->thread_keyring != current_cred->thread_keyring) ||
> (new_cred->request_keyring != current_cred->request_keyring) ||
> (new_cred->security != current_cred->security) ||
> (new_cred->user_ns != current_cred->user_ns)) {
> return -EPERM;
> }
>
I *really* don't like the idea of being able to use any old file
descriptor. I barely care what rights the caller needs to have to
invoke this -- if you're going to pass an fd that grants a capability
(in the non-Linux sense of the work), please make sure that the sender
actually wants that behavior.
IOW, have a syscall to generate a special fd for this purpose. It's
only a couple lines of code, and I think we'll really regret it if we
fsck this up.
(I will take it as a personal challenge to find at least one exploitable
privilege escalation in this if an arbitrary fd works.)
Also... real_cred looks confusing. AFAICS it is used *only* for knfsd
and faccessat. That is, current userspace can't see it. But now you'll
expose various oddities. For example, AFAICS a capability-less process
that's a userns owner can always use setuid. This will *overwrite*
real_cred. Then you're screwed, especially if this happens by accident.
That being said, Windows has had functions like this for a long time.
Processes have a primary token and possibly an impersonation token. Any
process can call ImpersonateLoggedOnUser (no privilege required) to
impersonate the credentials of a token (which is special kind of fd).
Similarly, any process can call RevertToSelf to undo it.
Is there any actual problem with allowing completely unprivileged tasks
to switch to one of these magic cred fds? That would avoid needing a
"revert" operation.
Another note: I think that there may be issues if the creator of a token
has no_new_privs set and the user doesn't. Imagine a daemon that
accepts one of these fds, impersonates it, and calls exec. This could
be used to escape from no_new_privs land.
--Andy
--
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/
Best Regards Mr.Hashim Kabore
Good Day I am Mr.Hashim Kabore, a regional managing director (coris bank int'l) ouagadougou Burkina Faso, in my department we have US$9,500. united state Dollars, to transfer into your account as a dormant fund.If you are interested to use this fund to help the orphans around the world contact me and send your Personal information for more detail, Your full names Your country of origin Your occupation.. Your Age... Your Mobile N°.. Best Regards Mr.Hashim Kabore My number is +226 64 31 02 02 -- 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: zram/zsmalloc issues in very low memory conditions
On 10/24/2013 05:51 AM, Olav Haugan wrote: > I am trying to use zram in very low memory conditions and I am having > some issues. zram is in the reclaim path. So if the system is very low > on memory the system is trying to reclaim pages by swapping out (in this > case to zram). However, since we are very low on memory zram fails to > get a page from zsmalloc and thus zram fails to store the page. We get > into a cycle where the system is low on memory so it tries to swap out > to get more memory but swap out fails because there is not enough memory > in the system! The major problem I am seeing is that there does not seem > to be a way for zram to tell the upper layers to stop swapping out > because the swap device is essentially "full" (since there is no more > memory available for zram pages). Has anyone thought about this issue > already and have ideas how to solve this or am I missing something and I > should not be seeing this issue? > The same question as Luigi "What do you want the system to do at this point?" If swap fails then OOM killer will be triggered, I don't think this will be a issue. By the way, could you take a try with zswap? Which can write pages to real swap device if compressed pool is full. > I am also seeing a couple other issues that I was wondering whether > folks have already thought about: > > 1) The size of a swap device is statically computed when the swap device > is turned on (nr_swap_pages). The size of zram swap device is dynamic > since we are compressing the pages and thus the swap subsystem thinks > that the zram swap device is full when it is not really full. Any > plans/thoughts about the possibility of being able to update the size > and/or the # of available pages in a swap device on the fly? > > 2) zsmalloc fails when the page allocated is at physical address 0 (pfn AFAIK, this will never happen. > = 0) since the handle returned from zsmalloc is encoded as (, > ) and thus the resulting handle will be 0 (since obj_idx starts > at 0). zs_malloc returns the handle but does not distinguish between a > valid handle of 0 and a failure to allocate. A possible solution to this > would be to start the obj_idx at 1. Is this feasible? > > Thanks, > > Olav Haugan > -- Regards, -Bob -- 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] audit: change pid to portid for audit_reply
On 10/24/2013 03:20 AM, Richard Guy Briggs wrote: > On Wed, Oct 23, 2013 at 07:25:23PM +0800, Gao feng wrote: >> The "pid" is not a suitable name for netlink port, >> change it to "portid". > > That is already in the works: > https://www.redhat.com/archives/linux-audit/2013-August/msg00023.html > https://lkml.org/lkml/2013/8/20/630 > > May I add your Signed-off-by: to that previous patch? Oops, I didn't notice that. you can add my Signed-off-by if you wish :) Thanks -- 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] x86/apic: Disable I/O APIC before shutdown local APIC
From: Fenghua Yu
In reboot and crash path, when shutdown local APIC, I/O APIC is still active.
This may cause issues because external interrupts can still come in and
disturb local APIC during shutdown process. To quiet external interrupts,
disable I/O APIC before shutdown local APIC.
Signed-off-by: Fenghua Yu
---
arch/x86/kernel/crash.c |2 +-
arch/x86/kernel/reboot.c |8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index e0e0841..18677a9 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -127,12 +127,12 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
cpu_emergency_vmxoff();
cpu_emergency_svm_disable();
- lapic_shutdown();
#ifdef CONFIG_X86_IO_APIC
/* Prevent crash_kexec() from deadlocking on ioapic_lock. */
ioapic_zap_locks();
disable_IO_APIC();
#endif
+ lapic_shutdown();
#ifdef CONFIG_HPET_TIMER
hpet_disable();
#endif
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 7e920bf..618ce26 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -550,6 +550,10 @@ static void native_machine_emergency_restart(void)
void native_machine_shutdown(void)
{
/* Stop the cpus and apics */
+#ifdef CONFIG_X86_IO_APIC
+ disable_IO_APIC();
+#endif
+
#ifdef CONFIG_SMP
/*
* Stop all of the others. Also disable the local irq to
@@ -562,10 +566,6 @@ void native_machine_shutdown(void)
lapic_shutdown();
-#ifdef CONFIG_X86_IO_APIC
- disable_IO_APIC();
-#endif
-
#ifdef CONFIG_HPET_TIMER
hpet_disable();
#endif
--
1.6.0.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pstore: avoid incorrectly mark entry as duplicate
tony.l...@gmail.com writes:
> On Wed, Oct 23, 2013 at 7:55 AM, Madper Xie wrote:
>> The "duplicate" entries won't appear in pstorefs. And a complain will be
>> print -- pstore: failed to load 76 record(s) from 'efi'
>
> Maybe I don't quite get this - but it sounds like you have a whole lot
> of entries using up space in efivars that have similar names - differing
> just in the timestamp - that won't show up in the pstore filesystem - because
> we'd try to name them all the same thing.
>
Maybe I misunderstand you...
Sure pstore try to name them all the same thing, but it's another
issue. and it doesn't prevent entries showing up in pstore fs.
Consider the following case: (after efi-pstore support append mode, it
always like this case):
I choose four dumped efivars from my DELL XPS:
dump-type0-9-1-1380441690-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-9-1-1380448560-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-9-1-1380460890-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-9-1-1382496073-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
^^ [ ^ ]
!! !
typetimestampGUID
When pstore load them from efivars, pstore incorrectly assuming that
efivars with the same TYPE, ID and GUID are duplicate.
list_for_each_entry(pos, &allpstore, list) {
if (pos->type == type &&/---
pos->id == id && <-| as I said, it only check type,id,psi
pos->psi == psi) { \---
rc = -EEXIST;<- then set -EEXIST, and ignore *dup* entry
break;
}
}
You can see the code above, for those four entries, only one could be
showed in pstorefs, all others will get a -EEXIST. So I add a timestamp
check here, it's the only different part.
> How did all those things end up in efivars?
before the patch I can see
dmesg-efi-1 dmesg-efi-11 dmesg-efi-3 dmesg-efi-5 dmesg-efi-7 dmesg-efi-9
dmesg-efi-10 dmesg-efi-2 dmesg-efi-4 dmesg-efi-6 dmesg-efi-8
after apply the patch:
[root@dhcp-13-41 vars]# ls /dev/pstore/
dmesg-efi-1 dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5
dmesg-efi-6 dmesg-efi-8
dmesg-efi-1 dmesg-efi-10 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5
dmesg-efi-7 dmesg-efi-8
dmesg-efi-1 dmesg-efi-10 dmesg-efi-12 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5
dmesg-efi-7 dmesg-efi-8
dmesg-efi-1 dmesg-efi-10 dmesg-efi-13 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-14 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-15 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-16 dmesg-efi-3 dmesg-efi-4 dmesg-efi-5
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6
dmesg-efi-8 dmesg-efi-9
dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6
dmesg-efi-8 dmesg-efi-9
dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6
dmesg-efi-8 dmesg-efi-9
dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5 dmesg-efi-6
dmesg-efi-8
dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5 dmesg-efi-6
dmesg-efi-8
dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5 dmesg-efi-6
dmesg-efi-8
>
> Wouldn't the right fix be to make pstore allow them all to appear (using the
> timestamp to differentiate names?) so that we could see them, log them,
> and then remove them from pstore (in turn freeing up efivars space - which
> people keep telling me is in short supply).
>
Yeah, many file have the same name, just like my case above. But it not
really block the file shows up and should be solved in another
patch. And I'm trying fix it.
> -Tony
--
Best,
Madper Xie.
--
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: [3.11.4] Thunderbolt/PCI unplug oops in pci_pme_list_scan
On Thu, Oct 17, 2013 at 7:59 AM, Andreas Noever wrote: > On Wed, Oct 16, 2013 at 10:21 PM, Bjorn Helgaas wrote: >> On Tue, Oct 15, 2013 at 03:44:52AM +0100, Matthew Garrett wrote: >>> On Mon, Oct 14, 2013 at 05:50:38PM -0600, Bjorn Helgaas wrote: >>> > [+cc Rafael, Mika, Kirill, linux-pci] >>> > >>> > On Mon, Oct 14, 2013 at 4:47 PM, Andreas Noever >>> > wrote: >>> > > When I unplug the Thunderbolt ethernet adapter on my MacBookPro Linux >>> > > crashes a few seconds later. Using >>> > > echo 1 > /sys/bus/pci/devices/:08:00.0/remove >>> > > to remove a bridge two levels above the device triggers the fault >>> > > immediately: >>> > >>> > There have been significant changes in acpiphp related to Thunderbolt >>> > since v3.11. >>> >>> Apple don't expose Thunderbolt via ACPI, so it appears as native PCIe. >>> I'd be surprised if acpiphp makes a difference here. >> >> Yeah, you're right; I wasn't paying attention. >> >> We save a pci_dev pointer in the pci_pme_list, which of course has a >> longer lifetime than the pci_dev itself, but we don't acquire a reference >> on it, so I suspect the pci_dev got released before we got around to >> doing the pci_pme_list_scan(). >> >> Andreas, can you try the patch below? It's against v3.12-rc2, but it >> should apply to v3.11, too. > > I have tested your patch against 3.11 where it solves the problem. Thanks! Hi Andreas, sorry for the delay here. I'm still trying to understand exactly why my patch fixes the problem, since I don't see a relevant refcounting change between v3.11 and v3.12-rc5. And I don't actually see the hole yet from inspection. It seems like we should be safe even without my patch. But maybe it's a case of releasing the pci_bus before releasing a pci_dev on the bus. I thought we recently fixed a hole there, but maybe not. I'll look more carefully at that path. Can I trouble you to collect a complete dmesg log from v3.11 without my patch? Maybe if I stare long enough at that and the lspci you supplied, I can figure out what's going on. If you were really gung-ho, you could add instrumentation to print out the pci_dev and pci_bus pointers as we enumerate them. My guess is that we'd see one of those pointers in the GPF register dump. Bjorn -- 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/
EFI boot problem in 3.11
I have a box here which is set up for EFI boot with no boot loader. The kernel is compiled with a built-in initrd and command line. In 3.10 this was all working well. However, after updating to 3.11.5 a reboot leads to the EFI firmware boot screen appearing followed by the middle section of it going black (just leaving two vertical stripes of the EFI firmware boot screen on either side of the screen) and the system locking up (numlock etc do not work). However, if I hit ‘delete’ quickly when powering on, and enter the firmware setup screen, I can then ‘exit without saving’ and the system will boot successfully — ‘save and exit’ does not work as that performs a full reboot while ‘exit without saving’ seems to continue the boot where it left off. Due to the aforementioned graphics corruption, I am wondering whether it is somehow related to the frame buffer? As this is a production system I unfortunately do not have flexibility to try a number of kernel versions in-between to locate where the issue was introduced. All enabled .config options in the graphics section are: FB, FB_EFI, VGA_ARB, LOGO, LOGO_LINUX_CLUT224, VGA_CONSOLE, FRAMEBUFFER_CONSOLE Please Cc me in replies. Best, Jasper Bryant-Greene smime.p7s Description: S/MIME cryptographic signature
Re: [virtio-net] BUG: sleeping function called from invalid context at kernel/mutex.c:616
Hi Jason, On Tue, Oct 22, 2013 at 04:35:32PM +0800, Jason Wang wrote: > On 10/20/2013 10:34 AM, Fengguang Wu wrote: > > Greetings, > > > > I got the below dmesg and the first bad commit is > > > > commit 3ab098df35f8b98b6553edc2e40234af512ba877 > > Author: Jason Wang > > Date: Tue Oct 15 11:18:58 2013 +0800 > > > > virtio-net: don't respond to cpu hotplug notifier if we're not ready > > > > We're trying to re-configure the affinity unconditionally in cpu hotplug > > callback. This may lead the issue during resuming from s3/s4 since > > > > - virt queues haven't been allocated at that time. > > - it's unnecessary since thaw method will re-configure the affinity. > > > > Fix this issue by checking the config_enable and do nothing is we're > > not ready. > > > > The bug were introduced by commit > > 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17 > > (virtio-net: reset virtqueue affinity when doing cpu hotplug). > > > > Cc: Rusty Russell > > Cc: Michael S. Tsirkin > > Cc: Wanlong Gao > > Acked-by: Michael S. Tsirkin > > Reviewed-by: Wanlong Gao > > Signed-off-by: Jason Wang > > Signed-off-by: David S. Miller > > > > [ 622.91] CPU0 attaching NULL sched-domain. > > [ 622.96] CPU1 attaching NULL sched-domain. > > [ 622.944485] CPU0 attaching NULL sched-domain. > > [ 622.950795] BUG: sleeping function called from invalid context at > > kernel/mutex.c:616 > > [ 622.950796] in_atomic(): 1, irqs_disabled(): 1, pid: 10, name: > > migration/1 > > [ 622.950796] no locks held by migration/1/10. > > [ 622.950798] CPU: 1 PID: 10 Comm: migration/1 Not tainted > > 3.12.0-rc5-wl-01249-gb91e82d #317 > > [ 622.950799] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > > [ 622.950802] 88001d42dba0 81a32f22 > > 88001bfb9c70 > > [ 622.950803] 88001d42dbb0 810edb02 88001d42dc38 > > 81a396ed > > [ 622.950805] 0046 88001d42dbe8 810e861d > > > > [ 622.950805] Call Trace: > > [ 622.950810] [] dump_stack+0x54/0x74 > > [ 622.950815] [] __might_sleep+0x112/0x114 > > [ 622.950817] [] mutex_lock_nested+0x3c/0x3c6 > > [ 622.950818] [] ? up+0x39/0x3e > > [ 622.950821] [] ? acpi_os_signal_semaphore+0x21/0x2d > > [ 622.950824] [] ? acpi_ut_release_mutex+0x5e/0x62 > > [ 622.950828] [] virtnet_cpu_callback+0x33/0x87 > > [ 622.950830] [] notifier_call_chain+0x3c/0x5e > > [ 622.950832] [] __raw_notifier_call_chain+0xe/0x10 > > [ 622.950835] [] __cpu_notify+0x20/0x37 > > [ 622.950836] [] cpu_notify+0x13/0x15 > > [ 622.950838] [] take_cpu_down+0x27/0x3a > > [ 622.950841] [] stop_machine_cpu_stop+0x93/0xf1 > > [ 622.950842] [] cpu_stopper_thread+0xa0/0x12f > > [ 622.950844] [] ? cpu_stopper_thread+0x12f/0x12f > > [ 622.950847] [] ? > > lock_release_holdtime.part.7+0xa3/0xa8 > > [ 622.950848] [] ? cpu_stop_should_run+0x3f/0x47 > > [ 622.950850] [] smpboot_thread_fn+0x1c5/0x1e3 > > [ 622.950852] [] ? lg_global_unlock+0x67/0x67 > > [ 622.950854] [] kthread+0xd8/0xe0 > > [ 622.950857] [] ? wait_for_common+0x12f/0x164 > > [ 622.950859] [] ? kthread_create_on_node+0x124/0x124 > > [ 622.950861] [] ret_from_fork+0x7c/0xb0 > > [ 622.950862] [] ? kthread_create_on_node+0x124/0x124 > > [ 622.950876] smpboot: CPU 1 is now offline > > [ 623.194556] SMP alternatives: lockdep: fixing up alternatives > > [ 623.194559] smpboot: Booting Node 0 Processor 1 APIC 0x1 > > Thanks for the testing Fengguang, could you please try the attached > patch to see if it works? Yes it reduces the sleeping function bug: /kernel/x86_64-lkp-CONFIG_SCSI_DEBUG/7c4ed2767afb813493b0a8fb18d666cd44550963 ++---+--+--+ | | v3.12-rc3 | 3ab098df35f8 | 7c4ed2767afb | ++---+--+--+ | good_boots | 30| 0| 93 | | has_kernel_error_warning | 0 | 20 | 7| | BUG:sleeping_function_called_from_invalid_context_at_kernel/mutex.c | 0 | 20 | | | INFO:rcu_sched_self-detected_stall_on_CPU(t=jiffies_g=c=q=) | 0 | 0| 1| | INFO:task_blocked_for_more_than_seconds | 0 | 0| 2| | INFO:NMI_handler(arch_trigger_all_cpu_backtrace_handler)took_too_long_to_run:msecs | 0 | 0| 1| | Kernel_panic-not_syncing:hung_task:blocked_tasks
Aw: Re: [tpmdd-devel] [PATCH] tpm: MAINTAINERS: Add myself as tpm maintainer
Hi Rajiv, > Long time, no see.. Good to see you again. > Peter, thank you a ton for stepping in. > Since you're of course the owner (yes, we need such figure), > let me know if my help is desirable or if you think there isn't > additional bandwidth needed to maintain it. Thanks for the offer - I think I can handle the maintenance effort itself, HOWEVER I would really like to see you sticking around here as a reviewer, due to your experience, especially for the stuff I'm submitting. The more reviewers the merrier ;) Whether you want to be listed in MAINTAINERS or the subscription to tpmdd is enough is up to you. Please tell me what you think, then I'd clean up the MAINTAINERS entry for the tpm subsystem ;) Thanks, Peter -- 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] MAINTAINERS: Don't send to devicetree list for "arch/*/boot/dts"
Em Wed, 23 Oct 2013 12:12:32 -0500 Rob Herring escreveu: > On 10/23/2013 08:22 AM, Doug Anderson wrote: > > As discussed in the ARM kernel summit, people on the devicetree list > > would no longer like to receive emails about all dts changes. Remove > > from MAINTAINERS. > > We need to make sure platform maintainers are copied though. That may be > hard since we don't have standard layout/naming of dts files. > > We might also want to drop these: > K: of_get_property > K: of_match_table > > They are at least on the wrong maintainer list now as they should be > associated with the binding maintainers and not DT core code if we do > keep them. > > Also based on the discussion, we need to add > Documentation/devicetree/bindings/* to appropriate subsystem > maintainers, but that should probably wait until after Friday at least. /me is confused. What's the procedure for the DT patches for the devices supported by the subsystem I maintain, e. g. patches for /drivers/media/platform? Should I just apply them, if I think that it is needed by the hardware? Are there any criteria to be followed? If so, what criteria? /me hopes that all those questions will be discussed/answered at KS on Friday's discussions ;) In any case, my suggestion is that this patch should be a way more verbose, and should come together with a patch adding something at Documentation (SubmittingPatches, or maybe SubmitingDTPatches) in order to be sure that both developers and subsystem maintainers will do the right thing. Thanks, Mauro > > Rob > > > > > Signed-off-by: Doug Anderson > > --- > > MAINTAINERS | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index ebaf8bd..0166e8e 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5987,7 +5987,6 @@ OMAP DEVICE TREE SUPPORT > > M: Benoît Cousson > > M: Tony Lindgren > > L: linux-o...@vger.kernel.org > > -L: devicet...@vger.kernel.org > > S: Maintained > > F: arch/arm/boot/dts/*omap* > > F: arch/arm/boot/dts/*am3* > > @@ -6167,7 +6166,6 @@ M:Ian Campbell > > L: devicet...@vger.kernel.org > > S: Maintained > > F: Documentation/devicetree/ > > -F: arch/*/boot/dts/ > > F: include/dt-bindings/ > > > > OPENRISC ARCHITECTURE > > > -- Cheers, Mauro -- 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] serial: omap: improve RS-485 performance
If RS-485 is enabled, make the OMAP UART fire THR interrupts when both
TX FIFO and TX shift register are empty instead of polling the
equivalent status bit. This removes the burst of interrupt requests
seen at every end of transmission.
Also: the comment said that the TX FIFO trigger level was set at 16
characters when it's 32 in reality.
Signed-off-by: Philippe Proulx
---
drivers/tty/serial/omap-serial.c | 50 ++--
1 file changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c715778..02cb61e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -283,21 +283,22 @@ static void serial_omap_enable_ms(struct uart_port *port)
static void serial_omap_stop_tx(struct uart_port *port)
{
struct uart_omap_port *up = to_uart_omap_port(port);
- struct circ_buf *xmit = &up->port.state->xmit;
int res;
pm_runtime_get_sync(up->dev);
- /* handle rs485 */
+ /* Handle RS-485 */
if (up->rs485.flags & SER_RS485_ENABLED) {
- /* do nothing if current tx not yet completed */
- res = serial_in(up, UART_LSR) & UART_LSR_TEMT;
- if (!res)
- return;
-
- /* if there's no more data to send, turn off rts */
- if (uart_circ_empty(xmit)) {
- /* if rts not already disabled */
+ if (up->scr & OMAP_UART_SCR_TX_EMPTY) {
+ /* THR interrupt is fired when both TX FIFO and TX
+* shift register are empty. This means there's nothing
+* left to transmit now, so make sure the THR interrupt
+* is fired when TX FIFO is below the trigger level,
+* disable THR interrupts and toggle the RS-485 GPIO
+* data direction pin if needed.
+*/
+ up->scr &= ~OMAP_UART_SCR_TX_EMPTY;
+ serial_out(up, UART_OMAP_SCR, up->scr);
res = (up->rs485.flags & SER_RS485_RTS_AFTER_SEND) ? 1
: 0;
if (gpio_get_value(up->rts_gpio) != res) {
if (up->rs485.delay_rts_after_send > 0) {
@@ -305,6 +306,18 @@ static void serial_omap_stop_tx(struct uart_port *port)
}
gpio_set_value(up->rts_gpio, res);
}
+ } else {
+ /* We're asked to stop, but there's still stuff in the
+* UART FIFO, so make sure the THR interrupt is fired
+* when both TX FIFO and TX shift register are empty.
+* The next THR interrupt (if no transmission is started
+* in the meantime) will indicate the end of a
+* transmission. Therefore we _don't_ disable THR
+* interrupts in this situation.
+*/
+ up->scr |= OMAP_UART_SCR_TX_EMPTY;
+ serial_out(up, UART_OMAP_SCR, up->scr);
+ return;
}
}
@@ -384,8 +397,12 @@ static void serial_omap_start_tx(struct uart_port *port)
pm_runtime_get_sync(up->dev);
- /* handle rs485 */
+ /* Handle RS-485 */
if (up->rs485.flags & SER_RS485_ENABLED) {
+ /* Fire THR interrupts when FIFO is below trigger level */
+ up->scr &= ~OMAP_UART_SCR_TX_EMPTY;
+ serial_out(up, UART_OMAP_SCR, up->scr);
+
/* if rts not already enabled */
res = (up->rs485.flags & SER_RS485_RTS_ON_SEND) ? 1 : 0;
if (gpio_get_value(up->rts_gpio) != res) {
@@ -938,7 +955,7 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
*/
/* Set receive FIFO threshold to 16 characters and
-* transmit FIFO threshold to 16 spaces
+* transmit FIFO threshold to 32 spaces
*/
up->fcr &= ~OMAP_UART_FCR_RX_FIFO_TRIG_MASK;
up->fcr &= ~OMAP_UART_FCR_TX_FIFO_TRIG_MASK;
@@ -1344,6 +1361,15 @@ serial_omap_config_rs485(struct uart_port *port, struct
serial_rs485 *rs485conf)
up->ier = mode;
serial_out(up, UART_IER, up->ier);
+ /* If RS-485 is disabled, make sure the THR interrupt is fired when
+* TX FIFO is below the trigger level.
+*/
+ if (!(up->rs485.flags & SER_RS485_ENABLED) &&
+ (up->scr & OMAP_UART_SCR_TX_EMPTY)) {
+ up->scr &= ~OMAP_UART_SCR_TX_EMPTY;
+ serial_out(up, UART_OMAP_SCR, up->scr);
+ }
+
spin_unlock_irqrestore(&up->port.lock, flags);
pm_runtime_mark_last_busy(up->dev);
pm_runtime_put_autosuspend(up->dev);
--
1.8.4.1
--
To unsubscri
[PATCH 2/2] serial: omap: fix a few checkpatch warnings
Signed-off-by: Philippe Proulx
---
drivers/tty/serial/omap-serial.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 02cb61e..bf00477 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -175,7 +175,7 @@ struct uart_omap_port {
boolis_suspending;
};
-#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
port)))
+#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port, port)))
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
@@ -242,9 +242,9 @@ serial_omap_baud_is_mode16(struct uart_port *port, unsigned
int baud)
unsigned int n16 = port->uartclk / (16 * baud);
int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
- if(baudAbsDiff13 < 0)
+ if (baudAbsDiff13 < 0)
baudAbsDiff13 = -baudAbsDiff13;
- if(baudAbsDiff16 < 0)
+ if (baudAbsDiff16 < 0)
baudAbsDiff16 = -baudAbsDiff16;
return (baudAbsDiff13 >= baudAbsDiff16);
@@ -301,9 +301,8 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_OMAP_SCR, up->scr);
res = (up->rs485.flags & SER_RS485_RTS_AFTER_SEND) ? 1
: 0;
if (gpio_get_value(up->rts_gpio) != res) {
- if (up->rs485.delay_rts_after_send > 0) {
+ if (up->rs485.delay_rts_after_send > 0)
mdelay(up->rs485.delay_rts_after_send);
- }
gpio_set_value(up->rts_gpio, res);
}
} else {
@@ -407,9 +406,8 @@ static void serial_omap_start_tx(struct uart_port *port)
res = (up->rs485.flags & SER_RS485_RTS_ON_SEND) ? 1 : 0;
if (gpio_get_value(up->rts_gpio) != res) {
gpio_set_value(up->rts_gpio, res);
- if (up->rs485.delay_rts_before_send > 0) {
+ if (up->rs485.delay_rts_before_send > 0)
mdelay(up->rs485.delay_rts_before_send);
- }
}
}
@@ -1686,8 +1684,9 @@ static int serial_omap_probe(struct platform_device *pdev)
up->port.uartclk = omap_up_info->uartclk;
if (!up->port.uartclk) {
up->port.uartclk = DEFAULT_CLK_SPEED;
- dev_warn(&pdev->dev, "No clock speed specified: using default:"
- "%d\n", DEFAULT_CLK_SPEED);
+ dev_warn(&pdev->dev,
+"No clock speed specified: using default: %d\n"
+DEFAULT_CLK_SPEED);
}
up->latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 1/3] Input: twl4030-pwrbutton - add device tree support
On Wed, Oct 23, 2013 at 05:24:14PM -0500, Rob Herring wrote:
> So a twl4030 device is only a power button? DT should describe the h/w
> not a node for a sub-function of a device.
No. TWL4030 is a companion chip for the OMAP3 processor. It provides
miscellaneous functionality, e.g.:
* RTC
* Watchdog
* Regulators
* Keypad Matrix
* USB
* Audio
* Vibrator
* GPIO
* ...
One part of the functionality is the power button. The patch
assumes, that the twl4030-pwrbutton node is used as follows:
twl {
/* ... common stuff ... */
pwrbutton {
compatible = "ti,twl4030-pwrbutton";
interrupts = <8>;
};
};
See also:
* Documentation/devicetree/bindings/mfd/twl-familly.txt
* Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
* Documentation/devicetree/bindings/sound/omap-twl4030.txt
* Documentation/devicetree/bindings/mfd/twl4030-power.txt
* Documentation/devicetree/bindings/mfd/twl4030-audio.txt
* Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
-- Sebastian
signature.asc
Description: Digital signature
[PATCH 0/2] serial: omap: improve performance for RS-485
The current RS-485 implementation for the OMAP serial driver is to not disable THR interrupts when the driver ring buffer becomes empty until it makes sure the TX shift register is empty, which means the UART is not transmitting anymore and only then can the driver toggle the GPIO output pin for RS-485 data direction. Since the UART TX FIFO trigger level is set to 32 characters (the comment said 16, but it's really 32), this means there's a burst of IRQs for the transmission time of 33 characters (which means at least 34 ms at 9600 bauds, for example) since the TX FIFO is always below its trigger level and the THR interrupts are not disabled. The driver is essentially polling the status bit using interrupts during this time. This patchset makes use of the TXEMPTYCTLIT bit of the SCR register instead, which makes it possible to get a THR interrupt only when both the TX FIFO and the TX shift register are empty. We only use this mode if RS-485 is enabled. This patchset also fixes a few minor coding style warnings from checkpatch.pl. The patches apply to tty/tty-next. Philippe Proulx (2): serial: omap: improve RS-485 performance serial: omap: fix a few checkpatch warnings drivers/tty/serial/omap-serial.c | 67 +++- 1 file changed, 46 insertions(+), 21 deletions(-) -- 1.8.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Resend PATCH 5/5] IA64/PCI/ACPI: Rework PCI root bridge ACPI resource conversion
[+cc Greg] On Fri, Oct 18, 2013 at 08:44:12PM +0800, Lan Tianyu wrote: > On 10/18/2013 04:33 AM, Bjorn Helgaas wrote: >> On Thu, Oct 17, 2013 at 12:09 AM, Lan Tianyu wrote: >>>On 2013年10月17日 07:55, Bjorn Helgaas wrote: On Fri, Oct 11, 2013 at 08:19:01PM +0800, tianyu@intel.com wrote: >>I wonder if it would make sense to make >>acpi_dev_resource_address_space() ignore addr.translation_offset for >>IO resources. Or maybe ignore it if the _TTP (type translation) bit >>is set? > > I wonder why current code doesn't check _TTP? The code in the > add_io_space() seems to think _TTP is always set, right? I think it's an oversight, and you should fix it. I suggest that you ignore the _TRA value when _TTP is set. Obviously this only applies to I/O port resources, since _TTP is only defined in the I/O Resource Flag (Table 6-185 in ACPI 5.0 spec). >>Mike, is there any chance you could collect an acpidump from an >>rx7620 or similar ia64 system? In particular, I want to see a >>multi-node system where we have several PCI domains, and whether it >>sets the _TTP bits. Greg collected an acpidump from an HP system that uses these I/O port ranges. Unfortunately the system wasn't running Linux, so it's an EFI dump, not the usual one we get from the "pmtools" package. But I think it has the information we want. It's huge, and I put some of the relevant parts of it here: https://bugzilla.kernel.org/show_bug.cgi?id=63581 Here's a sample that shows the _TTP bit is set for the I/O aperture: Device E000 (\_SB_.N000.E000) Name _SEG (\_SB_.N000.E000._SEG) 0x01 Name _CRS (\_SB_.N000.E001._CRS) Buffer 0x0092 ByteList <0x88 0x0d 0x00 0x02 0x0e 0x00 0x00 0x00 0x00 0x00 0xff 0x00 0x00 0x00 0x00 0x01 0x8a 0x2b 0x00 0x01 0x0c 0x33 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xd0 0x00 0x04 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 Byte 0: 0x8a (QWORD address space descriptor) Byte 3: Resource Type = 0x01 (I/O range) Byte 5: Type Specific Flags = 0x33 (_TRS, _TTP, _RNG = 3) QWORD Address Space Descriptor: Type: I/O Flags: Sparse, Translate, ISA I/O addresses, Non-ISA I/O addresses GRA: 0x MIN: 0x MAX: 0x TRA: 0x0400d000 LEN: 0x0001 MAX address fixed MIN address fixed Address positively decoded Device produces and consumes this resource Bjorn -- 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: [PATCHv5 1/3] Input: twl4030-pwrbutton - add device tree support
On 10/23/2013 03:26 PM, Sebastian Reichel wrote:
> Add device tree support for twl4030 power button driver.
>
> Signed-off-by: Sebastian Reichel
> ---
> .../devicetree/bindings/input/twl4030-pwrbutton.txt | 13 +
> drivers/input/misc/twl4030-pwrbutton.c | 16
>
> 2 files changed, 25 insertions(+), 4 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
>
> diff --git a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
> b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
> new file mode 100644
> index 000..945ec74
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
> @@ -0,0 +1,13 @@
> +* TWL4030's pwrbutton device tree bindings
> +
> +Required SoC Specific Properties:
> +- compatible: should be one of the following
> + - "ti,twl4030-pwrbutton": For controllers compatible with twl4030
> +- interrupt: should be one of the following
> + - <8>: For controllers compatible with twl4030
> +
> +Example:
> + twl_pwrbutton: pwrbutton {
> + compatible = "ti,twl4030-pwrbutton";
> + interrupts = <8>;
> + };
So a twl4030 device is only a power button? DT should describe the h/w
not a node for a sub-function of a device.
Rob
> diff --git a/drivers/input/misc/twl4030-pwrbutton.c
> b/drivers/input/misc/twl4030-pwrbutton.c
> index b9a05fd..a3a0fe3 100644
> --- a/drivers/input/misc/twl4030-pwrbutton.c
> +++ b/drivers/input/misc/twl4030-pwrbutton.c
> @@ -52,7 +52,7 @@ static irqreturn_t powerbutton_irq(int irq, void *_pwr)
> return IRQ_HANDLED;
> }
>
> -static int __init twl4030_pwrbutton_probe(struct platform_device *pdev)
> +static int twl4030_pwrbutton_probe(struct platform_device *pdev)
> {
> struct input_dev *pwr;
> int irq = platform_get_irq(pdev, 0);
> @@ -106,16 +106,24 @@ static int __exit twl4030_pwrbutton_remove(struct
> platform_device *pdev)
> return 0;
> }
>
> +#if IS_ENABLED(CONFIG_OF)
> +static const struct of_device_id twl4030_pwrbutton_dt_match_table[] = {
> + { .compatible = "ti,twl4030-pwrbutton" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, twl4030_pwrbutton_dt_match_table);
> +#endif
> +
> static struct platform_driver twl4030_pwrbutton_driver = {
> + .probe = twl4030_pwrbutton_probe,
> .remove = __exit_p(twl4030_pwrbutton_remove),
> .driver = {
> .name = "twl4030_pwrbutton",
> .owner = THIS_MODULE,
> + .of_match_table =
> of_match_ptr(twl4030_pwrbutton_dt_match_table),
> },
> };
> -
> -module_platform_driver_probe(twl4030_pwrbutton_driver,
> - twl4030_pwrbutton_probe);
> +module_platform_driver(twl4030_pwrbutton_driver);
>
> MODULE_ALIAS("platform:twl4030_pwrbutton");
> MODULE_DESCRIPTION("Triton2 Power Button");
>
--
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: zram/zsmalloc issues in very low memory conditions
(sorry about the HTML in the previous message) On Wed, Oct 23, 2013 at 2:51 PM, Olav Haugan wrote: > I am trying to use zram in very low memory conditions and I am having > some issues. zram is in the reclaim path. So if the system is very low > on memory the system is trying to reclaim pages by swapping out (in this > case to zram). However, since we are very low on memory zram fails to > get a page from zsmalloc and thus zram fails to store the page. We get > into a cycle where the system is low on memory so it tries to swap out > to get more memory but swap out fails because there is not enough memory > in the system! The major problem I am seeing is that there does not seem > to be a way for zram to tell the upper layers to stop swapping out > because the swap device is essentially "full" (since there is no more > memory available for zram pages). Has anyone thought about this issue > already and have ideas how to solve this or am I missing something and I > should not be seeing this issue? What do you want the system to do at this point? OOM kill? Also, if you are that low on memory, how are you preventing thrashing on the code pages? I am asking because we also use zram but haven't run into this problem---however we had to deal with other problems that motivate these questions. > > I am also seeing a couple other issues that I was wondering whether > folks have already thought about: > > 1) The size of a swap device is statically computed when the swap device > is turned on (nr_swap_pages). The size of zram swap device is dynamic > since we are compressing the pages and thus the swap subsystem thinks > that the zram swap device is full when it is not really full. Any > plans/thoughts about the possibility of being able to update the size > and/or the # of available pages in a swap device on the fly? That is a known limitation of zram. If you can predict your compression ratio and your working set size, it's not a big problem: allocate a swap device which, based on the expected compression ratio, will use up RAM until what's left is just enough for the working set. > 2) zsmalloc fails when the page allocated is at physical address 0 (pfn > = 0) since the handle returned from zsmalloc is encoded as (, > ) and thus the resulting handle will be 0 (since obj_idx starts > at 0). zs_malloc returns the handle but does not distinguish between a > valid handle of 0 and a failure to allocate. A possible solution to this > would be to start the obj_idx at 1. Is this feasible? > > Thanks, > > Olav Haugan > > -- > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org -- 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: [Xen-devel] [PATCH] xen/hvc-console: Make it work with HVM guests.
On 10/23/2013 05:15 PM, Konrad Rzeszutek Wilk wrote:
On Sun, Oct 06, 2013 at 09:52:40PM +0100, Julien Grall wrote:
On 09/30/2013 03:45 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 27, 2013 at 10:49:37PM +0100, Julien Grall wrote:
On 09/27/2013 10:25 PM, Konrad Rzeszutek Wilk wrote:
@@ -641,7 +641,20 @@ struct console xenboot_console = {
void xen_raw_console_write(const char *str)
{
- dom0_write_console(0, str, strlen(str));
+ ssize_t len = strlen(str);
+ int rc = 0;
+
+ if (xen_domain()) {
+ dom0_write_console(0, str, len);
+ if (rc == -ENOSYS && xen_hvm_domain())
+ goto outb_print;
+
+ } else if (xen_cpuid_base()) {
+ int i;
+outb_print:
+ for (i = 0; i < len; i++)
+ outb(str[i], 0xe9);
+ }
}
xen_cpuid_base and outb(0xe9) is x86 specific and won't compile on ARM.
Odd, I see outb defined in arch/arm and arch/arm64
?(arch/arm[|64]/include/asm.io.h)
On ARM32 the IO access is memory mapped (the exact address depends
on Linux configuration).
The main problem is not the outb macro but the ioport 0xe9.On ARM,
this ioport is not trapped by Xen.
You are of course right about xen_cpuid_base.
How about this:
For the ARM side, the code looks good.
Can I that as 'Acked-by' ? thanks
Actually, I looked closer the code, with the new solution
xen_raw_printk/xen_raw_console_write can't be call on ARM during early init.
On ARM, xen_domain_type is initialized during a core initcall. So it's
not possible to call the function before.
From 04b772d2b819f0dda2163e3193fa7cd447a6245c Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Fri, 27 Sep 2013 17:18:13 -0400
Subject: [PATCH] xen/hvc: If we use xen_raw_printk let it also work on HVM
guests.
The xen_raw_printk works great for debugging purposes. We use
for PV guests and we can also use it for HVM guests.
However, for HVM guests we have a fallback of using the 0xe9
port in case the hypervisor does not support an HVM guest of
using the console_io hypercall. As such lets use 0xe9 during
early bootup, and once the hyper-page is setup and if the
console_io hypercall is supported - use that. Otherwise we
will fallback to using the 0xe9 after early bootup.
We also alter the return value for dom0_write_console to return
an error value instead of zero. The HVC API has been supporting
returning error values for quite some time.
P.S.
To use (and to see the output in the Xen ring buffer) one has to build
the hypervisor with 'debug=y'.
Signed-off-by: Konrad Rzeszutek Wilk
[v1: ifdef xen_cpuid_base as it is X86 specific]
---
drivers/tty/hvc/hvc_xen.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index e61c36c..6458c9f 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -183,7 +183,7 @@ static int dom0_write_console(uint32_t vtermno, const char
*str, int len)
{
int rc = HYPERVISOR_console_io(CONSOLEIO_write, len, (char *)str);
if (rc < 0)
- return 0;
+ return rc;
return len;
}
@@ -641,7 +641,22 @@ struct console xenboot_console = {
void xen_raw_console_write(const char *str)
{
- dom0_write_console(0, str, strlen(str));
+ ssize_t len = strlen(str);
+ int rc = 0;
+
+ if (xen_domain()) {
+ rc = dom0_write_console(0, str, len);
+#ifdef CONFIG_X86
+ if (rc == -ENOSYS && xen_hvm_domain())
+ goto outb_print;
+
+ } else if (xen_cpuid_base()) {
+ int i;
+outb_print:
+ for (i = 0; i < len; i++)
+ outb(str[i], 0xe9);
+#endif
+ }
}
void xen_raw_printk(const char *fmt, ...)
--
Julien Grall
--
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: -27% netperf TCP_STREAM regression by "tcp_memcontrol: Kill struct tcp_memcontrol"
> - return !!sk->sk_prot->memory_pressure;
> + return !!*sk->sk_prot->memory_pressure;
Good catch, Christoph! With no surprise, it restores the performance:
a4fe34bf902b8f709c63 2e685cad57906e19add7 a235435d612680e595ea
707.40 -41.0% 417.50-8.8% 645.00
lkp-nex04/micro/netperf/120s-200%-TCP_STREAM
2775.60 -23.7% 2116.50+2.1% 2834.00
lkp-sb03/micro/netperf/120s-200%-TCP_STREAM
3483.00 -27.2% 2534.00-0.1% 3479.00
TOTAL netperf.Throughput_Mbps
It's a bit late, but
Tested-by: Fengguang Wu
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: staging: bcm: Removed a developer debug statement.
On Wed, Oct 23, 2013 at 03:11:20PM -0400, Chuong Ngo wrote: > Removed a developer debug statement per the TODO list. Additionally, removed > braces for the if-statement to match coding style. Line wrap the changelog at 72 characters. You don't really need to mention the removed braces because that's too obvious to bother commenting on. My guess is that Greg will probably be willing to apply this as is so don't worry about resending unless he requests it. (He normally seems to let newbies get by with one line wrapping warning before he starts making you redo it). 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/
[PATCH] perf/ui/tui: don't force a refresh during progress update
Each call to tui_progress__update() would forcibly refresh the entire screen. This is somewhat inefficient and causes noticable flickering during the startup of perf-report, especially on large/slow terminals. It looks like the force-refresh in tui_progress__update() serves no purpose other than to clear the screen so that the progress bar of a previous operation does not subsume with that of a subsequent operation. But we can do just that in a much more efficient manner by clearing only the region that a previous progress bar may have occupied before repainting the new progress bar. Then the force-refresh could be removed with no change in visuals. This patch disables the slow force-refresh in tui_progress__update() and instead calls SLsmg_fill_region() on the entire area that the progress bar may occupy before repainting it. This change makes the startup of perf-report much faster and appear much "smoother". It turns out that this was a big bottleneck in the startup speed of perf-report -- with this patch, perf-report starts up ~1.6x faster (0.8s vs 0.5s) on my machines. (These numbers were measured by running "time perf report" on an 8MB perf.data and pressing 'q' immediately.) Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Ingo Molnar Signed-off-by: Patrick Palka --- tools/perf/ui/tui/progress.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/perf/ui/tui/progress.c b/tools/perf/ui/tui/progress.c index 6c2184d..641049a 100644 --- a/tools/perf/ui/tui/progress.c +++ b/tools/perf/ui/tui/progress.c @@ -17,13 +17,14 @@ static void tui_progress__update(u64 curr, u64 total, const char *title) if (total == 0) return; - ui__refresh_dimensions(true); + ui__refresh_dimensions(false); pthread_mutex_lock(&ui__lock); y = SLtt_Screen_Rows / 2 - 2; SLsmg_set_color(0); SLsmg_draw_box(y, 0, 3, SLtt_Screen_Cols); SLsmg_gotorc(y++, 1); SLsmg_write_string((char *)title); + SLsmg_fill_region(y, 1, 1, SLtt_Screen_Cols - 2, ' '); SLsmg_set_color(HE_COLORSET_SELECTED); bar = ((SLtt_Screen_Cols - 2) * curr) / total; SLsmg_fill_region(y, 1, 1, bar, ' '); -- 1.8.4.rc3 -- 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: OMAPFB: CMA allocation failures
Hi, I wonder if there is any progress on the issue? Do you need me to send more data? Or should I raise the issue with the CMA maintainer? Regards, Ivo > Оригинално писмо >От: Ивайло Димитров >Относно: Re: OMAPFB: CMA allocation failures >До: Tomi Valkeinen >Изпратено на: Сряда, 2013, Октомври 16 09:33:51 EEST > > > Hi Tomi, > >>I think we should somehow find out what the pages are that cannot be >>migrated, and where they come from. >> >>So there are "anonymous pages without mapping" with >>page_count(page) != >>1. I have to say I don't know what that means =). I need to find some >>time to study the mm. > >I put some more traces in the point of failure, the result: >page_count(page) == 2, page->flags == 0x0008025D, which is: >PG_locked, PG_referenced, PG_uptodate, PG_dirty, PG_active, PG_arch_1, >PG_unevictable >Whatever those mean :). I have no idea how to identify where those pages come >from. > >>Well, as I said, you're the first one to report any errors, after the >>change being in use for a year. Maybe people just haven't used recent >>enough kernels, and the issue is only now starting to emerge, but I >>wouldn't draw any conclusions yet. > >I am (almost) sure I am the first one to test video playback on OMAP3 with >DSP video >acceleration, using recent kernel and Maemo5 on n900 :). So there is high >probability the >issue was not reported earlier because noone have tested it thoroughly after >the change. > >>If the CMA would have big generic issues, I think we would've seen >>issues earlier. So I'm guessing it's some driver or app in your setup >>that's causing the issues. Maybe the driver/app is broken, or maybe that >>specific behavior is not handled well by CMA. In both case I think we >>need to identify what that driver/app is. > >What I know is going on, is that there is heavy fs I/O at the same time - >there is >a thumbnailer process running in background which tries to extract thumbnails >of all video >files in the system. Also, there are other processes doing various jobs >(e-mail fetching, IM >accounts login, whatnot). And in addition Xorg mlocks parts of its address >space. Of course >all this happens with lots of memory being swapped in and out. I guess all >this is related. > >However, even after the system has settled, the CMA failures continue to >happen. It looks like >some pages are allocated from CMA which should not be. > >>I wonder how I could try to reproduce this with a generic omap3 board... > >I can always reproduce it here (well, not on generic board, but I guess it is >even better to >test in real-life conditions), so if you need some specific tests or traces >or whatever, I >can do them for you. > >Regards, >Ivo > -- 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] pstore: avoid incorrectly mark entry as duplicate
On Wed, Oct 23, 2013 at 7:55 AM, Madper Xie wrote: > The "duplicate" entries won't appear in pstorefs. And a complain will be > print -- pstore: failed to load 76 record(s) from 'efi' Maybe I don't quite get this - but it sounds like you have a whole lot of entries using up space in efivars that have similar names - differing just in the timestamp - that won't show up in the pstore filesystem - because we'd try to name them all the same thing. How did all those things end up in efivars? Wouldn't the right fix be to make pstore allow them all to appear (using the timestamp to differentiate names?) so that we could see them, log them, and then remove them from pstore (in turn freeing up efivars space - which people keep telling me is in short supply). -Tony -- 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/
zram/zsmalloc issues in very low memory conditions
I am trying to use zram in very low memory conditions and I am having some issues. zram is in the reclaim path. So if the system is very low on memory the system is trying to reclaim pages by swapping out (in this case to zram). However, since we are very low on memory zram fails to get a page from zsmalloc and thus zram fails to store the page. We get into a cycle where the system is low on memory so it tries to swap out to get more memory but swap out fails because there is not enough memory in the system! The major problem I am seeing is that there does not seem to be a way for zram to tell the upper layers to stop swapping out because the swap device is essentially "full" (since there is no more memory available for zram pages). Has anyone thought about this issue already and have ideas how to solve this or am I missing something and I should not be seeing this issue? I am also seeing a couple other issues that I was wondering whether folks have already thought about: 1) The size of a swap device is statically computed when the swap device is turned on (nr_swap_pages). The size of zram swap device is dynamic since we are compressing the pages and thus the swap subsystem thinks that the zram swap device is full when it is not really full. Any plans/thoughts about the possibility of being able to update the size and/or the # of available pages in a swap device on the fly? 2) zsmalloc fails when the page allocated is at physical address 0 (pfn = 0) since the handle returned from zsmalloc is encoded as (, ) and thus the resulting handle will be 0 (since obj_idx starts at 0). zs_malloc returns the handle but does not distinguish between a valid handle of 0 and a failure to allocate. A possible solution to this would be to start the obj_idx at 1. Is this feasible? Thanks, Olav Haugan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iio:light:tsl2563: Add DT support
Add Device Tree support for the TSL2563 driver
and document the binding.
Signed-off-by: Sebastian Reichel
---
.../devicetree/bindings/iio/light/tsl2563.txt | 19 +++
drivers/iio/light/tsl2563.c | 4
2 files changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/tsl2563.txt
diff --git a/Documentation/devicetree/bindings/iio/light/tsl2563.txt
b/Documentation/devicetree/bindings/iio/light/tsl2563.txt
new file mode 100644
index 000..b52cf4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/tsl2563.txt
@@ -0,0 +1,19 @@
+* TAOS TSL2563 ambient light sensor
+
+Required properties:
+
+ - compatible : should be "taos,tsl2563"
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - cover-comp-gain : integer used as multiplier for gain
+ compensation (default = 1)
+
+Example:
+
+tsl2563@29 {
+ compatible = "taos,tsl2563";
+ reg = <0x29>;
+ cover-comp-gain = <16>;
+};
diff --git a/drivers/iio/light/tsl2563.c b/drivers/iio/light/tsl2563.c
index ebb962c..bd30b1d 100644
--- a/drivers/iio/light/tsl2563.c
+++ b/drivers/iio/light/tsl2563.c
@@ -699,6 +699,7 @@ static int tsl2563_probe(struct i2c_client *client,
struct iio_dev *indio_dev;
struct tsl2563_chip *chip;
struct tsl2563_platform_data *pdata = client->dev.platform_data;
+ struct device_node *np = client->dev.of_node;
int err = 0;
u8 id = 0;
@@ -735,6 +736,9 @@ static int tsl2563_probe(struct i2c_client *client,
if (pdata)
chip->cover_comp_gain = pdata->cover_comp_gain;
+ else if (np)
+ of_property_read_u32_index(np, "cover-comp-gain", 0,
+ &chip->cover_comp_gain);
else
chip->cover_comp_gain = 1;
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm,vdso: preallocate new vmas
On Wed, Oct 23, 2013 at 3:13 AM, Michel Lespinasse wrote: > On Tue, Oct 22, 2013 at 10:54 AM, Andy Lutomirski wrote: >> On 10/22/2013 08:48 AM, wal...@google.com wrote: >>> Generally the problems I see with mmap_sem are related to long latency >>> operations. Specifically, the mmap_sem write side is currently held >>> during the entire munmap operation, which iterates over user pages to >>> free them, and can take hundreds of milliseconds for large VMAs. >> >> This is the leading cause of my "egads, something that should have been >> fast got delayed for several ms" detector firing. > > Yes, I'm seeing such issues relatively frequently as well. > >> I've been wondering: >> >> Could we replace mmap_sem with some kind of efficient range lock? The >> operations would be: >> >> - mm_lock_all_write (drop-in replacement for down_write(&...->mmap_sem)) >> - mm_lock_all_read (same for down_read) >> - mm_lock_write_range(mm, start, end) >> - mm_lock_read_range(mm, start_end) >> >> and corresponding unlock functions (that maybe take a cookie that the >> lock functions return or that take a pointer to some small on-stack data >> structure). > > That seems doable, however I believe we can get rid of the latencies > in the first place which seems to be a better direction. As I briefly > mentioned, I would like to tackle the munmap problem sometime; Jan > Kara also has a project to remove places where blocking FS functions > are called with mmap_sem held (he's doing it for lock ordering > purposes, so that FS can call in to MM functions that take mmap_sem, > but there are latency benefits as well if we can avoid blocking in FS > with mmap_sem held). There will still be scalability issues if there are enough threads, but maybe this isn't so bad. (My workload may also have priority inversion problems -- there's a thread that runs on its own core and needs the mmap_sem read lock and a thread that runs on a highly contended core that needs the write lock.) > >> The easiest way to implement this that I can think of is a doubly-linked >> list or even just an array, which should be fine for a handful of >> threads. Beyond that, I don't really know. Creating a whole trie for >> these things would be expensive, and fine-grained locking on rbtree-like >> things isn't so easy. > > Jan also had an implementation of range locks using interval trees. To > take a range lock, you'd add the range you want to the interval tree, > count the conflicting range lock requests that were there before you, > and (if nonzero) block until that count goes to 0. When releasing the > range lock, you look for any conflicting requests in the interval tree > and decrement their conflict count, waking them up if the count goes > to 0. Yuck. Now we're taking a per-mm lock on the rbtree, doing some cacheline-bouncing rbtree operations, and dropping the lock to serialize access to something that probably only has a small handful of accessors at a time. I bet that an O(num locks) array or linked list will end up being faster in practice. I think the idea solution would be to shove these things into the page tables somehow, but that seems impossibly complicated. --Andy > > But as I said earlier, I would prefer if we could avoid holding > mmap_sem during long-latency operations rather than working around > this issue with range locks. > > -- > Michel "Walken" Lespinasse > A program is never fully debugged until the last user dies. -- Andy Lutomirski AMA Capital Management, LLC -- 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] Does PHY UTMI data width belong to DWC2 or PHY binding?
> From: Matt Porter [mailto:matt.por...@linaro.org] > Sent: Wednesday, October 23, 2013 7:43 AM > > On Tue, Oct 22, 2013 at 04:38:52PM -0500, Rob Herring wrote: > > On 10/22/2013 06:25 AM, Matt Porter wrote: > > > On Tue, Oct 22, 2013 at 12:48:29PM +0200, Matthijs Kooijman wrote: > > >> Hi Kishon, > > >> > > >> On Mon, Oct 21, 2013 at 02:57:26PM +0530, Kishon Vijay Abraham I wrote: > > >>> I think it makes sense to keep the data width property in the dwc2 node > > >>> itself. > > >>> I mean it describes how the dwc2 IP is configured in that particular > > >>> SoC (given > > >>> that it can be either <8> or <16>). > > >> If I'm reading the RT3052 datasheet correctly (GHWCFG4 register), the IP > > >> can be configured for 8, 16 or 8 _and_ 16. In the latter case, the "8 > > >> and 16 supported" would make sense as a property of dwc2 (though this > > >> value should be autodetectable through GHWCFG4), while the actual 8 or > > >> 16 supported by the PHY would make sense as property of a phy. > > > > > > There would be no value in adding a property for an already detectable > > > value to dwc2's binding. To be honest, it's pretty much useless > > > information due to the existence of the "8 and 16" option. > > > > > >> Note sure if this is really useful in practice as well, or if just > > >> setting the actual width to use on dwc2 makes more sense... > > > > > > The GHWCFG4 information itself is not useful in practice, as described > > > in the original thread: https://lkml.org/lkml/2013/10/10/477 > > > > > > It's certainly useful in practice to have this width property in either > > > the dwc2 or the phy binding. One can make a case for either. As I > > > mentioned in the original post, if we put it in the phy binding we'll be > > > updating the generic phy binding. We'll then need an api added into the > > > generic phy framework to fetch the width of a phy. > > > > > > Both cases are doable and trivial, we just need the canonical decision > > > from a DT maintainer as to where the property belongs. Given that they > > > are in ARM ksummit, I'm not expecting to hear anything right this > > > moment. :) > > > > The host can support both, so it is not a property of the host and is a > > property of the phy. It is no different than what mode a SPI slave > > requires or whether an i2c slave supports 8 or 10-bit addressing. Those > > examples are all 1 to many rather than 1 to 1 where it doesn't really > > matter, but the same logic applies. > > Makes good sense, thanks. > > In this case, given the PHY ownership of width, we can completely avoid > any DT properties. The generic phy compliant BCM Kona phy driver can > report via the generic phy framework that it is 8-bit wide. There's no > support for this type of thing now but it's pretty trivial to add. > I went ahead and did a quick proof-of-concept that adds a free-form > phy attributes struct for the generic phy. Given that generic phys can > be for any transmission technology this could be filled with a jumble > unrelated and often unpopulated attributes over time. In any case, the > below patch allows the phy provider to choose to specify utmi_width and > a controller driver that cares can use phy_get_attrs() to fetch the > optional phy attributes and use the utmi_width field if applicable. As an alternate approach, you could add a 'utmi_width' property to the PHY's DT node, and have the dwc2 driver scan the tree until it finds its PHY, and then check it for that property. That would avoid the need to add anything new to the PHY framework. I don't know if that would be considered good practice by the DT guys, though. -- Paul -- 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 06/16] perf bench: Change the procps visible command-name of invididual benchmark tests plus cleanups
From: Ingo Molnar
Before this patch, looking at 'perf bench sched pipe' behavior over
'top' only told us that something related to perf is running:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
19934 mingo 20 0 54836 1296 952 R 18.6 0.0 0:00.56 perf
19935 mingo 20 0 54836 384 36 S 18.6 0.0 0:00.56 perf
After the patch it's clearly visible what's going on:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
19744 mingo 20 0 125m 3536 2644 R 68.2 0.0 0:01.12 sched-pipe
19745 mingo 20 0 125m 1172 276 R 68.2 0.0 0:01.12 sched-pipe
The benchmark-subsystem name is concatenated with the individual
testcase name.
Unfortunately 'perf top' does not show the reconfigured name, possibly
because it caches ->comm[] values and does not recognize changes to
them?
Also clean up a few bits in builtin-bench.c while at it and reorganize
the code and the output strings to be consistent.
Use iterators to access the various arrays. Rename 'suites' concept to
'benchmark collection' and the 'bench_suite' to 'benchmark/bench'. The
many repetitions of 'suite' made the code harder to read and understand.
The new output is:
comet:~/tip/tools/perf> ./perf bench
Usage:
perf bench [] []
# List of all available benchmark collections:
sched: Scheduler and IPC benchmarks
mem: Memory access benchmarks
numa: NUMA scheduling and MM benchmarks
all: All benchmarks
comet:~/tip/tools/perf> ./perf bench sched
# List of available benchmarks for collection 'sched':
messaging: Benchmark for scheduling and IPC
pipe: Benchmark for pipe() between two processes
all: Test all scheduler benchmarks
comet:~/tip/tools/perf> ./perf bench mem
# List of available benchmarks for collection 'mem':
memcpy: Benchmark for memcpy()
memset: Benchmark for memset() tests
all: Test all memory benchmarks
comet:~/tip/tools/perf> ./perf bench numa
# List of available benchmarks for collection 'numa':
mem: Benchmark for NUMA workloads
all: Test all NUMA benchmarks
Individual benchmark modules were not touched.
Signed-off-by: Ingo Molnar
Cc: David Ahern
Cc: Hitoshi Mitake
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20131023123756.ga17...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-bench.c | 239 +++--
1 file changed, 122 insertions(+), 117 deletions(-)
diff --git a/tools/perf/builtin-bench.c b/tools/perf/builtin-bench.c
index 33af80fa49cf..e47f90cc7b98 100644
--- a/tools/perf/builtin-bench.c
+++ b/tools/perf/builtin-bench.c
@@ -1,21 +1,18 @@
/*
- *
* builtin-bench.c
*
- * General benchmarking subsystem provided by perf
+ * General benchmarking collections provided by perf
*
* Copyright (C) 2009, Hitoshi Mitake
- *
*/
/*
+ * Available benchmark collection list:
*
- * Available subsystem list:
- * sched ... scheduler and IPC mechanism
+ * sched ... scheduler and IPC performance
* mem ... memory access performance
- *
+ * numa ... NUMA scheduling and MM performance
*/
-
#include "perf.h"
#include "util/util.h"
#include "util/parse-options.h"
@@ -25,112 +22,92 @@
#include
#include
#include
+#include
-struct bench_suite {
- const char *name;
- const char *summary;
- int (*fn)(int, const char **, const char *);
+typedef int (*bench_fn_t)(int argc, const char **argv, const char *prefix);
+
+struct bench {
+ const char *name;
+ const char *summary;
+ bench_fn_t fn;
};
- \
-/* sentinel: easy for help */
-#define suite_all { "all", "Test all benchmark suites", NULL }
#ifdef HAVE_LIBNUMA_SUPPORT
-static struct bench_suite numa_suites[] = {
- { "mem",
- "Benchmark for NUMA workloads",
- bench_numa },
- suite_all,
- { NULL,
- NULL,
- NULL }
+static struct bench numa_benchmarks[] = {
+ { "mem","Benchmark for NUMA workloads",
bench_numa },
+ { "all","Test all NUMA benchmarks", NULL
},
+ { NULL, NULL, NULL
}
};
#endif
-static struct bench_suite sched_suites[] = {
- { "messaging",
- "Benchmark for scheduler and IPC mechanisms",
- bench_sched_messaging },
- { "pipe",
- "Flood of communication over pipe() between two processes",
- bench_sched_pipe },
- suite_all,
- { NULL,
- NULL,
- NULL }
+static struct bench sched_benchmarks[] = {
+ { "messaging", "Benchmark for scheduling and IPC",
bench_sched_mes
[PATCH 16/16] perf tools: Show progress on histogram collapsing
From: Namhyung Kim
It can take quite amount of time so add progress bar UI to inform user.
Signed-off-by: Namhyung Kim
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1381468543-25334-4-git-send-email-namhy...@kernel.org
[ perf_progress -> ui_progress ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-annotate.c | 2 +-
tools/perf/builtin-diff.c | 2 +-
tools/perf/builtin-report.c | 10 +-
tools/perf/builtin-top.c | 4 ++--
tools/perf/tests/hists_link.c | 2 +-
tools/perf/util/hist.c| 5 -
tools/perf/util/hist.h| 3 ++-
7 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 17c6b494e8cc..6c5ae57831f6 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -247,7 +247,7 @@ static int __cmd_annotate(struct perf_annotate *ann)
if (nr_samples > 0) {
total_nr_samples += nr_samples;
- hists__collapse_resort(hists);
+ hists__collapse_resort(hists, NULL);
hists__output_resort(hists);
if (symbol_conf.event_group &&
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 9c828881714c..b605009e803f 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -369,7 +369,7 @@ static void perf_evlist__collapse_resort(struct perf_evlist
*evlist)
list_for_each_entry(evsel, &evlist->entries, node) {
struct hists *hists = &evsel->hists;
- hists__collapse_resort(hists);
+ hists__collapse_resort(hists, NULL);
}
}
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index e3598a456017..98d3891392e2 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -496,6 +496,7 @@ static int __cmd_report(struct perf_report *rep)
struct map *kernel_map;
struct kmap *kernel_kmap;
const char *help = "For a higher level overview, try: perf report
--sort comm,dso";
+ struct ui_progress prog;
struct perf_data_file *file = session->file;
signal(SIGINT, sig_handler);
@@ -558,13 +559,19 @@ static int __cmd_report(struct perf_report *rep)
}
nr_samples = 0;
+ list_for_each_entry(pos, &session->evlist->entries, node)
+ nr_samples += pos->hists.nr_entries;
+
+ ui_progress__init(&prog, nr_samples, "Merging related events...");
+
+ nr_samples = 0;
list_for_each_entry(pos, &session->evlist->entries, node) {
struct hists *hists = &pos->hists;
if (pos->idx == 0)
hists->symbol_filter_str = rep->symbol_filter_str;
- hists__collapse_resort(hists);
+ hists__collapse_resort(hists, &prog);
nr_samples += hists->stats.nr_events[PERF_RECORD_SAMPLE];
/* Non-group events are considered as leader */
@@ -576,6 +583,7 @@ static int __cmd_report(struct perf_report *rep)
hists__link(leader_hists, hists);
}
}
+ ui_progress__finish();
if (session_done())
return 0;
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 386d83324a8d..76c9264ed070 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -286,7 +286,7 @@ static void perf_top__print_sym_table(struct perf_top *top)
return;
}
- hists__collapse_resort(&top->sym_evsel->hists);
+ hists__collapse_resort(&top->sym_evsel->hists, NULL);
hists__output_resort(&top->sym_evsel->hists);
hists__decay_entries(&top->sym_evsel->hists,
top->hide_user_symbols,
@@ -552,7 +552,7 @@ static void perf_top__sort_new_samples(void *arg)
if (t->evlist->selected != NULL)
t->sym_evsel = t->evlist->selected;
- hists__collapse_resort(&t->sym_evsel->hists);
+ hists__collapse_resort(&t->sym_evsel->hists, NULL);
hists__output_resort(&t->sym_evsel->hists);
hists__decay_entries(&t->sym_evsel->hists,
t->hide_user_symbols,
diff --git a/tools/perf/tests/hists_link.c b/tools/perf/tests/hists_link.c
index 025503a22ff7..b51abcb2c243 100644
--- a/tools/perf/tests/hists_link.c
+++ b/tools/perf/tests/hists_link.c
@@ -467,7 +467,7 @@ int test__hists_link(void)
goto out;
list_for_each_entry(evsel, &evlist->entries, node) {
- hists__collapse_resort(&evsel->hists);
+ hists__collapse_resort(&evsel->hists, NULL);
if (verbose > 2)
print_hists(&evsel->hists);
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index f0b863ef4896..7e80
ARM seccomp filters and EABI/OABI
I'm looking at the seccomp code, the ARM entry code, and the syscall(2) manpage, and I'm a bit lost. (The fact that I don't really speak ARM assembly doesn't help.) My basic question is: what happens if an OABI syscall happens? AFAICS, the syscall arguments for EABI are r0..r5, although their ordering is a bit odd*. For OABI, r6 seems to play some role, but I'm lost as to what it is. The seccomp_bpf_load function won't load r6, so there had better not be anything useful in there... (Also, struct seccomp_data will have issues with a seventh "argument".) But what happens to the syscall number? For an EABI syscall, it's in r7. For an OABI syscall, it's in the swi instruction and gets copied to r7 on entry. If a debugger changes r7, presumably the syscall number changes. Oddly, there are two different syscall tables. The major differences seem to be that some of the OABI entries have their argument order changed. But there's also a magic constant 0x90 added to the syscall number somewhere -- is it reflected in _sigsys._syscall? Is it reflected in ucontext's r7? I'm a bit surprised to see that both the EABI and OABI ABIs show up as AUDIT_ARCH_ARM. Can any of you shed some light on this? I don't have an ARM system I can test on, but if one of you can point me at a decent QEMU image, I can play around. For reference, I'm working on userspace code to decode a TRAP and eventually to allow syscall emulation (either by emulating the syscall inside the signal handler and setting the return value or (egads!) by changing the syscall and restarting it -- the latter is probably impossible if the original syscall came in through OABI and may be generally impossible if userspace expects any of the argument registers to be preserved). * I think that a syscall with signature long func(int a, long long b, int c, int d, int e) ends up with c in r1 and b in r2/r3. The syscall(2) manpage appears to be entirely wrong. -- 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 08/16] perf sched: Optimize build time
From: Adrian Hunter
builtin-sched.c took a log time to build with -O6 optimization. This
turned out to be caused by:
.curr_pid = { [0 ... MAX_CPUS - 1] = -1 },
Fix by initializing curr_pid programmatically.
This addresses the problem cured in f36f83f947ed using a smaller hammer.
Signed-off-by: Adrian Hunter
Acked-by: David Ahern
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1382427258-17495-13-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-sched.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 5a338566195e..ddb5dc15be17 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1670,7 +1670,6 @@ int cmd_sched(int argc, const char **argv, const char
*prefix __maybe_unused)
.sort_list= LIST_HEAD_INIT(sched.sort_list),
.start_work_mutex = PTHREAD_MUTEX_INITIALIZER,
.work_done_wait_mutex = PTHREAD_MUTEX_INITIALIZER,
- .curr_pid = { [0 ... MAX_CPUS - 1] = -1 },
.sort_order = default_sort_order,
.replay_repeat= 10,
.profile_cpu = -1,
@@ -1732,6 +1731,10 @@ int cmd_sched(int argc, const char **argv, const char
*prefix __maybe_unused)
.switch_event = replay_switch_event,
.fork_event = replay_fork_event,
};
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(sched.curr_pid); i++)
+ sched.curr_pid[i] = -1;
argc = parse_options(argc, argv, sched_options, sched_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
--
1.8.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 05/16] perf probe: Find fentry mcount fuzzed parameter location
From: Masami Hiramatsu
At this point, --fentry (mcount function entry) option for gcc fuzzes
the debuginfo variable locations by skipping the mcount instruction
offset (on x86, this is a 5 byte call instruction).
This makes variable searching fail at the entry of functions which
are mcount'ed.
e.g.)
Available variables at vfs_read
@
(No matched variables)
This patch adds additional location search at the function entry point
to solve this issue, which tries to find the earliest address for the
variable location.
Note that this only works with function parameters (formal parameters)
because any local variables should not exist on the function entry
address (those are not initialized yet).
With this patch, perf probe shows correct parameters if possible;
# perf probe --vars vfs_read
Available variables at vfs_read
@
char* buf
loff_t* pos
size_t count
struct file*file
Signed-off-by: Masami Hiramatsu
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/20131011071025.15557.13275.st...@udc4-manage.rcp.hitachi.co.jp
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-finder.c | 39 +++
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 5a46be968c0b..c04405296e5b 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -273,12 +273,15 @@ static struct probe_trace_arg_ref
*alloc_trace_arg_ref(long offs)
/*
* Convert a location into trace_arg.
* If tvar == NULL, this just checks variable can be converted.
+ * If fentry == true and vr_die is a parameter, do huristic search
+ * for the location fuzzed by function entry mcount.
*/
static int convert_variable_location(Dwarf_Die *vr_die, Dwarf_Addr addr,
-Dwarf_Op *fb_ops,
+Dwarf_Op *fb_ops, Dwarf_Die *sp_die,
struct probe_trace_arg *tvar)
{
Dwarf_Attribute attr;
+ Dwarf_Addr tmp = 0;
Dwarf_Op *op;
size_t nops;
unsigned int regn;
@@ -291,12 +294,29 @@ static int convert_variable_location(Dwarf_Die *vr_die,
Dwarf_Addr addr,
goto static_var;
/* TODO: handle more than 1 exprs */
- if (dwarf_attr(vr_die, DW_AT_location, &attr) == NULL ||
- dwarf_getlocation_addr(&attr, addr, &op, &nops, 1) <= 0 ||
- nops == 0) {
- /* TODO: Support const_value */
+ if (dwarf_attr(vr_die, DW_AT_location, &attr) == NULL)
+ return -EINVAL; /* Broken DIE ? */
+ if (dwarf_getlocation_addr(&attr, addr, &op, &nops, 1) <= 0) {
+ ret = dwarf_entrypc(sp_die, &tmp);
+ if (ret || addr != tmp ||
+ dwarf_tag(vr_die) != DW_TAG_formal_parameter ||
+ dwarf_highpc(sp_die, &tmp))
+ return -ENOENT;
+ /*
+* This is fuzzed by fentry mcount. We try to find the
+* parameter location at the earliest address.
+*/
+ for (addr += 1; addr <= tmp; addr++) {
+ if (dwarf_getlocation_addr(&attr, addr, &op,
+ &nops, 1) > 0)
+ goto found;
+ }
return -ENOENT;
}
+found:
+ if (nops == 0)
+ /* TODO: Support const_value */
+ return -ENOENT;
if (op->atom == DW_OP_addr) {
static_var:
@@ -600,7 +620,7 @@ static int convert_variable(Dwarf_Die *vr_die, struct
probe_finder *pf)
dwarf_diename(vr_die));
ret = convert_variable_location(vr_die, pf->addr, pf->fb_ops,
- pf->tvar);
+ &pf->sp_die, pf->tvar);
if (ret == -ENOENT)
pr_err("Failed to find the location of %s at this address.\n"
" Perhaps, it has been optimized out.\n", pf->pvar->var);
@@ -1148,13 +1168,15 @@ struct local_vars_finder {
static int copy_variables_cb(Dwarf_Die *die_mem, void *data)
{
struct local_vars_finder *vf = data;
+ struct probe_finder *pf = vf->pf;
int tag;
tag = dwarf_tag(die_mem);
if (tag == DW_TAG_formal_parameter ||
tag == DW_TAG_variable) {
if (convert_variable_location(die_mem, vf->pf->addr,
- vf->pf->fb_ops, NULL) == 0) {
+ vf->pf->fb_ops, &pf->sp_die,
+ NULL) == 0) {
vf->args[vf->nargs].var = (char
*)dwarf_diename(die_mem);
if (vf->args[vf->nargs].var == NULL) {
[PATCH 11/16] perf tools: Do not accept parse_tag_value() overflow
From: Adrian Hunter parse_tag_value() accepts an "unsigned long" and multiplies it according to a tag character. Do not accept the value if the multiplication overflows. Signed-off-by: Adrian Hunter Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1382427258-17495-14-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/util.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c index c25e57b3acb2..28a0a89c1f73 100644 --- a/tools/perf/util/util.c +++ b/tools/perf/util/util.c @@ -386,6 +386,8 @@ unsigned long parse_tag_value(const char *str, struct parse_tag *tags) if (s != endptr) break; + if (value > ULONG_MAX / i->mult) + break; value *= i->mult; return value; } -- 1.8.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 15/16] perf ui progress: Per progress bar state
From: Arnaldo Carvalho de Melo
That will ease using a progress bar across multiple functions, like in
the upcoming patches that will present a progress bar when collapsing
histograms.
Based on a previous patch by Namhyung Kim.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-cr7lq7ud9fj21bg7wvq27...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/gtk/progress.c | 8
tools/perf/ui/progress.c | 22 +-
tools/perf/ui/progress.h | 15 +++
tools/perf/ui/tui/progress.c | 8
tools/perf/util/session.c| 24 +++-
5 files changed, 47 insertions(+), 30 deletions(-)
diff --git a/tools/perf/ui/gtk/progress.c b/tools/perf/ui/gtk/progress.c
index 195c7f94f98e..b656655fbc39 100644
--- a/tools/perf/ui/gtk/progress.c
+++ b/tools/perf/ui/gtk/progress.c
@@ -7,14 +7,14 @@
static GtkWidget *dialog;
static GtkWidget *progress;
-static void gtk_ui_progress__update(u64 curr, u64 total, const char *title)
+static void gtk_ui_progress__update(struct ui_progress *p)
{
- double fraction = total ? 1.0 * curr / total : 0.0;
+ double fraction = p->total ? 1.0 * p->curr / p->total : 0.0;
char buf[1024];
if (dialog == NULL) {
GtkWidget *vbox = gtk_vbox_new(TRUE, 5);
- GtkWidget *label = gtk_label_new(title);
+ GtkWidget *label = gtk_label_new(p->title);
dialog = gtk_window_new(GTK_WINDOW_TOPLEVEL);
progress = gtk_progress_bar_new();
@@ -32,7 +32,7 @@ static void gtk_ui_progress__update(u64 curr, u64 total,
const char *title)
}
gtk_progress_bar_set_fraction(GTK_PROGRESS_BAR(progress), fraction);
- snprintf(buf, sizeof(buf), "%"PRIu64" / %"PRIu64, curr, total);
+ snprintf(buf, sizeof(buf), "%"PRIu64" / %"PRIu64, p->curr, p->total);
gtk_progress_bar_set_text(GTK_PROGRESS_BAR(progress), buf);
/* we didn't call gtk_main yet, so do it manually */
diff --git a/tools/perf/ui/progress.c b/tools/perf/ui/progress.c
index d753821b6e0b..a0f24c7115c5 100644
--- a/tools/perf/ui/progress.c
+++ b/tools/perf/ui/progress.c
@@ -1,9 +1,7 @@
#include "../cache.h"
#include "progress.h"
-static void null_progress__update(u64 curr __maybe_unused,
- u64 total __maybe_unused,
- const char *title __maybe_unused)
+static void null_progress__update(struct ui_progress *p __maybe_unused)
{
}
@@ -14,9 +12,23 @@ static struct ui_progress_ops null_progress__ops =
struct ui_progress_ops *ui_progress__ops = &null_progress__ops;
-void ui_progress__update(u64 curr, u64 total, const char *title)
+void ui_progress__update(struct ui_progress *p, u64 adv)
{
- return ui_progress__ops->update(curr, total, title);
+ p->curr += adv;
+
+ if (p->curr >= p->next) {
+ p->next += p->step;
+ ui_progress__ops->update(p);
+ }
+}
+
+void ui_progress__init(struct ui_progress *p, u64 total, const char *title)
+{
+ p->curr = 0;
+ p->next = p->step = total / 16;
+ p->total = total;
+ p->title = title;
+
}
void ui_progress__finish(void)
diff --git a/tools/perf/ui/progress.h b/tools/perf/ui/progress.h
index d41bde5908a6..29ec8efffefb 100644
--- a/tools/perf/ui/progress.h
+++ b/tools/perf/ui/progress.h
@@ -3,14 +3,21 @@
#include <../types.h>
+void ui_progress__finish(void);
+
+struct ui_progress {
+ const char *title;
+ u64 curr, next, step, total;
+};
+
+void ui_progress__init(struct ui_progress *p, u64 total, const char *title);
+void ui_progress__update(struct ui_progress *p, u64 adv);
+
struct ui_progress_ops {
- void (*update)(u64, u64, const char *);
+ void (*update)(struct ui_progress *p);
void (*finish)(void);
};
extern struct ui_progress_ops *ui_progress__ops;
-void ui_progress__update(u64 curr, u64 total, const char *title);
-void ui_progress__finish(void);
-
#endif
diff --git a/tools/perf/ui/tui/progress.c b/tools/perf/ui/tui/progress.c
index 0fcc5a1f525a..3e2d936d7443 100644
--- a/tools/perf/ui/tui/progress.c
+++ b/tools/perf/ui/tui/progress.c
@@ -5,7 +5,7 @@
#include "tui.h"
#include "../browser.h"
-static void tui_progress__update(u64 curr, u64 total, const char *title)
+static void tui_progress__update(struct ui_progress *p)
{
int bar, y;
/*
@@ -15,7 +15,7 @@ static void tui_progress__update(u64 curr, u64 total, const
char *title)
if (use_browser <= 0)
return;
- if (total == 0)
+ if (p->total == 0)
return;
ui__refresh_dimensions(true);
@@ -24,9 +24,9 @@ static void tui_progress__update(u64 curr, u64 total, const
char *title)
SLsmg_set_color(0);
SLsmg_draw_box(y, 0, 3, SLtt
[PATCH] mm: get rid of unnecessary pageblock scanning in setup_zone_migrate_reserve
From: KOSAKI Motohiro
Yasuaki Ithimatsu reported memory hot-add spent more than 5 _hours_
on 9TB memory machine and we found out setup_zone_migrate_reserve
spnet >90% time.
The problem is, setup_zone_migrate_reserve scan all pageblock
unconditionally, but it is only necessary number of reserved block
was reduced (i.e. memory hot remove).
Moreover, maximum MIGRATE_RESERVE per zone are currently 2. It mean,
number of reserved pageblock are almost always unchanged.
This patch adds zone->nr_migrate_reserve_block to maintain number
of MIGRATE_RESERVE pageblock and it reduce an overhead of
setup_zone_migrate_reserve dramatically.
Cc: Mel Gorman
Reported-by: Yasuaki Ishimatsu
Cc: Yasuaki Ishimatsu
Signed-off-by: KOSAKI Motohiro
---
include/linux/mmzone.h |6 ++
mm/page_alloc.c| 13 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index bd791e4..67ab5fe 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -490,6 +490,12 @@ struct zone {
unsigned long managed_pages;
/*
+* Number of MIGRATE_RESEVE page block. To maintain for just
+* optimization. Protected by zone->lock.
+*/
+ int nr_migrate_reserve_block;
+
+ /*
* rarely used fields:
*/
const char *name;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 58e67ea..76ca054 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3909,6 +3909,7 @@ static void setup_zone_migrate_reserve(struct zone *zone)
struct page *page;
unsigned long block_migratetype;
int reserve;
+ int old_reserve;
/*
* Get the start pfn, end pfn and the number of blocks to reserve
@@ -3930,6 +3931,12 @@ static void setup_zone_migrate_reserve(struct zone *zone)
* future allocation of hugepages at runtime.
*/
reserve = min(2, reserve);
+ old_reserve = zone->nr_migrate_reserve_block;
+
+ /* When memory hot-add, we almost always need to do nothing */
+ if (reserve == old_reserve)
+ return;
+ zone->nr_migrate_reserve_block = reserve;
for (pfn = start_pfn; pfn < end_pfn; pfn += pageblock_nr_pages) {
if (!pfn_valid(pfn))
@@ -3967,6 +3974,12 @@ static void setup_zone_migrate_reserve(struct zone *zone)
reserve--;
continue;
}
+ } else if (!old_reserve) {
+ /*
+* When boot time, we don't need scan whole zone
+* for turning off MIGRATE_RESERVE.
+*/
+ break;
}
/*
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/16] perf probe: Support "$vars" meta argument syntax for local variables
From: Masami Hiramatsu
Support "$vars" meta argument syntax for tracing all local variables at
probe point.
Now you can trace all available local variables (including function
parameters) at the probe point by passing $vars.
# perf probe --add foo $vars
This automatically finds all local variables at foo() and adds it as
probe arguments.
Signed-off-by: Masami Hiramatsu
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/20131011071023.15557.51770.st...@udc4-manage.rcp.hitachi.co.jp
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-event.c | 1 -
tools/perf/util/probe-finder.c | 96 ++
tools/perf/util/probe-finder.h | 1 +
3 files changed, 89 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 779b2dacd43f..9c6989ca2bea 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -47,7 +47,6 @@
#include "session.h"
#define MAX_CMDLEN 256
-#define MAX_PROBE_ARGS 128
#define PERFPROBE_GROUP "probe"
bool probe_event_dry_run; /* Dry run flag */
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index c09e0a9fdf4c..5a46be968c0b 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -1136,12 +1136,78 @@ found:
return ret;
}
+struct local_vars_finder {
+ struct probe_finder *pf;
+ struct perf_probe_arg *args;
+ int max_args;
+ int nargs;
+ int ret;
+};
+
+/* Collect available variables in this scope */
+static int copy_variables_cb(Dwarf_Die *die_mem, void *data)
+{
+ struct local_vars_finder *vf = data;
+ int tag;
+
+ tag = dwarf_tag(die_mem);
+ if (tag == DW_TAG_formal_parameter ||
+ tag == DW_TAG_variable) {
+ if (convert_variable_location(die_mem, vf->pf->addr,
+ vf->pf->fb_ops, NULL) == 0) {
+ vf->args[vf->nargs].var = (char
*)dwarf_diename(die_mem);
+ if (vf->args[vf->nargs].var == NULL) {
+ vf->ret = -ENOMEM;
+ return DIE_FIND_CB_END;
+ }
+ pr_debug(" %s", vf->args[vf->nargs].var);
+ vf->nargs++;
+ }
+ }
+
+ if (dwarf_haspc(die_mem, vf->pf->addr))
+ return DIE_FIND_CB_CONTINUE;
+ else
+ return DIE_FIND_CB_SIBLING;
+}
+
+static int expand_probe_args(Dwarf_Die *sc_die, struct probe_finder *pf,
+struct perf_probe_arg *args)
+{
+ Dwarf_Die die_mem;
+ int i;
+ int n = 0;
+ struct local_vars_finder vf = {.pf = pf, .args = args,
+ .max_args = MAX_PROBE_ARGS, .ret = 0};
+
+ for (i = 0; i < pf->pev->nargs; i++) {
+ /* var never be NULL */
+ if (strcmp(pf->pev->args[i].var, "$vars") == 0) {
+ pr_debug("Expanding $vars into:");
+ vf.nargs = n;
+ /* Special local variables */
+ die_find_child(sc_die, copy_variables_cb, (void *)&vf,
+ &die_mem);
+ pr_debug(" (%d)\n", vf.nargs - n);
+ if (vf.ret < 0)
+ return vf.ret;
+ n = vf.nargs;
+ } else {
+ /* Copy normal argument */
+ args[n] = pf->pev->args[i];
+ n++;
+ }
+ }
+ return n;
+}
+
/* Add a found probe point into trace event list */
static int add_probe_trace_event(Dwarf_Die *sc_die, struct probe_finder *pf)
{
struct trace_event_finder *tf =
container_of(pf, struct trace_event_finder, pf);
struct probe_trace_event *tev;
+ struct perf_probe_arg *args;
int ret, i;
/* Check number of tevs */
@@ -1161,21 +1227,35 @@ static int add_probe_trace_event(Dwarf_Die *sc_die,
struct probe_finder *pf)
pr_debug("Probe point found: %s+%lu\n", tev->point.symbol,
tev->point.offset);
- /* Find each argument */
- tev->nargs = pf->pev->nargs;
- tev->args = zalloc(sizeof(struct probe_trace_arg) * tev->nargs);
- if (tev->args == NULL)
+ /* Expand special probe argument if exist */
+ args = zalloc(sizeof(struct perf_probe_arg) * MAX_PROBE_ARGS);
+ if (args == NULL)
return -ENOMEM;
- for (i = 0; i < pf->pev->nargs; i++) {
- pf->pvar = &pf->pev->args[i];
+
+ ret = expand_probe_args(sc_die, pf, args);
+ if (ret < 0)
+ goto end;
+
+ tev->nargs = ret;
+ tev->args = zalloc(sizeof(struct probe_trace_arg) * tev->nargs);
+ if (tev->args == NULL) {
[PATCH 14/16] perf ui: Rename ui_progress to ui_progress_ops
From: Arnaldo Carvalho de Melo
Reserving 'struct ui_progress' to the per progress instances, not to the
particular set of operations used to implmenet a progress bar in the
current UI (GTK, TUI, etc).
Cc: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-zjqbfp9gx3yo45s0rp9uv...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Makefile.perf | 1 +
tools/perf/ui/gtk/gtk.h | 2 +-
tools/perf/ui/gtk/progress.c | 14 +++---
tools/perf/ui/gtk/setup.c| 2 +-
tools/perf/ui/progress.c | 18 +-
tools/perf/ui/progress.h | 6 ++
tools/perf/ui/tui/progress.c | 7 ---
tools/perf/ui/tui/setup.c| 3 ++-
tools/perf/ui/tui/tui.h | 6 ++
9 files changed, 33 insertions(+), 26 deletions(-)
create mode 100644 tools/perf/ui/tui/tui.h
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 326a26e5fc1c..8a9ca3836043 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -487,6 +487,7 @@ ifndef NO_SLANG
LIB_OBJS += $(OUTPUT)ui/tui/util.o
LIB_OBJS += $(OUTPUT)ui/tui/helpline.o
LIB_OBJS += $(OUTPUT)ui/tui/progress.o
+ LIB_H += ui/tui/tui.h
LIB_H += ui/browser.h
LIB_H += ui/browsers/map.h
LIB_H += ui/keysyms.h
diff --git a/tools/perf/ui/gtk/gtk.h b/tools/perf/ui/gtk/gtk.h
index 8576cf194872..0a9173ff9a61 100644
--- a/tools/perf/ui/gtk/gtk.h
+++ b/tools/perf/ui/gtk/gtk.h
@@ -34,7 +34,7 @@ struct perf_gtk_context *perf_gtk__activate_context(GtkWidget
*window);
int perf_gtk__deactivate_context(struct perf_gtk_context **ctx);
void perf_gtk__init_helpline(void);
-void perf_gtk__init_progress(void);
+void gtk_ui_progress__init(void);
void perf_gtk__init_hpp(void);
void perf_gtk__signal(int sig);
diff --git a/tools/perf/ui/gtk/progress.c b/tools/perf/ui/gtk/progress.c
index 482bcf3df9b7..195c7f94f98e 100644
--- a/tools/perf/ui/gtk/progress.c
+++ b/tools/perf/ui/gtk/progress.c
@@ -7,7 +7,7 @@
static GtkWidget *dialog;
static GtkWidget *progress;
-static void gtk_progress_update(u64 curr, u64 total, const char *title)
+static void gtk_ui_progress__update(u64 curr, u64 total, const char *title)
{
double fraction = total ? 1.0 * curr / total : 0.0;
char buf[1024];
@@ -40,7 +40,7 @@ static void gtk_progress_update(u64 curr, u64 total, const
char *title)
gtk_main_iteration();
}
-static void gtk_progress_finish(void)
+static void gtk_ui_progress__finish(void)
{
/* this will also destroy all of its children */
gtk_widget_destroy(dialog);
@@ -48,12 +48,12 @@ static void gtk_progress_finish(void)
dialog = NULL;
}
-static struct ui_progress gtk_progress_fns = {
- .update = gtk_progress_update,
- .finish = gtk_progress_finish,
+static struct ui_progress_ops gtk_ui_progress__ops = {
+ .update = gtk_ui_progress__update,
+ .finish = gtk_ui_progress__finish,
};
-void perf_gtk__init_progress(void)
+void gtk_ui_progress__init(void)
{
- progress_fns = >k_progress_fns;
+ ui_progress__ops = >k_ui_progress__ops;
}
diff --git a/tools/perf/ui/gtk/setup.c b/tools/perf/ui/gtk/setup.c
index 6c2dd2e423f3..1d57676f8212 100644
--- a/tools/perf/ui/gtk/setup.c
+++ b/tools/perf/ui/gtk/setup.c
@@ -8,7 +8,7 @@ int perf_gtk__init(void)
{
perf_error__register(&perf_gtk_eops);
perf_gtk__init_helpline();
- perf_gtk__init_progress();
+ gtk_ui_progress__init();
perf_gtk__init_hpp();
return gtk_init_check(NULL, NULL) ? 0 : -1;
diff --git a/tools/perf/ui/progress.c b/tools/perf/ui/progress.c
index 3ec695607a4d..d753821b6e0b 100644
--- a/tools/perf/ui/progress.c
+++ b/tools/perf/ui/progress.c
@@ -1,26 +1,26 @@
#include "../cache.h"
#include "progress.h"
-static void nop_progress_update(u64 curr __maybe_unused,
- u64 total __maybe_unused,
- const char *title __maybe_unused)
+static void null_progress__update(u64 curr __maybe_unused,
+ u64 total __maybe_unused,
+ const char *title __maybe_unused)
{
}
-static struct ui_progress default_progress_fns =
+static struct ui_progress_ops null_progress__ops =
{
- .update = nop_progress_update,
+ .update = null_progress__update,
};
-struct ui_progress *progress_fns = &default_progress_fns;
+struct ui_progress_ops *ui_progress__ops = &null_progress__ops;
void ui_progress__update(u64 curr, u64 total, const char *title)
{
- return progress_fns->update(curr, total, title);
+ return ui_progress__ops->update(curr, total, title);
}
void ui_progress__finish(void)
{
- if (progress_fns->finish)
- progress_fns->finish();
+ if (ui_progress__ops->finish)
+ ui_progr
[PATCH 01/16] perf test: Clarify the "sample parsing" test entry
From: Arnaldo Carvalho de Melo
Before:
[root@sandy ~]# perf test -v 22
22: Test sample parsing:
--- start ---
sample format has changed - test needs updating
end
Test sample parsing: FAILED!
[root@sandy ~]#
After:
[root@sandy ~]# perf test -v 22
22: Test sample parsing:
--- start ---
sample format has changed, some new PERF_SAMPLE_ bit was introduced - test
needs updating
end
Test sample parsing: FAILED!
[root@sandy ~]#
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-8cazc2fpmk70jcbww8c0c...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/sample-parsing.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/tests/sample-parsing.c
b/tools/perf/tests/sample-parsing.c
index 77f598dbd97a..17d000c6c8ff 100644
--- a/tools/perf/tests/sample-parsing.c
+++ b/tools/perf/tests/sample-parsing.c
@@ -276,7 +276,7 @@ int test__sample_parsing(void)
* were added.
*/
if (PERF_SAMPLE_MAX > PERF_SAMPLE_IDENTIFIER << 1) {
- pr_debug("sample format has changed - test needs updating\n");
+ pr_debug("sample format has changed, some new PERF_SAMPLE_ bit
was introduced - test needs updating\n");
return -1;
}
--
1.8.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 13/16] perf tools: Fix non-debug build
From: Adrian Hunter In the absence of s DEBUG variable definition on the command line perf tools was building without optimization. Fix by assigning DEBUG if it is not defined. Signed-off-by: Adrian Hunter Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1382427258-17495-2-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/config/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index c516d6ba6716..543aa953bab1 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -66,6 +66,10 @@ ifneq ($(WERROR),0) CFLAGS += -Werror endif +ifndef DEBUG + DEBUG := 0 +endif + ifeq ($(DEBUG),0) CFLAGS += -O6 endif -- 1.8.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 03/16] perf tools: Stop using 'self' in some more places
From: Arnaldo Carvalho de Melo
As suggested by tglx, 'self' should be replaced by something that is
more useful.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-fmblhc6tbb99tk1q8vowt...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-annotate.c | 4 +-
tools/perf/builtin-diff.c | 5 +-
tools/perf/builtin-inject.c | 22
tools/perf/builtin-report.c | 14 ++---
tools/perf/util/build-id.c| 6 +-
tools/perf/util/hist.c| 18 +++---
tools/perf/util/sort.c| 124 +-
tools/perf/util/strfilter.c | 46
tools/perf/util/thread.c | 72
9 files changed, 155 insertions(+), 156 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 03cfa592071f..17c6b494e8cc 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -118,11 +118,11 @@ static int hist_entry__tty_annotate(struct hist_entry *he,
ann->print_line, ann->full_paths, 0, 0);
}
-static void hists__find_annotations(struct hists *self,
+static void hists__find_annotations(struct hists *hists,
struct perf_evsel *evsel,
struct perf_annotate *ann)
{
- struct rb_node *nd = rb_first(&self->entries), *next;
+ struct rb_node *nd = rb_first(&hists->entries), *next;
int key = K_RIGHT;
while (nd) {
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 419d27dd708b..9c828881714c 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -303,12 +303,11 @@ static int formula_fprintf(struct hist_entry *he, struct
hist_entry *pair,
return -1;
}
-static int hists__add_entry(struct hists *self,
+static int hists__add_entry(struct hists *hists,
struct addr_location *al, u64 period,
u64 weight, u64 transaction)
{
- if (__hists__add_entry(self, al, NULL, period, weight, transaction)
- != NULL)
+ if (__hists__add_entry(hists, al, NULL, period, weight, transaction) !=
NULL)
return 0;
return -ENOMEM;
}
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 4aa6d7850bcc..eb1a5941912b 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -162,38 +162,38 @@ static int perf_event__repipe_tracing_data(struct
perf_tool *tool,
return err;
}
-static int dso__read_build_id(struct dso *self)
+static int dso__read_build_id(struct dso *dso)
{
- if (self->has_build_id)
+ if (dso->has_build_id)
return 0;
- if (filename__read_build_id(self->long_name, self->build_id,
- sizeof(self->build_id)) > 0) {
- self->has_build_id = true;
+ if (filename__read_build_id(dso->long_name, dso->build_id,
+ sizeof(dso->build_id)) > 0) {
+ dso->has_build_id = true;
return 0;
}
return -1;
}
-static int dso__inject_build_id(struct dso *self, struct perf_tool *tool,
+static int dso__inject_build_id(struct dso *dso, struct perf_tool *tool,
struct machine *machine)
{
u16 misc = PERF_RECORD_MISC_USER;
int err;
- if (dso__read_build_id(self) < 0) {
- pr_debug("no build_id found for %s\n", self->long_name);
+ if (dso__read_build_id(dso) < 0) {
+ pr_debug("no build_id found for %s\n", dso->long_name);
return -1;
}
- if (self->kernel)
+ if (dso->kernel)
misc = PERF_RECORD_MISC_KERNEL;
- err = perf_event__synthesize_build_id(tool, self, misc,
perf_event__repipe,
+ err = perf_event__synthesize_build_id(tool, dso, misc,
perf_event__repipe,
machine);
if (err) {
- pr_err("Can't synthesize build_id event for %s\n",
self->long_name);
+ pr_err("Can't synthesize build_id event for %s\n",
dso->long_name);
return -1;
}
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 81addcabb356..e3598a456017 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -373,9 +373,9 @@ static int process_read_event(struct perf_tool *tool,
/* For pipe mode, sample_type is not currently set */
static int perf_report__setup_sample_type(struct perf_report *rep)
{
- struct perf_session *self = rep->session;
- u64 sample_type = perf_evlist__combined_sample_type(self->evlist);
- bool is_pipe = perf_data_file__is_pipe(self->file);
+ struct pe
[PATCH 07/16] perf sched: Make struct perf_sched sched a local variable
From: Adrian Hunter
Change "struct perf_sched sched" from being global to being local.
The build slowdown cured by f36f83f947ed is dealt with in the following
patch, by programatically setting perf_sched.curr_pid.
Signed-off-by: Adrian Hunter
Acked-by: David Ahern
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1382427258-17495-12-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-sched.c | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 5a46b102eb08..5a338566195e 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1655,29 +1655,28 @@ static int __cmd_record(int argc, const char **argv)
return cmd_record(i, rec_argv, NULL);
}
-static const char default_sort_order[] = "avg, max, switch, runtime";
-static struct perf_sched sched = {
- .tool = {
- .sample = perf_sched__process_tracepoint_sample,
- .comm= perf_event__process_comm,
- .lost= perf_event__process_lost,
- .fork= perf_sched__process_fork_event,
- .ordered_samples = true,
- },
- .cmp_pid = LIST_HEAD_INIT(sched.cmp_pid),
- .sort_list= LIST_HEAD_INIT(sched.sort_list),
- .start_work_mutex = PTHREAD_MUTEX_INITIALIZER,
- .work_done_wait_mutex = PTHREAD_MUTEX_INITIALIZER,
- .curr_pid = { [0 ... MAX_CPUS - 1] = -1 },
- .sort_order = default_sort_order,
- .replay_repeat= 10,
- .profile_cpu = -1,
- .next_shortname1 = 'A',
- .next_shortname2 = '0',
-};
-
int cmd_sched(int argc, const char **argv, const char *prefix __maybe_unused)
{
+ const char default_sort_order[] = "avg, max, switch, runtime";
+ struct perf_sched sched = {
+ .tool = {
+ .sample =
perf_sched__process_tracepoint_sample,
+ .comm= perf_event__process_comm,
+ .lost= perf_event__process_lost,
+ .fork= perf_sched__process_fork_event,
+ .ordered_samples = true,
+ },
+ .cmp_pid = LIST_HEAD_INIT(sched.cmp_pid),
+ .sort_list= LIST_HEAD_INIT(sched.sort_list),
+ .start_work_mutex = PTHREAD_MUTEX_INITIALIZER,
+ .work_done_wait_mutex = PTHREAD_MUTEX_INITIALIZER,
+ .curr_pid = { [0 ... MAX_CPUS - 1] = -1 },
+ .sort_order = default_sort_order,
+ .replay_repeat= 10,
+ .profile_cpu = -1,
+ .next_shortname1 = 'A',
+ .next_shortname2 = '0',
+ };
const struct option latency_options[] = {
OPT_STRING('s', "sort", &sched.sort_order, "key[,key2...]",
"sort by key(s): runtime, switch, avg, max"),
--
1.8.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/
[GIT PULL 00/16] perf/core improvements and fixes
From: Arnaldo Carvalho de Melo Hi Ingo, Please consider pulling, - Arnaldo The following changes since commit aa30a2e03a453aad9fd96c3f2d4a82c3497674e5: Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core (2013-10-23 09:45:50 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux tags/perf-core-for-mingo for you to fetch changes up to c1fb5651bb40f9efaf32d280f39e06df7e352673: perf tools: Show progress on histogram collapsing (2013-10-23 15:48:24 -0300) perf/core improvements and fixes: . Show progress on histogram collapsing, that can take a long time, from Namhyung Kim. . Support "$vars" meta argument syntax for local variables, allowing asking for all possible variables at a given probe point to be collected when it hits, from Masami Hiramatsu. . Address the root cause of that 'perf sched' stack initialization build slowdown, by programmatically setting a big array after moving the global variable back to the stack. Fix from Adrian Hunter. . Do not repipe attributes to a perf.data file in 'perf inject', fix from Adrian Hunter . Change the procps visible command-name of invididual benchmark tests plus cleanups, from Ingo Molnar. . Do not accept parse_tag_value() overflow, fix from Adrian Hunter. . Validate that mmap_pages is not too big. From Adrian Hunter. . Fix non-debug build, from Adrian Hunter . Clarify the "sample parsing" test entry. . Consider PERF_SAMPLE_TRANSACTION in the "sample parsing" test. Signed-off-by: Arnaldo Carvalho de Melo Adrian Hunter (7): perf sched: Make struct perf_sched sched a local variable perf sched: Optimize build time perf script: Make perf_script a local variable perf inject: Do not repipe attributes to a perf.data file perf tools: Do not accept parse_tag_value() overflow perf evlist: Validate that mmap_pages is not too big perf tools: Fix non-debug build Arnaldo Carvalho de Melo (5): perf test: Clarify the "sample parsing" test entry perf test: Consider PERF_SAMPLE_TRANSACTION in the "sample parsing" test perf tools: Stop using 'self' in some more places perf ui: Rename ui_progress to ui_progress_ops perf ui progress: Per progress bar state Ingo Molnar (1): perf bench: Change the procps visible command-name of invididual benchmark tests plus cleanups Masami Hiramatsu (2): perf probe: Support "$vars" meta argument syntax for local variables perf probe: Find fentry mcount fuzzed parameter location Namhyung Kim (1): perf tools: Show progress on histogram collapsing tools/perf/Makefile.perf | 1 + tools/perf/builtin-annotate.c | 6 +- tools/perf/builtin-bench.c| 239 +++--- tools/perf/builtin-diff.c | 7 +- tools/perf/builtin-inject.c | 27 +++-- tools/perf/builtin-report.c | 24 ++-- tools/perf/builtin-sched.c| 44 +++ tools/perf/builtin-script.c | 40 --- tools/perf/builtin-top.c | 4 +- tools/perf/config/Makefile| 4 + tools/perf/tests/hists_link.c | 2 +- tools/perf/tests/sample-parsing.c | 4 +- tools/perf/ui/gtk/gtk.h | 2 +- tools/perf/ui/gtk/progress.c | 20 ++-- tools/perf/ui/gtk/setup.c | 2 +- tools/perf/ui/progress.c | 32 +++-- tools/perf/ui/progress.h | 19 +-- tools/perf/ui/tui/progress.c | 15 +-- tools/perf/ui/tui/setup.c | 3 +- tools/perf/ui/tui/tui.h | 6 + tools/perf/util/build-id.c| 6 +- tools/perf/util/evlist.c | 14 ++- tools/perf/util/hist.c| 23 ++-- tools/perf/util/hist.h| 3 +- tools/perf/util/probe-event.c | 1 - tools/perf/util/probe-finder.c| 133 ++--- tools/perf/util/probe-finder.h| 1 + tools/perf/util/session.c | 24 ++-- tools/perf/util/sort.c| 124 ++-- tools/perf/util/strfilter.c | 46 tools/perf/util/thread.c | 72 ++-- tools/perf/util/util.c| 2 + 32 files changed, 560 insertions(+), 390 deletions(-) create mode 100644 tools/perf/ui/tui/tui.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/
[PATCH 12/16] perf evlist: Validate that mmap_pages is not too big
From: Adrian Hunter
Amend perf_evlist__parse_mmap_pages() to check that the mmap_pages
entered via the --mmap_pages/-m option is not too big.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1382427258-17495-15-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evlist.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 85c4c80bcac8..2ce92eceb424 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -698,7 +698,8 @@ static size_t perf_evlist__mmap_size(unsigned long pages)
int perf_evlist__parse_mmap_pages(const struct option *opt, const char *str,
int unset __maybe_unused)
{
- unsigned int pages, val, *mmap_pages = opt->value;
+ unsigned int *mmap_pages = opt->value;
+ unsigned long pages, val;
size_t size;
static struct parse_tag tags[] = {
{ .tag = 'B', .mult = 1 },
@@ -709,12 +710,12 @@ int perf_evlist__parse_mmap_pages(const struct option
*opt, const char *str,
};
val = parse_tag_value(str, tags);
- if (val != (unsigned int) -1) {
+ if (val != (unsigned long) -1) {
/* we got file size value */
pages = PERF_ALIGN(val, page_size) / page_size;
- if (!is_power_of_2(pages)) {
+ if (pages < (1UL << 31) && !is_power_of_2(pages)) {
pages = next_pow2(pages);
- pr_info("rounding mmap pages size to %u (%u pages)\n",
+ pr_info("rounding mmap pages size to %lu (%lu pages)\n",
pages * page_size, pages);
}
} else {
@@ -727,6 +728,11 @@ int perf_evlist__parse_mmap_pages(const struct option
*opt, const char *str,
}
}
+ if (pages > UINT_MAX || pages > SIZE_MAX / page_size) {
+ pr_err("--mmap_pages/-m value too big\n");
+ return -1;
+ }
+
size = perf_evlist__mmap_size(pages);
if (!size) {
pr_err("--mmap_pages/-m value must be a power of two.");
--
1.8.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 09/16] perf script: Make perf_script a local variable
From: Adrian Hunter
Change perf_script from being global to being local.
Signed-off-by: Adrian Hunter
Acked-by: David Ahern
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1382427258-17495-4-git-send-email-adrian.hun...@intel.com
[ Made the minor consistency changes suggested by David Ahern ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c | 40
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 27de6068049d..0ae88c2538a1 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -542,18 +542,9 @@ static int process_sample_event(struct perf_tool *tool
__maybe_unused,
return 0;
}
-static struct perf_tool perf_script = {
- .sample = process_sample_event,
- .mmap= perf_event__process_mmap,
- .mmap2 = perf_event__process_mmap2,
- .comm= perf_event__process_comm,
- .exit= perf_event__process_exit,
- .fork= perf_event__process_fork,
- .attr= perf_event__process_attr,
- .tracing_data= perf_event__process_tracing_data,
- .build_id= perf_event__process_build_id,
- .ordered_samples = true,
- .ordering_requires_timestamps = true,
+struct perf_script {
+ struct perf_tooltool;
+ struct perf_session *session;
};
static void sig_handler(int sig __maybe_unused)
@@ -561,13 +552,13 @@ static void sig_handler(int sig __maybe_unused)
session_done = 1;
}
-static int __cmd_script(struct perf_session *session)
+static int __cmd_script(struct perf_script *script)
{
int ret;
signal(SIGINT, sig_handler);
- ret = perf_session__process_events(session, &perf_script);
+ ret = perf_session__process_events(script->session, &script->tool);
if (debug_mode)
pr_err("Misordered timestamps: %" PRIu64 "\n", nr_unordered);
@@ -1273,6 +1264,21 @@ int cmd_script(int argc, const char **argv, const char
*prefix __maybe_unused)
char *script_path = NULL;
const char **__argv;
int i, j, err;
+ struct perf_script script = {
+ .tool = {
+ .sample = process_sample_event,
+ .mmap= perf_event__process_mmap,
+ .mmap2 = perf_event__process_mmap2,
+ .comm= perf_event__process_comm,
+ .exit= perf_event__process_exit,
+ .fork= perf_event__process_fork,
+ .attr= perf_event__process_attr,
+ .tracing_data= perf_event__process_tracing_data,
+ .build_id= perf_event__process_build_id,
+ .ordered_samples = true,
+ .ordering_requires_timestamps = true,
+ },
+ };
const struct option options[] = {
OPT_BOOLEAN('D', "dump-raw-trace", &dump_trace,
"dump raw trace in ASCII"),
@@ -1498,10 +1504,12 @@ int cmd_script(int argc, const char **argv, const char
*prefix __maybe_unused)
if (!script_name)
setup_pager();
- session = perf_session__new(&file, false, &perf_script);
+ session = perf_session__new(&file, false, &script.tool);
if (session == NULL)
return -ENOMEM;
+ script.session = session;
+
if (cpu_list) {
if (perf_session__cpu_bitmap(session, cpu_list, cpu_bitmap))
return -1;
@@ -1565,7 +1573,7 @@ int cmd_script(int argc, const char **argv, const char
*prefix __maybe_unused)
if (err < 0)
goto out;
- err = __cmd_script(session);
+ err = __cmd_script(&script);
perf_session__delete(session);
cleanup_scripting();
--
1.8.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 02/16] perf test: Consider PERF_SAMPLE_TRANSACTION in the "sample parsing" test
From: Arnaldo Carvalho de Melo
[root@sandy ~]# perf test -v 22
22: Test sample parsing:
--- start ---
sample format has changed, some new PERF_SAMPLE_ bit was introduced - test
needs updating
end
Test sample parsing: FAILED!
[root@sandy ~]#
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-cx83wuzz30m10m4s1xt0o...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/sample-parsing.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/tests/sample-parsing.c
b/tools/perf/tests/sample-parsing.c
index 17d000c6c8ff..61c9da2eb3a9 100644
--- a/tools/perf/tests/sample-parsing.c
+++ b/tools/perf/tests/sample-parsing.c
@@ -275,7 +275,7 @@ int test__sample_parsing(void)
* Fail the test if it has not been updated when new sample format bits
* were added.
*/
- if (PERF_SAMPLE_MAX > PERF_SAMPLE_IDENTIFIER << 1) {
+ if (PERF_SAMPLE_MAX > PERF_SAMPLE_TRANSACTION << 1) {
pr_debug("sample format has changed, some new PERF_SAMPLE_ bit
was introduced - test needs updating\n");
return -1;
}
--
1.8.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 10/16] perf inject: Do not repipe attributes to a perf.data file
From: Adrian Hunter
perf.data files contain the attributes separately, do not put them in
the event stream as well.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1382427258-17495-6-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-inject.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index eb1a5941912b..409ceaf3b9b9 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -72,12 +72,17 @@ static int perf_event__repipe_attr(struct perf_tool *tool,
union perf_event *event,
struct perf_evlist **pevlist)
{
+ struct perf_inject *inject = container_of(tool, struct perf_inject,
+ tool);
int ret;
ret = perf_event__process_attr(tool, event, pevlist);
if (ret)
return ret;
+ if (!inject->pipe_output)
+ return 0;
+
return perf_event__repipe_synth(tool, event);
}
--
1.8.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: [PATCH] xfs: fix possible NULL dereference
2013/10/23 Ben Myers :
> Hey Geyslan,
>
> On Wed, Oct 23, 2013 at 08:58:51AM -0200, Geyslan Gregório Bem wrote:
>> - Regarding the "possible new patch" subject, I humbly pass the ball to you.
>>
>> Thank you for the attention.
>
> Thank you for the patch. I would really prefer to commit this showing
> authorship from you, rather than a Reported-by. Can I mark you down?
>
> Regards,
> Ben
>
Thank you, Ben. Sure, you can mark me.
> ---
>
> xfs: fix possible NULL dereference in xlog_verify_iclog
>
> In xlog_verify_iclog a debug check of the incore log buffers prints an
> error if icptr is null and then goes on to dereference the pointer
> regardless. Convert this to an assert so that the intention is clear.
> This was reported by Coverty.
>
> Reported-by: Geyslan G. Bem
> Signed-off-by: Ben Myers
> ---
> fs/xfs/xfs_log.c |8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> Index: b/fs/xfs/xfs_log.c
> ===
> --- a/fs/xfs/xfs_log.c 2013-10-23 14:52:47.875216875 -0500
> +++ b/fs/xfs/xfs_log.c 2013-10-23 14:53:53.775245830 -0500
> @@ -3714,11 +3714,9 @@ xlog_verify_iclog(
> /* check validity of iclog pointers */
> spin_lock(&log->l_icloglock);
> icptr = log->l_iclog;
> - for (i=0; i < log->l_iclog_bufs; i++) {
> - if (icptr == NULL)
> - xfs_emerg(log->l_mp, "%s: invalid ptr", __func__);
> - icptr = icptr->ic_next;
> - }
> + for (i=0; i < log->l_iclog_bufs; i++, icptr = icptr->ic_next)
> + ASSERT(icptr);
> +
> if (icptr != log->l_iclog)
> xfs_emerg(log->l_mp, "%s: corrupt iclog ring", __func__);
> spin_unlock(&log->l_icloglock);
>
--
Regards,
Geyslan G. Bem
hackingbits.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: [Cbe-oss-dev] [PATCH 2/8] cell: Remove OOM message after input_allocate_device
Hi Joe,
On Wed, 2013-10-23 at 12:14 -0700, Joe Perches wrote:
> Emitting an OOM message isn't necessary after input_allocate_device
> as there's a generic OOM and a dump_stack already done.
>
> Signed-off-by: Joe Perches
> ---
> arch/powerpc/platforms/cell/cbe_powerbutton.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/cell/cbe_powerbutton.c
> b/arch/powerpc/platforms/cell/cbe_powerbutton.c
> index 2bb8031..8804dbd 100644
> --- a/arch/powerpc/platforms/cell/cbe_powerbutton.c
> +++ b/arch/powerpc/platforms/cell/cbe_powerbutton.c
> @@ -58,7 +58,6 @@ static int __init cbe_powerbutton_init(void)
> dev = input_allocate_device();
> if (!dev) {
> ret = -ENOMEM;
> - printk(KERN_ERR "%s: Not enough memory.\n", __func__);
> goto out;
> }
Arnd is out on leave, so I'll say that this looks OK.
Acked-by: Geoff Levand
--
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] perf, x86: Optimize intel_pmu_pebs_fixup_ip()
On Wed, Oct 23, 2013 at 08:09:53AM +0100, Linus Torvalds wrote: > On Tue, Oct 22, 2013 at 10:12 PM, Peter Zijlstra wrote: > >> > >> Careful! There is one magic piece of state that you need to > >> save-and-restore if you do this, namely %cr2. Taking a page fault > >> always writes to %cr2, and we must *not* corrupt it in the NMI > >> handler. > > > > It looks like this is already dealt with (a similar thing is done for > > i386). > > Oh, ok then, we should be good to go. I wonder why we needed that > special "_nmi()" version, then.. Ah, the whole fault from nmi trickery from Steve is from after we did the copy_from_user_nmi() thing. We're only just catching up :-) > Please do check that NMI increment the irq-counts etc.. Otherwise > you'll need to add the explicit "pagefault_disable/enable()" pair > around the __copy_from_user_inatomic().. Yeah, we add NMI_OFFSET to preempt_count on nmi_enter. I'll also make sure to test we actually hit the fault path by concurrently running something like: while :; echo 1 > /proc/sys/vm/drop_caches ; done while doing perf top or so.. -- 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] xfs: fix possible NULL dereference
Hey Geyslan,
On Wed, Oct 23, 2013 at 08:58:51AM -0200, Geyslan Gregório Bem wrote:
> - Regarding the "possible new patch" subject, I humbly pass the ball to you.
>
> Thank you for the attention.
Thank you for the patch. I would really prefer to commit this showing
authorship from you, rather than a Reported-by. Can I mark you down?
Regards,
Ben
---
xfs: fix possible NULL dereference in xlog_verify_iclog
In xlog_verify_iclog a debug check of the incore log buffers prints an
error if icptr is null and then goes on to dereference the pointer
regardless. Convert this to an assert so that the intention is clear.
This was reported by Coverty.
Reported-by: Geyslan G. Bem
Signed-off-by: Ben Myers
---
fs/xfs/xfs_log.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
Index: b/fs/xfs/xfs_log.c
===
--- a/fs/xfs/xfs_log.c 2013-10-23 14:52:47.875216875 -0500
+++ b/fs/xfs/xfs_log.c 2013-10-23 14:53:53.775245830 -0500
@@ -3714,11 +3714,9 @@ xlog_verify_iclog(
/* check validity of iclog pointers */
spin_lock(&log->l_icloglock);
icptr = log->l_iclog;
- for (i=0; i < log->l_iclog_bufs; i++) {
- if (icptr == NULL)
- xfs_emerg(log->l_mp, "%s: invalid ptr", __func__);
- icptr = icptr->ic_next;
- }
+ for (i=0; i < log->l_iclog_bufs; i++, icptr = icptr->ic_next)
+ ASSERT(icptr);
+
if (icptr != log->l_iclog)
xfs_emerg(log->l_mp, "%s: corrupt iclog ring", __func__);
spin_unlock(&log->l_icloglock);
--
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/
[PATCHv5 0/3] DT Support for TWL4030 power button
Hi, This is the fifth iteration of DT support for the TWL4030 power button. Changes since v4 [0]: * do not change dev_dbg to dev_err for input_allocate_device, since it prints its own message. Call will be removed completly by another patchset [1]. [0] https://lkml.org/lkml/2013/10/23/372 [1] https://lkml.org/lkml/2013/10/23/390 -- Sebastian Sebastian Reichel (3): Input: twl4030-pwrbutton - add device tree support Input: twl4030-pwrbutton: use dev_err for errors Input: twl4030-pwrbutton: simplify driver using devm_* .../bindings/input/twl4030-pwrbutton.txt | 13 +++ drivers/input/misc/twl4030-pwrbutton.c | 44 +- 2 files changed, 30 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt -- 1.8.4.rc3 -- 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/
[PATCHv5 1/3] Input: twl4030-pwrbutton - add device tree support
Add device tree support for twl4030 power button driver.
Signed-off-by: Sebastian Reichel
---
.../devicetree/bindings/input/twl4030-pwrbutton.txt | 13 +
drivers/input/misc/twl4030-pwrbutton.c | 16
2 files changed, 25 insertions(+), 4 deletions(-)
create mode 100644
Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
diff --git a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
new file mode 100644
index 000..945ec74
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
@@ -0,0 +1,13 @@
+* TWL4030's pwrbutton device tree bindings
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - "ti,twl4030-pwrbutton": For controllers compatible with twl4030
+- interrupt: should be one of the following
+ - <8>: For controllers compatible with twl4030
+
+Example:
+ twl_pwrbutton: pwrbutton {
+ compatible = "ti,twl4030-pwrbutton";
+ interrupts = <8>;
+ };
diff --git a/drivers/input/misc/twl4030-pwrbutton.c
b/drivers/input/misc/twl4030-pwrbutton.c
index b9a05fd..a3a0fe3 100644
--- a/drivers/input/misc/twl4030-pwrbutton.c
+++ b/drivers/input/misc/twl4030-pwrbutton.c
@@ -52,7 +52,7 @@ static irqreturn_t powerbutton_irq(int irq, void *_pwr)
return IRQ_HANDLED;
}
-static int __init twl4030_pwrbutton_probe(struct platform_device *pdev)
+static int twl4030_pwrbutton_probe(struct platform_device *pdev)
{
struct input_dev *pwr;
int irq = platform_get_irq(pdev, 0);
@@ -106,16 +106,24 @@ static int __exit twl4030_pwrbutton_remove(struct
platform_device *pdev)
return 0;
}
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id twl4030_pwrbutton_dt_match_table[] = {
+ { .compatible = "ti,twl4030-pwrbutton" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, twl4030_pwrbutton_dt_match_table);
+#endif
+
static struct platform_driver twl4030_pwrbutton_driver = {
+ .probe = twl4030_pwrbutton_probe,
.remove = __exit_p(twl4030_pwrbutton_remove),
.driver = {
.name = "twl4030_pwrbutton",
.owner = THIS_MODULE,
+ .of_match_table =
of_match_ptr(twl4030_pwrbutton_dt_match_table),
},
};
-
-module_platform_driver_probe(twl4030_pwrbutton_driver,
- twl4030_pwrbutton_probe);
+module_platform_driver(twl4030_pwrbutton_driver);
MODULE_ALIAS("platform:twl4030_pwrbutton");
MODULE_DESCRIPTION("Triton2 Power Button");
--
1.8.4.rc3
--
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/
[PATCHv5 3/3] Input: twl4030-pwrbutton: simplify driver using devm_*
Use managed irq resource to simplify the driver.
Signed-off-by: Sebastian Reichel
---
drivers/input/misc/twl4030-pwrbutton.c | 26 --
1 file changed, 4 insertions(+), 22 deletions(-)
diff --git a/drivers/input/misc/twl4030-pwrbutton.c
b/drivers/input/misc/twl4030-pwrbutton.c
index 48639ff..be1759c 100644
--- a/drivers/input/misc/twl4030-pwrbutton.c
+++ b/drivers/input/misc/twl4030-pwrbutton.c
@@ -58,7 +58,7 @@ static int twl4030_pwrbutton_probe(struct platform_device
*pdev)
int irq = platform_get_irq(pdev, 0);
int err;
- pwr = input_allocate_device();
+ pwr = devm_input_allocate_device(&pdev->dev);
if (!pwr) {
dev_dbg(&pdev->dev, "Can't allocate power button\n");
return -ENOMEM;
@@ -70,40 +70,23 @@ static int twl4030_pwrbutton_probe(struct platform_device
*pdev)
pwr->phys = "twl4030_pwrbutton/input0";
pwr->dev.parent = &pdev->dev;
- err = request_threaded_irq(irq, NULL, powerbutton_irq,
+ err = devm_request_threaded_irq(&pwr->dev, irq, NULL, powerbutton_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
"twl4030_pwrbutton", pwr);
if (err < 0) {
dev_err(&pdev->dev, "Can't get IRQ for pwrbutton: %d\n", err);
- goto free_input_dev;
+ return err;
}
err = input_register_device(pwr);
if (err) {
dev_err(&pdev->dev, "Can't register power button: %d\n", err);
- goto free_irq;
+ return err;
}
platform_set_drvdata(pdev, pwr);
return 0;
-
-free_irq:
- free_irq(irq, pwr);
-free_input_dev:
- input_free_device(pwr);
- return err;
-}
-
-static int __exit twl4030_pwrbutton_remove(struct platform_device *pdev)
-{
- struct input_dev *pwr = platform_get_drvdata(pdev);
- int irq = platform_get_irq(pdev, 0);
-
- free_irq(irq, pwr);
- input_unregister_device(pwr);
-
- return 0;
}
#if IS_ENABLED(CONFIG_OF)
@@ -116,7 +99,6 @@ MODULE_DEVICE_TABLE(of, twl4030_pwrbutton_dt_match_table);
static struct platform_driver twl4030_pwrbutton_driver = {
.probe = twl4030_pwrbutton_probe,
- .remove = __exit_p(twl4030_pwrbutton_remove),
.driver = {
.name = "twl4030_pwrbutton",
.owner = THIS_MODULE,
--
1.8.4.rc3
--
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/
[PATCHv5 2/3] Input: twl4030-pwrbutton: use dev_err for errors
Use dev_err() to output errors instead of dev_dbg().
Signed-off-by: Sebastian Reichel
---
drivers/input/misc/twl4030-pwrbutton.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/twl4030-pwrbutton.c
b/drivers/input/misc/twl4030-pwrbutton.c
index a3a0fe3..48639ff 100644
--- a/drivers/input/misc/twl4030-pwrbutton.c
+++ b/drivers/input/misc/twl4030-pwrbutton.c
@@ -74,13 +74,13 @@ static int twl4030_pwrbutton_probe(struct platform_device
*pdev)
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
"twl4030_pwrbutton", pwr);
if (err < 0) {
- dev_dbg(&pdev->dev, "Can't get IRQ for pwrbutton: %d\n", err);
+ dev_err(&pdev->dev, "Can't get IRQ for pwrbutton: %d\n", err);
goto free_input_dev;
}
err = input_register_device(pwr);
if (err) {
- dev_dbg(&pdev->dev, "Can't register power button: %d\n", err);
+ dev_err(&pdev->dev, "Can't register power button: %d\n", err);
goto free_irq;
}
--
1.8.4.rc3
--
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] Fix: Dereference pointer-value of sk_prot->memory_pressure
From: ebied...@xmission.com (Eric W. Biederman) Date: Wed, 23 Oct 2013 12:55:18 -0700 > From: Christoph Paasch > Date: Wed, 23 Oct 2013 12:49:21 -0700 > > 2e685cad57 (tcp_memcontrol: Kill struct tcp_memcontrol) falsly modified > the access to memory_pressure of sk->sk_prot->memory_pressure. The patch > did modify the memory_pressure-field of struct cg_proto, but not the one > of struct proto. > > So, the access to sk_prot->memory_pressure should not be changed. > > Acked-by: Eric Dumazet > Reported-by: Fengguang Wu > Signed-off-by: Christoph Paasch > Signed-off-by: Eric W. Biederman Applied, but I replaced "Fix: " with "net: " in the commit header line. -- 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] Does PHY UTMI data width belong to DWC2 or PHY binding?
On Wed, Oct 23, 2013 at 01:11:15PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 23, 2013 at 10:42:42AM -0400, Matt Porter wrote:
> > On Tue, Oct 22, 2013 at 04:38:52PM -0500, Rob Herring wrote:
> > > On 10/22/2013 06:25 AM, Matt Porter wrote:
> > > > On Tue, Oct 22, 2013 at 12:48:29PM +0200, Matthijs Kooijman wrote:
> > > >> Hi Kishon,
> > > >>
> > > >> On Mon, Oct 21, 2013 at 02:57:26PM +0530, Kishon Vijay Abraham I wrote:
> > > >>> I think it makes sense to keep the data width property in the dwc2
> > > >>> node itself.
> > > >>> I mean it describes how the dwc2 IP is configured in that particular
> > > >>> SoC (given
> > > >>> that it can be either <8> or <16>).
> > > >> If I'm reading the RT3052 datasheet correctly (GHWCFG4 register), the
> > > >> IP
> > > >> can be configured for 8, 16 or 8 _and_ 16. In the latter case, the "8
> > > >> and 16 supported" would make sense as a property of dwc2 (though this
> > > >> value should be autodetectable through GHWCFG4), while the actual 8 or
> > > >> 16 supported by the PHY would make sense as property of a phy.
> > > >
> > > > There would be no value in adding a property for an already detectable
> > > > value to dwc2's binding. To be honest, it's pretty much useless
> > > > information due to the existence of the "8 and 16" option.
> > > >
> > > >> Note sure if this is really useful in practice as well, or if just
> > > >> setting the actual width to use on dwc2 makes more sense...
> > > >
> > > > The GHWCFG4 information itself is not useful in practice, as described
> > > > in the original thread: https://lkml.org/lkml/2013/10/10/477
> > > >
> > > > It's certainly useful in practice to have this width property in either
> > > > the dwc2 or the phy binding. One can make a case for either. As I
> > > > mentioned in the original post, if we put it in the phy binding we'll be
> > > > updating the generic phy binding. We'll then need an api added into the
> > > > generic phy framework to fetch the width of a phy.
> > > >
> > > > Both cases are doable and trivial, we just need the canonical decision
> > > > from a DT maintainer as to where the property belongs. Given that they
> > > > are in ARM ksummit, I'm not expecting to hear anything right this
> > > > moment. :)
> > >
> > > The host can support both, so it is not a property of the host and is a
> > > property of the phy. It is no different than what mode a SPI slave
> > > requires or whether an i2c slave supports 8 or 10-bit addressing. Those
> > > examples are all 1 to many rather than 1 to 1 where it doesn't really
> > > matter, but the same logic applies.
> >
> > Makes good sense, thanks.
> >
> > In this case, given the PHY ownership of width, we can completely avoid
> > any DT properties. The generic phy compliant BCM Kona phy driver can
> > report via the generic phy framework that it is 8-bit wide. There's no
> > support for this type of thing now but it's pretty trivial to add.
> >
> > I went ahead and did a quick proof-of-concept that adds a free-form
> > phy attributes struct for the generic phy. Given that generic phys can
> > be for any transmission technology this could be filled with a jumble
> > unrelated and often unpopulated attributes over time. In any case, the
> > below patch allows the phy provider to choose to specify utmi_width and
> > a controller driver that cares can use phy_get_attrs() to fetch the
> > optional phy attributes and use the utmi_width field if applicable.
> >
> > Kishon: I'll start a separate thread to discuss what approach you'd like
> > to see in the generic phy framework to manage this.
> >
> > -Matt
> >
> > diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> > index 6d72269..b763d7b 100644
> > --- a/include/linux/phy/phy.h
> > +++ b/include/linux/phy/phy.h
> > @@ -38,6 +38,14 @@ struct phy_ops {
> > };
> >
> > /**
> > + * struct phy_attrs - represents phy attributes
> > + * @utmi_width: Data path width implemented by UTMI PHY
> > + */
> > +struct phy_attrs {
> > + int utmi_width;
>
> this is supposed to be a generic PHY layer and as such, it shouldn't
> know about USB details such as the UTMI bus. How about calling bus_width
> just to make it more generic ? Then it would work for UTMI, PIPE3, ULPI,
> SLPI (did that even fly ?) or any other PHY <-> link interconnect.
That sounds much better. Yeah, I was also thinking about embedding a
per-phy-class attribute struct and that just looked ugly. I like the simple
generic bus_width.
I'll update and post a real patch.
Thanks,
Matt
--
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: Perf Python Scripting Leaks Memory
On Wed, 2013-10-23 at 17:01 -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 23, 2013 at 04:37:41PM +0200, Joseph Schuchart escreveu: > >We are using the Python scripting interface in perf to extract kernel > >events relevant for performance analysis of HPC codes. We noticed that > > the > >"perf script" call allocates a significant amount of memory (in the order > >of several 100 MiB) during it's run, e.g. 125 MiB for a 25 MiB input > > file: > > Thanks for the analysis and the bug fix! > > I asked Tom Zanussi and he kindly reviewed your patch and provided an > Acked-by tag for it, Tom, may I add a Reviewed-by: as well? > Sure. Reviewed-by: Tom > Joseph, can I have your Signed-off-by: tag, as documented in: > > Documentation/SubmittingPatches > > In the "12) Sign your work" section? > > Thanks! > > - Arnaldo -- 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: Perf Python Scripting Leaks Memory
Em Wed, Oct 23, 2013 at 04:37:41PM +0200, Joseph Schuchart escreveu: >We are using the Python scripting interface in perf to extract kernel >events relevant for performance analysis of HPC codes. We noticed that the >"perf script" call allocates a significant amount of memory (in the order >of several 100 MiB) during it's run, e.g. 125 MiB for a 25 MiB input file: Thanks for the analysis and the bug fix! I asked Tom Zanussi and he kindly reviewed your patch and provided an Acked-by tag for it, Tom, may I add a Reviewed-by: as well? Joseph, can I have your Signed-off-by: tag, as documented in: Documentation/SubmittingPatches In the "12) Sign your work" section? Thanks! - Arnaldo -- 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: linux-next: Tree for Oct 23
On Wed, Oct 23, 2013 at 05:13:22PM +0200, Thierry Reding wrote: > Hi all, > > I've uploaded today's linux-next tree to the master branch of the > repository below: > > git://gitorious.org/thierryreding/linux-next.git > > A next-20131023 tag is also provided for convenience. > > No new conflicts. I've fixed various build failures, so 32-bit and 64-bit > allmodconfigs build fine on x86. ARM and x86 default configurations also > build fine. Most of the patches to fix the build failures have been sent > to the respective maintainers. > Build test results are a bit better than yesterday: total: 110 pass: 92 skipped: 4 fail: 14 For the qemu tests, the mips64 build still fails due to an unused variable 'usp' in arch/mips/include/asm/syscall.h, and the sh test crashes with a NULL pointer access in ata_finalize_port_ops(). Detailed results are, as always, 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/
[PATCH] Fix: Dereference pointer-value of sk_prot->memory_pressure
From: Christoph Paasch Date: Wed, 23 Oct 2013 12:49:21 -0700 2e685cad57 (tcp_memcontrol: Kill struct tcp_memcontrol) falsly modified the access to memory_pressure of sk->sk_prot->memory_pressure. The patch did modify the memory_pressure-field of struct cg_proto, but not the one of struct proto. So, the access to sk_prot->memory_pressure should not be changed. Acked-by: Eric Dumazet Reported-by: Fengguang Wu Signed-off-by: Christoph Paasch Signed-off-by: Eric W. Biederman --- Resent because I fat fingered and deleted Dave by accident. include/net/sock.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/net/sock.h b/include/net/sock.h index c93542f92420..e3a18ff0c38b 100644 --- a/include/net/sock.h +++ b/include/net/sock.h @@ -1137,7 +1137,7 @@ static inline bool sk_under_memory_pressure(const struct sock *sk) if (mem_cgroup_sockets_enabled && sk->sk_cgrp) return !!sk->sk_cgrp->memory_pressure; - return !!sk->sk_prot->memory_pressure; + return !!*sk->sk_prot->memory_pressure; } static inline void sk_leave_memory_pressure(struct sock *sk) -- 1.7.5.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/
