Re: Linux 4.4.110

On Fri, Jan 05, 2018 at 07:02:35PM +0100, Greg KH wrote: > On Fri, Jan 05, 2018 at 04:55:07PM +0100, Willy Tarreau wrote: > > On Fri, Jan 05, 2018 at 03:54:33PM +0100, Greg KH wrote: > > > I'm announcing the release of the 4.4.110 kernel. > > > > > > All users of the 4.4 kernel series must

[GIT pull] EFI updates for 4.15

Linus, please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus This update contains: - A fix for a add_efi_memmap parameter regression which ensures that the parameter is parsed before it is used. -

Re: [PATCH 1/3] mm, numa: rework do_pages_move

On Fri, 5 Jan 2018, Michal Hocko wrote: > I believe there should be some cap on the number of pages. We shouldn't > keep it held for million of pages if all of them are moved to the same > node. I would really like to postpone that to later unless it causes > some noticeable regressions because

Re: [PATCH 1/3] mm, numa: rework do_pages_move

On Fri, 5 Jan 2018, Michal Hocko wrote: > I believe there should be some cap on the number of pages. We shouldn't > keep it held for million of pages if all of them are moved to the same > node. I would really like to postpone that to later unless it causes > some noticeable regressions because

Re: [v2 PATCH 5/6] dt-bindings: usb: mtk-xhci: update USB wakeup properties

On Wed, Jan 03, 2018 at 04:53:21PM +0800, Chunfeng Yun wrote: > Add two arguments in "mediatek,syscon-wakeup" to support multi > wakeup glue layer between SSUSB and SPM, and use standard property > "wakeup-source" to replace the private "mediatek,wakeup-src" > > Signed-off-by: Chunfeng Yun

Re: [v2 PATCH 5/6] dt-bindings: usb: mtk-xhci: update USB wakeup properties

On Wed, Jan 03, 2018 at 04:53:21PM +0800, Chunfeng Yun wrote: > Add two arguments in "mediatek,syscon-wakeup" to support multi > wakeup glue layer between SSUSB and SPM, and use standard property > "wakeup-source" to replace the private "mediatek,wakeup-src" > > Signed-off-by: Chunfeng Yun > ---

Re: [PATCH V3] perf script: add script to profile and resolve physical mem type

On Thu, Jan 04, 2018 at 12:59:55PM -0800, kan.li...@intel.com wrote: > From: Kan Liang > > There could be different types of memory in the system. E.g normal > System Memory, Persistent Memory. To understand how the workload maps to > those memories, it's important to know

Re: [PATCH V3] perf script: add script to profile and resolve physical mem type

On Thu, Jan 04, 2018 at 12:59:55PM -0800, kan.li...@intel.com wrote: > From: Kan Liang > > There could be different types of memory in the system. E.g normal > System Memory, Persistent Memory. To understand how the workload maps to > those memories, it's important to know the I/O statistics of

Re: [GIT PULL 00/25] LightNVM updates for 4.16

On 01/05/2018 04:50 PM, Jens Axboe wrote: On Fri, Jan 05 2018, Matias Bjørling wrote: Hi Jens, Here is a couple of patches for 4.16. This patchset prepares the lightnvm and pblk source code for the 2.0 specification release. The specification is close to its final revision. After these

Re: [GIT PULL 00/25] LightNVM updates for 4.16

On 01/05/2018 04:50 PM, Jens Axboe wrote: On Fri, Jan 05 2018, Matias Bjørling wrote: Hi Jens, Here is a couple of patches for 4.16. This patchset prepares the lightnvm and pblk source code for the 2.0 specification release. The specification is close to its final revision. After these

Re: [GIT PULL 24/25] lightnvm: pblk: add iostat support

On 01/05/2018 04:42 PM, Jens Axboe wrote: On Fri, Jan 05 2018, Matias Bjørling wrote: From: Javier González Since pblk registers its own block device, the iostat accounting is not automatically done for us. Therefore, add the necessary accounting logic to satisfy the

Re: [GIT PULL 24/25] lightnvm: pblk: add iostat support

On 01/05/2018 04:42 PM, Jens Axboe wrote: On Fri, Jan 05 2018, Matias Bjørling wrote: From: Javier González Since pblk registers its own block device, the iostat accounting is not automatically done for us. Therefore, add the necessary accounting logic to satisfy the iostat interface.

Re: [RFC] boot failed when enable KAISER/KPTI

