[PATCH v13 06/12] arch/x86: enable task isolation functionality

In exit_to_usermode_loop(), call task_isolation_ready() for TIF_TASK_ISOLATION tasks when we are checking the thread-info flags, and after we've handled the other work, call task_isolation_enter() for such tasks. In syscall_trace_enter_phase1(), we add the necessary support for reporting syscalls

[PATCH v13 06/12] arch/x86: enable task isolation functionality

In exit_to_usermode_loop(), call task_isolation_ready() for TIF_TASK_ISOLATION tasks when we are checking the thread-info flags, and after we've handled the other work, call task_isolation_enter() for such tasks. In syscall_trace_enter_phase1(), we add the necessary support for reporting syscalls

[PATCH v13 02/12] vmstat: add vmstat_idle function

This function checks to see if a vmstat worker is not running, and the vmstat diffs don't require an update. The function is called from the task-isolation code to see if we need to actually do some work to quiet vmstat. Acked-by: Christoph Lameter Signed-off-by: Chris Metcalf

[PATCH v13 10/12] arm, tile: turn off timer tick for oneshot_stopped state

When the schedule tick is disabled in tick_nohz_stop_sched_tick(), we call hrtimer_cancel(), which eventually calls down into __remove_hrtimer() and thus into hrtimer_force_reprogram(). That function's call to tick_program_event() detects that we are trying to set the expiration to KTIME_MAX and

[PATCH v13 11/12] task_isolation: support CONFIG_TASK_ISOLATION_ALL

This option, similar to NO_HZ_FULL_ALL, simplifies configuring a system to boot by default with all cores except the boot core running in task isolation mode. Signed-off-by: Chris Metcalf --- init/Kconfig | 10 ++ kernel/isolation.c | 6 ++ 2 files

[PATCH v13 07/12] arm64: factor work_pending state machine to C

Currently ret_fast_syscall, work_pending, and ret_to_user form an ad-hoc state machine that can be difficult to reason about due to duplicated code and a large number of branch targets. This patch factors the common logic out into the existing do_notify_resume function, converting the code to C

[PATCH v13 08/12] arch/arm64: enable task isolation functionality

In do_notify_resume(), call task_isolation_ready() for TIF_TASK_ISOLATION tasks when we are checking the thread-info flags; and after we've handled the other work, call task_isolation_enter() for such tasks. To ensure we always call task_isolation_enter() when returning to userspace, add

[PATCH v13 07/12] arm64: factor work_pending state machine to C

Currently ret_fast_syscall, work_pending, and ret_to_user form an ad-hoc state machine that can be difficult to reason about due to duplicated code and a large number of branch targets. This patch factors the common logic out into the existing do_notify_resume function, converting the code to C

[PATCH v13 02/12] vmstat: add vmstat_idle function

This function checks to see if a vmstat worker is not running, and the vmstat diffs don't require an update. The function is called from the task-isolation code to see if we need to actually do some work to quiet vmstat. Acked-by: Christoph Lameter Signed-off-by: Chris Metcalf ---

[PATCH v13 10/12] arm, tile: turn off timer tick for oneshot_stopped state

When the schedule tick is disabled in tick_nohz_stop_sched_tick(), we call hrtimer_cancel(), which eventually calls down into __remove_hrtimer() and thus into hrtimer_force_reprogram(). That function's call to tick_program_event() detects that we are trying to set the expiration to KTIME_MAX and

[PATCH v13 11/12] task_isolation: support CONFIG_TASK_ISOLATION_ALL

This option, similar to NO_HZ_FULL_ALL, simplifies configuring a system to boot by default with all cores except the boot core running in task isolation mode. Signed-off-by: Chris Metcalf --- init/Kconfig | 10 ++ kernel/isolation.c | 6 ++ 2 files changed, 16 insertions(+)

[PATCH v13 08/12] arch/arm64: enable task isolation functionality

In do_notify_resume(), call task_isolation_ready() for TIF_TASK_ISOLATION tasks when we are checking the thread-info flags; and after we've handled the other work, call task_isolation_enter() for such tasks. To ensure we always call task_isolation_enter() when returning to userspace, add

