Re: [PATCH v2 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks

Hi Will, On 2018/1/5 21:12, Will Deacon wrote: > diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c > index 5f7097d0cd12..d99b36555a16 100644 > --- a/arch/arm64/mm/context.c > +++ b/arch/arm64/mm/context.c > @@ -246,6 +246,8 @@ asmlinkage void post_ttbr_update_workaround(void) >

Re: [PATCH v2 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks

Hi Will, On 2018/1/5 21:12, Will Deacon wrote: > diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c > index 5f7097d0cd12..d99b36555a16 100644 > --- a/arch/arm64/mm/context.c > +++ b/arch/arm64/mm/context.c > @@ -246,6 +246,8 @@ asmlinkage void post_ttbr_update_workaround(void) >

Re: [PATCH] ARM: make memzero optimization smarter

On Tue, 16 Jan 2018, Arnd Bergmann wrote: > On Tue, Jan 16, 2018 at 6:10 PM, Nicolas Pitre > wrote: > > On Tue, 16 Jan 2018, Arnd Bergmann wrote: > > > >> However, we can avoid this class of bogus warnings for the memset() macro > >> by only doing the

Re: [PATCH] ARM: make memzero optimization smarter

On Tue, 16 Jan 2018, Arnd Bergmann wrote: > On Tue, Jan 16, 2018 at 6:10 PM, Nicolas Pitre > wrote: > > On Tue, 16 Jan 2018, Arnd Bergmann wrote: > > > >> However, we can avoid this class of bogus warnings for the memset() macro > >> by only doing the micro-optimization for zero-length

Re: [PATCH] sparse doesn't support struct randomization

On Tue, Jan 16, 2018 at 6:45 PM, Matthew Wilcox wrote: > From: Matthew Wilcox > > Without this patch, I drown in a sea of unknown attribute warnings > > Signed-off-by: Matthew Wilcox Thanks! Acked-by: Kees Cook

Re: [PATCH] sparse doesn't support struct randomization

On Tue, Jan 16, 2018 at 6:45 PM, Matthew Wilcox wrote: > From: Matthew Wilcox > > Without this patch, I drown in a sea of unknown attribute warnings > > Signed-off-by: Matthew Wilcox Thanks! Acked-by: Kees Cook Andrew, are you able to take this? I have no other gcc-plugin changes pending

Re: [PATCH v6 5/5] kaslr: add kaslr_mem=nn[KMG]!ss[KMG] to avoid memory regions

On 01/16/18 at 11:34am, Luiz Capitulino wrote: > On Tue, 16 Jan 2018 08:43:20 +0800 > Baoquan He wrote: > > > On 01/15/18 at 08:49pm, Chao Fan wrote: > > > Hi Luiz, > > > > > > I don't know if this patch is OK for you. > > > Of coure you can only use kaslr_mem=nn@ss to solve

Re: [PATCH v6 5/5] kaslr: add kaslr_mem=nn[KMG]!ss[KMG] to avoid memory regions

On 01/16/18 at 11:34am, Luiz Capitulino wrote: > On Tue, 16 Jan 2018 08:43:20 +0800 > Baoquan He wrote: > > > On 01/15/18 at 08:49pm, Chao Fan wrote: > > > Hi Luiz, > > > > > > I don't know if this patch is OK for you. > > > Of coure you can only use kaslr_mem=nn@ss to solve the 1G huge page >

Re: [PATCH V4 12/15] perf hists browser: add parameter to disable lost event warning

Hi, On Mon, Jan 15, 2018 at 12:20:48PM -0800, kan.li...@intel.com wrote: > From: Kan Liang > > For overwrite mode, the ringbuffer will be paused. The event lost is > expected. It needs a way to notify the browser not print the warning. > > It will be used later for perf

Re: [PATCH V4 12/15] perf hists browser: add parameter to disable lost event warning

Hi, On Mon, Jan 15, 2018 at 12:20:48PM -0800, kan.li...@intel.com wrote: > From: Kan Liang > > For overwrite mode, the ringbuffer will be paused. The event lost is > expected. It needs a way to notify the browser not print the warning. > > It will be used later for perf top to disable lost

Re: [PATCHv<8> 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite

Hi Ong, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on v4.15-rc8 next-20180116] [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

Re: [PATCHv<8> 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite

Hi Ong, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on v4.15-rc8 next-20180116] [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

Re: [PATCH 2/2] blk-mq: simplify queue mapping & schedule with each possisble CPU

Hi Jianchao, On Wed, Jan 17, 2018 at 10:56:13AM +0800, jianchao.wang wrote: > Hi ming > > Thanks for your patch and kindly response. You are welcome! > > On 01/16/2018 11:32 PM, Ming Lei wrote: > > OK, I got it, and it should have been the only corner case in which > > all CPUs mapped to this

Re: [PATCH 2/2] blk-mq: simplify queue mapping & schedule with each possisble CPU

Hi Jianchao, On Wed, Jan 17, 2018 at 10:56:13AM +0800, jianchao.wang wrote: > Hi ming > > Thanks for your patch and kindly response. You are welcome! > > On 01/16/2018 11:32 PM, Ming Lei wrote: > > OK, I got it, and it should have been the only corner case in which > > all CPUs mapped to this

[PATCH] mm/page_poison: Make early_page_poison_param __init

The early_param() is only called during kernel initialization, So Linux marks the function of it with __init macro to save memory. But it forgot to mark the early_page_poison_param(). So, Make it __init as well. Cc: Andrew Morton Cc: Philippe Ombredanne

[PATCH] mm/page_owner: Make early_page_owner_param __init

The early_param() is only called during kernel initialization, So Linux marks the functions of it with __init macro to save memory. But it forgot to mark the early_page_owner_param(). So, Make it __init as well. Cc: Andrew Morton Cc: Vlastimil Babka

[PATCH] Bluetooth: 6lowpan: Fix disconnect bug in 6lowpan

This patch fix the bluetooth 6lowpan disconnect fail bug. The type of the same address type have different define value in HCI layer and L2CAP layer.That makes disconnect fail due to wrong network type.User will not be able to disconnect from console with the network type that used in connect.

linux-next: manual merge of the kvm tree with Linus' tree

Hi all, [This is the same conflict I reported the day before yesterday, but one of the commits has moved and another that contributed has been dropped.] Today's linux-next merge of the kvm tree got a conflict in: arch/x86/include/asm/cpufeatures.h between commits: a89f040fa34e

[PATCH] mm/page_poison: Make early_page_poison_param __init

The early_param() is only called during kernel initialization, So Linux marks the function of it with __init macro to save memory. But it forgot to mark the early_page_poison_param(). So, Make it __init as well. Cc: Andrew Morton Cc: Philippe Ombredanne Cc: Kate Stewart Cc: Michal Hocko Cc:

[PATCH] mm/page_owner: Make early_page_owner_param __init

The early_param() is only called during kernel initialization, So Linux marks the functions of it with __init macro to save memory. But it forgot to mark the early_page_owner_param(). So, Make it __init as well. Cc: Andrew Morton Cc: Vlastimil Babka Cc: Michal Hocko Cc: Greg Kroah-Hartman

[PATCH] Bluetooth: 6lowpan: Fix disconnect bug in 6lowpan

This patch fix the bluetooth 6lowpan disconnect fail bug. The type of the same address type have different define value in HCI layer and L2CAP layer.That makes disconnect fail due to wrong network type.User will not be able to disconnect from console with the network type that used in connect.

linux-next: manual merge of the kvm tree with Linus' tree

Hi all, [This is the same conflict I reported the day before yesterday, but one of the commits has moved and another that contributed has been dropped.] Today's linux-next merge of the kvm tree got a conflict in: arch/x86/include/asm/cpufeatures.h between commits: a89f040fa34e

[PATCH] mm/kmemleak: Make kmemleak_boot_config __init

The early_param() is only called during kernel initialization, So Linux marks the functions of it with __init macro to save memory. But it forgot to mark the kmemleak_boot_config(). So, Make it __init as well. Cc: Catalin Marinas Cc: Andrew Morton

[PATCH] mm/kmemleak: Make kmemleak_boot_config __init

The early_param() is only called during kernel initialization, So Linux marks the functions of it with __init macro to save memory. But it forgot to mark the kmemleak_boot_config(). So, Make it __init as well. Cc: Catalin Marinas Cc: Andrew Morton Cc: linux...@kvack.org Signed-off-by: Dou

[PATCH] x86/kvm: Make parse_no_xxx __init for kvm

The early_param() is only called during kernel initialization, So Linux marks the functions of it with __init macro to save memory. But it forgot to mark the parse_no_kvmapf/stealacc/kvmclock_vsyscall, So, Make them __init as well. Cc: Paolo Bonzini Cc: rkrc...@redhat.com

[PATCH] x86/kvm: Make parse_no_xxx __init for kvm

The early_param() is only called during kernel initialization, So Linux marks the functions of it with __init macro to save memory. But it forgot to mark the parse_no_kvmapf/stealacc/kvmclock_vsyscall, So, Make them __init as well. Cc: Paolo Bonzini Cc: rkrc...@redhat.com Cc:

[PATCH] x86/x2apic: Make set_x2apic_phys_mode __init

The early_param() is only called during kernel initialization, So Linux marks the functions of it with __init macro to save memory. But it forgot to mark set_x2apic_phys_mode(). So, Make it __init as well. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter

[PATCH] x86/x2apic: Make set_x2apic_phys_mode __init

The early_param() is only called during kernel initialization, So Linux marks the functions of it with __init macro to save memory. But it forgot to mark set_x2apic_phys_mode(). So, Make it __init as well. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Juergen Gross Cc:

[PATCH] tile/pci_gx: Make setup_pcie_rc_delay __init

The early_param() is only called during kernel initialization, So Linux marks the functions of it with __init macro to save memory. But it forgot to mark setup_pcie_rc_delay(). So, Make it __init as well. Cc: Bjorn Helgaas Cc: Palmer Dabbelt Cc: Chris

[PATCH] tile/pci_gx: Make setup_pcie_rc_delay __init

The early_param() is only called during kernel initialization, So Linux marks the functions of it with __init macro to save memory. But it forgot to mark setup_pcie_rc_delay(). So, Make it __init as well. Cc: Bjorn Helgaas Cc: Palmer Dabbelt Cc: Chris Metcalf Cc: Andrew Morton Signed-off-by:

[PATCH] Documentation: Fix misconversion of #if

From: Matthew Wilcox At some stage of the conversion pipeline, something thought that the DocBook entity should be rendered as NUM instead of #. Signed-off-by: Matthew Wilcox --- Documentation/kernel-hacking/hacking.rst | 4 ++-- 1 file

[PATCH] Documentation: Fix misconversion of #if

From: Matthew Wilcox At some stage of the conversion pipeline, something thought that the DocBook entity should be rendered as NUM instead of #. Signed-off-by: Matthew Wilcox --- Documentation/kernel-hacking/hacking.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 3/3] arm64: Add work around for Arm Cortex-A55 Erratum 1024718

On 2018-01-16 02:23, Suzuki K Poulose wrote: Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer from an erratum 1024718, which causes incorrect updates when DBM/AP bits in a page table entry is modified without a break-before-make sequence. The work around is to disable the

Re: [PATCH 3/3] arm64: Add work around for Arm Cortex-A55 Erratum 1024718

On 2018-01-16 02:23, Suzuki K Poulose wrote: Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer from an erratum 1024718, which causes incorrect updates when DBM/AP bits in a page table entry is modified without a break-before-make sequence. The work around is to disable the

Re: [PATCH v2] powerpc/mm: Fix growth direction for hugepages mmaps with slice

On 01/16/2018 10:18 PM, Christophe LEROY wrote: Le 16/01/2018 à 17:03, Aneesh Kumar K.V a écrit : Christophe Leroy writes: An application running with libhugetlbfs fails to allocate additional pages to HEAP due to the hugemap being done inconditionally as topdown

Re: [PATCH v2] fs: Add VirtualBox guest shared folder (vboxsf) support

On Tue, Jan 16, 2018 at 11:15:15AM +0100, Hans de Goede wrote: > > * your ->rename() can race with ->get_link(). Look at the place where > >the former reassigns ->path and frees the old value and think what > >happens if the latter is called just prior to that kfree(). > > > > * the same

Re: [PATCH v2] powerpc/mm: Fix growth direction for hugepages mmaps with slice

On 01/16/2018 10:18 PM, Christophe LEROY wrote: Le 16/01/2018 à 17:03, Aneesh Kumar K.V a écrit : Christophe Leroy writes: An application running with libhugetlbfs fails to allocate additional pages to HEAP due to the hugemap being done inconditionally as topdown mapping:

Re: [PATCH v2] fs: Add VirtualBox guest shared folder (vboxsf) support

On Tue, Jan 16, 2018 at 11:15:15AM +0100, Hans de Goede wrote: > > * your ->rename() can race with ->get_link(). Look at the place where > >the former reassigns ->path and frees the old value and think what > >happens if the latter is called just prior to that kfree(). > > > > * the same

Re: [PATCH v2] mkfs.f2fs: expand scalability of nat bitmap

Hi Jaegeuk, On 2018/1/17 8:47, Jaegeuk Kim wrote: > Hi Chao, > > On 01/15, Chao Yu wrote: >> Previously, our total node number (nat_bitmap) and total nat segment count >> will not monotonously increase along with image size, and max nat_bitmap size >> is limited by "CHECKSUM_OFFSET -

Re: [PATCH v2] mkfs.f2fs: expand scalability of nat bitmap

Hi Jaegeuk, On 2018/1/17 8:47, Jaegeuk Kim wrote: > Hi Chao, > > On 01/15, Chao Yu wrote: >> Previously, our total node number (nat_bitmap) and total nat segment count >> will not monotonously increase along with image size, and max nat_bitmap size >> is limited by "CHECKSUM_OFFSET -

Re: [PATCH v2 11/10] objtool: Even more complex static block checks

On Tue, Jan 16, 2018 at 08:49:17PM +0100, Peter Zijlstra wrote: > Subject: objtool: Even more complex static block checks > From: Peter Zijlstra > Date: Tue Jan 16 20:17:01 CET 2018 > > I've observed GCC transform: > > f() > { > if (!static_branch_unlikely()) >

Re: [PATCH v2 11/10] objtool: Even more complex static block checks

On Tue, Jan 16, 2018 at 08:49:17PM +0100, Peter Zijlstra wrote: > Subject: objtool: Even more complex static block checks > From: Peter Zijlstra > Date: Tue Jan 16 20:17:01 CET 2018 > > I've observed GCC transform: > > f() > { > if (!static_branch_unlikely()) >

Re: [PATCH v2 10/10] objtool: More complex static jump implementation

On Tue, Jan 16, 2018 at 03:28:35PM +0100, Peter Zijlstra wrote: > When using something like: > > -#define sched_feat(x) > (static_branch_##x(_feat_keys[__SCHED_FEAT_##x])) > +#define sched_feat(x) > (static_branch_##x(_feat_keys[__SCHED_FEAT_##x]) && \ > +

Re: [PATCH v2 10/10] objtool: More complex static jump implementation

On Tue, Jan 16, 2018 at 03:28:35PM +0100, Peter Zijlstra wrote: > When using something like: > > -#define sched_feat(x) > (static_branch_##x(_feat_keys[__SCHED_FEAT_##x])) > +#define sched_feat(x) > (static_branch_##x(_feat_keys[__SCHED_FEAT_##x]) && \ > +

Re: [PATCH v6 03/24] mm: Dont assume page-table invariance during faults

Laurent Dufour writes: > From: Peter Zijlstra > > One of the side effects of speculating on faults (without holding > mmap_sem) is that we can race with free_pgtables() and therefore we > cannot assume the page-tables will stick around. > >

Re: [PATCH v6 03/24] mm: Dont assume page-table invariance during faults

Laurent Dufour writes: > From: Peter Zijlstra > > One of the side effects of speculating on faults (without holding > mmap_sem) is that we can race with free_pgtables() and therefore we > cannot assume the page-tables will stick around. > > Remove the reliance on the pte pointer. This needs a

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

On Wed, Jan 17, 2018 at 12:55:37PM +1100, Stephen Rothwell wrote: > Hi all, > > On Wed, 17 Jan 2018 12:51:45 +1100 Stephen Rothwell > wrote: > > > > diff --cc drivers/infiniband/hw/mlx5/qp.c > > index cffe5966aef9,ae36db3d0deb.. > > +++

Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree

On Wed, Jan 17, 2018 at 12:55:37PM +1100, Stephen Rothwell wrote: > Hi all, > > On Wed, 17 Jan 2018 12:51:45 +1100 Stephen Rothwell > wrote: > > > > diff --cc drivers/infiniband/hw/mlx5/qp.c > > index cffe5966aef9,ae36db3d0deb.. > > +++ b/drivers/infiniband/hw/mlx5/qp.c > > @@@

Re: [PATCH V2 01/10] clk: clk-divider: add CLK_DIVIDER_ZERO_GATE clk support

On Thu, Dec 21, 2017 at 05:24:01PM -0800, Stephen Boyd wrote: > On 12/20, Dong Aisheng wrote: > > On Thu, Nov 02, 2017 at 12:50:39AM -0700, Stephen Boyd wrote: > > > On 07/13, Dong Aisheng wrote: > > > > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c > > > > index

Re: [PATCH V2 01/10] clk: clk-divider: add CLK_DIVIDER_ZERO_GATE clk support

On Thu, Dec 21, 2017 at 05:24:01PM -0800, Stephen Boyd wrote: > On 12/20, Dong Aisheng wrote: > > On Thu, Nov 02, 2017 at 12:50:39AM -0700, Stephen Boyd wrote: > > > On 07/13, Dong Aisheng wrote: > > > > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c > > > > index

Re: [PATCH v3 06/20] arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN

Hi Will, On 2017/12/6 20:35, Will Deacon wrote: > config ARM64_SW_TTBR0_PAN > bool "Emulate Privileged Access Never using TTBR0_EL1 switching" > - depends on BROKEN # Temporary while switch_mm is reworked > help > Enabling this option prevents the kernel from

Re: [PATCH v3 06/20] arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN

Hi Will, On 2017/12/6 20:35, Will Deacon wrote: > config ARM64_SW_TTBR0_PAN > bool "Emulate Privileged Access Never using TTBR0_EL1 switching" > - depends on BROKEN # Temporary while switch_mm is reworked > help > Enabling this option prevents the kernel from

Re: [RFC PATCH V1 2/2] clk: add lock for clk_core_is_enabled

On Tue, Dec 26, 2017 at 05:29:18PM -0800, Stephen Boyd wrote: > On 12/22, Dong Aisheng wrote: > > According to design doc, .is_enabled should be protected by enable lock. > > Then users don't have to protect it against enable/disable operation > > in clock drivers. > > > > See:

Re: [RFC PATCH V1 2/2] clk: add lock for clk_core_is_enabled

On Tue, Dec 26, 2017 at 05:29:18PM -0800, Stephen Boyd wrote: > On 12/22, Dong Aisheng wrote: > > According to design doc, .is_enabled should be protected by enable lock. > > Then users don't have to protect it against enable/disable operation > > in clock drivers. > > > > See:

Re: [PATCH 2/2] blk-mq: simplify queue mapping & schedule with each possisble CPU

Hi ming Thanks for your patch and kindly response. On 01/16/2018 11:32 PM, Ming Lei wrote: > OK, I got it, and it should have been the only corner case in which > all CPUs mapped to this hctx become offline, and I believe the following > patch should address this case, could you give a test? >

Re: [PATCH 2/2] blk-mq: simplify queue mapping & schedule with each possisble CPU

Hi ming Thanks for your patch and kindly response. On 01/16/2018 11:32 PM, Ming Lei wrote: > OK, I got it, and it should have been the only corner case in which > all CPUs mapped to this hctx become offline, and I believe the following > patch should address this case, could you give a test? >

[PATCH 1/5] powerpc/vas: Remove a stray line in Makefile

Remove a bogus line from arch/powerpc/platforms/powernv/Makefile that was added by commit ece4e51 ("powerpc/vas: Export HVWC to debugfs"). Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH 1/5] powerpc/vas: Remove a stray line in Makefile

Remove a bogus line from arch/powerpc/platforms/powernv/Makefile that was added by commit ece4e51 ("powerpc/vas: Export HVWC to debugfs"). Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH 3/5] powerpc/ftw: Implement a simple FTW driver

The Fast Thread Wake-up (FTW) driver provides user space applications an interface to the low latency Core-to-Core wakeup functionality in POWER9. This mechanism allows a thread on one core to efficiently send a message to a "waiting thread" on another core on the same chip, using the Virtual

[PATCH 3/5] powerpc/ftw: Implement a simple FTW driver

The Fast Thread Wake-up (FTW) driver provides user space applications an interface to the low latency Core-to-Core wakeup functionality in POWER9. This mechanism allows a thread on one core to efficiently send a message to a "waiting thread" on another core on the same chip, using the Virtual

[PATCH 4/5] powerpc/ftw: Add a couple of trace points

Add a couple of trace points in the FTW driver Signed-off-by: Sukadev Bhattiprolu --- drivers/misc/ftw/ftw-trace.h | 75 drivers/misc/ftw/ftw.c | 6 2 files changed, 81 insertions(+) create mode 100644

[PATCH 4/5] powerpc/ftw: Add a couple of trace points

Add a couple of trace points in the FTW driver Signed-off-by: Sukadev Bhattiprolu --- drivers/misc/ftw/ftw-trace.h | 75 drivers/misc/ftw/ftw.c | 6 2 files changed, 81 insertions(+) create mode 100644 drivers/misc/ftw/ftw-trace.h diff

[PATCH 5/5] powerpc/ftw: Document FTW API/usage

Document the usage of the VAS Fast thread-wakeup API and add an entry in MAINTAINERS file. Thanks for input/comments from Benjamin Herrenschmidt, Michael Neuling, Michael Ellerman, Robert Blackmore, Ian Munsie, Haren Myneni and Paul Mackerras. Signed-off-by: Sukadev Bhattiprolu

[PATCH 5/5] powerpc/ftw: Document FTW API/usage

Document the usage of the VAS Fast thread-wakeup API and add an entry in MAINTAINERS file. Thanks for input/comments from Benjamin Herrenschmidt, Michael Neuling, Michael Ellerman, Robert Blackmore, Ian Munsie, Haren Myneni and Paul Mackerras. Signed-off-by: Sukadev Bhattiprolu ---

[PATCH 2/5] powerpc/ftw: Define FTW_SETUP ioctl API

Define the FTW_SETUP ioctl interface for fast thread wakeup (FTW). A follow-on patch will implement the FTW driver and ioctl. Thanks to input from Ben Herrenschmidt, Michael Neuling, Michael Ellerman. Signed-off-by: Sukadev Bhattiprolu --- Changelog[v2] -

[PATCH 2/5] powerpc/ftw: Define FTW_SETUP ioctl API

Define the FTW_SETUP ioctl interface for fast thread wakeup (FTW). A follow-on patch will implement the FTW driver and ioctl. Thanks to input from Ben Herrenschmidt, Michael Neuling, Michael Ellerman. Signed-off-by: Sukadev Bhattiprolu --- Changelog[v2] - [Michael Neuling] Use a single

[PATCH 0/5] Implement FTW driver

The Virtual Accelerator Switchboard (VAS) subsystem in the POWER9 processor provides a low latency Core-to-core wakeup" mechanism which allows a thread on one core the processor to efficiently send a message to a thread waiting on another core. This Fast thread-wakeup (FTW) driver provides user

[PATCH 0/5] Implement FTW driver

The Virtual Accelerator Switchboard (VAS) subsystem in the POWER9 processor provides a low latency Core-to-core wakeup" mechanism which allows a thread on one core the processor to efficiently send a message to a thread waiting on another core. This Fast thread-wakeup (FTW) driver provides user

Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack

On 01/16/2018 11:36 AM, Joerg Roedel wrote: /* + * Switch from the entry-trampline stack to the kernel stack of the + * running task. + * + * nr_regs is the number of dwords to push from the entry stack to the + * task stack. If it is > 0 it expects an irq frame at the bottom of the + *

Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack

On 01/16/2018 11:36 AM, Joerg Roedel wrote: /* + * Switch from the entry-trampline stack to the kernel stack of the + * running task. + * + * nr_regs is the number of dwords to push from the entry stack to the + * task stack. If it is > 0 it expects an irq frame at the bottom of the + *

[PATCH] sparse doesn't support struct randomization

From: Matthew Wilcox Without this patch, I drown in a sea of unknown attribute warnings Signed-off-by: Matthew Wilcox --- include/linux/compiler-gcc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] sparse doesn't support struct randomization

From: Matthew Wilcox Without this patch, I drown in a sea of unknown attribute warnings Signed-off-by: Matthew Wilcox --- include/linux/compiler-gcc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h index

Re: [PATCH v3 0/3] tracing: Fix the parser when processing strings w/ or w/o terminated '\0'

On Tue, Jan 16, 2018 at 05:02:27PM +0800, changbin...@intel.com wrote: > From: Changbin Du > > I found there are some problems in the tracing parser when I investiage the > root > cause of issues mentioned in below patch. > https://patchwork.kernel.org/patch/10132953/ >

linux-next: manual merge of the block tree with the dma-mapping tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: lib/Kconfig between commit: 002e67454f61 ("dma-direct: rename dma_noop to dma_direct") from the dma-mapping tree and commit: e80a0af4759a ("lib/scatterlist: Introduce sgl_alloc() and sgl_free()") from the block

Re: [PATCH v3 0/3] tracing: Fix the parser when processing strings w/ or w/o terminated '\0'

On Tue, Jan 16, 2018 at 05:02:27PM +0800, changbin...@intel.com wrote: > From: Changbin Du > > I found there are some problems in the tracing parser when I investiage the > root > cause of issues mentioned in below patch. > https://patchwork.kernel.org/patch/10132953/ > > This serials can fix

linux-next: manual merge of the block tree with the dma-mapping tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: lib/Kconfig between commit: 002e67454f61 ("dma-direct: rename dma_noop to dma_direct") from the dma-mapping tree and commit: e80a0af4759a ("lib/scatterlist: Introduce sgl_alloc() and sgl_free()") from the block

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/16/18 17:33), Petr Mladek wrote: [..] > > JFI, the patch is in Linus's tree as of now (d0729bc6bee797fb). > > Great. I have pushed the patch that removes printk_symbol() > into printk.git, branch for-4.16-print-symbol. > > Note that I have updated the commit message similar way > like I

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/16/18 17:33), Petr Mladek wrote: [..] > > JFI, the patch is in Linus's tree as of now (d0729bc6bee797fb). > > Great. I have pushed the patch that removes printk_symbol() > into printk.git, branch for-4.16-print-symbol. > > Note that I have updated the commit message similar way > like I

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/16/18 11:19), Petr Mladek wrote: [..] > > [1] https://marc.info/?l=linux-mm=145692016122716 > > Fixes: 6b97a20d3a79 ("printk: set may_schedule for some of > > console_trylock() callers") > > Signed-off-by: Sergey Senozhatsky > > Reported-by: Tetsuo Handa

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/16/18 11:19), Petr Mladek wrote: [..] > > [1] https://marc.info/?l=linux-mm=145692016122716 > > Fixes: 6b97a20d3a79 ("printk: set may_schedule for some of > > console_trylock() callers") > > Signed-off-by: Sergey Senozhatsky > > Reported-by: Tetsuo Handa > > IMHO, this is a step in the

Re: [BUG 4.15-rc7] IRQ matrix management errors

On Tue, Jan 16, 2018 at 12:20:18PM +0100, Thomas Gleixner wrote: > 8<-- > diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c > index f8b03bb8e725..3cc471beb50b 100644 > --- a/arch/x86/kernel/apic/vector.c > +++ b/arch/x86/kernel/apic/vector.c > @@

Re: [BUG 4.15-rc7] IRQ matrix management errors

On Tue, Jan 16, 2018 at 12:20:18PM +0100, Thomas Gleixner wrote: > 8<-- > diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c > index f8b03bb8e725..3cc471beb50b 100644 > --- a/arch/x86/kernel/apic/vector.c > +++ b/arch/x86/kernel/apic/vector.c > @@

Re: [PATCH v5 1/2] printk: Add console owner and waiter logic to load balance console writes

On 1/10/2018 10:24 PM, Petr Mladek wrote: From: Steven Rostedt From: Steven Rostedt (VMware) This patch implements what I discussed in Kernel Summit. I added lockdep annotation (hopefully correctly), and it hasn't had any splats (since I fixed some

Re: [PATCH v5 1/2] printk: Add console owner and waiter logic to load balance console writes

On 1/10/2018 10:24 PM, Petr Mladek wrote: From: Steven Rostedt From: Steven Rostedt (VMware) This patch implements what I discussed in Kernel Summit. I added lockdep annotation (hopefully correctly), and it hasn't had any splats (since I fixed some bugs in the first iterations). It did catch

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/16/18 10:45), Steven Rostedt wrote: [..] > > [1] https://marc.info/?l=linux-mm=145692016122716 > > Especially since Konstantin is working on pulling in all LKML archives, > the above should be denoted as: > > Link: >

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/16/18 10:45), Steven Rostedt wrote: [..] > > [1] https://marc.info/?l=linux-mm=145692016122716 > > Especially since Konstantin is working on pulling in all LKML archives, > the above should be denoted as: > > Link: >

[patch -mm 2/4] mm, memcg: replace cgroup aware oom killer mount option with tunable

Now that each mem cgroup on the system has a memory.oom_policy tunable to specify oom kill selection behavior, remove the needless "groupoom" mount option that requires (1) the entire system to be forced, perhaps unnecessarily, perhaps unexpectedly, into a single oom policy that differs from the

[patch -mm 2/4] mm, memcg: replace cgroup aware oom killer mount option with tunable

Now that each mem cgroup on the system has a memory.oom_policy tunable to specify oom kill selection behavior, remove the needless "groupoom" mount option that requires (1) the entire system to be forced, perhaps unnecessarily, perhaps unexpectedly, into a single oom policy that differs from the

[patch -mm 1/4] mm, memcg: introduce per-memcg oom policy tunable

The cgroup aware oom killer is needlessly declared for the entire system by a mount option. It's unnecessary to force the system into a single oom policy: either cgroup aware, or the traditional process aware. This patch introduces a memory.oom_policy tunable for all mem cgroups. It is currently

[patch -mm 1/4] mm, memcg: introduce per-memcg oom policy tunable

The cgroup aware oom killer is needlessly declared for the entire system by a mount option. It's unnecessary to force the system into a single oom policy: either cgroup aware, or the traditional process aware. This patch introduces a memory.oom_policy tunable for all mem cgroups. It is currently

[patch -mm 4/4] mm, memcg: add hierarchical usage oom policy

One of the three significant concerns brought up about the cgroup aware oom killer is that its decisionmaking is completely evaded by creating subcontainers and attaching processes such that the ancestor's usage does not exceed another cgroup on the system. In this regard, users who do not

[patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable

The behavior of killing an entire indivisible memory consumer, enabled by memory.oom_group, is an oom policy itself. It specifies that all usage should be accounted to an ancestor and, if selected by the cgroup aware oom killer, all processes attached to it and its descendant mem cgroups should

[patch -mm 4/4] mm, memcg: add hierarchical usage oom policy

One of the three significant concerns brought up about the cgroup aware oom killer is that its decisionmaking is completely evaded by creating subcontainers and attaching processes such that the ancestor's usage does not exceed another cgroup on the system. In this regard, users who do not

[patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable

The behavior of killing an entire indivisible memory consumer, enabled by memory.oom_group, is an oom policy itself. It specifies that all usage should be accounted to an ancestor and, if selected by the cgroup aware oom killer, all processes attached to it and its descendant mem cgroups should

[patch -mm 0/4] mm, memcg: introduce oom policies

There are three significant concerns about the cgroup aware oom killer as it is implemented in -mm: (1) allows users to evade the oom killer by creating subcontainers or using other controllers since scoring is done per cgroup and not hierarchically, (2) does not allow the user to

[patch -mm 0/4] mm, memcg: introduce oom policies

There are three significant concerns about the cgroup aware oom killer as it is implemented in -mm: (1) allows users to evade the oom killer by creating subcontainers or using other controllers since scoring is done per cgroup and not hierarchically, (2) does not allow the user to

Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT

On Tue, Jan 16, 2018 at 01:37:46PM -0800, Nicolin Chen wrote: > On Tue, Jan 16, 2018 at 09:19:13PM +, Marc Zyngier wrote: > > > > I understand that it should take care of the condition field as > > > a general instruction handler. Just for curiosity: If we confine > > > the topic to read

Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT

On Tue, Jan 16, 2018 at 01:37:46PM -0800, Nicolin Chen wrote: > On Tue, Jan 16, 2018 at 09:19:13PM +, Marc Zyngier wrote: > > > > I understand that it should take care of the condition field as > > > a general instruction handler. Just for curiosity: If we confine > > > the topic to read

Ut

-- My name is Mrs. Emile Kenold from London. Am suffering from lung cancer which had damaged my liver and back bone, my health is no longer responding to treatment. I have made up my mind to give a charity donation of £7 Million British Pound Sterling to you and i hope you use my donation for

Ut

-- My name is Mrs. Emile Kenold from London. Am suffering from lung cancer which had damaged my liver and back bone, my health is no longer responding to treatment. I have made up my mind to give a charity donation of £7 Million British Pound Sterling to you and i hope you use my donation for

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