On Fri, 5 Jan 2018, Xishi Qiu wrote: > I run the latest RHEL 7.2 with the KAISER/KPTI patch, and boot failed. > > ... > [0.00] PM: Registered nosave memory: [mem 0x810-0x8ff] > [0.00] PM: Registered nosave memory: [mem 0x910-0xfff] > [0.00]

Re: [RFC] boot failed when enable KAISER/KPTI

On Fri, 5 Jan 2018, Xishi Qiu wrote: > I run the latest RHEL 7.2 with the KAISER/KPTI patch, and boot failed. > > ... > [0.00] PM: Registered nosave memory: [mem 0x810-0x8ff] > [0.00] PM: Registered nosave memory: [mem 0x910-0xfff] > [0.00]

Re: [RFC] selftests/x86: Add test_vsyscall

On Fri, Jan 05, 2018 at 10:01:23AM -0800, Andy Lutomirski wrote: > Yes. There are very clever tools like 'pin' that instrument a binary > by decoding all the instructions it executes and generating an > instrumented copy. If that binary calls into the vDSO, the vDSO gets > decoded and

Re: [RFC] selftests/x86: Add test_vsyscall

On Fri, Jan 05, 2018 at 10:01:23AM -0800, Andy Lutomirski wrote: > Yes. There are very clever tools like 'pin' that instrument a binary > by decoding all the instructions it executes and generating an > instrumented copy. If that binary calls into the vDSO, the vDSO gets > decoded and

[PATCH v6 01/15] clk: ingenic: Use const pointer to clk_ops in struct

The CGU common code does not modify the pointed clk_ops structure, so it should be marked as const. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.h| 2 +- drivers/clk/ingenic/jz4780-cgu.c | 2 +- 2 files

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On 5 January 2018 at 18:22, Catalin Marinas wrote: > On Fri, Jan 05, 2018 at 06:01:33PM +, Ard Biesheuvel wrote: >> On 5 January 2018 at 17:58, Catalin Marinas wrote: >> > On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: >> >>

[PATCH v6 02/15] clk: ingenic: Fix recalc_rate for clocks with fixed divider

Previously, the clocks with a fixed divider would report their rate as being the same as the one of their parent, independently of the divider in use. This commit fixes this behaviour. This went unnoticed as neither the jz4740 nor the jz4780 CGU code have clocks with fixed dividers yet.

[PATCH v6 01/15] clk: ingenic: Use const pointer to clk_ops in struct

The CGU common code does not modify the pointed clk_ops structure, so it should be marked as const. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.h| 2 +- drivers/clk/ingenic/jz4780-cgu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) v2:

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On 5 January 2018 at 18:22, Catalin Marinas wrote: > On Fri, Jan 05, 2018 at 06:01:33PM +, Ard Biesheuvel wrote: >> On 5 January 2018 at 17:58, Catalin Marinas wrote: >> > On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: >> >> diff --git a/arch/arm/include/asm/jump_label.h >>

[PATCH v6 02/15] clk: ingenic: Fix recalc_rate for clocks with fixed divider

Previously, the clocks with a fixed divider would report their rate as being the same as the one of their parent, independently of the divider in use. This commit fixes this behaviour. This went unnoticed as neither the jz4740 nor the jz4780 CGU code have clocks with fixed dividers yet.

[PATCH v6 07/15] MIPS: Setup boot_command_line before plat_mem_setup

From: Paul Burton Platforms using DT will typically call __dt_setup_arch from plat_mem_setup. This in turn calls early_init_dt_scan. When CONFIG_CMDLINE is set, this leads to its value being copied into boot_command_line by early_init_dt_scan_chosen. If this happens before

[PATCH] retpoline/modpost: Quieten MODVERSION retpoline build

From: Andi Kleen The internal retpoline thunks used by the compiler contain a dot. They have to be exported, but modversions cannot handle them it because they don't have a prototype due to the C incompatible name (and it doesn't support asm("...")) This leads to lots of

[PATCH v6 03/15] clk: ingenic: support PLLs with no bypass bit

The second PLL of the JZ4770 does not have a bypass bit. This commit makes it possible to support it with the current common CGU code. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.c | 3 ++-

[PATCH v6 07/15] MIPS: Setup boot_command_line before plat_mem_setup