[PATCH v13 04/12] task_isolation: add initial support

The existing nohz_full mode is designed as a "soft" isolation mode that makes tradeoffs to minimize userspace interruptions while still attempting to avoid overheads in the kernel entry/exit path, to provide 100% kernel semantics, etc. However, some applications require a "hard" commitment from

[PATCH v13 04/12] task_isolation: add initial support

The existing nohz_full mode is designed as a "soft" isolation mode that makes tradeoffs to minimize userspace interruptions while still attempting to avoid overheads in the kernel entry/exit path, to provide 100% kernel semantics, etc. However, some applications require a "hard" commitment from

[PATCH v13 12/12] task_isolation: add user-settable notification signal

By default, if a task in task isolation mode re-enters the kernel, it is terminated with SIGKILL. With this commit, the application can choose what signal to receive on a task isolation violation by invoking prctl() with PR_TASK_ISOLATION_ENABLE, or'ing in the PR_TASK_ISOLATION_USERSIG bit, and

[PATCH v13 03/12] lru_add_drain_all: factor out lru_add_drain_needed

This per-cpu check was being done in the loop in lru_add_drain_all(), but having it be callable for a particular cpu is helpful for the task-isolation patches. Signed-off-by: Chris Metcalf --- include/linux/swap.h | 1 + mm/swap.c| 15 ++- 2 files

[PATCH v13 12/12] task_isolation: add user-settable notification signal

By default, if a task in task isolation mode re-enters the kernel, it is terminated with SIGKILL. With this commit, the application can choose what signal to receive on a task isolation violation by invoking prctl() with PR_TASK_ISOLATION_ENABLE, or'ing in the PR_TASK_ISOLATION_USERSIG bit, and

[PATCH v13 03/12] lru_add_drain_all: factor out lru_add_drain_needed

This per-cpu check was being done in the loop in lru_add_drain_all(), but having it be callable for a particular cpu is helpful for the task-isolation patches. Signed-off-by: Chris Metcalf --- include/linux/swap.h | 1 + mm/swap.c| 15 ++- 2 files changed, 11

[PATCH v13 00/12] support "task_isolation" mode

Here is a respin of the task-isolation patch set. This primarily reflects feedback from Frederic and Peter Z. Changes since v12: - Rebased on v4.7-rc7. - New default "strict" model for task isolation - tasks exit the kernel from the initial prctl() to userspace, and can only legally exit

[PATCH v13 00/12] support "task_isolation" mode

Here is a respin of the task-isolation patch set. This primarily reflects feedback from Frederic and Peter Z. Changes since v12: - Rebased on v4.7-rc7. - New default "strict" model for task isolation - tasks exit the kernel from the initial prctl() to userspace, and can only legally exit

Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support

On Tue, Jul 12, 2016 at 3:36 PM, Alan Tull wrote: > Supports Altera SOCFPGA bridges: > * fpga2sdram > * fpga2hps > * hps2fpga > * lwhps2fpga > > Allows enabling/disabling the bridges through the FPGA > Bridge Framework API functions. > > The fpga2sdram driver only

Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support

On Tue, Jul 12, 2016 at 3:36 PM, Alan Tull wrote: > Supports Altera SOCFPGA bridges: > * fpga2sdram > * fpga2hps > * hps2fpga > * lwhps2fpga > > Allows enabling/disabling the bridges through the FPGA > Bridge Framework API functions. > > The fpga2sdram driver only supports enabling and

Re: [RFC 1/3] watchdog: change watchdog_need_worker logic

On Thu, Jul 14, 2016 at 11:16:26AM +0200, Rasmus Villemoes wrote: > If the driver indicates that the watchdog is running, the framework > should feed it until userspace opens the device, regardless of whether > the driver has set max_hw_heartbeat_ms. > > This patch only affects the case where

Re: [RFC 1/3] watchdog: change watchdog_need_worker logic

