Re: [PATCH v4 2/5] clockevents: Add timed freeze

On Thu, Jun 9, 2016 at 3:43 PM, Thomas Gleixner wrote: > On Thu, 9 Jun 2016, dbaseh...@chromium.org wrote: >> >> +/* >> + * Clockevent device may run during freeze >> + */ >> +# define CLOCK_EVT_FEAT_FREEZE 0x000100 > > This is a bad name and a horrible comment.

Re: [PATCH v4 2/5] clockevents: Add timed freeze

On Thu, Jun 9, 2016 at 3:43 PM, Thomas Gleixner wrote: > On Thu, 9 Jun 2016, dbaseh...@chromium.org wrote: >> >> +/* >> + * Clockevent device may run during freeze >> + */ >> +# define CLOCK_EVT_FEAT_FREEZE 0x000100 > > This is a bad name and a horrible comment. The device does not

[PATCH v3 2/3] x86/signal: Rewire the restart_block() syscall to have a constant nr

Suppose a 64-bit task A traces a 32-bit task B. B makes a syscall that uses ERESTART_RESTARTBLOCK and gets a signal. A catches syscall exit, snapshots B's regs, changes the regs, and resumes. Then A restores the snapshot of B's regs. A expects B to resume where it left off when snapshotted,

[PATCH v3 1/3] x86/ptrace: Stop setting TS_COMPAT in ptrace code

Setting TS_COMPAT in ptrace is wrong: if we happen to do it during syscall entry, then we'll confuse seccomp and audit. (The former isn't a security problem: seccomp is currently entirely insecure if a malicious ptracer is attached.) As a minimal fix, this patch adds a new flag

[PATCH v3 3/3] x86/ptrace, x86/signal: Remove TS_I386_REGS_POKED

System call restart has some oddities wrt ptrace: 1. For whatever reason, the kernel delivers signals and triggers ptrace before handling syscall restart. This means that -ERESTART_RESTARTBLOCK, etc is visible to userspace. We could plausibly get away with changing that, but it seems

[PATCH v3 2/3] x86/signal: Rewire the restart_block() syscall to have a constant nr

Suppose a 64-bit task A traces a 32-bit task B. B makes a syscall that uses ERESTART_RESTARTBLOCK and gets a signal. A catches syscall exit, snapshots B's regs, changes the regs, and resumes. Then A restores the snapshot of B's regs. A expects B to resume where it left off when snapshotted,

[PATCH v3 1/3] x86/ptrace: Stop setting TS_COMPAT in ptrace code

Setting TS_COMPAT in ptrace is wrong: if we happen to do it during syscall entry, then we'll confuse seccomp and audit. (The former isn't a security problem: seccomp is currently entirely insecure if a malicious ptracer is attached.) As a minimal fix, this patch adds a new flag

[PATCH v3 3/3] x86/ptrace, x86/signal: Remove TS_I386_REGS_POKED

System call restart has some oddities wrt ptrace: 1. For whatever reason, the kernel delivers signals and triggers ptrace before handling syscall restart. This means that -ERESTART_RESTARTBLOCK, etc is visible to userspace. We could plausibly get away with changing that, but it seems

[PATCH v3 0/3] ptrace-vs-syscall-restart fixes, v3

Now that I have a complete fix and cleanup that I like, here it is. Patch 1 is the same as before except for a config-dependent build fix. This series is a cleanup and fixes at least two bugs: - 64-bit gdb attached to a 32-bit program malfunctions if the user types something like "print

[PATCH v3 0/3] ptrace-vs-syscall-restart fixes, v3

Now that I have a complete fix and cleanup that I like, here it is. Patch 1 is the same as before except for a config-dependent build fix. This series is a cleanup and fixes at least two bugs: - 64-bit gdb attached to a 32-bit program malfunctions if the user types something like "print

Re: ktime_get_ts64() splat during resume

On Monday, June 20, 2016 11:15:18 PM Rafael J. Wysocki wrote: > On Mon, Jun 20, 2016 at 8:29 PM, Linus Torvalds > wrote: > > On Mon, Jun 20, 2016 at 7:38 AM, Rafael J. Wysocki > > wrote: > >> > >> Overall, we seem to be heading towards the

Re: ktime_get_ts64() splat during resume

