[PATCH v1 0/4] PCI/VPD: Encapsulate VPD stuff in vpd.c

This is strictly cleanup, not intended to change or fix anything. Move all the VPD-related code and structures to drivers/pci/vpd.c. --- Bjorn Helgaas (4): PCI/VPD: Move VPD access code to vpd.c PCI/VPD: Move VPD sysfs code to vpd.c PCI/VPD: Move VPD quirks to vpd.c

[PATCH v1 1/4] PCI/VPD: Move VPD access code to vpd.c

From: Bjorn Helgaas Move the VPD-related code from access.c to vpd.c. The goal is to encapsulate all the VPD code and structures in vpd.c. No functional change intended. Signed-off-by: Bjorn Helgaas --- drivers/pci/access.c | 368 --

[PATCH v1 2/4] PCI/VPD: Move VPD sysfs code to vpd.c

From: Bjorn Helgaas Move the VPD-related sysfs code from pci-sysfs.c to vpd.c. This follows the pattern of pcie_aspm_create_sysfs_dev_files(). The goal is to encapsulate all the VPD code and structures in vpd.c. No functional change intended. Signed-off-by: Bjorn Helgaas ---

[PATCH v1 0/4] PCI/VPD: Encapsulate VPD stuff in vpd.c

This is strictly cleanup, not intended to change or fix anything. Move all the VPD-related code and structures to drivers/pci/vpd.c. --- Bjorn Helgaas (4): PCI/VPD: Move VPD access code to vpd.c PCI/VPD: Move VPD sysfs code to vpd.c PCI/VPD: Move VPD quirks to vpd.c

linux-next: manual merge of the metag tree with the syscalls tree

Hi James, Today's linux-next merge of the metag tree got a conflict in: arch/metag/kernel/sys_metag.c between commits: fabbf34a610d ("mm: add ksys_fadvise64_64() helper; remove in-kernel call to sys_fadvise64_64()") a302a8524798 ("mm: add ksys_mmap_pgoff() helper; remove in-kernel calls

linux-next: manual merge of the metag tree with the syscalls tree

Hi James, Today's linux-next merge of the metag tree got a conflict in: arch/metag/kernel/sys_metag.c between commits: fabbf34a610d ("mm: add ksys_fadvise64_64() helper; remove in-kernel call to sys_fadvise64_64()") a302a8524798 ("mm: add ksys_mmap_pgoff() helper; remove in-kernel calls

Re: [PATCH] media: staging/imx: fill vb2_v4l2_buffer sequence entry

Hello Steve, On Tue, 13 Mar 2018 15:03:07 -0700, Steve Longerbeam wrote: > Hi Peter, > > Thanks for the patch. > > This needs to be done in imx-ic-prpencvf.c as well, see > prp_vb2_buf_done(). Ahh, I see, would you prefer an follow up patch or an v2 patch doing

Re: [PATCH] media: staging/imx: fill vb2_v4l2_buffer sequence entry

Hello Steve, On Tue, 13 Mar 2018 15:03:07 -0700, Steve Longerbeam wrote: > Hi Peter, > > Thanks for the patch. > > This needs to be done in imx-ic-prpencvf.c as well, see > prp_vb2_buf_done(). Ahh, I see, would you prefer an follow up patch or an v2 patch doing the changes on

mmotm 2018-03-13-15-15 uploaded

The mm-of-the-moment snapshot 2018-03-13-15-15 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2018-03-13-15-15 uploaded

The mm-of-the-moment snapshot 2018-03-13-15-15 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

[PATCH v6 2/2] x86/devicetree: Use CPU description from Device Tree

Current x86 Device Tree implementation does not support multiprocessing. Use new DT bindings to describe the processors. Signed-off-by: Ivan Gorinov --- arch/x86/kernel/devicetree.c | 39 --- 1 file changed, 28 insertions(+), 11

[PATCH v6 2/2] x86/devicetree: Use CPU description from Device Tree