On Thu, Jul 14, 2016 at 11:16:26AM +0200, Rasmus Villemoes wrote: > If the driver indicates that the watchdog is running, the framework > should feed it until userspace opens the device, regardless of whether > the driver has set max_hw_heartbeat_ms. > > This patch only affects the case where

Re: [PATCH] virtio-net: Remove more stack DMA

From: Andy Lutomirski Date: Thu, 14 Jul 2016 13:21:46 -0700 > On Tue, Jul 12, 2016 at 10:40 AM, David Miller wrote: >> From: Andy Lutomirski >> Date: Mon, 11 Jul 2016 14:30:28 -0700 >> >>> DaveM, is it okay for this to go in via -tip?

Re: [PATCH] virtio-net: Remove more stack DMA

From: Andy Lutomirski Date: Thu, 14 Jul 2016 13:21:46 -0700 > On Tue, Jul 12, 2016 at 10:40 AM, David Miller wrote: >> From: Andy Lutomirski >> Date: Mon, 11 Jul 2016 14:30:28 -0700 >> >>> DaveM, is it okay for this to go in via -tip? >> >> Sure. > > Looks like the series that depends on this

Re: [PATCH v5 01/32] bluetooth: Switch SMP to crypto_cipher_encrypt_one()

From: Andy Lutomirski Date: Thu, 14 Jul 2016 12:10:45 -0700 > On Mon, Jul 11, 2016 at 1:53 PM, Andy Lutomirski wrote: >> SMP does ECB crypto on stack buffers. This is complicated and >> fragile, and it will not work if the stack is virtually allocated. >>

Re: [PATCH v5 01/32] bluetooth: Switch SMP to crypto_cipher_encrypt_one()

From: Andy Lutomirski Date: Thu, 14 Jul 2016 12:10:45 -0700 > On Mon, Jul 11, 2016 at 1:53 PM, Andy Lutomirski wrote: >> SMP does ECB crypto on stack buffers. This is complicated and >> fragile, and it will not work if the stack is virtually allocated. >> >> Switch to the crypto_cipher

Re: [PATCH -v4 2/2] printk: Add kernel parameter to control writes to /dev/kmsg

On Thu, 14 Jul 2016 13:23:23 -0700 Andrew Morton wrote: > On Fri, 8 Jul 2016 11:18:50 +0200 Borislav Petkov wrote: > > > From: Borislav Petkov > > > > Add a "printk.devkmsg" kernel command line parameter which controls how > >

Re: [PATCH -v4 2/2] printk: Add kernel parameter to control writes to /dev/kmsg

On Thu, 14 Jul 2016 13:23:23 -0700 Andrew Morton wrote: > On Fri, 8 Jul 2016 11:18:50 +0200 Borislav Petkov wrote: > > > From: Borislav Petkov > > > > Add a "printk.devkmsg" kernel command line parameter which controls how > > userspace writes into /dev/kmsg. It has three options: > > > >

Re: System freezes after OOM

On Thu, 14 Jul 2016, Michal Hocko wrote: > > It prevents the whole system from livelocking due to an oom killed process > > stalling forever waiting for mempool_alloc() to return. No other threads > > may be oom killed while waiting for it to exit. > > But it is true that the patch has

Re: System freezes after OOM

On Thu, 14 Jul 2016, Michal Hocko wrote: > > It prevents the whole system from livelocking due to an oom killed process > > stalling forever waiting for mempool_alloc() to return. No other threads > > may be oom killed while waiting for it to exit. > > But it is true that the patch has

Re: [PATCH v7 4/9] acpi/arm64: Add GTDT table parse driver

On Wed, Jul 13, 2016 at 1:53 PM, wrote: > From: Fu Wei > > This patch adds support for parsing arch timer in GTDT, > provides some kernel APIs to parse all the PPIs and > always-on info in GTDT and export them. > > By this driver, we can simplify

Re: [PATCH v7 4/9] acpi/arm64: Add GTDT table parse driver

On Wed, Jul 13, 2016 at 1:53 PM, wrote: > From: Fu Wei > > This patch adds support for parsing arch timer in GTDT, > provides some kernel APIs to parse all the PPIs and > always-on info in GTDT and export them. > > By this driver, we can simplify arm_arch_timer drivers, and > separate the ACPI