On Monday, June 20, 2016 11:15:18 PM Rafael J. Wysocki wrote: > On Mon, Jun 20, 2016 at 8:29 PM, Linus Torvalds > wrote: > > On Mon, Jun 20, 2016 at 7:38 AM, Rafael J. Wysocki > > wrote: > >> > >> Overall, we seem to be heading towards the "really weird" territory here. > > > > So the whole

Re: [PATCH 2/2] dt-bindings: qcom: Add MDM9615 bindings

On 06/17, Neil Armstrong wrote: > Signed-off-by: Neil Armstrong > --- Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH 2/2] dt-bindings: qcom: Add MDM9615 bindings

On 06/17, Neil Armstrong wrote: > Signed-off-by: Neil Armstrong > --- Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH v2] firmware: qcom: scm: Expose PAS command 10 as reset-controller

On 06/17, Bjorn Andersson wrote: > PAS command 10 is used to assert and deassert the MSS reset via > TrustZone, expose this as a reset-controller to mimic the direct > access case. > > Cc: Stephen Boyd > Acked-by: Rob Herring > Signed-off-by: Bjorn

Re: [PATCH v2] firmware: qcom: scm: Expose PAS command 10 as reset-controller

On 06/17, Bjorn Andersson wrote: > PAS command 10 is used to assert and deassert the MSS reset via > TrustZone, expose this as a reset-controller to mimic the direct > access case. > > Cc: Stephen Boyd > Acked-by: Rob Herring > Signed-off-by: Bjorn Andersson > --- Reviewed-by: Stephen Boyd

Re: [PATCH v2] tty: serial: msm: Don't reconfigure same baud rate

On 06/16, Bjorn Andersson wrote: > msm_set_termios() is called whenever the tty is opened. Setting the baud > rate requires a full reset of the msm serial block, even when the rate > is unchanged. In the case when the same uart is used as console this > reset will discard any console output data

Re: [PATCH v2] tty: serial: msm: Don't reconfigure same baud rate

On 06/16, Bjorn Andersson wrote: > msm_set_termios() is called whenever the tty is opened. Setting the baud > rate requires a full reset of the msm serial block, even when the rate > is unchanged. In the case when the same uart is used as console this > reset will discard any console output data

Re: x86/tsc: Set X86_FEATURE_TSC_RELIABLE to skip refined calibration

On Mon, Jun 20, 2016 at 04:20:26PM -0700, John Stultz wrote: > On Fri, Jun 17, 2016 at 12:48 AM, Thomas Gleixner wrote: > > On Thu, 16 Jun 2016, Bin Gao wrote: > > > >> Unlike PIT based calibration which counts TSC cycles against another timer, > >> MSR or CPUID method has no

Re: x86/tsc: Set X86_FEATURE_TSC_RELIABLE to skip refined calibration

On Mon, Jun 20, 2016 at 04:20:26PM -0700, John Stultz wrote: > On Fri, Jun 17, 2016 at 12:48 AM, Thomas Gleixner wrote: > > On Thu, 16 Jun 2016, Bin Gao wrote: > > > >> Unlike PIT based calibration which counts TSC cycles against another timer, > >> MSR or CPUID method has no calibration - it

Re: [PATCH RFC V2 3/3] perf script: Add callindent option

On Fri, Jun 17, 2016 at 11:22:56AM +0300, Adrian Hunter wrote: > Based on patches from Andi Kleen. > > When printing PT instruction traces with perf script it is rather useful to > see some indentation for the call tree. This patch adds a new callindent > field to perf script that prints spaces

Re: [PATCH RFC V2 3/3] perf script: Add callindent option

On Fri, Jun 17, 2016 at 11:22:56AM +0300, Adrian Hunter wrote: > Based on patches from Andi Kleen. > > When printing PT instruction traces with perf script it is rather useful to > see some indentation for the call tree. This patch adds a new callindent > field to perf script that prints spaces

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Mon, Jun 20, 2016 at 05:49:17PM +0200, Stephan Mueller wrote: > > Is speed everything we should care about? What about: > > - offloading of crypto operation from the CPU In practice CPU offland is not helpful, and in fact, in most cases is harmful, when one is only encrypting a tiny amount

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Mon, Jun 20, 2016 at 05:49:17PM +0200, Stephan Mueller wrote: > > Is speed everything we should care about? What about: > > - offloading of crypto operation from the CPU In practice CPU offland is not helpful, and in fact, in most cases is harmful, when one is only encrypting a tiny amount

