Re: [PATCH v6 6/8] coresight: add support for CPU debug module

On Tue, Apr 18, 2017 at 11:40:50AM -0600, Mathieu Poirier wrote: > On Thu, Apr 06, 2017 at 09:30:59PM +0800, Leo Yan wrote: > > Coresight includes debug module and usually the module connects with CPU > > debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has > > description for

Re: [PATCH v6 6/8] coresight: add support for CPU debug module

On Tue, Apr 18, 2017 at 11:40:50AM -0600, Mathieu Poirier wrote: > On Thu, Apr 06, 2017 at 09:30:59PM +0800, Leo Yan wrote: > > Coresight includes debug module and usually the module connects with CPU > > debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has > > description for

[PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

Seeing the kunmap_atomic dma_buf_op shares the same name with a macro in higmem.h, the former can be aliased if any dma-buf user includes that header. I'm personally trying to include highmem.h inside scatterlist.h and this breaks the dma-buf code proper. Christoph Hellwig suggested [1] renaming

[PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

Seeing the kunmap_atomic dma_buf_op shares the same name with a macro in higmem.h, the former can be aliased if any dma-buf user includes that header. I'm personally trying to include highmem.h inside scatterlist.h and this breaks the dma-buf code proper. Christoph Hellwig suggested [1] renaming

Re: [PATCH 2/2] hwmon: (brcmstb) Add driver for Broadcom STB DPFE

On 18 April 2017 at 15:47, Guenter Roeck wrote: > Hi Florian, > > On Tue, Apr 18, 2017 at 03:29:55PM -0700, Florian Fainelli wrote: >> Hey Guenter, >> >> On 04/18/2017 01:58 PM, Guenter Roeck wrote: >> > Hi Markus, >> > >> > On Tue, Apr 18, 2017 at 01:17:02PM -0700, Markus

Re: [PATCH 2/2] hwmon: (brcmstb) Add driver for Broadcom STB DPFE

On 18 April 2017 at 15:47, Guenter Roeck wrote: > Hi Florian, > > On Tue, Apr 18, 2017 at 03:29:55PM -0700, Florian Fainelli wrote: >> Hey Guenter, >> >> On 04/18/2017 01:58 PM, Guenter Roeck wrote: >> > Hi Markus, >> > >> > On Tue, Apr 18, 2017 at 01:17:02PM -0700, Markus Mayer wrote: >> >>

linux-next: manual merge of the vfs tree with the sparc tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in: arch/sparc/Kconfig between commit: 395102db441a ("sparc64: Use LOCKDEP_SMALL, not PROVE_LOCKING_SMALL") from the sparc tree and commit: 28fa21828dbd ("HAVE_ARCH_HARDENED_USERCOPY is unconditional now") from the vfs

linux-next: manual merge of the vfs tree with the sparc tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in: arch/sparc/Kconfig between commit: 395102db441a ("sparc64: Use LOCKDEP_SMALL, not PROVE_LOCKING_SMALL") from the sparc tree and commit: 28fa21828dbd ("HAVE_ARCH_HARDENED_USERCOPY is unconditional now") from the vfs

Re: [patch] mm, vmscan: avoid thrashing anon lru when free + file is low

Hi David, On Tue, Apr 18, 2017 at 02:32:56PM -0700, David Rientjes wrote: > On Tue, 18 Apr 2017, Minchan Kim wrote: > > > > The purpose of the code that commit 623762517e23 ("revert 'mm: vmscan: do > > > not swap anon pages just because free+file is low'") reintroduces is to > > > prefer

Re: [patch] mm, vmscan: avoid thrashing anon lru when free + file is low

Hi David, On Tue, Apr 18, 2017 at 02:32:56PM -0700, David Rientjes wrote: > On Tue, 18 Apr 2017, Minchan Kim wrote: > > > > The purpose of the code that commit 623762517e23 ("revert 'mm: vmscan: do > > > not swap anon pages just because free+file is low'") reintroduces is to > > > prefer

Re: [v4.9-rt PATCH] ARM: mm: remove tasklist locking from update_sections_early()

On Tue, Apr 18, 2017 at 1:48 PM, Grygorii Strashko wrote: > The below backtrace can be observed on -rt kernel with CONFIG_DEBUG_RODATA > option enabled: > > BUG: sleeping function called from invalid context at > kernel/locking/rtmutex.c:993 > in_atomic(): 1,

Re: [v4.9-rt PATCH] ARM: mm: remove tasklist locking from update_sections_early()

On Tue, Apr 18, 2017 at 1:48 PM, Grygorii Strashko wrote: > The below backtrace can be observed on -rt kernel with CONFIG_DEBUG_RODATA > option enabled: > > BUG: sleeping function called from invalid context at > kernel/locking/rtmutex.c:993 > in_atomic(): 1, irqs_disabled(): 128, pid: 14,

Re: [PATCH net-next v6 00/11] Landlock LSM: Toward unprivileged sandboxing

On 19/04/2017 01:26, Kees Cook wrote: > On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >> This sixth series add some changes to the previous one [1], including a >> simpler >> rule inheritance hierarchy (similar to seccomp-bpf), a ptrace scope >> protection, >> some

Re: [PATCH net-next v6 00/11] Landlock LSM: Toward unprivileged sandboxing

On 19/04/2017 01:26, Kees Cook wrote: > On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >> This sixth series add some changes to the previous one [1], including a >> simpler >> rule inheritance hierarchy (similar to seccomp-bpf), a ptrace scope >> protection, >> some file renaming

Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr

On 04/18/17 at 02:51pm, Ingo Molnar wrote: > > > I ported this series to tip:x86/boot (please post future versions against > > > that), > > > and beyond a trivial conflict with e820entry => e820_entry, it fails to > > > build on > > > 32-bit allmodconfig: > > > > > > ld: -r and -shared may

Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr

On 04/18/17 at 02:51pm, Ingo Molnar wrote: > > > I ported this series to tip:x86/boot (please post future versions against > > > that), > > > and beyond a trivial conflict with e820entry => e820_entry, it fails to > > > build on > > > 32-bit allmodconfig: > > > > > > ld: -r and -shared may

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/17/17 17:32, Tyrel Datwyler wrote: > This patch introduces event tracepoints for tracking a device_nodes > reference cycle as well as reconfig notifications generated in response > to node/property manipulations. > > With the recent upstreaming of the refcount API several device_node >

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/17/17 17:32, Tyrel Datwyler wrote: > This patch introduces event tracepoints for tracking a device_nodes > reference cycle as well as reconfig notifications generated in response > to node/property manipulations. > > With the recent upstreaming of the refcount API several device_node >

Re: [PATCH 2/4] KASLR: Parse all memmap entries in cmdline

On 04/18/17 at 04:32pm, Kees Cook wrote: > On Tue, Apr 18, 2017 at 3:52 PM, Baoquan He wrote: > > On 04/18/17 at 01:22pm, Kees Cook wrote: > >> > +#define COMMAND_LINE_SIZE 256 > >> > +static int handle_mem_memmap(void) > >> > +{ > >> > + char *args = (char

Re: [PATCH 2/4] KASLR: Parse all memmap entries in cmdline

On 04/18/17 at 04:32pm, Kees Cook wrote: > On Tue, Apr 18, 2017 at 3:52 PM, Baoquan He wrote: > > On 04/18/17 at 01:22pm, Kees Cook wrote: > >> > +#define COMMAND_LINE_SIZE 256 > >> > +static int handle_mem_memmap(void) > >> > +{ > >> > + char *args = (char *)get_cmd_line_ptr(); > >> > +

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, 2017-04-18 at 10:27 -0700, Dan Williams wrote: > > FWIW, RDMA probably wouldn't want to use a p2mem device either, we > > already have APIs that map BAR memory to user space, and would like to > > keep using them. A 'enable P2P for bar' helper function sounds better > > to me. > > ...and

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, 2017-04-18 at 10:27 -0700, Dan Williams wrote: > > FWIW, RDMA probably wouldn't want to use a p2mem device either, we > > already have APIs that map BAR memory to user space, and would like to > > keep using them. A 'enable P2P for bar' helper function sounds better > > to me. > > ...and

Re: [PATCH net-next v6 09/11] seccomp: Enhance test_harness with an assert step mechanism

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > This is useful to return an information about the error without being > able to write to TH_LOG_STREAM. > > Helpers from test_harness.h may be useful outside of the seccomp > directory. > > Signed-off-by: Mickaël Salaün

Re: [PATCH net-next v6 09/11] seccomp: Enhance test_harness with an assert step mechanism

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > This is useful to return an information about the error without being > able to write to TH_LOG_STREAM. > > Helpers from test_harness.h may be useful outside of the seccomp > directory. > > Signed-off-by: Mickaël Salaün > Cc: Andy

Re: [PATCH 1/3 v2] drm/vc4: Turn the V3D clock on at runtime.

Florian Fainelli writes: > On 04/18/2017 04:38 PM, Eric Anholt wrote: >> For the Raspberry Pi's bindings, the power domain also implicitly >> turns on the clock and deasserts reset, but for the new Cygnus port we >> start representing the clock in the devicetree. >> >> v2:

Re: [PATCH 1/3 v2] drm/vc4: Turn the V3D clock on at runtime.

Florian Fainelli writes: > On 04/18/2017 04:38 PM, Eric Anholt wrote: >> For the Raspberry Pi's bindings, the power domain also implicitly >> turns on the clock and deasserts reset, but for the new Cygnus port we >> start representing the clock in the devicetree. >> >> v2: Document the

Re: [PATCH 1/3 v2] drm/vc4: Turn the V3D clock on at runtime.

Florian Fainelli writes: > On 04/18/2017 04:38 PM, Eric Anholt wrote: >> For the Raspberry Pi's bindings, the power domain also implicitly >> turns on the clock and deasserts reset, but for the new Cygnus port we >> start representing the clock in the devicetree. >> >> v2:

Re: [PATCH 1/3 v2] drm/vc4: Turn the V3D clock on at runtime.

Florian Fainelli writes: > On 04/18/2017 04:38 PM, Eric Anholt wrote: >> For the Raspberry Pi's bindings, the power domain also implicitly >> turns on the clock and deasserts reset, but for the new Cygnus port we >> start representing the clock in the devicetree. >> >> v2: Document the

Re: [PATCH net-next v6 10/11] bpf,landlock: Add tests for Landlock

On Tue, Apr 18, 2017 at 4:53 PM, Mickaël Salaün wrote: > On 19/04/2017 01:16, Kees Cook wrote: >> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >>> --- /dev/null >>> +++ b/tools/testing/selftests/landlock/Makefile >>> @@ -0,0 +1,47 @@ >>> +LIBDIR :=

Re: [PATCH net-next v6 10/11] bpf,landlock: Add tests for Landlock

On Tue, Apr 18, 2017 at 4:53 PM, Mickaël Salaün wrote: > On 19/04/2017 01:16, Kees Cook wrote: >> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >>> --- /dev/null >>> +++ b/tools/testing/selftests/landlock/Makefile >>> @@ -0,0 +1,47 @@ >>> +LIBDIR := ../../../lib >>> +BPFOBJ :=

Re: [PATCH net-next v6 10/11] bpf,landlock: Add tests for Landlock

On 19/04/2017 01:16, Kees Cook wrote: > On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >> Test basic context access, ptrace protection and filesystem event with >> multiple cases. >> >> Changes since v5: >> * add subtype test >> * add ptrace tests >> * split and rename

Re: [PATCH net-next v6 10/11] bpf,landlock: Add tests for Landlock

On 19/04/2017 01:16, Kees Cook wrote: > On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >> Test basic context access, ptrace protection and filesystem event with >> multiple cases. >> >> Changes since v5: >> * add subtype test >> * add ptrace tests >> * split and rename files >> * cleanup

Re: [PATCH 1/3 v2] drm/vc4: Turn the V3D clock on at runtime.

On 04/18/2017 04:38 PM, Eric Anholt wrote: > For the Raspberry Pi's bindings, the power domain also implicitly > turns on the clock and deasserts reset, but for the new Cygnus port we > start representing the clock in the devicetree. > > v2: Document the clock-names property, check for -ENOENT

Re: [PATCH 1/3 v2] drm/vc4: Turn the V3D clock on at runtime.

On 04/18/2017 04:38 PM, Eric Anholt wrote: > For the Raspberry Pi's bindings, the power domain also implicitly > turns on the clock and deasserts reset, but for the new Cygnus port we > start representing the clock in the devicetree. > > v2: Document the clock-names property, check for -ENOENT

Re: [PATCH net-next v6 06/11] seccomp,landlock: Handle Landlock events per process hierarchy

On Tue, Apr 18, 2017 at 4:24 PM, Mickaël Salaün wrote: > On 19/04/2017 00:53, Kees Cook wrote: >> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >>> +#ifdef CONFIG_SECCOMP_FILTER >> >> Isn't CONFIG_SECCOMP_FILTER already required for landlock? > > Yes

Re: [PATCH net-next v6 06/11] seccomp,landlock: Handle Landlock events per process hierarchy

On Tue, Apr 18, 2017 at 4:24 PM, Mickaël Salaün wrote: > On 19/04/2017 00:53, Kees Cook wrote: >> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >>> +#ifdef CONFIG_SECCOMP_FILTER >> >> Isn't CONFIG_SECCOMP_FILTER already required for landlock? > > Yes it is, but Landlock could only/also

Re: [PATCH net-next v6 04/11] landlock: Add LSM hooks related to filesystem

On Tue, Apr 18, 2017 at 4:16 PM, Casey Schaufler wrote: > On 4/18/2017 3:44 PM, Mickaël Salaün wrote: >> On 19/04/2017 00:17, Kees Cook wrote: >>> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: +void __init landlock_add_hooks(void) +{

Re: [PATCH net-next v6 04/11] landlock: Add LSM hooks related to filesystem

On Tue, Apr 18, 2017 at 4:16 PM, Casey Schaufler wrote: > On 4/18/2017 3:44 PM, Mickaël Salaün wrote: >> On 19/04/2017 00:17, Kees Cook wrote: >>> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: +void __init landlock_add_hooks(void) +{ + pr_info("landlock: Version

Re: [PATCH net-next v6 04/11] landlock: Add LSM hooks related to filesystem

On Tue, Apr 18, 2017 at 3:44 PM, Mickaël Salaün wrote: > > On 19/04/2017 00:17, Kees Cook wrote: >> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >>> Handle 33 filesystem-related LSM hooks for the Landlock filesystem >>> event:

Re: [PATCH net-next v6 04/11] landlock: Add LSM hooks related to filesystem

On Tue, Apr 18, 2017 at 3:44 PM, Mickaël Salaün wrote: > > On 19/04/2017 00:17, Kees Cook wrote: >> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >>> Handle 33 filesystem-related LSM hooks for the Landlock filesystem >>> event: LANDLOCK_SUBTYPE_EVENT_FS. >>> >>> A Landlock event wrap

[PATCH 1/3 v2] drm/vc4: Turn the V3D clock on at runtime.

For the Raspberry Pi's bindings, the power domain also implicitly turns on the clock and deasserts reset, but for the new Cygnus port we start representing the clock in the devicetree. v2: Document the clock-names property, check for -ENOENT for no clock in DT. Signed-off-by: Eric Anholt

[PATCH 1/3 v2] drm/vc4: Turn the V3D clock on at runtime.

For the Raspberry Pi's bindings, the power domain also implicitly turns on the clock and deasserts reset, but for the new Cygnus port we start representing the clock in the devicetree. v2: Document the clock-names property, check for -ENOENT for no clock in DT. Signed-off-by: Eric Anholt

Re: [PATCH net-next v6 08/11] bpf: Add a Landlock sandbox example

On 19/04/2017 01:06, Kees Cook wrote: > On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >> Add a basic sandbox tool to create a process isolated from some part of >> the system. This sandbox create a read-only environment. It is only >> allowed to write to a character

Re: [PATCH net-next v6 08/11] bpf: Add a Landlock sandbox example

On 19/04/2017 01:06, Kees Cook wrote: > On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >> Add a basic sandbox tool to create a process isolated from some part of >> the system. This sandbox create a read-only environment. It is only >> allowed to write to a character device such as a

[PATCH] CHROMIUM: ecryptfs: sync before truncating lower inode

If the updated ecryptfs header data is not written to disk before the lower file is truncated, a crash may leave the filesystem in the state when the lower file truncation is journaled, while the changes to the ecryptfs header are lost (if the underlying filesystem is ext4 in data=ordered mode,

[PATCH] CHROMIUM: ecryptfs: sync before truncating lower inode

If the updated ecryptfs header data is not written to disk before the lower file is truncated, a crash may leave the filesystem in the state when the lower file truncation is journaled, while the changes to the ecryptfs header are lost (if the underlying filesystem is ext4 in data=ordered mode,

[PATCH] ARM: dts: bcm-cygnus: Add 911360's V3D device.

This loads the VC4 driver on the 911360_entphn platform (with the corresponding series sent to dri-devel), which is supported by master of the Mesa tree. Signed-off-by: Eric Anholt --- arch/arm/boot/dts/bcm-cygnus.dtsi | 13 +

[PATCH] ARM: dts: bcm-cygnus: Add 911360's V3D device.

This loads the VC4 driver on the 911360_entphn platform (with the corresponding series sent to dri-devel), which is supported by master of the Mesa tree. Signed-off-by: Eric Anholt --- arch/arm/boot/dts/bcm-cygnus.dtsi | 13 + arch/arm/boot/dts/bcm911360_entphn.dts | 8

Re: [PATCH 2/4] KASLR: Parse all memmap entries in cmdline

On Tue, Apr 18, 2017 at 3:52 PM, Baoquan He wrote: > On 04/18/17 at 01:22pm, Kees Cook wrote: >> > +#define COMMAND_LINE_SIZE 256 >> > +static int handle_mem_memmap(void) >> > +{ >> > + char *args = (char *)get_cmd_line_ptr(); >> > + char

[PATCH] nvmet: convert from kmap to nvmet_copy_from_sgl

This is safer as it doesn't rely on the data being stored in a single page in an sgl. It also aids our effort to start phasing out users of sg_page. See [1]. For this we kmalloc some memory, copy to it and free at the end. Note: we can't allocate this memory on the stack as the kbuild test robot

[PATCH] nvmet: convert from kmap to nvmet_copy_from_sgl

This is safer as it doesn't rely on the data being stored in a single page in an sgl. It also aids our effort to start phasing out users of sg_page. See [1]. For this we kmalloc some memory, copy to it and free at the end. Note: we can't allocate this memory on the stack as the kbuild test robot

Re: [PATCH 2/4] KASLR: Parse all memmap entries in cmdline

On Tue, Apr 18, 2017 at 3:52 PM, Baoquan He wrote: > On 04/18/17 at 01:22pm, Kees Cook wrote: >> > +#define COMMAND_LINE_SIZE 256 >> > +static int handle_mem_memmap(void) >> > +{ >> > + char *args = (char *)get_cmd_line_ptr(); >> > + char tmp_cmdline[COMMAND_LINE_SIZE]; >> >> Can't

[PATCH v7 2/4] mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols

Before this patch, m25p80_read() supported few SPI protocols: - regular SPI 1-1-1 - SPI Dual Output 1-1-2 - SPI Quad Output 1-1-4 On the other hand, m25p80_write() only supported SPI 1-1-1. This patch updates both m25p80_read() and m25p80_write() functions to let them support SPI 1-2-2 and SPI

[PATCH v7 2/4] mtd: m25p80: add support of SPI 1-2-2 and 1-4-4 protocols

Before this patch, m25p80_read() supported few SPI protocols: - regular SPI 1-1-1 - SPI Dual Output 1-1-2 - SPI Quad Output 1-1-4 On the other hand, m25p80_write() only supported SPI 1-1-1. This patch updates both m25p80_read() and m25p80_write() functions to let them support SPI 1-2-2 and SPI

[PATCH v2] clocksource: Use GENMASK_ULL in definition of CLOCKSOURCE_MASK

Besides reusing existing code this removes the special case handling for 64-bit masks, which causes clang to raise a shift count overflow warning due to https://bugs.llvm.org//show_bug.cgi?id=10030. Suggested-by: Dmitry Torokhov Signed-off-by: Matthias Kaehlcke

[PATCH v2] clocksource: Use GENMASK_ULL in definition of CLOCKSOURCE_MASK

Besides reusing existing code this removes the special case handling for 64-bit masks, which causes clang to raise a shift count overflow warning due to https://bugs.llvm.org//show_bug.cgi?id=10030. Suggested-by: Dmitry Torokhov Signed-off-by: Matthias Kaehlcke --- Changes in v2: - Remove

[PATCH v7 1/4] mtd: spi-nor: introduce SPI 1-2-2 and SPI 1-4-4 protocols

This patch changes the prototype of spi_nor_scan(): its 3rd parameter is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor framework about the actual hardware capabilities supported by the SPI controller and its driver. Besides, this patch also introduces a new 'struct

[PATCH v7 1/4] mtd: spi-nor: introduce SPI 1-2-2 and SPI 1-4-4 protocols

This patch changes the prototype of spi_nor_scan(): its 3rd parameter is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor framework about the actual hardware capabilities supported by the SPI controller and its driver. Besides, this patch also introduces a new 'struct

[PATCH v7 4/4] mtd: spi-nor: introduce Octo SPI protocols

This patch starts adding support to Octo SPI protocols (SPI x-y-8). Op codes for Fast Read and/or Page Program operations using Octo SPI protocols are not known yet (no JEDEC specification has defined them yet) but we'd rather introduce the Octo SPI protocols now so it's done as it should be.

[PATCH v7 4/4] mtd: spi-nor: introduce Octo SPI protocols

This patch starts adding support to Octo SPI protocols (SPI x-y-8). Op codes for Fast Read and/or Page Program operations using Octo SPI protocols are not known yet (no JEDEC specification has defined them yet) but we'd rather introduce the Octo SPI protocols now so it's done as it should be.

[PATCH v7 3/4] mtd: spi-nor: introduce Double Transfer Rate (DTR) SPI protocols

This patch introduces support to Double Transfer Rate (DTR) SPI protocols. DTR is used only for Fast Read operations. According to manufacturer datasheets, whatever the number of I/O lines used during instruction (x) and address/mode/dummy (y) clock cycles, DTR is used only during data (z) clock

[PATCH v7 3/4] mtd: spi-nor: introduce Double Transfer Rate (DTR) SPI protocols

This patch introduces support to Double Transfer Rate (DTR) SPI protocols. DTR is used only for Fast Read operations. According to manufacturer datasheets, whatever the number of I/O lines used during instruction (x) and address/mode/dummy (y) clock cycles, DTR is used only during data (z) clock

[PATCH v7 0/4] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories

Hi all, based on git-hub/spi-nor. The 4 patches have passed the checkpatch test. DISCLAIMER: despite what the subjet claims, I've removed the SFDP patches from this version since they are still RFC/WIP. However I've chosen not to change the subjet line so it's easier to make the link between

[PATCH v7 0/4] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories

Hi all, based on git-hub/spi-nor. The 4 patches have passed the checkpatch test. DISCLAIMER: despite what the subjet claims, I've removed the SFDP patches from this version since they are still RFC/WIP. However I've chosen not to change the subjet line so it's easier to make the link between

Re: [PATCH net-next v6 00/11] Landlock LSM: Toward unprivileged sandboxing

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > This sixth series add some changes to the previous one [1], including a > simpler > rule inheritance hierarchy (similar to seccomp-bpf), a ptrace scope > protection, > some file renaming (better feature identification

Re: [PATCH net-next v6 06/11] seccomp,landlock: Handle Landlock events per process hierarchy

On 19/04/2017 00:53, Kees Cook wrote: > On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >> The seccomp(2) syscall can be used by a task to apply a Landlock rule to >> itself. As a seccomp filter, a Landlock rule is enforced for the current >> task and all its future

Re: [PATCH net-next v6 00/11] Landlock LSM: Toward unprivileged sandboxing

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > This sixth series add some changes to the previous one [1], including a > simpler > rule inheritance hierarchy (similar to seccomp-bpf), a ptrace scope > protection, > some file renaming (better feature identification per file), a

Re: [PATCH net-next v6 06/11] seccomp,landlock: Handle Landlock events per process hierarchy

On 19/04/2017 00:53, Kees Cook wrote: > On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >> The seccomp(2) syscall can be used by a task to apply a Landlock rule to >> itself. As a seccomp filter, a Landlock rule is enforced for the current >> task and all its future children. A rule is

Re: [PATCH v2 0/8] NFC: fix device allocation and nfcmrvl crashes

Hi Johan, On Tue, Apr 18, 2017 at 12:09:16PM +0200, Johan Hovold wrote: > On Thu, Mar 30, 2017 at 12:15:34PM +0200, Johan Hovold wrote: > > This started out with the observation that the nfcmrvl_uart driver > > unconditionally dereferenced the tty class device despite the fact that > > not every

Re: [PATCH v2 0/8] NFC: fix device allocation and nfcmrvl crashes

Hi Johan, On Tue, Apr 18, 2017 at 12:09:16PM +0200, Johan Hovold wrote: > On Thu, Mar 30, 2017 at 12:15:34PM +0200, Johan Hovold wrote: > > This started out with the observation that the nfcmrvl_uart driver > > unconditionally dereferenced the tty class device despite the fact that > > not every

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 03:51:27PM -0700, Dan Williams wrote: > > This really seems like much less trouble than trying to wrapper all > > the arch's dma ops, and doesn't have the wonky restrictions. > > I don't think the root bus iommu drivers have any business knowing or > caring about dma

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 03:51:27PM -0700, Dan Williams wrote: > > This really seems like much less trouble than trying to wrapper all > > the arch's dma ops, and doesn't have the wonky restrictions. > > I don't think the root bus iommu drivers have any business knowing or > caring about dma

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

On 4/18/17 2:43 PM, Andrey Konovalov wrote: > I've finally managed to reproduce one of the crashes on commit > 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7). > > I'm not sure if this bug has the same root cause as the first one > reported in this thread, but it definitely has to do with

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

On 4/18/17 2:43 PM, Andrey Konovalov wrote: > I've finally managed to reproduce one of the crashes on commit > 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7). > > I'm not sure if this bug has the same root cause as the first one > reported in this thread, but it definitely has to do with

Re: [PATCH net-next v6 10/11] bpf,landlock: Add tests for Landlock

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > Test basic context access, ptrace protection and filesystem event with > multiple cases. > > Changes since v5: > * add subtype test > * add ptrace tests > * split and rename files > * cleanup and rebase > > Signed-off-by:

Re: [PATCH net-next v6 10/11] bpf,landlock: Add tests for Landlock

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > Test basic context access, ptrace protection and filesystem event with > multiple cases. > > Changes since v5: > * add subtype test > * add ptrace tests > * split and rename files > * cleanup and rebase > > Signed-off-by: Mickaël Salaün >

Re: [PATCH net-next v6 04/11] landlock: Add LSM hooks related to filesystem

On 4/18/2017 3:44 PM, Mickaël Salaün wrote: > On 19/04/2017 00:17, Kees Cook wrote: >> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >>> Handle 33 filesystem-related LSM hooks for the Landlock filesystem >>> event: LANDLOCK_SUBTYPE_EVENT_FS. >>> >>> A Landlock event

Re: [PATCH net-next v6 04/11] landlock: Add LSM hooks related to filesystem

On 4/18/2017 3:44 PM, Mickaël Salaün wrote: > On 19/04/2017 00:17, Kees Cook wrote: >> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >>> Handle 33 filesystem-related LSM hooks for the Landlock filesystem >>> event: LANDLOCK_SUBTYPE_EVENT_FS. >>> >>> A Landlock event wrap LSM hooks for

Re: [PATCH v6 5/8] coresight: use const for device_node structures

Hi Mathieu, On Tue, Apr 18, 2017 at 09:24:47AM -0600, Mathieu Poirier wrote: > On Thu, Apr 06, 2017 at 09:30:58PM +0800, Leo Yan wrote: > > Almost low level functions from open firmware have used const to > > qualify device_node structures, so add const for device_node > > parameters in

Re: [PATCH v6 5/8] coresight: use const for device_node structures

Hi Mathieu, On Tue, Apr 18, 2017 at 09:24:47AM -0600, Mathieu Poirier wrote: > On Thu, Apr 06, 2017 at 09:30:58PM +0800, Leo Yan wrote: > > Almost low level functions from open firmware have used const to > > qualify device_node structures, so add const for device_node > > parameters in

Re: [PATCH 3/4] KASLR: Handle memory limit specified by memmap and mem option

On 04/18/17 at 01:36pm, Kees Cook wrote: > On Mon, Apr 17, 2017 at 6:34 AM, Baoquan He wrote: > > Option mem= will limit the max address system can use. Any memory > > region above the limit will be removed. And memmap=nn[KMG] which > > has no offset specified has the same

Re: [PATCH 3/4] KASLR: Handle memory limit specified by memmap and mem option

On 04/18/17 at 01:36pm, Kees Cook wrote: > On Mon, Apr 17, 2017 at 6:34 AM, Baoquan He wrote: > > Option mem= will limit the max address system can use. Any memory > > region above the limit will be removed. And memmap=nn[KMG] which > > has no offset specified has the same behaviour as mem=.

[PATCH V15 03/11] cper: add timestamp print to CPER status printing

The ACPI 6.1 spec added a timestamp to the HEST generic data structure. Print the timestamp out when printing out the error status information. Signed-off-by: Tyler Baicar CC: Jonathan (Zhixiong) Zhang Reviewed-by: James Morse

[PATCH V15 03/11] cper: add timestamp print to CPER status printing

The ACPI 6.1 spec added a timestamp to the HEST generic data structure. Print the timestamp out when printing out the error status information. Signed-off-by: Tyler Baicar CC: Jonathan (Zhixiong) Zhang Reviewed-by: James Morse Reviewed-by: Ard Biesheuvel --- drivers/firmware/efi/cper.c | 28

[PATCH V15 04/11] efi: parse ARM processor error

Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Tyler Baicar CC:

[PATCH V15 04/11] efi: parse ARM processor error

Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Tyler Baicar CC: Jonathan (Zhixiong) Zhang

[PATCH V15 02/11] ras: acpi/apei: cper: add support for generic data v3 structure

The ACPI 6.1 spec adds a new version of the generic data structure. Add support to handle the new structure as well as properly verify and iterate through the generic data entries. Signed-off-by: Tyler Baicar CC: Jonathan (Zhixiong) Zhang

[PATCH V15 02/11] ras: acpi/apei: cper: add support for generic data v3 structure

The ACPI 6.1 spec adds a new version of the generic data structure. Add support to handle the new structure as well as properly verify and iterate through the generic data entries. Signed-off-by: Tyler Baicar CC: Jonathan (Zhixiong) Zhang Reviewed-by: James Morse Reviewed-by: Ard Biesheuvel

[PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then this function can be registered into the SEA exception handler. That way GHES will parse and

[PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then this function can be registered into the SEA exception handler. That way GHES will parse and

[PATCH V15 08/11] efi: print unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with one of the section types that the kernel knows how to parse, the section is skipped. Therefore, user is

[PATCH V15 08/11] efi: print unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with one of the section types that the kernel knows how to parse, the section is skipped. Therefore, user is

[PATCH V15 07/11] acpi: apei: panic OS with fatal error status block

From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the firmware first model, the platform could inform the OS about a fatal hardware error through the non-NMI GHES notification

[PATCH V15 07/11] acpi: apei: panic OS with fatal error status block

From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the firmware first model, the platform could inform the OS about a fatal hardware error through the non-NMI GHES notification type. The OS should

Re: [PATCH v7 3/4] mtd: spi-nor: introduce Double Transfer Rate (DTR) SPI protocols

On 04/19/2017 12:51 AM, Cyrille Pitchen wrote: > This patch introduces support to Double Transfer Rate (DTR) SPI protocols. > DTR is used only for Fast Read operations. > > According to manufacturer datasheets, whatever the number of I/O lines > used during instruction (x) and address/mode/dummy

Re: [PATCH v7 4/4] mtd: spi-nor: introduce Octo SPI protocols

On 04/19/2017 12:51 AM, Cyrille Pitchen wrote: > This patch starts adding support to Octo SPI protocols (SPI x-y-8). > > Op codes for Fast Read and/or Page Program operations using Octo SPI > protocols are not known yet (no JEDEC specification has defined them yet) > but we'd rather introduce the

Re: [PATCH v7 1/4] mtd: spi-nor: introduce SPI 1-2-2 and SPI 1-4-4 protocols

On 04/19/2017 12:51 AM, Cyrille Pitchen wrote: > This patch changes the prototype of spi_nor_scan(): its 3rd parameter > is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor > framework about the actual hardware capabilities supported by the SPI > controller and its driver. >

Re: [PATCH v7 3/4] mtd: spi-nor: introduce Double Transfer Rate (DTR) SPI protocols

On 04/19/2017 12:51 AM, Cyrille Pitchen wrote: > This patch introduces support to Double Transfer Rate (DTR) SPI protocols. > DTR is used only for Fast Read operations. > > According to manufacturer datasheets, whatever the number of I/O lines > used during instruction (x) and address/mode/dummy

Re: [PATCH v7 4/4] mtd: spi-nor: introduce Octo SPI protocols

On 04/19/2017 12:51 AM, Cyrille Pitchen wrote: > This patch starts adding support to Octo SPI protocols (SPI x-y-8). > > Op codes for Fast Read and/or Page Program operations using Octo SPI > protocols are not known yet (no JEDEC specification has defined them yet) > but we'd rather introduce the

Re: [PATCH v7 1/4] mtd: spi-nor: introduce SPI 1-2-2 and SPI 1-4-4 protocols

On 04/19/2017 12:51 AM, Cyrille Pitchen wrote: > This patch changes the prototype of spi_nor_scan(): its 3rd parameter > is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor > framework about the actual hardware capabilities supported by the SPI > controller and its driver. >

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