Re: [PATCH v23 18/22] richacl: xattr mapping functions

On Tue, Jul 12, 2016 at 2:02 PM, Jeff Layton wrote: > On Thu, 2016-06-30 at 15:47 +0200, Andreas Gruenbacher wrote: >> Map between "system.richacl" xattrs and the in-kernel representation. >> >> Signed-off-by: Andreas Gruenbacher >> --- >> fs/Makefile

Re: [PATCH v23 18/22] richacl: xattr mapping functions

On Tue, Jul 12, 2016 at 2:02 PM, Jeff Layton wrote: > On Thu, 2016-06-30 at 15:47 +0200, Andreas Gruenbacher wrote: >> Map between "system.richacl" xattrs and the in-kernel representation. >> >> Signed-off-by: Andreas Gruenbacher >> --- >> fs/Makefile| 2 +- >>

Re: [PATCH v5 01/32] bluetooth: Switch SMP to crypto_cipher_encrypt_one()

Hi Andy, >> SMP does ECB crypto on stack buffers. This is complicated and >> fragile, and it will not work if the stack is virtually allocated. >> >> Switch to the crypto_cipher interface, which is simpler and safer. > > Hi Dave- > > It looks like we're delaying virtually mapped stacks to

Re: [PATCH v5 01/32] bluetooth: Switch SMP to crypto_cipher_encrypt_one()

Hi Andy, >> SMP does ECB crypto on stack buffers. This is complicated and >> fragile, and it will not work if the stack is virtually allocated. >> >> Switch to the crypto_cipher interface, which is simpler and safer. > > Hi Dave- > > It looks like we're delaying virtually mapped stacks to

Re: [PATCH -v4 1/2] ratelimit: Extend to print suppressed messages on release

On Fri, 8 Jul 2016 11:18:49 +0200 Borislav Petkov wrote: > From: Borislav Petkov > > Extend the ratelimiting facility to print the amount of suppressed lines > when it is being released. Why? What's driving this? What are the benefits to our users? Are there

Re: [PATCH -v4 1/2] ratelimit: Extend to print suppressed messages on release

On Fri, 8 Jul 2016 11:18:49 +0200 Borislav Petkov wrote: > From: Borislav Petkov > > Extend the ratelimiting facility to print the amount of suppressed lines > when it is being released. Why? What's driving this? What are the benefits to our users? Are there any downsides or

Re: System freezes after OOM

On Thu, 14 Jul 2016, Tetsuo Handa wrote: > David Rientjes wrote: > > On Wed, 13 Jul 2016, Mikulas Patocka wrote: > > > > > What are the real problems that f9054c70d28bc214b2857cf8db8269f4f45a5e23 > > > tries to fix? > > > > > > > It prevents the whole system from livelocking due to an oom

Re: System freezes after OOM

On Thu, 14 Jul 2016, Tetsuo Handa wrote: > David Rientjes wrote: > > On Wed, 13 Jul 2016, Mikulas Patocka wrote: > > > > > What are the real problems that f9054c70d28bc214b2857cf8db8269f4f45a5e23 > > > tries to fix? > > > > > > > It prevents the whole system from livelocking due to an oom

[PATCH 03/11] 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 03/11] 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 02/11] 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

[PATCH 00/11] x86: misc prep patches for virtually mapped stacks

Hi Ingo- Here are eleven miscellaneous, mostly standalone x86 patches that I pulled from the virtually mapped stack patch set. They're based on 4.7-rc6, and I imagine they apply cleanly on most or all -tip branches. Once these land, I'll see if the THREAD_INFO_IN_TASK stuff splits out cleanly

[PATCH 02/11] 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

[PATCH 00/11] x86: misc prep patches for virtually mapped stacks

Hi Ingo- Here are eleven miscellaneous, mostly standalone x86 patches that I pulled from the virtually mapped stack patch set. They're based on 4.7-rc6, and I imagine they apply cleanly on most or all -tip branches. Once these land, I'll see if the THREAD_INFO_IN_TASK stuff splits out cleanly