From: Paul Burton Platforms using DT will typically call __dt_setup_arch from plat_mem_setup. This in turn calls early_init_dt_scan. When CONFIG_CMDLINE is set, this leads to its value being copied into boot_command_line by early_init_dt_scan_chosen. If this happens before the code setting up

[PATCH] retpoline/modpost: Quieten MODVERSION retpoline build

From: Andi Kleen The internal retpoline thunks used by the compiler contain a dot. They have to be exported, but modversions cannot handle them it because they don't have a prototype due to the C incompatible name (and it doesn't support asm("...")) This leads to lots of warnings from modpost

[PATCH v6 03/15] clk: ingenic: support PLLs with no bypass bit

The second PLL of the JZ4770 does not have a bypass bit. This commit makes it possible to support it with the current common CGU code. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.c | 3 ++- drivers/clk/ingenic/cgu.h | 2 ++ 2 files changed, 4 insertions(+),

[PATCH v6 08/15] MIPS: ingenic: Use common cmdline handling code

From: Paul Burton jz4740_init_cmdline appends all arguments from argv (in fw_arg1) to arcs_cmdline, up to argc (in fw_arg0). The common code in fw_init_cmdline will do the exact same thing when run on a system where fw_arg0 isn't a pointer to kseg0 (it'll also set _fw_envp

[PATCH v6 12/15] MIPS: JZ4770: Work around config2 misreporting associativity

From: Maarten ter Huurne According to config2, the associativity would be 5-ways, but the documentation states 4-ways, which also matches the documented L2 cache size of 256 kB. Signed-off-by: Maarten ter Huurne --- arch/mips/mm/sc-mips.c | 9

Re: possible deadlock in ppp_dev_uninit

On Fri, Jan 05, 2018 at 07:15:31PM +0100, Guillaume Nault wrote: > That's probably worth a test anyway. > Copy/paste error :-/ Here's a version that should apply cleanly. #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master 8< diff --git

[PATCH v6 05/15] dt-bindings: clock: Add jz4770-cgu.h header

This will be used from the devicetree bindings to specify the clocks that should be obtained from the jz4770-cgu driver. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd Reviewed-by: Rob Herring ---

[PATCH v6 06/15] clk: Add Ingenic jz4770 CGU driver

Add support for the clocks provided by the CGU in the Ingenic JZ4770 SoC. Signed-off-by: Paul Cercueil Signed-off-by: Maarten ter Huurne Acked-by: Stephen Boyd --- drivers/clk/ingenic/Makefile | 1 +

[PATCH v6 09/15] MIPS: platform: add machtype IDs for more Ingenic SoCs

Add a machtype ID for the JZ4780 SoC, which was missing, and one for the newly supported JZ4770 SoC. Signed-off-by: Paul Cercueil Reviewed-by: PrasannaKumar Muralidharan --- arch/mips/include/asm/bootinfo.h | 2 ++ 1 file changed, 2

[PATCH v6 10/15] MIPS: ingenic: Detect machtype from SoC compatible string

Previously, the mips_machtype variable was always initialized to MACH_INGENIC_JZ4740 even if running on different SoCs. Signed-off-by: Paul Cercueil --- arch/mips/jz4740/prom.c | 1 - arch/mips/jz4740/setup.c | 26 ++ 2 files changed, 22

[PATCH v6 08/15] MIPS: ingenic: Use common cmdline handling code

From: Paul Burton jz4740_init_cmdline appends all arguments from argv (in fw_arg1) to arcs_cmdline, up to argc (in fw_arg0). The common code in fw_init_cmdline will do the exact same thing when run on a system where fw_arg0 isn't a pointer to kseg0 (it'll also set _fw_envp but we don't use it).

[PATCH v6 12/15] MIPS: JZ4770: Work around config2 misreporting associativity

From: Maarten ter Huurne According to config2, the associativity would be 5-ways, but the documentation states 4-ways, which also matches the documented L2 cache size of 256 kB. Signed-off-by: Maarten ter Huurne --- arch/mips/mm/sc-mips.c | 9 + 1 file changed, 9 insertions(+) v2:

Re: possible deadlock in ppp_dev_uninit

On Fri, Jan 05, 2018 at 07:15:31PM +0100, Guillaume Nault wrote: > That's probably worth a test anyway. > Copy/paste error :-/ Here's a version that should apply cleanly. #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master 8< diff --git

[PATCH v6 05/15] dt-bindings: clock: Add jz4770-cgu.h header