Current x86 Device Tree implementation does not support multiprocessing. Use new DT bindings to describe the processors. Signed-off-by: Ivan Gorinov --- arch/x86/kernel/devicetree.c | 39 --- 1 file changed, 28 insertions(+), 11 deletions(-) diff --git

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Tue, Mar 13, 2018 at 2:02 PM, Andrew Morton wrote: > On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook wrote: > >> On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds >> wrote: >> > On Mon, Mar 12, 2018 at 3:55 PM,

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Tue, Mar 13, 2018 at 2:02 PM, Andrew Morton wrote: > On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook wrote: > >> On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds >> wrote: >> > On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton >> > wrote: >> >> >> >> Replacing the __builtin_choose_expr() with ?:

[PATCH v6 0/2] x86/devicetree: Enable multiprocessing

Current x86 implementation of Device Tree does not support multiprocessing, and the bindings documentation describes the "reg" property as CPU number instead of hardware-assigned local APIC ID. v6: * Calling of_property_read_u32() to get Local APIC ID from "reg" * DT documentation changes:

[PATCH v6 0/2] x86/devicetree: Enable multiprocessing

Current x86 implementation of Device Tree does not support multiprocessing, and the bindings documentation describes the "reg" property as CPU number instead of hardware-assigned local APIC ID. v6: * Calling of_property_read_u32() to get Local APIC ID from "reg" * DT documentation changes:

Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working

Sorry for the miscommunication. I reviewed the patches and tested them on the Centriq 2400 platform. Perhaps the following is the most appropriate. Acked-by: Austin Christ On 3/13/2018 3:17 PM, Wolfram Sang wrote: On Tue, Mar 13, 2018 at 03:09:00PM -0600, Christ,

[PATCH v6 1/2] of: Documentation: Specify local APIC ID in "reg"

Use the "reg" property to specify the processor's local APIC ID. Local APIC ID is assigned by hardware and may differ from CPU number. Signed-off-by: Ivan Gorinov --- Documentation/devicetree/bindings/x86/ce4100.txt | 37 ++-- 1 file changed, 28

Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working

Sorry for the miscommunication. I reviewed the patches and tested them on the Centriq 2400 platform. Perhaps the following is the most appropriate. Acked-by: Austin Christ On 3/13/2018 3:17 PM, Wolfram Sang wrote: On Tue, Mar 13, 2018 at 03:09:00PM -0600, Christ, Austin wrote: I've tested

[PATCH v6 1/2] of: Documentation: Specify local APIC ID in "reg"

Use the "reg" property to specify the processor's local APIC ID. Local APIC ID is assigned by hardware and may differ from CPU number. Signed-off-by: Ivan Gorinov --- Documentation/devicetree/bindings/x86/ce4100.txt | 37 ++-- 1 file changed, 28 insertions(+), 9 deletions(-)

Re: [tip:x86/mm] x86/tme: Detect if TME and MKTME is activated by BIOS

On Tue, 2018-03-13 at 15:49 +0300, Kirill A. Shutemov wrote: > On Tue, Mar 13, 2018 at 03:12:02PM +1300, Kai Huang wrote: > > It seems setup_pku() will call get_cpu_cap to restore c- > > >x86_phys_bits > > later? In which case I think you need to change setup_pku as well. > > Thanks for catching

Re: [tip:x86/mm] x86/tme: Detect if TME and MKTME is activated by BIOS

On Tue, 2018-03-13 at 15:49 +0300, Kirill A. Shutemov wrote: > On Tue, Mar 13, 2018 at 03:12:02PM +1300, Kai Huang wrote: > > It seems setup_pku() will call get_cpu_cap to restore c- > > >x86_phys_bits > > later? In which case I think you need to change setup_pku as well. > > Thanks for catching

Re: [PATCH] scsi: eata: drop VLA in reorder()

2018-03-13 10:05 GMT+01:00 Christoph Hellwig : > On Mon, Mar 12, 2018 at 10:35:36PM -0400, Martin K. Petersen wrote: >> No objections to Salvatore's patch but I have a slight affinity for >> retiring unused code over patching it. So unless there are objections... > > Lets kill

Re: [PATCH] scsi: eata: drop VLA in reorder()