[PATCH 07/11] 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 05/11] 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. Reviewed-by: Josh Poimboeuf Signed-off-by: Andy Lutomirski ---

[PATCH 07/11] 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 05/11] 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. Reviewed-by: Josh Poimboeuf Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack_64.c | 12 ++--

[PATCH 04/11] 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. Reviewed-by: Josh Poimboeuf Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack.c | 10 +-

[PATCH 10/11] x86/smp: Remove stack_smp_processor_id()

It serves no purpose -- raw_smp_processor_id() works fine. This change will be needed to move thread_info off the stack. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/cpu.h | 1 - arch/x86/include/asm/smp.h | 6 -- arch/x86/kernel/cpu/common.c | 2 +- 3 files

[PATCH 09/11] x86: Move addr_limit to thread_struct

thread_info is a legacy mess. To prepare for its partial removal, move addr_limit out. As an added benefit, this way is simpler. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/checksum_32.h | 3 +-- arch/x86/include/asm/processor.h | 17 ++---

[PATCH 08/11] x86: Move uaccess_err and sig_on_uaccess_err to thread_struct

thread_info is a legacy mess. To prepare for its partial removal, move the uaccess control fields out -- they're straightforward. Signed-off-by: Andy Lutomirski --- arch/x86/entry/vsyscall/vsyscall_64.c | 6 +++--- arch/x86/include/asm/processor.h | 3 +++

[PATCH 04/11] 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. Reviewed-by: Josh Poimboeuf Signed-off-by: Andy Lutomirski --- arch/x86/kernel/dumpstack.c | 10 +- 1 file changed, 9 insertions(+), 1

[PATCH 10/11] x86/smp: Remove stack_smp_processor_id()

It serves no purpose -- raw_smp_processor_id() works fine. This change will be needed to move thread_info off the stack. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/cpu.h | 1 - arch/x86/include/asm/smp.h | 6 -- arch/x86/kernel/cpu/common.c | 2 +- 3 files changed, 1

[PATCH 09/11] x86: Move addr_limit to thread_struct

thread_info is a legacy mess. To prepare for its partial removal, move addr_limit out. As an added benefit, this way is simpler. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/checksum_32.h | 3 +-- arch/x86/include/asm/processor.h | 17 ++---

[PATCH 08/11] x86: Move uaccess_err and sig_on_uaccess_err to thread_struct

thread_info is a legacy mess. To prepare for its partial removal, move the uaccess control fields out -- they're straightforward. Signed-off-by: Andy Lutomirski --- arch/x86/entry/vsyscall/vsyscall_64.c | 6 +++--- arch/x86/include/asm/processor.h | 3 +++

[PATCH 06/11] x86/mm/64: In vmalloc_fault(), use CR3 instead of current->active_mm

If we get a vmalloc fault while current->active_mm->pgd doesn't match CR3, we'll crash without this change. I've seen this failure mode on heavily instrumented kernels with virtually mapped stacks. Signed-off-by: Andy Lutomirski --- arch/x86/mm/fault.c | 2 +- 1 file changed,

[PATCH 01/11] 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 06/11] x86/mm/64: In vmalloc_fault(), use CR3 instead of current->active_mm

If we get a vmalloc fault while current->active_mm->pgd doesn't match CR3, we'll crash without this change. I've seen this failure mode on heavily instrumented kernels with virtually mapped stacks. Signed-off-by: Andy Lutomirski --- arch/x86/mm/fault.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 01/11] 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

Re: System freezes after OOM

On Thu, 14 Jul 2016, Mikulas Patocka wrote: > > schedule > > schedule_timeout > > io_schedule_timeout > > mempool_alloc > > __split_and_process_bio > > dm_request > > generic_make_request > > submit_bio > > mpage_readpages > > ext4_readpages > > __do_page_cache_readahead > > ra_submit > >

[PATCH 11/11] x86/smp: Remove unnecessary initialization of thread_info::cpu