This will be used from the devicetree bindings to specify the clocks that should be obtained from the jz4770-cgu driver. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd Reviewed-by: Rob Herring --- include/dt-bindings/clock/jz4770-cgu.h | 58 ++ 1 file

[PATCH v6 06/15] clk: Add Ingenic jz4770 CGU driver

Add support for the clocks provided by the CGU in the Ingenic JZ4770 SoC. Signed-off-by: Paul Cercueil Signed-off-by: Maarten ter Huurne Acked-by: Stephen Boyd --- drivers/clk/ingenic/Makefile | 1 + drivers/clk/ingenic/jz4770-cgu.c | 483 +++ 2 files

[PATCH v6 10/15] MIPS: ingenic: Detect machtype from SoC compatible string

Previously, the mips_machtype variable was always initialized to MACH_INGENIC_JZ4740 even if running on different SoCs. Signed-off-by: Paul Cercueil --- arch/mips/jz4740/prom.c | 1 - arch/mips/jz4740/setup.c | 26 ++ 2 files changed, 22 insertions(+), 5 deletions(-)

[PATCH v6 09/15] MIPS: platform: add machtype IDs for more Ingenic SoCs

Add a machtype ID for the JZ4780 SoC, which was missing, and one for the newly supported JZ4770 SoC. Signed-off-by: Paul Cercueil Reviewed-by: PrasannaKumar Muralidharan --- arch/mips/include/asm/bootinfo.h | 2 ++ 1 file changed, 2 insertions(+) v2: No change v3: No change v4: No change

[PATCH v6 14/15] devicetree/bindings: Add GCW vendor prefix

Game Consoles Worldwide, mostly known under the acronym GCW, is the creator of the GCW Zero open-source video game system. Signed-off-by: Paul Cercueil Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed,

[PATCH v6 04/15] clk: ingenic: Add code to enable/disable PLLs

This commit permits the PLLs to be dynamically enabled and disabled when their children clocks are enabled and disabled. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.c | 89

[PATCH v6 14/15] devicetree/bindings: Add GCW vendor prefix

Game Consoles Worldwide, mostly known under the acronym GCW, is the creator of the GCW Zero open-source video game system. Signed-off-by: Paul Cercueil Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) v2: It's 'Game

[PATCH v6 04/15] clk: ingenic: Add code to enable/disable PLLs

This commit permits the PLLs to be dynamically enabled and disabled when their children clocks are enabled and disabled. Signed-off-by: Paul Cercueil Acked-by: Stephen Boyd --- drivers/clk/ingenic/cgu.c | 89 +++ 1 file changed, 74 insertions(+), 15

[PATCH v6 11/15] MIPS: ingenic: Initial JZ4770 support

Provide just enough bits (clocks, clocksource, uart) to allow a kernel to boot on the JZ4770 SoC to a initramfs userspace. Signed-off-by: Paul Cercueil Reviewed-by: PrasannaKumar Muralidharan --- arch/mips/boot/dts/ingenic/jz4770.dtsi | 212

[PATCH v6 13/15] MIPS: JZ4770: Workaround for corrupted DMA transfers

From: Maarten ter Huurne We have seen MMC DMA transfers read corrupted data from SDRAM when a burst interval ends at physical address 0x1000. To avoid this problem, we remove the final page of low memory from the memory map. Signed-off-by: Maarten ter Huurne

[PATCH v6 11/15] MIPS: ingenic: Initial JZ4770 support

Provide just enough bits (clocks, clocksource, uart) to allow a kernel to boot on the JZ4770 SoC to a initramfs userspace. Signed-off-by: Paul Cercueil Reviewed-by: PrasannaKumar Muralidharan --- arch/mips/boot/dts/ingenic/jz4770.dtsi | 212 +

[PATCH v6 13/15] MIPS: JZ4770: Workaround for corrupted DMA transfers

From: Maarten ter Huurne We have seen MMC DMA transfers read corrupted data from SDRAM when a burst interval ends at physical address 0x1000. To avoid this problem, we remove the final page of low memory from the memory map. Signed-off-by: Maarten ter Huurne --- arch/mips/jz4740/setup.c |

[PATCH v6 00/15] JZ4770 SoC support

Hi Ralf, This is the V6 (and hopefully last) version of my JZ4770 patchset. - In patches 07-08/15 I simply updated Paul Burton's email address from @imgtec.com to @mips.com. - Patch 10/15 changed, now I only init mips_machtype from devicetree instead of using MIPS_MACHINE in platform code,