2018-03-13 10:05 GMT+01:00 Christoph Hellwig : > On Mon, Mar 12, 2018 at 10:35:36PM -0400, Martin K. Petersen wrote: >> No objections to Salvatore's patch but I have a slight affinity for >> retiring unused code over patching it. So unless there are objections... > > Lets kill it. And the not DMA

Re: [PATCH] media: staging/imx: fill vb2_v4l2_buffer sequence entry

Hi Peter, Thanks for the patch. This needs to be done in imx-ic-prpencvf.c as well, see prp_vb2_buf_done(). Steve On 03/13/2018 01:00 PM, Peter Seiderer wrote: Signed-off-by: Peter Seiderer --- drivers/staging/media/imx/imx-media-csi.c | 5 + 1 file changed, 5

Re: [PATCH] media: staging/imx: fill vb2_v4l2_buffer sequence entry

Hi Peter, Thanks for the patch. This needs to be done in imx-ic-prpencvf.c as well, see prp_vb2_buf_done(). Steve On 03/13/2018 01:00 PM, Peter Seiderer wrote: Signed-off-by: Peter Seiderer --- drivers/staging/media/imx/imx-media-csi.c | 5 + 1 file changed, 5 insertions(+) diff

[PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary arguments that can be removed by creating separate functins. Create specific functions for these calls to reduce x86/64 defconfig size by ~20k. Modify the existing macros to use the specific calls. new: $ size -t

[PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary arguments that can be removed by creating separate functins. Create specific functions for these calls to reduce x86/64 defconfig size by ~20k. Modify the existing macros to use the specific calls. new: $ size -t

Re: [PATCH] net: dsa: drop some VLAs in switch.c

2018-03-13 20:58 GMT+01:00 Vivien Didelot : > Hi Salvatore, Hi Vivien, > Salvatore Mesoraca writes: > >> dsa_switch's num_ports is currently fixed to DSA_MAX_PORTS. So we avoid >> 2 VLAs[1] by using DSA_MAX_PORTS instead of

Re: [PATCH] net: dsa: drop some VLAs in switch.c

2018-03-13 20:58 GMT+01:00 Vivien Didelot : > Hi Salvatore, Hi Vivien, > Salvatore Mesoraca writes: > >> dsa_switch's num_ports is currently fixed to DSA_MAX_PORTS. So we avoid >> 2 VLAs[1] by using DSA_MAX_PORTS instead of ds->num_ports. >> >> [1] https://lkml.org/lkml/2018/3/7/621 >> >>

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 03:22 PM, Sinan Kaya wrote: > It sounds like you have very tight hardware expectations for this to work > at this moment. You also don't want to generalize this code for others and > address the shortcomings. No, that's the way the community has pushed this work. Our original work

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 03:22 PM, Sinan Kaya wrote: > It sounds like you have very tight hardware expectations for this to work > at this moment. You also don't want to generalize this code for others and > address the shortcomings. No, that's the way the community has pushed this work. Our original work

Re: [PATCH 4/8] struct page: add field for vm_struct

On Tue, Mar 13, 2018 at 11:45:50PM +0200, Igor Stoppa wrote: > When a page is used for virtual memory, it is often necessary to obtain > a handler to the corresponding vm_struct, which refers to the virtually > continuous area generated when invoking vmalloc. > > The struct page has a "mapping"

Re: [PATCH 4/8] struct page: add field for vm_struct

On Tue, Mar 13, 2018 at 11:45:50PM +0200, Igor Stoppa wrote: > When a page is used for virtual memory, it is often necessary to obtain > a handler to the corresponding vm_struct, which refers to the virtually > continuous area generated when invoking vmalloc. > > The struct page has a "mapping"

Re: [RESEND RFC] translate_pid API

On Tue, Mar 13, 2018 at 2:44 PM, Nagarathnam Muthusamy wrote: > > > On 03/13/2018 02:28 PM, Jann Horn wrote: >> >> On Tue, Mar 13, 2018 at 2:20 PM, Nagarathnam Muthusamy >> wrote: >>> >>> On 03/13/2018 01:47 PM, Jann Horn wrote:

Re: [RESEND RFC] translate_pid API

On Tue, Mar 13, 2018 at 2:44 PM, Nagarathnam Muthusamy wrote: > > > On 03/13/2018 02:28 PM, Jann Horn wrote: >> >> On Tue, Mar 13, 2018 at 2:20 PM, Nagarathnam Muthusamy >> wrote: >>> >>> On 03/13/2018 01:47 PM, Jann Horn wrote: On Mon, Mar 12, 2018 at 10:18 AM, wrote: >

Re: [PATCH] clk: rockchip: Add 1.6GHz PLL rate

Hi, On Tue, Mar 13, 2018 at 1:37 PM, Derek Basehore wrote: > We need this rate to generate 100, 200, and 228.57MHz from the same > PLL. 228.57MHz is useful for a pixel clock when the VPLL is used for > and external display. > > Signed-off-by: Derek Basehore

Re: [PATCH] clk: rockchip: Add 1.6GHz PLL rate

Hi, On Tue, Mar 13, 2018 at 1:37 PM, Derek Basehore wrote: > We need this rate to generate 100, 200, and 228.57MHz from the same > PLL. 228.57MHz is useful for a pixel clock when the VPLL is used for > and external display. > > Signed-off-by: Derek Basehore > --- >

Re: [PATCH] staging: lustre: use module_name() macro for debug printf

On Tue, Mar 13 2018, Arnd Bergmann wrote: > We now allow lustre to be built when CONFIG_MODULES is disabled, > but that causes a build failure: > > In file included from drivers/staging/lustre/include/linux/libcfs/libcfs.h:42, > from

Re: [PATCH] staging: lustre: use module_name() macro for debug printf

On Tue, Mar 13 2018, Arnd Bergmann wrote: > We now allow lustre to be built when CONFIG_MODULES is disabled, > but that causes a build failure: > > In file included from drivers/staging/lustre/include/linux/libcfs/libcfs.h:42, > from

Re: [PATCH] staging: lustre: fid: avoid false-positive uninitialized variable warning

On Tue, Mar 13 2018, Arnd Bergmann wrote: > One of Neil's recent cleanups apparently has led the code to get > to a state where gcc tracks the 'seqnr' variable just enough to > see that it is sometimes initialized in seq_client_alloc_seq(), > but not enough that it can prove this initialization

Re: [PATCH] staging: lustre: fid: avoid false-positive uninitialized variable warning

On Tue, Mar 13 2018, Arnd Bergmann wrote: > One of Neil's recent cleanups apparently has led the code to get > to a state where gcc tracks the 'seqnr' variable just enough to > see that it is sometimes initialized in seq_client_alloc_seq(), > but not enough that it can prove this initialization

[RFC PATCH] dma-mapping: platform_dma_configure() can be static

Fixes: 9a019f425175 ("dma-mapping: move dma configuration to bus infrastructure") Signed-off-by: Fengguang Wu --- platform.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index

Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure

Hi Nipun, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16-rc5 next-20180313] [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

[RFC PATCH] dma-mapping: platform_dma_configure() can be static

Fixes: 9a019f425175 ("dma-mapping: move dma configuration to bus infrastructure") Signed-off-by: Fengguang Wu --- platform.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index adf94eb..dc9c790 100644 ---

Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure

Hi Nipun, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16-rc5 next-20180313] [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

Re: [PATCH] clang-format: add configuration file

On Tue, Mar 13, 2018 at 10:00 PM, Andrew Morton wrote: > On Tue, 13 Mar 2018 00:39:52 +0100 Miguel Ojeda > wrote: > >> --- a/Documentation/process/4.Coding.rst >> +++ b/Documentation/process/4.Coding.rst >> @@ -58,6 +58,12 @@ can never

Re: [PATCH] clang-format: add configuration file

On Tue, Mar 13, 2018 at 10:00 PM, Andrew Morton wrote: > On Tue, 13 Mar 2018 00:39:52 +0100 Miguel Ojeda > wrote: > >> --- a/Documentation/process/4.Coding.rst >> +++ b/Documentation/process/4.Coding.rst >> @@ -58,6 +58,12 @@ can never be transgressed. If there is a good reason to >> go

[PATCH 6/8] Pmalloc selftest

Add basic self-test functionality for pmalloc. The testing is introduced as early as possible, right after the main dependency, genalloc, has passed successfully, so that it can help diagnosing failures in pmalloc users. Signed-off-by: Igor Stoppa ---

[PATCH 7/8] lkdtm: crash on overwriting protected pmalloc var

Verify that pmalloc read-only protection is in place: trying to overwrite a protected variable will crash the kernel. Signed-off-by: Igor Stoppa --- drivers/misc/lkdtm.h | 1 + drivers/misc/lkdtm_core.c | 3 +++ drivers/misc/lkdtm_perms.c | 28

[PATCH 6/8] Pmalloc selftest

Add basic self-test functionality for pmalloc. The testing is introduced as early as possible, right after the main dependency, genalloc, has passed successfully, so that it can help diagnosing failures in pmalloc users. Signed-off-by: Igor Stoppa --- include/linux/test_pmalloc.h | 24 +

[PATCH 7/8] lkdtm: crash on overwriting protected pmalloc var

Verify that pmalloc read-only protection is in place: trying to overwrite a protected variable will crash the kernel. Signed-off-by: Igor Stoppa --- drivers/misc/lkdtm.h | 1 + drivers/misc/lkdtm_core.c | 3 +++ drivers/misc/lkdtm_perms.c | 28 3 files

Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support

On Tue, 13 Mar 2018, Stefan Berger wrote: > On 03/11/2018 06:58 PM, James Morris wrote: > > On Fri, 9 Mar 2018, Stefan Berger wrote: > > > > > Yuqiong is publishing a paper in this area. I believe the conference is > > > only > > > later this year. > > > > > > Our goals are to enable IMA

[PATCH 8/8] Documentation for Pmalloc

Detailed documentation about the protectable memory allocator. Signed-off-by: Igor Stoppa --- Documentation/core-api/index.rst | 1 + Documentation/core-api/pmalloc.rst | 111 + 2 files changed, 112 insertions(+) create mode

Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support

On Tue, 13 Mar 2018, Stefan Berger wrote: > On 03/11/2018 06:58 PM, James Morris wrote: > > On Fri, 9 Mar 2018, Stefan Berger wrote: > > > > > Yuqiong is publishing a paper in this area. I believe the conference is > > > only > > > later this year. > > > > > > Our goals are to enable IMA

[PATCH 8/8] Documentation for Pmalloc

Detailed documentation about the protectable memory allocator. Signed-off-by: Igor Stoppa --- Documentation/core-api/index.rst | 1 + Documentation/core-api/pmalloc.rst | 111 + 2 files changed, 112 insertions(+) create mode 100644

[PATCH 5/8] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

[PATCH 5/8] Protectable Memory

The MMU available in many systems running Linux can often provide R/O protection to the memory pages it handles. However, the MMU-based protection works efficiently only when said pages contain exclusively data that will not need further modifications. Statically allocated variables can be

[PATCH 4/8] struct page: add field for vm_struct

When a page is used for virtual memory, it is often necessary to obtain a handler to the corresponding vm_struct, which refers to the virtually continuous area generated when invoking vmalloc. The struct page has a "mapping" field, which can be re-used, to store a pointer to the parent area.

[PATCH 4/8] struct page: add field for vm_struct

When a page is used for virtual memory, it is often necessary to obtain a handler to the corresponding vm_struct, which refers to the virtually continuous area generated when invoking vmalloc. The struct page has a "mapping" field, which can be re-used, to store a pointer to the parent area.

[PATCH 2/8] Add label to genalloc.rst for cross reference

Put a label at the beginning of the genalloc.rst, to allow other documents to cross-reference it. Signed-off-by: Igor Stoppa --- Documentation/core-api/genalloc.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/core-api/genalloc.rst

[PATCH 2/8] Add label to genalloc.rst for cross reference

Put a label at the beginning of the genalloc.rst, to allow other documents to cross-reference it. Signed-off-by: Igor Stoppa --- Documentation/core-api/genalloc.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/core-api/genalloc.rst b/Documentation/core-api/genalloc.rst

[PATCH 3/8] genalloc: selftest

Introduce a set of macros for writing concise test cases for genalloc. The test cases are meant to provide regression testing, when working on new functionality for genalloc. Primarily they are meant to confirm that the various allocation strategy will continue to work as expected. The

[PATCH 3/8] genalloc: selftest

Introduce a set of macros for writing concise test cases for genalloc. The test cases are meant to provide regression testing, when working on new functionality for genalloc. Primarily they are meant to confirm that the various allocation strategy will continue to work as expected. The

Re: [RESEND RFC] translate_pid API

On 03/13/2018 02:28 PM, Jann Horn wrote: On Tue, Mar 13, 2018 at 2:20 PM, Nagarathnam Muthusamy wrote: On 03/13/2018 01:47 PM, Jann Horn wrote: On Mon, Mar 12, 2018 at 10:18 AM, wrote: Resending the RFC with participants

Re: [RESEND RFC] translate_pid API

On 03/13/2018 02:28 PM, Jann Horn wrote: On Tue, Mar 13, 2018 at 2:20 PM, Nagarathnam Muthusamy wrote: On 03/13/2018 01:47 PM, Jann Horn wrote: On Mon, Mar 12, 2018 at 10:18 AM, wrote: Resending the RFC with participants of previous discussions in the list. Following patch which is a

[PATCH] selftests/*/Makefile: stop calling headers_install

Various tests should not call headers_install. Adding headers_install as a prereq before building kselftests. Signed-off-by: Anders Roxell --- tools/testing/selftests/Makefile | 5 - tools/testing/selftests/gpio/Makefile | 6 +-

[PATCH] selftests/*/Makefile: stop calling headers_install

Various tests should not call headers_install. Adding headers_install as a prereq before building kselftests. Signed-off-by: Anders Roxell --- tools/testing/selftests/Makefile | 5 - tools/testing/selftests/gpio/Makefile | 6 +- tools/testing/selftests/vm/Makefile | 4 3

Re: [PATCH 4.15 049/146] mm/page_alloc: fix memmap_init_zone pageblock alignment

On Tue, Mar 13, 2018 at 8:34 PM, Dan Rue wrote: > On Tue, Mar 13, 2018 at 04:23:36PM +0100, Greg Kroah-Hartman wrote: >> 4.15-stable review patch. If anyone has any objections, please let me know. > > On 4.14 and 4.15, this patch breaks booting on dragonboard 410c and > hikey

Re: [PATCH 4.15 049/146] mm/page_alloc: fix memmap_init_zone pageblock alignment

On Tue, Mar 13, 2018 at 8:34 PM, Dan Rue wrote: > On Tue, Mar 13, 2018 at 04:23:36PM +0100, Greg Kroah-Hartman wrote: >> 4.15-stable review patch. If anyone has any objections, please let me know. > > On 4.14 and 4.15, this patch breaks booting on dragonboard 410c and > hikey 620 (both arm64).

[PATCH 1/8] genalloc: track beginning of allocations

The genalloc library is only capable of tracking if a certain unit of allocation is in use or not. It is not capable of discerning where the memory associated to an allocation request begins and where it ends. The reason is that units of allocations are tracked by using a bitmap, where each bit

[PATCH 1/8] genalloc: track beginning of allocations

The genalloc library is only capable of tracking if a certain unit of allocation is in use or not. It is not capable of discerning where the memory associated to an allocation request begins and where it ends. The reason is that units of allocations are tracked by using a bitmap, where each bit

[RFC PATCH v19 0/8] mm: security: ro protection for dynamic data

This patch-set introduces the possibility of protecting memory that has been allocated dynamically. The memory is managed in pools: when a memory pool is turned into R/O, all the memory that is part of it, will become R/O. A R/O pool can be destroyed, to recover its memory, but it cannot be

Re: Timing performance regression 4.15 to 4.16-rc1

Dne 13.3.2018 v 17:45 Zdenek Kabelac napsal(a): Dne 13.3.2018 v 12:17 Zdenek Kabelac napsal(a): Dne 13.3.2018 v 05:03 Al Viro napsal(a): On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote: Hi I've noticed quite some drop of performance (around 15% in some cases) where execution

[RFC PATCH v19 0/8] mm: security: ro protection for dynamic data

This patch-set introduces the possibility of protecting memory that has been allocated dynamically. The memory is managed in pools: when a memory pool is turned into R/O, all the memory that is part of it, will become R/O. A R/O pool can be destroyed, to recover its memory, but it cannot be

Re: Timing performance regression 4.15 to 4.16-rc1

Dne 13.3.2018 v 17:45 Zdenek Kabelac napsal(a): Dne 13.3.2018 v 12:17 Zdenek Kabelac napsal(a): Dne 13.3.2018 v 05:03 Al Viro napsal(a): On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote: Hi I've noticed quite some drop of performance (around 15% in some cases) where execution

[PATCH] PCI/MSI: Don't set up INTx if MSI or MSI-X is enabled

From: Bjorn Helgaas If a device already has MSI or MSI-X enabled, there's no need to set up its legacy INTx interrupt. bba6f6fc68e7 ("[PATCH] MSI-X: fix resume crash") changed the cris, frv, x86, and ia64 arches to skip INTx setup when MSI is enabled. 16cf0ebc35dd

[PATCH] PCI/MSI: Don't set up INTx if MSI or MSI-X is enabled

From: Bjorn Helgaas If a device already has MSI or MSI-X enabled, there's no need to set up its legacy INTx interrupt. bba6f6fc68e7 ("[PATCH] MSI-X: fix resume crash") changed the cris, frv, x86, and ia64 arches to skip INTx setup when MSI is enabled. 16cf0ebc35dd ("x86/PCI: Do not use

[PATCH v1 0/2] Improve preemptirq tracepoint usage

Hi, These patches improve the design of preemptirq tracepoints, clean up several of the ifdeffery and overall makes the feature configuration cleaner and less confusing. It also uses the tracepoints infra for the lockdep hooks for irqs on/off thus making a central point for all users of the event

[PATCH v1 0/2] Improve preemptirq tracepoint usage

Hi, These patches improve the design of preemptirq tracepoints, clean up several of the ifdeffery and overall makes the feature configuration cleaner and less confusing. It also uses the tracepoints infra for the lockdep hooks for irqs on/off thus making a central point for all users of the event

[PATCH v1 1/2] tracing: Improve design of preemptirq tracepoints and its users

This patch detaches the preemptirq tracepoints from the tracers and keeps it separate. With this, several ifdefs are cleaner, and lockdep and other users can use the preemptirq tracepoints by registering probes onto them. This makes it much cleaner by getting rid of all the horrific ifdeferry

[PATCH v1 2/2] tracepoint: Prevent false-positive lockdep warnings

Since the last patch, lockdep hooks for irqs on/off will use the tracepoint infrastructure. This can however cause false lockdep warnings triggered by RCU code that does lockdep asserts. There are 2 cases: 1) trace_hardirqs_off calls the lockdep_hardirqs_off hook, however this call happens only

[PATCH v1 1/2] tracing: Improve design of preemptirq tracepoints and its users

This patch detaches the preemptirq tracepoints from the tracers and keeps it separate. With this, several ifdefs are cleaner, and lockdep and other users can use the preemptirq tracepoints by registering probes onto them. This makes it much cleaner by getting rid of all the horrific ifdeferry

[PATCH v1 2/2] tracepoint: Prevent false-positive lockdep warnings

Since the last patch, lockdep hooks for irqs on/off will use the tracepoint infrastructure. This can however cause false lockdep warnings triggered by RCU code that does lockdep asserts. There are 2 cases: 1) trace_hardirqs_off calls the lockdep_hardirqs_off hook, however this call happens only