It's statically initialized to zero -- no need to dynamically initialize it to zero as well. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/smpboot.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index

[PATCH 11/11] x86/smp: Remove unnecessary initialization of thread_info::cpu

It's statically initialized to zero -- no need to dynamically initialize it to zero as well. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/smpboot.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index fafe8b923cac..0e91dbeca2fd

Re: System freezes after OOM

On Thu, 14 Jul 2016, Mikulas Patocka wrote: > > schedule > > schedule_timeout > > io_schedule_timeout > > mempool_alloc > > __split_and_process_bio > > dm_request > > generic_make_request > > submit_bio > > mpage_readpages > > ext4_readpages > > __do_page_cache_readahead > > ra_submit > >

Re: [PATCH] virtio-net: Remove more stack DMA

On Tue, Jul 12, 2016 at 10:40 AM, David Miller wrote: > From: Andy Lutomirski > Date: Mon, 11 Jul 2016 14:30:28 -0700 > >> DaveM, is it okay for this to go in via -tip? > > Sure. Looks like the series that depends on this is getting delayed to 4.9. Could

Re: [PATCH -v4 2/2] printk: Add kernel parameter to control writes to /dev/kmsg

On Fri, 8 Jul 2016 11:18:50 +0200 Borislav Petkov wrote: > From: Borislav Petkov > > Add a "printk.devkmsg" kernel command line parameter which controls how > userspace writes into /dev/kmsg. It has three options: > > * ratelimit - ratelimit logging from

Re: [PATCH] virtio-net: Remove more stack DMA

On Tue, Jul 12, 2016 at 10:40 AM, David Miller wrote: > From: Andy Lutomirski > Date: Mon, 11 Jul 2016 14:30:28 -0700 > >> DaveM, is it okay for this to go in via -tip? > > Sure. Looks like the series that depends on this is getting delayed to 4.9. Could you queue this patch for net-next

Re: [PATCH -v4 2/2] printk: Add kernel parameter to control writes to /dev/kmsg

On Fri, 8 Jul 2016 11:18:50 +0200 Borislav Petkov wrote: > From: Borislav Petkov > > Add a "printk.devkmsg" kernel command line parameter which controls how > userspace writes into /dev/kmsg. It has three options: > > * ratelimit - ratelimit logging from userspace. > * on - unlimited

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

Quoting Kees Cook (keesc...@chromium.org): > On Thu, Jul 14, 2016 at 10:49 AM, Serge E. Hallyn wrote: > > Kees, you said adding a capability is hard - can you expound on that? > > Best I can find at the moment was discussion around CAP_COMPROMISE_KERNEL: >

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

Quoting Kees Cook (keesc...@chromium.org): > On Thu, Jul 14, 2016 at 10:49 AM, Serge E. Hallyn wrote: > > Kees, you said adding a capability is hard - can you expound on that? > > Best I can find at the moment was discussion around CAP_COMPROMISE_KERNEL: >

Re: [RESEND PATCH v3] mtd: spi-nor: Add support for S3AN spi-nor devices

Hi Brian: On Thu, Jul 14, 2016 at 8:07 PM, Brian Norris wrote:) > > > This still doesn't apply to l2-mtd.git / linux-next.git. If I get time, > I'll see how easily I can fix that up myself. v3 was from May 11. I have just updated a V4 rebased over l2-mtd/master.

Re: [RESEND PATCH v3] mtd: spi-nor: Add support for S3AN spi-nor devices

Hi Brian: On Thu, Jul 14, 2016 at 8:07 PM, Brian Norris wrote:) > > > This still doesn't apply to l2-mtd.git / linux-next.git. If I get time, > I'll see how easily I can fix that up myself. v3 was from May 11. I have just updated a V4 rebased over l2-mtd/master. Thanks -- Ricardo Ribalda

Re: [PATCH 3.12 00/88] 3.12.62-stable review

On Thu, Jul 14, 2016 at 10:16:06AM +0200, Jiri Slaby wrote: > This is the start of the stable review cycle for the 3.12.62 release. > There are 88 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > >

