Re: [PATCH] arm: kgdb: fix NUMREGBYTES so that gdb_regs[] is the correct size

runcated register 19 in remote 'g' packet" > > This also causes the register serialization/deserialization logic to > overflow gdb_regs[], overwriting whatever follows. > > Fixes: 834b2964b7ab ("kgdb,arm: fix register dump") > Cc: <sta...@vger.kernel.org> # 2.6.37+ &g

Re: [PATCH] arm: kgdb: fix NUMREGBYTES so that gdb_regs[] is the correct size

e 'g' packet" > > This also causes the register serialization/deserialization logic to > overflow gdb_regs[], overwriting whatever follows. > > Fixes: 834b2964b7ab ("kgdb,arm: fix register dump") > Cc: # 2.6.37+ > Signed-off-by: David Rivshin Acked-by: Rabin Vincent

[PATCH for v4.9-stable] sched: fix softirq time accounting

From: Rabin Vincent <rab...@axis.com> softirq time accounting is broken on v4.9.x if ksoftirqd runs. With CONFIG_IRQ_TIME_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set this test code: struct tasklet_struct tasklet; static void delay_tasklet(un

[PATCH for v4.9-stable] sched: fix softirq time accounting

From: Rabin Vincent softirq time accounting is broken on v4.9.x if ksoftirqd runs. With CONFIG_IRQ_TIME_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set this test code: struct tasklet_struct tasklet; static void delay_tasklet(unsigned long data

Re: [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal

On Tue, Aug 22, 2017 at 10:45:24AM +0100, Will Deacon wrote: > On Mon, Aug 21, 2017 at 02:42:03PM +0100, Mark Rutland wrote: > > On Tue, Jul 11, 2017 at 03:58:49PM +0100, Will Deacon wrote: > > > On Tue, Jul 11, 2017 at 03:19:22PM +0100, Mark Rutland wrote: > > > > When there's a fatal signal

Re: [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal

On Tue, Aug 22, 2017 at 10:45:24AM +0100, Will Deacon wrote: > On Mon, Aug 21, 2017 at 02:42:03PM +0100, Mark Rutland wrote: > > On Tue, Jul 11, 2017 at 03:58:49PM +0100, Will Deacon wrote: > > > On Tue, Jul 11, 2017 at 03:19:22PM +0100, Mark Rutland wrote: > > > > When there's a fatal signal

[PATCH] CIFS: fix circular locking dependency

From: Rabin Vincent <rab...@axis.com> When a CIFS filesystem is mounted with the forcemand option and the following command is run on it, lockdep warns about a circular locking dependency between CifsInodeInfo::lock_sem and the inode lock. while echo foo > hello; do :; done & w

[PATCH] CIFS: fix circular locking dependency

From: Rabin Vincent When a CIFS filesystem is mounted with the forcemand option and the following command is run on it, lockdep warns about a circular locking dependency between CifsInodeInfo::lock_sem and the inode lock. while echo foo > hello; do :; done & while touch -c hello; do

Re: [4.9.28] vmscan: shrink_slab: ext4_es_scan+0x0/0x150 negative objects to delete nr=-2147483624

On Thu, May 18, 2017 at 07:21:49AM +0200, Marc Burkhardt wrote: > tonight my dmesg was flooded with mesages like > > vmscan: shrink_slab: ext4_es_scan+0x0/0x150 negative objects to delete > nr=-2147483624 > > Is that an integer overflow happening in ext4? > > It's the first time I see this

Re: [4.9.28] vmscan: shrink_slab: ext4_es_scan+0x0/0x150 negative objects to delete nr=-2147483624

On Thu, May 18, 2017 at 07:21:49AM +0200, Marc Burkhardt wrote: > tonight my dmesg was flooded with mesages like > > vmscan: shrink_slab: ext4_es_scan+0x0/0x150 negative objects to delete > nr=-2147483624 > > Is that an integer overflow happening in ext4? > > It's the first time I see this

[PATCH v4] ubifs: allow userspace to map mounts to volumes

From: Rabin Vincent <rab...@axis.com> There currently appears to be no way for userspace to find out the underlying volume number for a mounted ubifs file system, since ubifs uses anonymous block devices. The volume name is present in /proc/mounts but UBI volumes can be renamed after the

[PATCH v4] ubifs: allow userspace to map mounts to volumes

From: Rabin Vincent There currently appears to be no way for userspace to find out the underlying volume number for a mounted ubifs file system, since ubifs uses anonymous block devices. The volume name is present in /proc/mounts but UBI volumes can be renamed after the volume has been mounted

Re: Setting ->s_dev to a char device (Was: Re: [PATCH v2] ubifs: allow userspace to map mounts to volumes)

t; valid volume name, anyway? That would seem to be the obvious approach... The following patch works for me, if it's OK to show options that can't actually be used when mounting: 8<--- >From 19797334f9c87a2e0c90fe2c93f29cce397b6230 Mon Sep 17 00:00:00 2001 Fro

Re: Setting ->s_dev to a char device (Was: Re: [PATCH v2] ubifs: allow userspace to map mounts to volumes)

t; valid volume name, anyway? That would seem to be the obvious approach... The following patch works for me, if it's OK to show options that can't actually be used when mounting: 8<--- >From 19797334f9c87a2e0c90fe2c93f29cce397b6230 Mon Sep 17 00:00:00 2001 From: Rabin V

[PATCH v2] ubifs: allow userspace to map mounts to volumes

From: Rabin Vincent <rab...@axis.com> There currently appears to be no way for userspace to find out the underlying volume number for a mounted ubifs file system, since ubifs uses anonymous block devices. The volume name is present in /proc/mounts but UBI volumes can be renamed after the

[PATCH v2] ubifs: allow userspace to map mounts to volumes

From: Rabin Vincent There currently appears to be no way for userspace to find out the underlying volume number for a mounted ubifs file system, since ubifs uses anonymous block devices. The volume name is present in /proc/mounts but UBI volumes can be renamed after the volume has been mounted

[PATCH] ubifs: allow userspace to map mounts to volumes

From: Rabin Vincent <rab...@axis.com> There currently appears to be no way for userspace to find out the underlying volume number for a mounted ubifs file system, since ubifs uses anonymous block devices. The volume name is present in /proc/mounts but UBI volumes can be renamed after the

[PATCH] ubifs: allow userspace to map mounts to volumes

From: Rabin Vincent There currently appears to be no way for userspace to find out the underlying volume number for a mounted ubifs file system, since ubifs uses anonymous block devices. The volume name is present in /proc/mounts but UBI volumes can be renamed after the volume has been mounted

[PATCH] CIFS: fix oplock break deadlocks

From: Rabin Vincent <rab...@axis.com> When the final cifsFileInfo_put() is called from cifsiod and an oplock break work is queued, lockdep complains loudly: = [ INFO: possible recursive locking detected ] 4.11.0+ #21 Not t

[PATCH] CIFS: fix oplock break deadlocks

From: Rabin Vincent When the final cifsFileInfo_put() is called from cifsiod and an oplock break work is queued, lockdep complains loudly: = [ INFO: possible recursive locking detected ] 4.11.0+ #21 Not tainted

[PATCH] CIFS: silence lockdep splat in cifs_relock_file()

From: Rabin Vincent <rab...@axis.com> cifs_relock_file() can perform a down_write() on the inode's lock_sem even though it was already performed in cifs_strict_readv(). Lockdep complains about this. AFAICS, there is no problem here, and lockdep just needs to be told that this nesting

[PATCH] CIFS: silence lockdep splat in cifs_relock_file()

From: Rabin Vincent cifs_relock_file() can perform a down_write() on the inode's lock_sem even though it was already performed in cifs_strict_readv(). Lockdep complains about this. AFAICS, there is no problem here, and lockdep just needs to be told that this nesting is OK

[PATCH] Makefile: evaluate LDFLAGS_BUILD_ID only once

2 119 sched:sched_process_exec + 1 878 sched:sched_process_exec - 1,238817018 seconds time elapsed + 0,971020553 seconds time elapsed Signed-off-by: Rabin Vincent <ra...@rab.in> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile inde

[PATCH] Makefile: evaluate LDFLAGS_BUILD_ID only once

2 119 sched:sched_process_exec + 1 878 sched:sched_process_exec - 1,238817018 seconds time elapsed + 0,971020553 seconds time elapsed Signed-off-by: Rabin Vincent --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 779302695453..c78a

[PATCH] mm: prevent NR_ISOLATE_* stats from going negative

From: Rabin Vincent <rab...@axis.com> Commit 6afcf8ef0ca0 ("mm, compaction: fix NR_ISOLATED_* stats for pfn based migration") moved the dec_node_page_state() call (along with the page_is_file_cache() call) to after putback_lru_page(). But page_is_file_cache() can change after

[PATCH] mm: prevent NR_ISOLATE_* stats from going negative

From: Rabin Vincent Commit 6afcf8ef0ca0 ("mm, compaction: fix NR_ISOLATED_* stats for pfn based migration") moved the dec_node_page_state() call (along with the page_is_file_cache() call) to after putback_lru_page(). But page_is_file_cache() can change after putback_lru_page() is

[PATCH] printk: fix lost last line in kmsg dump

From: Rabin Vincent <rab...@axis.com> kmsg_dump_get_buffer() selects the youngest log messages which fit into the provided buffer. When that function determines the correct start index, by looping and calling msg_print_text() with a NULL buffer, it allows the youngest log messages to comp

[PATCH] printk: fix lost last line in kmsg dump

From: Rabin Vincent kmsg_dump_get_buffer() selects the youngest log messages which fit into the provided buffer. When that function determines the correct start index, by looping and calling msg_print_text() with a NULL buffer, it allows the youngest log messages to completely fill the provided

[PATCH] MIPS: perf: fix deadlock

From: Rabin Vincent <rab...@axis.com> mipsxx_pmu_handle_shared_irq() calls irq_work_run() while holding the pmuint_rwlock for read. irq_work_run() can, via perf_pending_event(), call try_to_wake_up() which can try to take rq->lock. However, perf can also call perf_pmu_enable() (and

[PATCH] MIPS: perf: fix deadlock

From: Rabin Vincent mipsxx_pmu_handle_shared_irq() calls irq_work_run() while holding the pmuint_rwlock for read. irq_work_run() can, via perf_pending_event(), call try_to_wake_up() which can try to take rq->lock. However, perf can also call perf_pmu_enable() (and thus take the pmuint_rwl

Re: [PATCH] arm: ftrace: fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER

Move the override out of that ifdef and into the CONFIG_DYNAMIC_FTRACE > ifdef where it belongs. > > Fixes: 80d6b0c2eed2a ("ARM: mm: allow text and rodata sections to be > read-only") > > Suggested-by: Nicolai Stange <nicsta...@gmail.com> > Suggested-by: Rabin Vinc

Re: [PATCH] arm: ftrace: fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER

Move the override out of that ifdef and into the CONFIG_DYNAMIC_FTRACE > ifdef where it belongs. > > Fixes: 80d6b0c2eed2a ("ARM: mm: allow text and rodata sections to be > read-only") > > Suggested-by: Nicolai Stange > Suggested-by: Rabin Vincent > Signed-off-by: Abel Vesa Acked-by: Rabin Vincent

Re: [PATCHv5] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

On Sat, Mar 04, 2017 at 12:51:12AM +, Abel Vesa wrote: > diff --git a/arch/arm/kernel/entry-ftrace.S b/arch/arm/kernel/entry-ftrace.S > index c73c403..93f9abb 100644 > --- a/arch/arm/kernel/entry-ftrace.S > +++ b/arch/arm/kernel/entry-ftrace.S > @@ -92,12 +92,78 @@ > 2: mcount_exit > .endm

Re: [PATCHv5] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

On Sat, Mar 04, 2017 at 12:51:12AM +, Abel Vesa wrote: > diff --git a/arch/arm/kernel/entry-ftrace.S b/arch/arm/kernel/entry-ftrace.S > index c73c403..93f9abb 100644 > --- a/arch/arm/kernel/entry-ftrace.S > +++ b/arch/arm/kernel/entry-ftrace.S > @@ -92,12 +92,78 @@ > 2: mcount_exit > .endm

Re: DIfferent BogoMIPS value after bbaa06702719 ("clocksource/drivers/arm_global_timer: Register delay timer")

On Thu, Mar 02, 2017 at 02:36:23PM +0100, Rafał Miłecki wrote: > I just updated kernel on my SmartRG SR400ac (bcm4708-smartrg-sr400ac.dts) from > 4.4 to 4.9 and noticed that this part of the log: > [0.020820] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816) > (...) > [0.190806]

Re: DIfferent BogoMIPS value after bbaa06702719 ("clocksource/drivers/arm_global_timer: Register delay timer")

On Thu, Mar 02, 2017 at 02:36:23PM +0100, Rafał Miłecki wrote: > I just updated kernel on my SmartRG SR400ac (bcm4708-smartrg-sr400ac.dts) from > 4.4 to 4.9 and noticed that this part of the log: > [0.020820] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816) > (...) > [0.190806]

Re: [PATCH] printk: fix printk.devkmsg sysctl

On Fri, Jan 27, 2017 at 07:19:30PM +0100, Borislav Petkov wrote: > On Fri, Jan 27, 2017 at 04:42:30PM +0100, Rabin Vincent wrote: > > proc_dostring() eats the '\n' and stops > > Not a problem, see diff below. Would it be possible for you to please submit it as a patch yourself so

Re: [PATCH] printk: fix printk.devkmsg sysctl

On Fri, Jan 27, 2017 at 07:19:30PM +0100, Borislav Petkov wrote: > On Fri, Jan 27, 2017 at 04:42:30PM +0100, Rabin Vincent wrote: > > proc_dostring() eats the '\n' and stops > > Not a problem, see diff below. Would it be possible for you to please submit it as a patch yourself so

Re: [PATCH] printk: fix printk.devkmsg sysctl

On Fri, Jan 27, 2017 at 04:01:41PM +0100, Borislav Petkov wrote: > On Fri, Jan 27, 2017 at 02:11:46PM +0100, Rabin Vincent wrote: > > @@ -177,7 +177,7 @@ int devkmsg_sysctl_set_loglvl(struct ctl_table *table, > > int write, > > * Do not accept an unknown str

Re: [PATCH] printk: fix printk.devkmsg sysctl

On Fri, Jan 27, 2017 at 04:01:41PM +0100, Borislav Petkov wrote: > On Fri, Jan 27, 2017 at 02:11:46PM +0100, Rabin Vincent wrote: > > @@ -177,7 +177,7 @@ int devkmsg_sysctl_set_loglvl(struct ctl_table *table, > > int write, > > * Do not accept an unknown str

[PATCH] printk: fix printk.devkmsg sysctl

From: Rabin Vincent <rab...@axis.com> The comment says that it doesn't want to accept trailing crap but that's just what it allows: # echo -n offX > /proc/sys/kernel/printk_devkmsg # while at the same time it rejects legitimate uses: # echo -n off > /proc/sys/kernel/printk_

[PATCH] printk: fix printk.devkmsg sysctl

From: Rabin Vincent The comment says that it doesn't want to accept trailing crap but that's just what it allows: # echo -n offX > /proc/sys/kernel/printk_devkmsg # while at the same time it rejects legitimate uses: # echo -n off > /proc/sys/kernel/printk_devkmsg -sh: echo: write

Re: Synopsys Ethernet QoS Driver

On Fri, Nov 18, 2016 at 02:20:27PM +, Joao Pinto wrote: > For now we are interesting in improving the synopsys QoS driver under > /nect/ethernet/synopsys. For now the driver structure consists of a single > file > called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform

Re: Synopsys Ethernet QoS Driver

On Fri, Nov 18, 2016 at 02:20:27PM +, Joao Pinto wrote: > For now we are interesting in improving the synopsys QoS driver under > /nect/ethernet/synopsys. For now the driver structure consists of a single > file > called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform

Re: [PATCH] ARM: ftrace: fix syscall name matching

On Mon, Nov 14, 2016 at 10:40:08AM -0500, Steven Rostedt wrote: > On Mon, 14 Nov 2016 13:40:17 + > Russell King - ARM Linux <li...@armlinux.org.uk> wrote: > > On Mon, Nov 14, 2016 at 02:03:45PM +0100, Rabin Vincent wrote: > > > +static inline bool arch_syscall_mat

Re: [PATCH] ARM: ftrace: fix syscall name matching

On Mon, Nov 14, 2016 at 10:40:08AM -0500, Steven Rostedt wrote: > On Mon, 14 Nov 2016 13:40:17 + > Russell King - ARM Linux wrote: > > On Mon, Nov 14, 2016 at 02:03:45PM +0100, Rabin Vincent wrote: > > > +static inline bool arch_syscall_match_sym

[tip:perf/core] perf callchain: Fixup help/config for no-unwinding

Commit-ID: c56cb33b56c13493eeb95612f80e4dd6e35cd109 Gitweb: http://git.kernel.org/tip/c56cb33b56c13493eeb95612f80e4dd6e35cd109 Author: Rabin Vincent <rab...@axis.com> AuthorDate: Wed, 10 Aug 2016 15:52:28 +0200 Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitDate

[tip:perf/core] perf callchain: Fixup help/config for no-unwinding

Commit-ID: c56cb33b56c13493eeb95612f80e4dd6e35cd109 Gitweb: http://git.kernel.org/tip/c56cb33b56c13493eeb95612f80e4dd6e35cd109 Author: Rabin Vincent AuthorDate: Wed, 10 Aug 2016 15:52:28 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 7 Nov 2016 22:13:47 -0300 perf

[PATCHv2] ARM: ftrace: fix syscall name matching

From: Rabin Vincent <rab...@axis.com> ARM has a few system calls (most notably mmap) for which the names of the functions which are referenced in the syscall table do not match the names of the syscall tracepoints. As a consequence of this, these tracepoints are not made available. Imp

[PATCHv2] ARM: ftrace: fix syscall name matching

From: Rabin Vincent ARM has a few system calls (most notably mmap) for which the names of the functions which are referenced in the syscall table do not match the names of the syscall tracepoints. As a consequence of this, these tracepoints are not made available. Implement

[PATCH] ARM: ftrace: fix syscall name matching

From: Rabin Vincent <rab...@axis.com> ARM has a few system calls (most notably mmap) for which the names of the functions which are referenced in the syscall table do not match the names of the syscall tracepoints. As a consequence of this, these tracepoints are not made available. Imp

[PATCH] ARM: ftrace: fix syscall name matching

From: Rabin Vincent ARM has a few system calls (most notably mmap) for which the names of the functions which are referenced in the syscall table do not match the names of the syscall tracepoints. As a consequence of this, these tracepoints are not made available. Implement

[PATCH] dm crypt: fix crash on exit

From: Rabin Vincent <rab...@axis.com> As the documentation for kthread_stop() says, "if threadfn() may call do_exit() itself, the caller must ensure task_struct can't go away". dm-crypt does not ensure this and therefore crashes when crypt_dtr() calls kthread_stop(). The cr

[PATCH] dm crypt: fix crash on exit

From: Rabin Vincent As the documentation for kthread_stop() says, "if threadfn() may call do_exit() itself, the caller must ensure task_struct can't go away". dm-crypt does not ensure this and therefore crashes when crypt_dtr() calls kthread_stop(). The crash is trivially reproducible

Re: [PATCH v3] scripts: add script for translating stack dump function

On Mon, Sep 19, 2016 at 12:15:42PM -0700, Linus Torvalds wrote: > Hmm. Would you mind if I change the > > addr2line -fpie $objfile $hexaddr | sed "s;$dir_prefix;;" > > into > > addr2line -fpie $objfile $hexaddr | > sed "s; at $dir_prefix\(\./\)*; at ;" > >

Re: [PATCH v3] scripts: add script for translating stack dump function

On Mon, Sep 19, 2016 at 12:15:42PM -0700, Linus Torvalds wrote: > Hmm. Would you mind if I change the > > addr2line -fpie $objfile $hexaddr | sed "s;$dir_prefix;;" > > into > > addr2line -fpie $objfile $hexaddr | > sed "s; at $dir_prefix\(\./\)*; at ;" > >

Re: [PATCH v2] scripts: add script for translating stack dump function offsets

On Fri, Sep 16, 2016 at 04:26:56PM -0500, Josh Poimboeuf wrote: > + addr2line -ie $objfile $hexaddr Could you pass in -f and -p too to addr2line? Before: $ scripts/faddr2line ~/dev/kvm2/vmlinux free_reserved_area+0x90 /home/rabin/dev/linux/include/linux/compiler.h:222

Re: [PATCH v2] scripts: add script for translating stack dump function offsets

On Fri, Sep 16, 2016 at 04:26:56PM -0500, Josh Poimboeuf wrote: > + addr2line -ie $objfile $hexaddr Could you pass in -f and -p too to addr2line? Before: $ scripts/faddr2line ~/dev/kvm2/vmlinux free_reserved_area+0x90 /home/rabin/dev/linux/include/linux/compiler.h:222

Re: [PATCH] pstore/core: drop cmpxchg based updates

> Cc: Kees Cook <keesc...@chromium.org> > Cc: Tony Luck <tony.l...@intel.com> > Signed-off-by: Sebastian Andrzej Siewior <bige...@linutronix.de> Tested-by: Rabin Vincent <rab...@axis.com> This patch is needed for pstore to work on (most?) ARMv7 chips. See this

Re: [PATCH] pstore/core: drop cmpxchg based updates

ed-off-by: Sebastian Andrzej Siewior Tested-by: Rabin Vincent This patch is needed for pstore to work on (most?) ARMv7 chips. See this thread for details: https://lkml.kernel.org/g/CABXOdTfT7xMfiBvRuUS1hsVs=q5q2wy1x1z8ocyyjnfckm0...@mail.gmail.com

Re: [PATCH] bdev: fix NULL pointer dereference in sync()/close() race

On Sat, Aug 27, 2016 at 09:07:28AM +0200, Vegard Nossum wrote: > I got this with syzkaller: > > general protection fault: [#1] PREEMPT SMP KASAN > Dumping ftrace buffer: >(ftrace buffer empty) > CPU: 0 PID: 11941 Comm: syz-executor Not tainted 4.8.0-rc2+ #169 >

Re: [PATCH] bdev: fix NULL pointer dereference in sync()/close() race

On Sat, Aug 27, 2016 at 09:07:28AM +0200, Vegard Nossum wrote: > I got this with syzkaller: > > general protection fault: [#1] PREEMPT SMP KASAN > Dumping ftrace buffer: >(ftrace buffer empty) > CPU: 0 PID: 11941 Comm: syz-executor Not tainted 4.8.0-rc2+ #169 >

[PATCH] perf callchain: fixup help/config for no-unwinding

From: Rabin Vincent <rab...@axis.com> Since 841e3558b2d ("perf callchain: Recording 'dwarf' callchains do not need DWARF unwinding support"), --call-graph dwarf is allowed in perf record even without unwind support. A couple of other places don't reflect this yet though: the

[PATCH] perf callchain: fixup help/config for no-unwinding

From: Rabin Vincent Since 841e3558b2d ("perf callchain: Recording 'dwarf' callchains do not need DWARF unwinding support"), --call-graph dwarf is allowed in perf record even without unwind support. A couple of other places don't reflect this yet though: the help text should

[PATCH] perf unwind: check symsrc ELF for .debug_frame

From: Rabin Vincent <rab...@axis.com> When using split debug info, the file without debug info may not have a .debug_frame section, so we need to check the symsrc ELF also, since that's the file we actually read the unwind information from. Signed-off-by: Rabin Vincent <rab...

[PATCH] perf unwind: check symsrc ELF for .debug_frame

From: Rabin Vincent When using split debug info, the file without debug info may not have a .debug_frame section, so we need to check the symsrc ELF also, since that's the file we actually read the unwind information from. Signed-off-by: Rabin Vincent --- tools/perf/util/unwind-libunwind

Re: debug tip after earlycon is closed?

On Thu, Jul 28, 2016 at 01:20:22PM +0100, Russell King - ARM Linux wrote: > To me, what this means is that the DT parsing of linux,stdout is > broken - while it may look nice from a design point of view, the > design is wrong and fails to take account of non-UART consoles in > the system. Note

Re: debug tip after earlycon is closed?

On Thu, Jul 28, 2016 at 01:20:22PM +0100, Russell King - ARM Linux wrote: > To me, what this means is that the DT parsing of linux,stdout is > broken - while it may look nice from a design point of view, the > design is wrong and fails to take account of non-UART consoles in > the system. Note

Re: [QUESTION] Is there a better way to get ftrace dump on guest?

On Tue, Jun 28, 2016 at 03:33:18PM +0900, Namhyung Kim wrote: > On Tue, Jun 28, 2016 at 3:25 PM, Namhyung Kim wrote: > > I'm running some guest machines for kernel development. For debugging > > purpose, I use lots of trace_printk() since it's faster than normal > >

Re: [QUESTION] Is there a better way to get ftrace dump on guest?

On Tue, Jun 28, 2016 at 03:33:18PM +0900, Namhyung Kim wrote: > On Tue, Jun 28, 2016 at 3:25 PM, Namhyung Kim wrote: > > I'm running some guest machines for kernel development. For debugging > > purpose, I use lots of trace_printk() since it's faster than normal > > printk(). When kernel crash

Faster incremental builds with Ninja

Ninja is a small build system with a focus on speed. More details at https://ninja-build.org/. I made an experimental Ninja build file generator for the kernel. The purpose was to see how much we could decrease compile times (especially to detect errors) for single file changes. Results on my

Faster incremental builds with Ninja

Ninja is a small build system with a focus on speed. More details at https://ninja-build.org/. I made an experimental Ninja build file generator for the kernel. The purpose was to see how much we could decrease compile times (especially to detect errors) for single file changes. Results on my

[PATCH 2/2] kbuild: add shell cache

&& perf stat -r5 make kernelversion Before: 0,252219929 seconds time elapsed ( +- 0,39% ) After: 0,008607464 seconds time elapsed ( +- 0,50% ) Signed-off-by: Rabin Vincent <ra...@rab.in> --- Makefile | 15 --- scripts/Kbuil

[PATCH 1/2] Makefile: evaluate LDFLAGS_BUILD_ID only once

) After: 0,864487173 seconds time elapsed ( +- 0,35% ) Signed-off-by: Rabin Vincent <ra...@rab.in> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 6471f20ca400..91baa282f3fa 100644 --- a/Makefile +++ b/Makefile @@ -814,7 +814,7 @@

[PATCH 2/2] kbuild: add shell cache

&& perf stat -r5 make kernelversion Before: 0,252219929 seconds time elapsed ( +- 0,39% ) After: 0,008607464 seconds time elapsed ( +- 0,50% ) Signed-off-by: Rabin Vincent --- Makefile | 15 --- scripts/Kbuild.incl

[PATCH 1/2] Makefile: evaluate LDFLAGS_BUILD_ID only once

) After: 0,864487173 seconds time elapsed ( +- 0,35% ) Signed-off-by: Rabin Vincent --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 6471f20ca400..91baa282f3fa 100644 --- a/Makefile +++ b/Makefile @@ -814,7 +814,7 @@ KBUILD_AFLAGS += $(ARC

Re: [PATCH] tracing: add support for tracing MMIO helpers

On Tue, Apr 26, 2016 at 09:14:47PM +0200, Arnd Bergmann wrote: > On Tuesday 26 April 2016 21:04:42 Rabin Vincent wrote: > > The support is added via and as such is only > > available on the archs which use that header. > > Why that limitation? I think only few archit

Re: [PATCH] tracing: add support for tracing MMIO helpers

On Tue, Apr 26, 2016 at 09:14:47PM +0200, Arnd Bergmann wrote: > On Tuesday 26 April 2016 21:04:42 Rabin Vincent wrote: > > The support is added via and as such is only > > available on the archs which use that header. > > Why that limitation? I think only few archit

[PATCH] tracing: add support for tracing MMIO helpers

racing must be explicitly enabled in the required driver source files by #defining TRACE_MMIO_HELPERS at the top of the file. The support is added via and as such is only available on the archs which use that header. Signed-off-by: Rabin Vincent <ra...@rab.in>

[PATCH] tracing: add support for tracing MMIO helpers

racing must be explicitly enabled in the required driver source files by #defining TRACE_MMIO_HELPERS at the top of the file. The support is added via and as such is only available on the archs which use that header. Signed-off-by: Rabin Vincent --- include/asm-generic/io.h | 4 ++ include/lin

[tip:sched/core] sched/debug: Don't dump sched debug info in SysRq-W

Commit-ID: fb90a6e93c0684ab2629a42462400603aa829b9c Gitweb: http://git.kernel.org/tip/fb90a6e93c0684ab2629a42462400603aa829b9c Author: Rabin Vincent <rab...@axis.com> AuthorDate: Mon, 4 Apr 2016 15:42:02 +0200 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed, 13 Ap

[tip:sched/core] sched/debug: Don't dump sched debug info in SysRq-W

Commit-ID: fb90a6e93c0684ab2629a42462400603aa829b9c Gitweb: http://git.kernel.org/tip/fb90a6e93c0684ab2629a42462400603aa829b9c Author: Rabin Vincent AuthorDate: Mon, 4 Apr 2016 15:42:02 +0200 Committer: Ingo Molnar CommitDate: Wed, 13 Apr 2016 11:23:21 +0200 sched/debug: Don't dump

[PATCH] sched: don't dump sched debug info in SysRq-W

From: Rabin Vincent <rab...@axis.com> sysrq_sched_debug_show() can dump a lot of information. Don't print out all that if we're just trying to get a list of blocked tasks (SysRq-W). The information is still accessible with SysRq-T. Signed-off-by: Rabin Vincent <rab...@axis.com>

[PATCH] sched: don't dump sched debug info in SysRq-W

From: Rabin Vincent sysrq_sched_debug_show() can dump a lot of information. Don't print out all that if we're just trying to get a list of blocked tasks (SysRq-W). The information is still accessible with SysRq-T. Signed-off-by: Rabin Vincent --- kernel/sched/core.c | 3 ++- 1 file changed

Re: [PATCH] clockevents/drivers/arm_global_timer: Fix erratum 740657 workaround

On Tue, Mar 29, 2016 at 05:13:05PM +0100, Marc Zyngier wrote: > - What if my timer is not connected to a controller that implements this > API? Something that is not a GIC, for example? As you know irq_set_irqchip_state() does nothing in that case, and the erratum is thus presumably not worked

Re: [PATCH] clockevents/drivers/arm_global_timer: Fix erratum 740657 workaround

On Tue, Mar 29, 2016 at 05:13:05PM +0100, Marc Zyngier wrote: > - What if my timer is not connected to a controller that implements this > API? Something that is not a GIC, for example? As you know irq_set_irqchip_state() does nothing in that case, and the erratum is thus presumably not worked

Re: [PATCH] clockevents/drivers/arm_global_timer: Fix erratum 740657 workaround

On Tue, Mar 29, 2016 at 04:21:03PM +0200, Daniel Lezcano wrote: > On 03/29/2016 10:08 AM, Rabin Vincent wrote: > > -0 [001] d.h2 99.850527: irq_handler_entry: irq=16 name=gt > > -0 [001] d.h2 99.850538: irq_handler_exit: irq=16 ret=handled > > -0 [001] d.H2 99.850540: irq_

Re: [PATCH] clockevents/drivers/arm_global_timer: Fix erratum 740657 workaround

On Tue, Mar 29, 2016 at 04:21:03PM +0200, Daniel Lezcano wrote: > On 03/29/2016 10:08 AM, Rabin Vincent wrote: > > -0 [001] d.h2 99.850527: irq_handler_entry: irq=16 name=gt > > -0 [001] d.h2 99.850538: irq_handler_exit: irq=16 ret=handled > > -0 [001] d.H2 99.850540: irq_

[PATCH] clockevents/drivers/arm_global_timer: Fix erratum 740657 workaround

From: Rabin Vincent <rab...@axis.com> According to the errata document for the Cortex A9 MPCore, the correct code sequence in the interrupt handler to workaround erratum 740657 "Global Timer can send two interrupts for the same event" is: (1) Read the ICCIAR (Interrupt Acknowled

[PATCH] clockevents/drivers/arm_global_timer: Fix erratum 740657 workaround

From: Rabin Vincent According to the errata document for the Cortex A9 MPCore, the correct code sequence in the interrupt handler to workaround erratum 740657 "Global Timer can send two interrupts for the same event" is: (1) Read the ICCIAR (Interrupt Acknowledge) register

Re: [PATCH v2] ARM: DMA: Fix kzalloc flags in __dma_alloc

locator unhappy. > > Signed-off-by: Alexandre Courbot <acour...@nvidia.com> > Cc: Rabin Vincent <ra...@rab.in> > --- > Changes since v1: > - Filter flags that may cause problem instead of forcing GFP_KERNEL > (and risk sleeping in atomic context), as suggested by Rabin. Acked-by: Rabin Vincent <ra...@rab.in> Thanks.

Re: [PATCH v2] ARM: DMA: Fix kzalloc flags in __dma_alloc

r unhappy. > > Signed-off-by: Alexandre Courbot > Cc: Rabin Vincent > --- > Changes since v1: > - Filter flags that may cause problem instead of forcing GFP_KERNEL > (and risk sleeping in atomic context), as suggested by Rabin. Acked-by: Rabin Vincent Thanks.

Re: [PATCH] ARM: DMA: Fix kzalloc flags in __dma_alloc

On Fri, Mar 18, 2016 at 11:12:26AM +0900, Alexandre Courbot wrote: > Commit 19e6e5e5392b ("ARM: 8547/1: dma-mapping: store buffer > information") allocates a structure meant for internal buffer management > with the GFP flags of the buffer itself. This can trigger the following > safeguard in the

Re: [PATCH] ARM: DMA: Fix kzalloc flags in __dma_alloc

On Fri, Mar 18, 2016 at 11:12:26AM +0900, Alexandre Courbot wrote: > Commit 19e6e5e5392b ("ARM: 8547/1: dma-mapping: store buffer > information") allocates a structure meant for internal buffer management > with the GFP flags of the buffer itself. This can trigger the following > safeguard in the

Re: [PATCH] block: protect iterate_bdevs() against concurrent close

(fixed Jens' address) On Thu, Mar 10, 2016 at 06:37:27PM +0100, Jan Kara wrote: > On Thu 10-03-16 13:26:03, Rabin Vincent wrote: > > If a block device is closed while iterate_bdevs() is handling it, the > > following NULL pointer dereference occurs because bdev-

Re: [PATCH] block: protect iterate_bdevs() against concurrent close

(fixed Jens' address) On Thu, Mar 10, 2016 at 06:37:27PM +0100, Jan Kara wrote: > On Thu 10-03-16 13:26:03, Rabin Vincent wrote: > > If a block device is closed while iterate_bdevs() is handling it, the > > following NULL pointer dereference occurs because bdev-

[PATCH] splice: handle zero nr_pages in splice_to_pipe()

Cc: sta...@vger.kernel.org Signed-off-by: Rabin Vincent <ra...@rab.in> --- fs/splice.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/splice.c b/fs/splice.c index 82bc0d64fc38..19e0b103d253 100644 --- a/fs/splice.c +++ b/fs/splice.c @@ -185,6 +185,9 @@ ssize_t splice_to_pipe(struct

[PATCH] splice: handle zero nr_pages in splice_to_pipe()

Cc: sta...@vger.kernel.org Signed-off-by: Rabin Vincent --- fs/splice.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/splice.c b/fs/splice.c index 82bc0d64fc38..19e0b103d253 100644 --- a/fs/splice.c +++ b/fs/splice.c @@ -185,6 +185,9 @@ ssize_t splice_to_pipe(struct pipe_inode_i

[PATCH] block: protect iterate_bdevs() against concurrent close

From: Rabin Vincent <rab...@axis.com> If a block device is closed while iterate_bdevs() is handling it, the following NULL pointer dereference occurs because bdev->b_disk is NULL in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in tu

[PATCH] block: protect iterate_bdevs() against concurrent close

From: Rabin Vincent If a block device is closed while iterate_bdevs() is handling it, the following NULL pointer dereference occurs because bdev->b_disk is NULL in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in turn called by the mapping_cap_writeback_dirty() c

  1   2   3   4   5   6   >