[PATCH v3 03/13] x86/mm: Remove kernel_unmap_pages_in_pgd() and efi_cleanup_page_tables()

kernel_unmap_pages_in_pgd() is dangerous: if a pgd entry in init_mm.pgd were to be cleared, callers would need to ensure that the pgd entry hadn't been propagated to any other pgd. Its only caller was efi_cleanup_page_tables(), and that, in turn, was unused, so just delete both functions. This

[PATCH v3 03/13] x86/mm: Remove kernel_unmap_pages_in_pgd() and efi_cleanup_page_tables()

kernel_unmap_pages_in_pgd() is dangerous: if a pgd entry in init_mm.pgd were to be cleared, callers would need to ensure that the pgd entry hadn't been propagated to any other pgd. Its only caller was efi_cleanup_page_tables(), and that, in turn, was unused, so just delete both functions. This

Re: [6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF

On Sun, 2016-06-19 at 23:06 +0530, Naveen N. Rao wrote: > On 2016/06/17 10:53PM, Michael Ellerman wrote: > > On Tue, 2016-07-06 at 13:32:23 UTC, "Naveen N. Rao" wrote: > > > diff --git a/arch/powerpc/net/bpf_jit_comp64.c > > > b/arch/powerpc/net/bpf_jit_comp64.c > > > new file mode 100644 > > >

[PATCH v3 06/13] fork: Add generic vmalloced stack support

If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with vmalloc_node. Signed-off-by: Andy Lutomirski --- arch/Kconfig| 29 + arch/ia64/include/asm/thread_info.h | 2 +- include/linux/sched.h | 15 +++

[PATCH v3 05/13] mm: Fix memcg stack accounting for sub-page stacks

We should account for stacks regardless of stack size, and we need to account in sub-page units if THREAD_SIZE < PAGE_SIZE. Change the units to kilobytes and Move it into account_kernel_stack(). Fixes: 12580e4b54ba8 ("mm: memcontrol: report kernel stack usage in cgroup2 memory.stat") Cc:

Re: [6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF

On Sun, 2016-06-19 at 23:06 +0530, Naveen N. Rao wrote: > On 2016/06/17 10:53PM, Michael Ellerman wrote: > > On Tue, 2016-07-06 at 13:32:23 UTC, "Naveen N. Rao" wrote: > > > diff --git a/arch/powerpc/net/bpf_jit_comp64.c > > > b/arch/powerpc/net/bpf_jit_comp64.c > > > new file mode 100644 > > >

[PATCH v3 06/13] fork: Add generic vmalloced stack support

If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with vmalloc_node. Signed-off-by: Andy Lutomirski --- arch/Kconfig| 29 + arch/ia64/include/asm/thread_info.h | 2 +- include/linux/sched.h | 15 +++ kernel/fork.c

[PATCH v3 05/13] mm: Fix memcg stack accounting for sub-page stacks

We should account for stacks regardless of stack size, and we need to account in sub-page units if THREAD_SIZE < PAGE_SIZE. Change the units to kilobytes and Move it into account_kernel_stack(). Fixes: 12580e4b54ba8 ("mm: memcontrol: report kernel stack usage in cgroup2 memory.stat") Cc:

[PATCH v3 08/13] x86/dumpstack: When OOPSing, rewind the stack before do_exit

If we call do_exit with a clean stack, we greatly reduce the risk of recursive oopses due to stack overflow in do_exit, and we allow do_exit to work even if we OOPS from an IST stack. The latter gives us a much better chance of surviving long enough after we detect a stack overflow to write out

[PATCH v3 08/13] x86/dumpstack: When OOPSing, rewind the stack before do_exit

If we call do_exit with a clean stack, we greatly reduce the risk of recursive oopses due to stack overflow in do_exit, and we allow do_exit to work even if we OOPS from an IST stack. The latter gives us a much better chance of surviving long enough after we detect a stack overflow to write out

[PATCH v3 07/13] x86/die: Don't try to recover from an OOPS on a non-default stack

It's not going to work, because the scheduler will explode if we try to schedule when running on an IST stack or similar. This will matter when we let kernel stack overflows (which are #DF) call die(). Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack.c | 3 +++ 1

[PATCH v3 10/13] x86/dumpstack: Try harder to get a call trace on stack overflow

If we overflow the stack, print_context_stack will abort. Detect this case and rewind back into the valid part of the stack so that we can trace it. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-)

[PATCH] mm: slab.h: use ilog2() in kmalloc_index()

kmalloc_index() uses simple straightforward way to calculate bit position of nearest or equal upper power of 2. This effectively results in generation of 24 episodes of compare-branch instructions in assembler. There is shorter way to calculate this: fls(size - 1). The patch removes hard-coded

[PATCH v3 07/13] x86/die: Don't try to recover from an OOPS on a non-default stack

It's not going to work, because the scheduler will explode if we try to schedule when running on an IST stack or similar. This will matter when we let kernel stack overflows (which are #DF) call die(). Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack.c | 3 +++ 1 file changed, 3

[PATCH v3 10/13] x86/dumpstack: Try harder to get a call trace on stack overflow

If we overflow the stack, print_context_stack will abort. Detect this case and rewind back into the valid part of the stack so that we can trace it. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git

[PATCH] mm: slab.h: use ilog2() in kmalloc_index()

kmalloc_index() uses simple straightforward way to calculate bit position of nearest or equal upper power of 2. This effectively results in generation of 24 episodes of compare-branch instructions in assembler. There is shorter way to calculate this: fls(size - 1). The patch removes hard-coded

[PATCH v3 09/13] x86/dumpstack: When dumping stack bytes due to OOPS, start with regs->sp

The comment suggests that show_stack(NULL, NULL) should backtrace the current context, but the code doesn't match the comment. If regs are given, start the "Stack:" hexdump at regs->sp. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack_32.c | 4 +++-

[PATCH v3 11/13] x86/dumpstack/64: Handle faults when printing the "Stack:" part of an OOPS

If we overflow the stack into a guard page, we'll recursively fault when trying to dump the contents of the guard page. Use probe_kernel_address so we can recover if this happens. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack_64.c | 12 ++-- 1 file

[PATCH v3 01/13] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

From: Ingo Molnar So when memory hotplug removes a piece of physical memory from pagetable mappings, it also frees the underlying PGD entry. This complicates PGD management, so don't do this. We can keep the PGD mapped and the PUD table all clear - it's only a single 4K page

[PATCH v3 04/13] mm: Track NR_KERNEL_STACK in KiB instead of number of stacks

Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a zone. This only makes sense if each kernel stack exists entirely in one zone, and allowing vmapped stacks could break this assumption. Since frv has THREAD_SIZE < PAGE_SIZE, we need to track kernel stack allocations in a unit

[PATCH v3 09/13] x86/dumpstack: When dumping stack bytes due to OOPS, start with regs->sp

The comment suggests that show_stack(NULL, NULL) should backtrace the current context, but the code doesn't match the comment. If regs are given, start the "Stack:" hexdump at regs->sp. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack_32.c | 4 +++- arch/x86/kernel/dumpstack_64.c |

[PATCH v3 11/13] x86/dumpstack/64: Handle faults when printing the "Stack:" part of an OOPS

If we overflow the stack into a guard page, we'll recursively fault when trying to dump the contents of the guard page. Use probe_kernel_address so we can recover if this happens. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack_64.c | 12 ++-- 1 file changed, 10

[PATCH v3 01/13] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

From: Ingo Molnar So when memory hotplug removes a piece of physical memory from pagetable mappings, it also frees the underlying PGD entry. This complicates PGD management, so don't do this. We can keep the PGD mapped and the PUD table all clear - it's only a single 4K page per 512 GB of

[PATCH v3 04/13] mm: Track NR_KERNEL_STACK in KiB instead of number of stacks

Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a zone. This only makes sense if each kernel stack exists entirely in one zone, and allowing vmapped stacks could break this assumption. Since frv has THREAD_SIZE < PAGE_SIZE, we need to track kernel stack allocations in a unit

[PATCH v3 12/13] x86/mm/64: Enable vmapped stacks

This allows x86_64 kernels to enable vmapped stacks. There are a couple of interesting bits. First, x86 lazily faults in top-level paging entries for the vmalloc area. This won't work if we get a page fault while trying to access the stack: the CPU will promote it to a double-fault and we'll

[PATCH v3 13/13] x86/mm: Improve stack-overflow #PF handling

If we get a page fault indicating kernel stack overflow, invoke handle_stack_overflow(). To prevent us from overflowing the stack again while handling the overflow (because we are likely to have very little stack space left), call handle_stack_overflow() on the double-fault stack Signed-off-by:

[PATCH v3 12/13] x86/mm/64: Enable vmapped stacks

This allows x86_64 kernels to enable vmapped stacks. There are a couple of interesting bits. First, x86 lazily faults in top-level paging entries for the vmalloc area. This won't work if we get a page fault while trying to access the stack: the CPU will promote it to a double-fault and we'll

[PATCH v3 13/13] x86/mm: Improve stack-overflow #PF handling

If we get a page fault indicating kernel stack overflow, invoke handle_stack_overflow(). To prevent us from overflowing the stack again while handling the overflow (because we are likely to have very little stack space left), call handle_stack_overflow() on the double-fault stack Signed-off-by:

[PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

Since the dawn of time, a kernel stack overflow has been a real PITA to debug, has caused nondeterministic crashes some time after the actual overflow, and has generally been easy to exploit for root. With this series, arches can enable HAVE_ARCH_VMAP_STACK. Arches that enable it (just x86 for

[PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

Since the dawn of time, a kernel stack overflow has been a real PITA to debug, has caused nondeterministic crashes some time after the actual overflow, and has generally been easy to exploit for root. With this series, arches can enable HAVE_ARCH_VMAP_STACK. Arches that enable it (just x86 for

[PATCH v3 02/13] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated

This avoids pointless races in which another CPU or task might see a partially populated global pgd entry. These races should normally be harmless, but, if another CPU propagates the entry via vmalloc_fault and then populate_pgd fails (due to memory allocation failure, for example), this prevents

Re: [PATCH v3 1/7] max8903: adds documentation for device tree bindings.

On 20/06/2016 11:22 PM, Rob Herring wrote: On Fri, Jun 17, 2016 at 03:00:20PM +1000, Chris Lapa wrote: From: Chris Lapa Signed-off-by: Chris Lapa --- .../devicetree/bindings/power/max8903-charger.txt | 25 ++ 1 file changed, 25

[PATCH v3 02/13] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated

This avoids pointless races in which another CPU or task might see a partially populated global pgd entry. These races should normally be harmless, but, if another CPU propagates the entry via vmalloc_fault and then populate_pgd fails (due to memory allocation failure, for example), this prevents

Re: [PATCH v3 1/7] max8903: adds documentation for device tree bindings.

On 20/06/2016 11:22 PM, Rob Herring wrote: On Fri, Jun 17, 2016 at 03:00:20PM +1000, Chris Lapa wrote: From: Chris Lapa Signed-off-by: Chris Lapa --- .../devicetree/bindings/power/max8903-charger.txt | 25 ++ 1 file changed, 25 insertions(+) create mode 100644

Re: [GIT PULL] AVR32 update for 4.7

Hi Linus, On Mon, 20 Jun 2016 10:34:52 -0700 Linus Torvalds wrote: > > Come back to me during the next merge window when this is appropriate, > and when it has been in linux-next for a week or two *without* being > rebased for no good reason. That would require

Re: [GIT PULL] AVR32 update for 4.7

Hi Linus, On Mon, 20 Jun 2016 10:34:52 -0700 Linus Torvalds wrote: > > Come back to me during the next merge window when this is appropriate, > and when it has been in linux-next for a week or two *without* being > rebased for no good reason. That would require that the avr32 tree was actually

Re: [PATCH v3 0/5] i.MX L2-cache code cleanups and performance tweaks

On Sunday, June 19, 2016 10:53:13 AM CEST Andrey Smirnov wrote: > One more question, less about your patches than the existing code: > > > > After going through the current users of l2x0_init for board files, > > I noticed that imx35 enables l2x0 for both dts and all the board files > > and has

Re: [PATCH v3 0/5] i.MX L2-cache code cleanups and performance tweaks

On Sunday, June 19, 2016 10:53:13 AM CEST Andrey Smirnov wrote: > One more question, less about your patches than the existing code: > > > > After going through the current users of l2x0_init for board files, > > I noticed that imx35 enables l2x0 for both dts and all the board files > > and has

Re: [PATCH 5/5] vmlinux.lds.h: replace config_enabled() with IS_ENABLED()

2016-06-21 5:45 GMT+09:00 Michal Marek : > Dne 14.6.2016 v 07:58 Masahiro Yamada napsal(a): >> The use of config_enabled() against config options is ambiguous. >> >> Now, IS_ENABLED() is implemented purely with macro expansion, so >> let's replace config_enabled() with

Re: [PATCH 5/5] vmlinux.lds.h: replace config_enabled() with IS_ENABLED()

2016-06-21 5:45 GMT+09:00 Michal Marek : > Dne 14.6.2016 v 07:58 Masahiro Yamada napsal(a): >> The use of config_enabled() against config options is ambiguous. >> >> Now, IS_ENABLED() is implemented purely with macro expansion, so >> let's replace config_enabled() with IS_ENABLED(). >> >>

Re: x86/tsc: Set X86_FEATURE_TSC_RELIABLE to skip refined calibration

On Fri, Jun 17, 2016 at 12:48 AM, Thomas Gleixner wrote: > On Thu, 16 Jun 2016, Bin Gao wrote: > >> Unlike PIT based calibration which counts TSC cycles against another timer, >> MSR or CPUID method has no calibration - it simply multiplies the known >> frequency of a timer by

Re: x86/tsc: Set X86_FEATURE_TSC_RELIABLE to skip refined calibration

On Fri, Jun 17, 2016 at 12:48 AM, Thomas Gleixner wrote: > On Thu, 16 Jun 2016, Bin Gao wrote: > >> Unlike PIT based calibration which counts TSC cycles against another timer, >> MSR or CPUID method has no calibration - it simply multiplies the known >> frequency of a timer by a ratio. So TSC

RE: [PATCH v3 1/5] ACPICA: Namespace: Fix a regression that MLC support triggers dead lock in dynamic table loading

Hi, Mika > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > Subject: Re: [PATCH v3 1/5] ACPICA: Namespace: Fix a regression that MLC > support triggers dead lock in dynamic table loading > > On Mon, Jun 20, 2016 at 05:07:22PM +0800, Lv Zheng wrote: > > The new MLC approach

RE: [PATCH v3 1/5] ACPICA: Namespace: Fix a regression that MLC support triggers dead lock in dynamic table loading

Hi, Mika > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > Subject: Re: [PATCH v3 1/5] ACPICA: Namespace: Fix a regression that MLC > support triggers dead lock in dynamic table loading > > On Mon, Jun 20, 2016 at 05:07:22PM +0800, Lv Zheng wrote: > > The new MLC approach

Re: [PATCH 1/1] mm/page_ref: introduce page_ref_inc_return

On Mon, 20 Jun 2016 12:38:13 +0200 Christian Borntraeger wrote: > From: David Hildenbrand > > Let's introduce that helper. > > ... > > +static inline int page_ref_inc_return(struct page *page) > +{ > + int ret =

Re: [PATCH 1/1] mm/page_ref: introduce page_ref_inc_return

On Mon, 20 Jun 2016 12:38:13 +0200 Christian Borntraeger wrote: > From: David Hildenbrand > > Let's introduce that helper. > > ... > > +static inline int page_ref_inc_return(struct page *page) > +{ > + int ret = atomic_inc_return(>_refcount); > + > + if

Re: [PATCH 1/2] ipc/sem.c: Fix complex_count vs. simple op race

On Sat, 18 Jun 2016 22:02:21 +0200 Manfred Spraul wrote: > Commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") introduced a race: > > sem_lock has a fast path that allows parallel simple operations. > There are two reasons why a simple operation cannot run in

Re: [PATCH 1/2] ipc/sem.c: Fix complex_count vs. simple op race

On Sat, 18 Jun 2016 22:02:21 +0200 Manfred Spraul wrote: > Commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") introduced a race: > > sem_lock has a fast path that allows parallel simple operations. > There are two reasons why a simple operation cannot run in parallel: > - a non-simple

[PATCH 3/3] serial: m32r_sio: make it explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/tty/serial/Kconfig:config SERIAL_M32R_SIO drivers/tty/serial/Kconfig: bool "M32R SIO I/F" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned,

[PATCH 3/3] serial: m32r_sio: make it explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/tty/serial/Kconfig:config SERIAL_M32R_SIO drivers/tty/serial/Kconfig: bool "M32R SIO I/F" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned,

RE: [PATCH] fsl mc-bus: Move mc-io destroy to bus remove

> -Original Message- > From: Bharat Bhushan [mailto:bharat.bhus...@nxp.com] > Sent: Thursday, June 16, 2016 1:52 AM > To: gre...@linuxfoundation.org; Stuart Yoder > Cc: de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; Bharat Bhushan >

RE: [PATCH] fsl mc-bus: Move mc-io destroy to bus remove

> -Original Message- > From: Bharat Bhushan [mailto:bharat.bhus...@nxp.com] > Sent: Thursday, June 16, 2016 1:52 AM > To: gre...@linuxfoundation.org; Stuart Yoder > Cc: de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; Bharat Bhushan > > Subject: [PATCH] fsl mc-bus: Move mc-io

[PATCH 2/3] serial: vt8500_serial: make it explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/tty/serial/Kconfig:config SERIAL_VT8500 drivers/tty/serial/Kconfig: bool "VIA VT8500 on-chip serial port support" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that

[PATCH 1/3] serial: pxa: make it explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/tty/serial/Kconfig:config SERIAL_PXA drivers/tty/serial/Kconfig: bool "PXA serial port support" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially

[PATCH 1/3] serial: pxa: make it explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/tty/serial/Kconfig:config SERIAL_PXA drivers/tty/serial/Kconfig: bool "PXA serial port support" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially

[PATCH 2/3] serial: vt8500_serial: make it explicitly non-modular

The Kconfig currently controlling compilation of this code is: drivers/tty/serial/Kconfig:config SERIAL_VT8500 drivers/tty/serial/Kconfig: bool "VIA VT8500 on-chip serial port support" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that

Re: [PATCH 8/8] arm64: dts: db820c: add support to external sd card.

Hi, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.7-rc4 next-20160620] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/arm64-dts-db820c-Add-basic

Re: [PATCH 8/8] arm64: dts: db820c: add support to external sd card.

Hi, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.7-rc4 next-20160620] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/arm64-dts-db820c-Add-basic

Re: [PATCH 0/3] nvme: Don't add namespaces for locked drives

On Mon, Jun 20, 2016 at 11:21:09AM -0700, Jethro Beekman wrote: > On 20-06-16 08:26, Keith Busch wrote: > > Would this just be a matter of setting req->retries and checking for it in > nvme_req_needs_retry? How does one keep track of the number of tries so far? I just sent a patch out earlier

Re: [PATCH 0/3] nvme: Don't add namespaces for locked drives

On Mon, Jun 20, 2016 at 11:21:09AM -0700, Jethro Beekman wrote: > On 20-06-16 08:26, Keith Busch wrote: > > Would this just be a matter of setting req->retries and checking for it in > nvme_req_needs_retry? How does one keep track of the number of tries so far? I just sent a patch out earlier

[PATCH v1 1/1] MAINTAINERS: belong Documentation/pinctrl.txt properly

I'm pretty sure that Documentation/pinctrl.txt would be better maintained by pinctrl subsystem. Signed-off-by: Andy Shevchenko --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9040236..c59d978 100644 ---

[PATCH v1 1/1] MAINTAINERS: belong Documentation/pinctrl.txt properly

I'm pretty sure that Documentation/pinctrl.txt would be better maintained by pinctrl subsystem. Signed-off-by: Andy Shevchenko --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9040236..c59d978 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Mon, 2016-06-20 at 15:52 -0400, Mike Snitzer wrote: > On Mon, Jun 20 2016 at  3:40pm -0400, > Mike Snitzer wrote: >   > > > > # dd if=/dev/zero of=/mnt/dax/meh bs=1024K oflag=direct > > [11729.754671] XFS (dm-4): Metadata corruption detected at > >

[PATCH] staging: lustre: llite: break ll_getxattr_common into 2 functions

Split the function ll_getxattr_common into two functions. The code used for listing xattrs and ll_getxattr_common is placed into a new function ll_getxattr_list. This allows ll_listxattr to call directly ll_getxattr_list instead of going through ll_getxattr_common. This change is needed for the

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Mon, 2016-06-20 at 15:52 -0400, Mike Snitzer wrote: > On Mon, Jun 20 2016 at  3:40pm -0400, > Mike Snitzer wrote: >   > > > > # dd if=/dev/zero of=/mnt/dax/meh bs=1024K oflag=direct > > [11729.754671] XFS (dm-4): Metadata corruption detected at > > xfs_agf_read_verify+0x70/0x120 [xfs],

[PATCH] staging: lustre: llite: break ll_getxattr_common into 2 functions

Split the function ll_getxattr_common into two functions. The code used for listing xattrs and ll_getxattr_common is placed into a new function ll_getxattr_list. This allows ll_listxattr to call directly ll_getxattr_list instead of going through ll_getxattr_common. This change is needed for the

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

Netanel Belgazal : [...] > > diff --git a/drivers/net/ethernet/amazon/ena/ena_com.h > > b/drivers/net/ethernet/amazon/ena/ena_com.h > > new file mode 100644 > > index 000..e49ba43 > > --- /dev/null > > [...] > > +static inline void ena_com_update_intr_reg(struct

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

Netanel Belgazal : [...] > > diff --git a/drivers/net/ethernet/amazon/ena/ena_com.h > > b/drivers/net/ethernet/amazon/ena/ena_com.h > > new file mode 100644 > > index 000..e49ba43 > > --- /dev/null > > [...] > > +static inline void ena_com_update_intr_reg(struct ena_eth_io_intr_reg > >

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Mon, Jun 20 2016 at 5:28pm -0400, Kani, Toshimitsu wrote: > On Mon, 2016-06-20 at 14:01 -0600, Kani, Toshimitsu wrote: > > On Mon, 2016-06-20 at 15:52 -0400, Mike Snitzer wrote: > > > > > > On Mon, Jun 20 2016 at  3:40pm -0400, > > > Mike Snitzer

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Mon, Jun 20 2016 at 5:28pm -0400, Kani, Toshimitsu wrote: > On Mon, 2016-06-20 at 14:01 -0600, Kani, Toshimitsu wrote: > > On Mon, 2016-06-20 at 15:52 -0400, Mike Snitzer wrote: > > > > > > On Mon, Jun 20 2016 at  3:40pm -0400, > > > Mike Snitzer wrote: > > >   >  : > > > > If I don't use

[patch] mm, compaction: abort free scanner if split fails

If the memory compaction free scanner cannot successfully split a free page (only possible due to per-zone low watermark), terminate the free scanner rather than continuing to scan memory needlessly. If the per-zone watermark is insufficient for a free page of order <= cc->order, then terminate

[patch] mm, compaction: abort free scanner if split fails

If the memory compaction free scanner cannot successfully split a free page (only possible due to per-zone low watermark), terminate the free scanner rather than continuing to scan memory needlessly. If the per-zone watermark is insufficient for a free page of order <= cc->order, then terminate

[GIT PULL 00/10] perf/core improvements and fixes

in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20160620 for you to fetch changes up to 2a0a7c72702bac1b87cd4d49196a334483386fab: perf script: Add stackcollapse.py script (2016-06-20 17:50:39 -0300

Re: kernel-4.7 bug in Intel sound and/or ACPI

On 6/20/2016 5:25 PM, Bjorn Helgaas wrote: > [+cc Sinan] > > On Mon, Jun 20, 2016 at 03:02:57AM +0200, Rafael J. Wysocki wrote: >> You should CC the linux-pci too (done now) >> >> On Monday, June 20, 2016 02:35:30 AM Wim Osterholt wrote: >>> L.S. >>> up to vanilla kernel-4.6.2 sound was working

[GIT PULL 00/10] perf/core improvements and fixes

in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20160620 for you to fetch changes up to 2a0a7c72702bac1b87cd4d49196a334483386fab: perf script: Add stackcollapse.py script (2016-06-20 17:50:39 -0300

Re: kernel-4.7 bug in Intel sound and/or ACPI

On 6/20/2016 5:25 PM, Bjorn Helgaas wrote: > [+cc Sinan] > > On Mon, Jun 20, 2016 at 03:02:57AM +0200, Rafael J. Wysocki wrote: >> You should CC the linux-pci too (done now) >> >> On Monday, June 20, 2016 02:35:30 AM Wim Osterholt wrote: >>> L.S. >>> up to vanilla kernel-4.6.2 sound was working

<    1   2   3   4   5   6   7   8   9   10   >