[PATCH v6 00/15] JZ4770 SoC support

Hi Ralf, This is the V6 (and hopefully last) version of my JZ4770 patchset. - In patches 07-08/15 I simply updated Paul Burton's email address from @imgtec.com to @mips.com. - Patch 10/15 changed, now I only init mips_machtype from devicetree instead of using MIPS_MACHINE in platform code,

[PATCH v6 15/15] MIPS: ingenic: Initial GCW Zero support

The GCW Zero (http://www.gcw-zero.com) is a retro-gaming focused handheld game console, successfully kickstarted in ~2012, running Linux. Signed-off-by: Paul Cercueil Acked-by: Mathieu Malaterre --- arch/mips/boot/dts/ingenic/Makefile | 1 +

[PATCH v6 15/15] MIPS: ingenic: Initial GCW Zero support

The GCW Zero (http://www.gcw-zero.com) is a retro-gaming focused handheld game console, successfully kickstarted in ~2012, running Linux. Signed-off-by: Paul Cercueil Acked-by: Mathieu Malaterre --- arch/mips/boot/dts/ingenic/Makefile | 1 + arch/mips/boot/dts/ingenic/gcw0.dts | 62

Re: [RFC] selftests/x86: Add test_vsyscall

On Fri, Jan 05, 2018 at 09:53:16AM -0800, Andy Lutomirski wrote: > emulate_noread would avoid one exploit technique that Kees saw > somewhere. And per-process disablement would let a system remain > compatible with old binaries without reducing security for newer > binaries. Or we can simply say

Re: [RFC] selftests/x86: Add test_vsyscall

On Fri, Jan 05, 2018 at 09:53:16AM -0800, Andy Lutomirski wrote: > emulate_noread would avoid one exploit technique that Kees saw > somewhere. And per-process disablement would let a system remain > compatible with old binaries without reducing security for newer > binaries. Or we can simply say

Re: possible deadlock in ppp_dev_uninit

On Wed, Jan 03, 2018 at 10:58:01PM -0800, syzbot wrote: > Hello, > > > WARNING: possible recursive locking detected > 4.15.0-rc6-next-20180103+ #87 Not tainted > > syzkaller221540/3462 is trying to acquire

Re: possible deadlock in ppp_dev_uninit

On Wed, Jan 03, 2018 at 10:58:01PM -0800, syzbot wrote: > Hello, > > > WARNING: possible recursive locking detected > 4.15.0-rc6-next-20180103+ #87 Not tainted > > syzkaller221540/3462 is trying to acquire

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On Fri, Jan 05, 2018 at 06:01:33PM +, Ard Biesheuvel wrote: > On 5 January 2018 at 17:58, Catalin Marinas wrote: > > On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: > >> diff --git a/arch/arm/include/asm/jump_label.h > >>

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On Fri, Jan 05, 2018 at 06:01:33PM +, Ard Biesheuvel wrote: > On 5 January 2018 at 17:58, Catalin Marinas wrote: > > On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: > >> diff --git a/arch/arm/include/asm/jump_label.h > >> b/arch/arm/include/asm/jump_label.h > >> index

Re: [PATCH 4.4 00/37] 4.4.110-stable review

> Pavel, can you send your /proc/cpuinfo on a noefi boot? (Just the > first CPU worth is fine.) With noefi option: [root@ca-ostest441 ~]# more /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU E5-2630

Re: [PATCH 4.4 00/37] 4.4.110-stable review

> Pavel, can you send your /proc/cpuinfo on a noefi boot? (Just the > first CPU worth is fine.) With noefi option: [root@ca-ostest441 ~]# more /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU E5-2630

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

[ adding Hugh ] On Thu, 4 Jan 2018, Dave Hansen wrote: > > BTW, we have just reported a bug caused by kaiser[1], which looks like > > caused by SMEP. Could you please help to have a look? > > > > [1] https://lkml.org/lkml/2018/1/5/3 > > Please report that to your kernel vendor. Your EFI page

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

[ adding Hugh ] On Thu, 4 Jan 2018, Dave Hansen wrote: > > BTW, we have just reported a bug caused by kaiser[1], which looks like > > caused by SMEP. Could you please help to have a look? > > > > [1] https://lkml.org/lkml/2018/1/5/3 > > Please report that to your kernel vendor. Your EFI page

Re: [PATCH 09/12] nvme-pci: Use PCI p2pmem subsystem to manage the CMB

On 05/01/18 11:11 AM, Keith Busch wrote: On Thu, Jan 04, 2018 at 12:01:34PM -0700, Logan Gunthorpe wrote: Register the CMB buffer as p2pmem and use the appropriate allocation functions to create and destroy the IO SQ. If the CMB supports WDS and RDS, publish it for use as p2p memory by other

Re: [PATCH 09/12] nvme-pci: Use PCI p2pmem subsystem to manage the CMB

On 05/01/18 11:11 AM, Keith Busch wrote: On Thu, Jan 04, 2018 at 12:01:34PM -0700, Logan Gunthorpe wrote: Register the CMB buffer as p2pmem and use the appropriate allocation functions to create and destroy the IO SQ. If the CMB supports WDS and RDS, publish it for use as p2p memory by other

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 5, 2018 at 9:52 AM, Greg Kroah-Hartman wrote: > On Fri, Jan 05, 2018 at 12:48:54PM -0500, Pavel Tatashin wrote: >> Boots successfully with "noefi" kernel parameter :) > > Thanks, that will help me narrow it down. I'll dig through more patches > when I get

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 5, 2018 at 9:52 AM, Greg Kroah-Hartman wrote: > On Fri, Jan 05, 2018 at 12:48:54PM -0500, Pavel Tatashin wrote: >> Boots successfully with "noefi" kernel parameter :) > > Thanks, that will help me narrow it down. I'll dig through more patches > when I get home tonight... I wish you