Re: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5

On Tue, Mar 13, 2018 at 07:07:26AM +, mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Dominik Brodowski [mailto:li...@dominikbrodowski.net] > > Sent: Tuesday, March 13, 2018 2:44 PM > > To: Limonciello, Mario ; Darren Hart > >

Re: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5

On Tue, Mar 13, 2018 at 07:07:26AM +, mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Dominik Brodowski [mailto:li...@dominikbrodowski.net] > > Sent: Tuesday, March 13, 2018 2:44 PM > > To: Limonciello, Mario ; Darren Hart > > > > Cc:

[pci PATCH v6 5/5] pci-pf-stub: Add PF driver stub for PFs that function only to enable VFs

From: Alexander Duyck Add a new driver called "pci-pf-stub" to act as a "white-list" for PF devices that provide no other functionality other then acting as a means of allocating a set of VFs. For now I only have one example ID provided by Amazon in terms of devices

[pci PATCH v6 5/5] pci-pf-stub: Add PF driver stub for PFs that function only to enable VFs

From: Alexander Duyck Add a new driver called "pci-pf-stub" to act as a "white-list" for PF devices that provide no other functionality other then acting as a means of allocating a set of VFs. For now I only have one example ID provided by Amazon in terms of devices that require this

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

Hi Palmer, Palmer Dabbelt writes: > On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@andestech.com wrote: >> These patches resolve the some issues of loadable module. >> - symbol out of ranges >> - unknown relocation types >> >> The reference of external variable and