Re: [PATCH 3.12 00/88] 3.12.62-stable review

On Thu, Jul 14, 2016 at 10:16:06AM +0200, Jiri Slaby wrote: > This is the start of the stable review cycle for the 3.12.62 release. > There are 88 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > >

[PATCH v4] mtd: spi-nor: Add support for S3AN spi-nor devices

Xilinx Spartan-3AN FPGAs contain an In-System Flash where they keep their configuration data and (optionally) some user data. The protocol of this flash follows most of the spi-nor standard. With the following differences: - Page size might not be a power of two. - The address calculation

[PATCH v4] mtd: spi-nor: Add support for S3AN spi-nor devices

Xilinx Spartan-3AN FPGAs contain an In-System Flash where they keep their configuration data and (optionally) some user data. The protocol of this flash follows most of the spi-nor standard. With the following differences: - Page size might not be a power of two. - The address calculation

Re: [PATCH 0/3] rtc: remove intersil isl12057

Hi Alexandre, Alexandre Belloni writes: > This is the series I intend to apply once you confirm my previous patch > is working. For previous patch and that series, once the typos are fixed: Acked-by: Arnaud Ebalard Thanks for spotting

Re: [PATCH 0/3] rtc: remove intersil isl12057

Hi Alexandre, Alexandre Belloni writes: > This is the series I intend to apply once you confirm my previous patch > is working. For previous patch and that series, once the typos are fixed: Acked-by: Arnaud Ebalard Thanks for spotting the duplication and your work. Cheers, a+ > >

[PATCH v2] ARM: dts: NSP: Correct RAM amount for BCM958625HR board

The BCM958625HR board has 2GB of RAM available. Increase the amount from 512MB to 2GB and add the device type to the memory entry. Fixes: 9a4865d42fe5 ("ARM: dts: NSP: Specify RAM amount for BCM958625HR board") Signed-off-by: Jon Mason ---

[PATCH v2] ARM: dts: NSP: Correct RAM amount for BCM958625HR board

The BCM958625HR board has 2GB of RAM available. Increase the amount from 512MB to 2GB and add the device type to the memory entry. Fixes: 9a4865d42fe5 ("ARM: dts: NSP: Specify RAM amount for BCM958625HR board") Signed-off-by: Jon Mason --- arch/arm/boot/dts/bcm958625hr.dts | 3 ++- 1 file

Re: [PATCH 1/3] Documentation: dt: Intersil isl12057 is not a trivial device

Hello, Alexandre Belloni writes: > The ISL12057 has a documentation file, remove it from trivial-devices.txt > > Signed-off-by: Alexandre Belloni > --- > Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 -

Re: [PATCH 1/3] Documentation: dt: Intersil isl12057 is not a trivial device

Hello, Alexandre Belloni writes: > The ISL12057 has a documentation file, remove it from trivial-devices.txt > > Signed-off-by: Alexandre Belloni > --- > Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 - > 1 file changed, 1 deletion(-) > > diff --git

[PATCH] media: s5p-jpeg add missing blank lines after declarations

Missing blank lines after declarations are making it hard to read the code. Fix them and also fix other checkpatch warnings at the same time. Signed-off-by: Shuah Khan --- drivers/media/platform/s5p-jpeg/jpeg-core.c | 13 ++--- 1 file changed, 10 insertions(+),

Re: [PATCH v23 13/22] vfs: Cache richacl in struct inode

On Wed, Jul 6, 2016 at 8:57 PM, Jeff Layton wrote: > On Thu, 2016-06-30 at 15:47 +0200, Andreas Gruenbacher wrote: >> Cache richacls in struct inode so that this doesn't have to be done >> individually in each filesystem. This is similar to POSIX ACLs. >> >> Signed-off-by:

Re: [PATCH] rtc: ds1307: fix century bit support

Hi Alexandre, Alexandre Belloni writes: > Add an option to properly support the century bit of ds1337 and compatibles > and ds1340. > Because the driver had a bug until now, it is not possible to switch users > to the fixed code directly as RTCs in the