Re: [PATCH 09/12] nvme-pci: Use PCI p2pmem subsystem to manage the CMB

On 05/01/18 08:30 AM, Marta Rybczynska wrote: @@ -429,10 +429,7 @@ static void __nvme_submit_cmd(struct nvme_queue *nvmeq, { u16 tail = nvmeq->sq_tail; - if (nvmeq->sq_cmds_io) - memcpy_toio(>sq_cmds_io[tail], cmd, sizeof(*cmd)); - else -

Re: [PATCH 09/12] nvme-pci: Use PCI p2pmem subsystem to manage the CMB

On 05/01/18 08:30 AM, Marta Rybczynska wrote: @@ -429,10 +429,7 @@ static void __nvme_submit_cmd(struct nvme_queue *nvmeq, { u16 tail = nvmeq->sq_tail; - if (nvmeq->sq_cmds_io) - memcpy_toio(>sq_cmds_io[tail], cmd, sizeof(*cmd)); - else -

Re: [PATCH 2/5] clk: lpc32xx: read-only divider can propagate rate change

Hi Jerome, On 01/05/2018 07:09 PM, Jerome Brunet wrote: > When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the > register shall be left un-touched, but it does not mean the clock > should stop rate propagation if CLK_SET_RATE_PARENT is set > okay, the statement sounds correct,

Re: [PATCH 2/5] clk: lpc32xx: read-only divider can propagate rate change

Hi Jerome, On 01/05/2018 07:09 PM, Jerome Brunet wrote: > When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the > register shall be left un-touched, but it does not mean the clock > should stop rate propagation if CLK_SET_RATE_PARENT is set > okay, the statement sounds correct,

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 04:00:55PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 04, 2018 at 09:56:47AM -0800, Guenter Roeck wrote: > > > > FWIW, v4.4.110-rc1 boots fine when merged into chromeos-4.4, on i7-7Y75. > > That's good to know, hopefully 4.4.110-final also still works for you :) It

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 04:00:55PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 04, 2018 at 09:56:47AM -0800, Guenter Roeck wrote: > > > > FWIW, v4.4.110-rc1 boots fine when merged into chromeos-4.4, on i7-7Y75. > > That's good to know, hopefully 4.4.110-final also still works for you :) It

Re: [PATCH 1/2] MIPS: Watch: Avoid duplication of bits in mips_install_watch_registers.

On 01/02/2018 03:31 AM, Matt Redfearn wrote: Currently the bits to be set in the watchhi register in addition to that requested by the user is defined inline for each register. To avoid this, define the bits once and or that in for each register. Signed-off-by: Matt Redfearn

Re: [PATCH 2/2] MIPS: Watch: Avoid duplication of bits in mips_read_watch_registers

On 01/02/2018 03:31 AM, Matt Redfearn wrote: Currently the bits to be masked when watchhi is read is defined inline for each register. To avoid this, define the bits once and mask each register with that value. Signed-off-by: Matt Redfearn Acked-by: David Daney

Re: [PATCH 1/2] MIPS: Watch: Avoid duplication of bits in mips_install_watch_registers.

On 01/02/2018 03:31 AM, Matt Redfearn wrote: Currently the bits to be set in the watchhi register in addition to that requested by the user is defined inline for each register. To avoid this, define the bits once and or that in for each register. Signed-off-by: Matt Redfearn Looks like a

Re: [PATCH 2/2] MIPS: Watch: Avoid duplication of bits in mips_read_watch_registers

On 01/02/2018 03:31 AM, Matt Redfearn wrote: Currently the bits to be masked when watchhi is read is defined inline for each register. To avoid this, define the bits once and mask each register with that value. Signed-off-by: Matt Redfearn Acked-by: David Daney ---

Re: [PATCH 1/2] staging: fsl-mc/dpio: Add dpaa2_io_service_select() API

On 1/5/2018 6:04 AM, Ioana Radulescu wrote: > All DPIO service API functions receive a dpaa2_io service pointer > as parameter (NULL meaning any service will do) which indicates > the hardware resource to be used to execute the specified command. > > There isn't however any available API for

Re: [PATCH 1/2] staging: fsl-mc/dpio: Add dpaa2_io_service_select() API

On 1/5/2018 6:04 AM, Ioana Radulescu wrote: > All DPIO service API functions receive a dpaa2_io service pointer > as parameter (NULL meaning any service will do) which indicates > the hardware resource to be used to execute the specified command. > > There isn't however any available API for

Re: [PATCH 1/3] mm, numa: rework do_pages_move

On Fri 05-01-18 11:15:18, Cristopher Lameter wrote: > On Fri, 5 Jan 2018, Michal Hocko wrote: > > > Yes. I am really wondering because there souldn't anything specific to > > improve the situation with patch 2 and 3. Likewise the only overhead > > from the patch 1 I can see is the reduced

Re: [PATCH 1/3] mm, numa: rework do_pages_move

On Fri 05-01-18 11:15:18, Cristopher Lameter wrote: > On Fri, 5 Jan 2018, Michal Hocko wrote: > > > Yes. I am really wondering because there souldn't anything specific to > > improve the situation with patch 2 and 3. Likewise the only overhead > > from the patch 1 I can see is the reduced

Re: [PATCH 09/12] nvme-pci: Use PCI p2pmem subsystem to manage the CMB

On Thu, Jan 04, 2018 at 12:01:34PM -0700, Logan Gunthorpe wrote: > Register the CMB buffer as p2pmem and use the appropriate allocation > functions to create and destroy the IO SQ. > > If the CMB supports WDS and RDS, publish it for use as p2p memory > by other devices. <> > + if (qid &&

Re: [PATCH 09/12] nvme-pci: Use PCI p2pmem subsystem to manage the CMB

On Thu, Jan 04, 2018 at 12:01:34PM -0700, Logan Gunthorpe wrote: > Register the CMB buffer as p2pmem and use the appropriate allocation > functions to create and destroy the IO SQ. > > If the CMB supports WDS and RDS, publish it for use as p2p memory > by other devices. <> > + if (qid &&

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

Em Thu, 04 Jan 2018 21:15:31 +0100 Knut Omang escreveu: > > I'm surprised the commit message and the provided documentation say > > nothing about using CHECK=foo on the command line. That already supports > > arbitrary checkers. > > The problem, highlighted by Jim

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

Em Thu, 04 Jan 2018 21:15:31 +0100 Knut Omang escreveu: > > I'm surprised the commit message and the provided documentation say > > nothing about using CHECK=foo on the command line. That already supports > > arbitrary checkers. > > The problem, highlighted by Jim Davis in > >

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

> If the *compiler* uses the out-of-line version, that's a separate > thing. But for our asm cases, let's just make it all be the inline > case, ok? Should be a simple change. > > It also should simplify the whole target generation. None of this > silly "__x86.indirect_thunk.\reg" crap with

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

> If the *compiler* uses the out-of-line version, that's a separate > thing. But for our asm cases, let's just make it all be the inline > case, ok? Should be a simple change. > > It also should simplify the whole target generation. None of this > silly "__x86.indirect_thunk.\reg" crap with

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Fri, Jan 5, 2018 at 8:44 AM, Dan Williams wrote: > On Fri, Jan 5, 2018 at 6:40 AM, Mark Rutland wrote: >> On Thu, Jan 04, 2018 at 02:09:52PM -0800, Dan Williams wrote: >>> On Thu, Jan 4, 2018 at 3:47 AM, Mark Rutland

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Fri, Jan 5, 2018 at 8:44 AM, Dan Williams wrote: > On Fri, Jan 5, 2018 at 6:40 AM, Mark Rutland wrote: >> On Thu, Jan 04, 2018 at 02:09:52PM -0800, Dan Williams wrote: >>> On Thu, Jan 4, 2018 at 3:47 AM, Mark Rutland wrote: >>> > Hi Dan, >>> > >>> > Thanks for these examples. >>> > >>> > On

Re: [PATCH v5 13/15] MIPS: JZ4770: Workaround for corrupted DMA transfers

Hi, Hi, [...] +/* + * We have seen MMC DMA transfers read corrupted data from SDRAM when a burst + * interval ends at physical address 0x1000. To avoid this problem, we + * remove the final page of low memory from the memory map. + */ +void __init

Re: [PATCH v5 13/15] MIPS: JZ4770: Workaround for corrupted DMA transfers

Hi, Hi, [...] +/* + * We have seen MMC DMA transfers read corrupted data from SDRAM when a burst + * interval ends at physical address 0x1000. To avoid this problem, we + * remove the final page of low memory from the memory map. + */ +void __init

Re: Linux 4.4.110

On Fri, Jan 05, 2018 at 04:55:07PM +0100, Willy Tarreau wrote: > On Fri, Jan 05, 2018 at 03:54:33PM +0100, Greg KH wrote: > > I'm announcing the release of the 4.4.110 kernel. > > > > All users of the 4.4 kernel series must upgrade. > > > > But be careful, there have been some reports of

Re: [PATCH] [v4] x86/doc: add PTI description

On 01/05/2018 09:44 AM, Dave Hansen wrote: > Changes from v3: > * Increasingly minor text fixes. Yeah. Just merge it and use patches for anything else. Reviewed-by: Randy Dunlap Thanks. > Changes from v2: > * Update some wording > * Minor typo and grammar fixes > *

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On 5 January 2018 at 17:58, Catalin Marinas wrote: > On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: >> diff --git a/arch/arm/include/asm/jump_label.h >> b/arch/arm/include/asm/jump_label.h >> index e12d7d096fc0..7b05b404063a 100644 >> ---

Re: Linux 4.4.110

On Fri, Jan 05, 2018 at 04:55:07PM +0100, Willy Tarreau wrote: > On Fri, Jan 05, 2018 at 03:54:33PM +0100, Greg KH wrote: > > I'm announcing the release of the 4.4.110 kernel. > > > > All users of the 4.4 kernel series must upgrade. > > > > But be careful, there have been some reports of

Re: [PATCH] [v4] x86/doc: add PTI description

On 01/05/2018 09:44 AM, Dave Hansen wrote: > Changes from v3: > * Increasingly minor text fixes. Yeah. Just merge it and use patches for anything else. Reviewed-by: Randy Dunlap Thanks. > Changes from v2: > * Update some wording > * Minor typo and grammar fixes > * Further clarify what

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On 5 January 2018 at 17:58, Catalin Marinas wrote: > On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: >> diff --git a/arch/arm/include/asm/jump_label.h >> b/arch/arm/include/asm/jump_label.h >> index e12d7d096fc0..7b05b404063a 100644 >> --- a/arch/arm/include/asm/jump_label.h >>

Re: [RFC] selftests/x86: Add test_vsyscall

On Fri, Jan 5, 2018 at 5:40 AM, Borislav Petkov wrote: > On Thu, Jan 04, 2018 at 09:38:37PM -0800, Andy Lutomirski wrote: >> It's RFC because I want to re-read it myself first. It's also missing >> a test that will reliably make sure that vsyscall=none prevents use of >>

Re: [RFC] selftests/x86: Add test_vsyscall

On Fri, Jan 5, 2018 at 5:40 AM, Borislav Petkov wrote: > On Thu, Jan 04, 2018 at 09:38:37PM -0800, Andy Lutomirski wrote: >> It's RFC because I want to re-read it myself first. It's also missing >> a test that will reliably make sure that vsyscall=none prevents use of >> vsyscalls. > > With my

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