[pci PATCH v6 4/5] nvme: Migrate over to unmanaged SR-IOV support

From: Alexander Duyck Instead of implementing our own version of a SR-IOV configuration stub in the nvme driver we can just reuse the existing pci_sriov_configure_simple function. Signed-off-by: Alexander Duyck --- v5: Replaced call to

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

Hi Palmer, Palmer Dabbelt writes: > On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@andestech.com wrote: >> These patches resolve the some issues of loadable module. >> - symbol out of ranges >> - unknown relocation types >> >> The reference of external variable and function symbols >>

[pci PATCH v6 4/5] nvme: Migrate over to unmanaged SR-IOV support

From: Alexander Duyck Instead of implementing our own version of a SR-IOV configuration stub in the nvme driver we can just reuse the existing pci_sriov_configure_simple function. Signed-off-by: Alexander Duyck --- v5: Replaced call to pci_sriov_configure_unmanaged with

Re: [PATCH] KVM: arm/arm64: replacing per-VM's per-CPU variable

On Tue, 13 Mar 2018 19:33:55 +, Robin Murphy wrote: > > On 13/03/18 13:01, Marc Zyngier wrote: > > [You're repeatedly posting to the kvmarm mailing list without being > > subscribed to it. I've flushed the queue now, but please consider > > subscribing to the list, it will help everyone] > >