Re: [PATCH 2/3] rtc: ds1307: add Intersil ISL12057 support

Alexandre Belloni writes: > Intersil ISL12057 is a drop-in replacement for DS1337. It can be supported > by the ds1307 driver. > > Signed-off-by: Alexandre Belloni > --- > drivers/rtc/Kconfig | 8 >

[PATCH] media: s5p-jpeg add missing blank lines after declarations

Missing blank lines after declarations are making it hard to read the code. Fix them and also fix other checkpatch warnings at the same time. Signed-off-by: Shuah Khan --- drivers/media/platform/s5p-jpeg/jpeg-core.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff

Re: [PATCH v23 13/22] vfs: Cache richacl in struct inode

On Wed, Jul 6, 2016 at 8:57 PM, Jeff Layton wrote: > On Thu, 2016-06-30 at 15:47 +0200, Andreas Gruenbacher wrote: >> Cache richacls in struct inode so that this doesn't have to be done >> individually in each filesystem. This is similar to POSIX ACLs. >> >> Signed-off-by: Andreas Gruenbacher

Re: [PATCH] rtc: ds1307: fix century bit support

Hi Alexandre, Alexandre Belloni writes: > Add an option to properly support the century bit of ds1337 and compatibles > and ds1340. > Because the driver had a bug until now, it is not possible to switch users > to the fixed code directly as RTCs in the field will wrongly have the > century bit

Re: [PATCH 2/3] rtc: ds1307: add Intersil ISL12057 support

Alexandre Belloni writes: > Intersil ISL12057 is a drop-in replacement for DS1337. It can be supported > by the ds1307 driver. > > Signed-off-by: Alexandre Belloni > --- > drivers/rtc/Kconfig | 8 > drivers/rtc/rtc-ds1307.c | 6 ++ > 2 files changed, 10 insertions(+), 4

[PATCH] media: Doc add missing documentation for samsung,exynos4212-jpeg

Add add missing documentation for samsung,exynos4212-jpeg codec, reorder entries to improve readability and make it easier to add new entries. Signed-off-by: Shuah Khan --- Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt | 6 +++--- 1 file changed, 3

[PATCH] media: Doc add missing documentation for samsung,exynos4212-jpeg

Add add missing documentation for samsung,exynos4212-jpeg codec, reorder entries to improve readability and make it easier to add new entries. Signed-off-by: Shuah Khan --- Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

Re: [PATCH] security: Use IS_ENABLED() instead of checking for built-in or module

On Thu, Jul 14, 2016 at 12:30 PM, Casey Schaufler wrote: > On 7/14/2016 9:20 AM, Javier Martinez Canillas wrote: >> Hello Casey, >> >> On 07/14/2016 12:17 PM, Casey Schaufler wrote: >>> On 7/14/2016 9:00 AM, Javier Martinez Canillas wrote: The IS_ENABLED() macro

Re: [PATCH] security: Use IS_ENABLED() instead of checking for built-in or module

On Thu, Jul 14, 2016 at 12:30 PM, Casey Schaufler wrote: > On 7/14/2016 9:20 AM, Javier Martinez Canillas wrote: >> Hello Casey, >> >> On 07/14/2016 12:17 PM, Casey Schaufler wrote: >>> On 7/14/2016 9:00 AM, Javier Martinez Canillas wrote: The IS_ENABLED() macro checks if a Kconfig symbol

Re: [RFC][PATCH] proc: Relax /proc//timerslack_ns capability requirements

On Thu, Jul 14, 2016 at 11:50 AM, John Stultz wrote: > When an interface to allow a task to change another tasks > timerslack was first proposed, it was suggested that something > greater then CAP_SYS_NICE would be needed, as a task could be > delayed further then what

Re: [RFC][PATCH] proc: Relax /proc//timerslack_ns capability requirements

On Thu, Jul 14, 2016 at 11:50 AM, John Stultz wrote: > When an interface to allow a task to change another tasks > timerslack was first proposed, it was suggested that something > greater then CAP_SYS_NICE would be needed, as a task could be > delayed further then what normally could be done with

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