Re: [PATCH] KVM: arm/arm64: replacing per-VM's per-CPU variable

On Tue, 13 Mar 2018 19:33:55 +, Robin Murphy wrote: > > On 13/03/18 13:01, Marc Zyngier wrote: > > [You're repeatedly posting to the kvmarm mailing list without being > > subscribed to it. I've flushed the queue now, but please consider > > subscribing to the list, it will help everyone] > >

[pci PATCH v6 3/5] ena: Migrate over to unmanaged SR-IOV support

From: Alexander Duyck Instead of implementing our own version of a SR-IOV configuration stub in the ena driver we can just reuse the existing pci_sriov_configure_simple function. Signed-off-by: Alexander Duyck --- v5: Replaced call to

[pci PATCH v6 3/5] ena: Migrate over to unmanaged SR-IOV support

From: Alexander Duyck Instead of implementing our own version of a SR-IOV configuration stub in the ena driver we can just reuse the existing pci_sriov_configure_simple function. Signed-off-by: Alexander Duyck --- v5: Replaced call to pci_sriov_configure_unmanaged with

[pci PATCH v6 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

From: Alexander Duyck Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been

[pci PATCH v6 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

From: Alexander Duyck Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been up to now been a software

Re: [RESEND RFC] translate_pid API

On Tue, Mar 13, 2018 at 2:20 PM, Nagarathnam Muthusamy wrote: > On 03/13/2018 01:47 PM, Jann Horn wrote: >> On Mon, Mar 12, 2018 at 10:18 AM, >> wrote: >>> >>> Resending the RFC with participants of previous discussions >>> in

[pci PATCH v6 1/5] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources

From: Alexander Duyck This patch adds a common configuration function called pci_sriov_configure_simple that will allow for managing VFs on devices where the PF is not capable of managing VF resources. Signed-off-by: Alexander Duyck ---

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