[PATCH V15 10/11] trace, ras: add ARM processor error trace event

Currently there are trace events for the various RAS errors with the exception of ARM processor type errors. Add a new trace event for such errors so that the user will know when they occur. These trace events are consistent with the ARM processor error section type defined in UEFI 2.6 spec

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

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 TTY: > > # :> X > # echo

[PATCH V15 10/11] trace, ras: add ARM processor error trace event

Currently there are trace events for the various RAS errors with the exception of ARM processor type errors. Add a new trace event for such errors so that the user will know when they occur. These trace events are consistent with the ARM processor error section type defined in UEFI 2.6 spec

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

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 TTY: > > # :> X > # echo $? > 0 > #

[PATCH V15 11/11] arm/arm64: KVM: add guest SEA support

Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. When an SEA occurs in the guest kernel, the guest exits and is routed to kvm_handle_guest_abort(). Prior to this patch, a print

[PATCH V15 11/11] arm/arm64: KVM: add guest SEA support

Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. When an SEA occurs in the guest kernel, the guest exits and is routed to kvm_handle_guest_abort(). Prior to this patch, a print

[PATCH V15 09/11] ras: acpi / apei: generate trace event for 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 any section type that the kernel knows how to parse, trace event is not generated for such section. And

[PATCH V15 09/11] ras: acpi / apei: generate trace event for 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 any section type that the kernel knows how to parse, trace event is not generated for such section. And

[PATCH V15 05/11] arm64: exception: handle Synchronous External Abort

SEA exceptions are often caused by an uncorrected hardware error, and are handled when data abort and instruction abort exception classes have specific values for their Fault Status Code. When SEA occurs, before killing the process, report the error in the kernel logs. Update fault_info[] with

[PATCH V15 05/11] arm64: exception: handle Synchronous External Abort

SEA exceptions are often caused by an uncorrected hardware error, and are handled when data abort and instruction abort exception classes have specific values for their Fault Status Code. When SEA occurs, before killing the process, report the error in the kernel logs. Update fault_info[] with

[PATCH V15 00/11] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

When a memory error, CPU error, PCIe error, or other type of hardware error that's covered by RAS occurs, firmware should populate the shared GHES memory location with the proper GHES structures to notify the OS of the error. For example, platforms that implement firmware first handling may

[PATCH V15 00/11] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

When a memory error, CPU error, PCIe error, or other type of hardware error that's covered by RAS occurs, firmware should populate the shared GHES memory location with the proper GHES structures to notify the OS of the error. For example, platforms that implement firmware first handling may

[PATCH V15 01/11] acpi: apei: read ack upon ghes record consumption

A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS controller produces multiple error records, then they may be overwritten before the OS has consumed

[PATCH V15 01/11] acpi: apei: read ack upon ghes record consumption

A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS controller produces multiple error records, then they may be overwritten before the OS has consumed

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

On 18/04/17 04:24 PM, Jason Gunthorpe wrote: > Try and write a stacked map_sg function like you describe and you will > see how horrible it quickly becomes. Yes, unfortunately, I have to agree with this statement completely. > Since dma mapping is a performance path we must be careful not to >

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

On 18/04/17 04:24 PM, Jason Gunthorpe wrote: > Try and write a stacked map_sg function like you describe and you will > see how horrible it quickly becomes. Yes, unfortunately, I have to agree with this statement completely. > Since dma mapping is a performance path we must be careful not to >

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

On Tue, Apr 18, 2017 at 3:56 PM, Logan Gunthorpe wrote: > > > On 18/04/17 04:50 PM, Dan Williams wrote: >> On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe wrote: >>> >>> >>> On 18/04/17 04:28 PM, Dan Williams wrote: Unlike the pci bus address

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

On Tue, Apr 18, 2017 at 3:56 PM, Logan Gunthorpe wrote: > > > On 18/04/17 04:50 PM, Dan Williams wrote: >> On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe wrote: >>> >>> >>> On 18/04/17 04:28 PM, Dan Williams wrote: Unlike the pci bus address offset case which I think is fundamental to

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

On 18/04/17 04:50 PM, Dan Williams wrote: > On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe wrote: >> >> >> On 18/04/17 04:28 PM, Dan Williams wrote: >>> Unlike the pci bus address offset case which I think is fundamental to >>> support since shipping archs do this today,

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

On 18/04/17 04:50 PM, Dan Williams wrote: > On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe wrote: >> >> >> On 18/04/17 04:28 PM, Dan Williams wrote: >>> Unlike the pci bus address offset case which I think is fundamental to >>> support since shipping archs do this today, I think it is ok to

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

On Fri, Mar 31, 2017 at 2:15 PM, Mickaël Salaün wrote: > > > On 29/03/2017 12:35, Djalal Harouni wrote: >> On Wed, Mar 29, 2017 at 1:46 AM, Mickaël Salaün wrote: > >>> @@ -25,6 +30,9 @@ struct seccomp_filter; >>> struct seccomp { >>> int mode; >>>

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

On Fri, Mar 31, 2017 at 2:15 PM, Mickaël Salaün wrote: > > > On 29/03/2017 12:35, Djalal Harouni wrote: >> On Wed, Mar 29, 2017 at 1:46 AM, Mickaël Salaün wrote: > >>> @@ -25,6 +30,9 @@ struct seccomp_filter; >>> struct seccomp { >>> int mode; >>> struct seccomp_filter *filter;

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

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 immutable and a task can >

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

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 immutable and a task can > only add new

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

Hi Kees, Thanks for your reviewing! On 04/18/17 at 01:22pm, Kees Cook wrote: > > static int > > parse_memmap(char *p, unsigned long long *start, unsigned long long *size) > > @@ -142,40 +112,33 @@ parse_memmap(char *p, unsigned long long *start, > > unsigned long long *size) > >

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

Hi Kees, Thanks for your reviewing! On 04/18/17 at 01:22pm, Kees Cook wrote: > > static int > > parse_memmap(char *p, unsigned long long *start, unsigned long long *size) > > @@ -142,40 +112,33 @@ parse_memmap(char *p, unsigned long long *start, > > unsigned long long *size) > >

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

On Tue, Apr 18, 2017 at 3:46 PM, Benjamin Herrenschmidt wrote: > 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 >>

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

On Tue, Apr 18, 2017 at 3:46 PM, Benjamin Herrenschmidt wrote: > 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

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

On Tue, Apr 18, 2017 at 3:42 PM, Jason Gunthorpe wrote: > On Tue, Apr 18, 2017 at 03:28:17PM -0700, Dan Williams wrote: > >> Unlike the pci bus address offset case which I think is fundamental to >> support since shipping archs do this toda > > But we can support

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

On Tue, Apr 18, 2017 at 3:42 PM, Jason Gunthorpe wrote: > On Tue, Apr 18, 2017 at 03:28:17PM -0700, Dan Williams wrote: > >> Unlike the pci bus address offset case which I think is fundamental to >> support since shipping archs do this toda > > But we can support this by modifying those arch's

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

On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe wrote: > > > On 18/04/17 04:28 PM, Dan Williams wrote: >> Unlike the pci bus address offset case which I think is fundamental to >> support since shipping archs do this today, I think it is ok to say >> p2p is restricted to a

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

On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe wrote: > > > On 18/04/17 04:28 PM, Dan Williams wrote: >> Unlike the pci bus address offset case which I think is fundamental to >> support since shipping archs do this today, I think it is ok to say >> p2p is restricted to a single sgl that gets

Re: RFC: WMI Enhancements

On Tue, Apr 18, 2017 at 09:28:36PM +0200, Pali Rohár wrote: > On Tuesday 18 April 2017 18:33:25 Darren Hart wrote: > > On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote: > > > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote: > > > > On Mon, Apr 17, 2017 at 03:03:29PM -0700,

Re: RFC: WMI Enhancements

On Tue, Apr 18, 2017 at 09:28:36PM +0200, Pali Rohár wrote: > On Tuesday 18 April 2017 18:33:25 Darren Hart wrote: > > On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote: > > > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote: > > > > On Mon, Apr 17, 2017 at 03:03:29PM -0700,

Re: [PATCH net-next v6 05/11] seccomp: Split put_seccomp_filter() with put_seccomp()

On 19/04/2017 00:23, Kees Cook wrote: > On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >> The semantic is unchanged. This will be useful for the Landlock >> integration with seccomp (next commit). >> >> Signed-off-by: Mickaël Salaün >> Cc: Kees Cook

Re: [PATCH net-next v6 05/11] seccomp: Split put_seccomp_filter() with put_seccomp()

On 19/04/2017 00:23, Kees Cook wrote: > On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: >> The semantic is unchanged. This will be useful for the Landlock >> integration with seccomp (next commit). >> >> Signed-off-by: Mickaël Salaün >> Cc: Kees Cook >> Cc: Andy Lutomirski >> Cc: Will

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

On 18/04/17 04:28 PM, Dan Williams wrote: > Unlike the pci bus address offset case which I think is fundamental to > support since shipping archs do this today, I think it is ok to say > p2p is restricted to a single sgl that gets to talk to host memory or > a single device. That said, what's

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

On 18/04/17 04:28 PM, Dan Williams wrote: > Unlike the pci bus address offset case which I think is fundamental to > support since shipping archs do this today, I think it is ok to say > p2p is restricted to a single sgl that gets to talk to host memory or > a single device. That said, what's

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

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: > >> From: Markus Mayer > >> > >> This driver

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

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: > >> From: Markus Mayer > >> > >> This driver allows access to DRAM

Re: [PATCH 1/4] fs: fix data invalidation in the cleancache during direct IO

On Fri, 14 Apr 2017 17:07:50 +0300 Andrey Ryabinin wrote: > Some direct write fs hooks call invalidate_inode_pages2[_range]() > conditionally iff mapping->nrpages is not zero. If page cache is empty, > buffered read following after direct IO write would get stale data

Re: [PATCH 1/4] fs: fix data invalidation in the cleancache during direct IO

On Fri, 14 Apr 2017 17:07:50 +0300 Andrey Ryabinin wrote: > Some direct write fs hooks call invalidate_inode_pages2[_range]() > conditionally iff mapping->nrpages is not zero. If page cache is empty, > buffered read following after direct IO write would get stale data from > the cleancache. >

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

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 similar kernel object types (e.g.

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

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 similar kernel object types (e.g. >> struct file,

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

On Tue, Apr 18, 2017 at 03:28:17PM -0700, Dan Williams wrote: > Unlike the pci bus address offset case which I think is fundamental to > support since shipping archs do this toda But we can support this by modifying those arch's unique dma_ops directly. Eg as I explained, my

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

On Tue, Apr 18, 2017 at 03:28:17PM -0700, Dan Williams wrote: > Unlike the pci bus address offset case which I think is fundamental to > support since shipping archs do this toda But we can support this by modifying those arch's unique dma_ops directly. Eg as I explained, my

Re: [PATCH v2 2/3] mtd: dataflash: Improve coding style in jedec_probe()

On 04/19/2017 12:36 AM, Joe Perches wrote: > On Tue, 2017-04-18 at 20:25 +0200, Marek Vasut wrote: >> On 04/18/2017 04:21 PM, Andrey Smirnov wrote: >>> As per request from Marek Vasut, change the following: >> >> Does that really have to be in the commit message ? ^_^' >> >>>- Replace

Re: [PATCH v2 2/3] mtd: dataflash: Improve coding style in jedec_probe()

On 04/19/2017 12:36 AM, Joe Perches wrote: > On Tue, 2017-04-18 at 20:25 +0200, Marek Vasut wrote: >> On 04/18/2017 04:21 PM, Andrey Smirnov wrote: >>> As per request from Marek Vasut, change the following: >> >> Does that really have to be in the commit message ? ^_^' >> >>>- Replace

Re: [PATCH v2 2/3] mtd: dataflash: Improve coding style in jedec_probe()

On Tue, 2017-04-18 at 20:25 +0200, Marek Vasut wrote: > On 04/18/2017 04:21 PM, Andrey Smirnov wrote: > > As per request from Marek Vasut, change the following: > > Does that really have to be in the commit message ? ^_^' > > >- Replace indentation between type and name of local variable

Re: [PATCH v2 2/3] mtd: dataflash: Improve coding style in jedec_probe()

On Tue, 2017-04-18 at 20:25 +0200, Marek Vasut wrote: > On 04/18/2017 04:21 PM, Andrey Smirnov wrote: > > As per request from Marek Vasut, change the following: > > Does that really have to be in the commit message ? ^_^' > > >- Replace indentation between type and name of local variable

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

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: >> From: Markus Mayer >> >> This driver allows access to DRAM properties, such as the refresh rate, >> via the Broadcom STB DDR PHY Front

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

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: >> From: Markus Mayer >> >> This driver allows access to DRAM properties, such as the refresh rate, >> via the Broadcom STB DDR PHY Front End (DPFE). The

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

On Tue, Apr 18, 2017 at 3:15 PM, Logan Gunthorpe wrote: > > > On 18/04/17 03:36 PM, Dan Williams wrote: >> On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe >> wrote: >>> On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: > I

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

On Tue, Apr 18, 2017 at 3:15 PM, Logan Gunthorpe wrote: > > > On 18/04/17 03:36 PM, Dan Williams wrote: >> On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe >> wrote: >>> On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: > I think this opens an even bigger can of worms..

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

On Tue, Apr 18, 2017 at 03:31:58PM -0600, Logan Gunthorpe wrote: > 1) It means that sg_has_p2p has to walk the entire sg and check every > page. Then map_sg_p2p/map_sg has to walk it again and repeat the check > then do some operation per page. If anyone is concerned about the > dma_map

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

On Tue, Apr 18, 2017 at 03:31:58PM -0600, Logan Gunthorpe wrote: > 1) It means that sg_has_p2p has to walk the entire sg and check every > page. Then map_sg_p2p/map_sg has to walk it again and repeat the check > then do some operation per page. If anyone is concerned about the > dma_map

Re: [PATCH net-next v6 05/11] seccomp: Split put_seccomp_filter() with put_seccomp()

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > The semantic is unchanged. This will be useful for the Landlock > integration with seccomp (next commit). > > Signed-off-by: Mickaël Salaün > Cc: Kees Cook > Cc: Andy Lutomirski

Re: [PATCH net-next v6 05/11] seccomp: Split put_seccomp_filter() with put_seccomp()

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > The semantic is unchanged. This will be useful for the Landlock > integration with seccomp (next commit). > > Signed-off-by: Mickaël Salaün > Cc: Kees Cook > Cc: Andy Lutomirski > Cc: Will Drewry > --- > include/linux/seccomp.h | 4

Re: [PATCH] ARM: dts: rockchip: reuse firefly dtsi

Hi Eddie, Am Dienstag, 18. April 2017, 20:15:27 CEST schrieb Eddie Cai: > firefly reload is very similar with firefly board, so reuse firefly dtsi > > Signed-off-by: Eddie Cai > --- > arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 310 -- >

Re: [PATCH] ARM: dts: rockchip: reuse firefly dtsi

Hi Eddie, Am Dienstag, 18. April 2017, 20:15:27 CEST schrieb Eddie Cai: > firefly reload is very similar with firefly board, so reuse firefly dtsi > > Signed-off-by: Eddie Cai > --- > arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 310 -- >

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

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 similar kernel object types (e.g. > struct file, struct path...). Multiple LSM

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

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 similar kernel object types (e.g. > struct file, struct path...). Multiple LSM hooks can trigger

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

On 18/04/17 03:36 PM, Dan Williams wrote: > On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe > wrote: >> On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: I think this opens an even bigger can of worms.. >>> >>> No, I don't think it does. You'd

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

On 18/04/17 03:36 PM, Dan Williams wrote: > On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe > wrote: >> On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: I think this opens an even bigger can of worms.. >>> >>> No, I don't think it does. You'd only shim when the target page is

Re: [RFC PATCH] x86/mce: Check MCi_STATUS[MISCV] for usable addr on Intel only

On Tue, Apr 18, 2017 at 09:26:03PM +, Ghannam, Yazen wrote: > We definitely don't need to look at MiscV. > > But the value in MCA_ADDR isn't necessarily a system physical address. It can > be, > or it can be a normalized address in the case of UMCs, or it can a set/way > for caches. > So it

Re: [RFC PATCH] x86/mce: Check MCi_STATUS[MISCV] for usable addr on Intel only

On Tue, Apr 18, 2017 at 09:26:03PM +, Ghannam, Yazen wrote: > We definitely don't need to look at MiscV. > > But the value in MCA_ADDR isn't necessarily a system physical address. It can > be, > or it can be a normalized address in the case of UMCs, or it can a set/way > for caches. > So it

Re: [PATCH net-next v6 02/11] bpf,landlock: Define an eBPF program type for Landlock

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > Add a new type of eBPF program used by Landlock rules. > > This new BPF program type will be registered with the Landlock LSM > initialization. > > Add an initial Landlock Kconfig. > > Changes since v5: > * rename file

Re: [PATCH net-next v6 02/11] bpf,landlock: Define an eBPF program type for Landlock

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > Add a new type of eBPF program used by Landlock rules. > > This new BPF program type will be registered with the Landlock LSM > initialization. > > Add an initial Landlock Kconfig. > > Changes since v5: > * rename file hooks.c to init.c > *

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

On 2017-04-18 13:44, Greg Kroah-Hartman wrote: > On Tue, Apr 18, 2017 at 12:59:50PM +0200, Peter Rosin wrote: >> On 2017-04-18 10:51, Greg Kroah-Hartman wrote: >>> On Thu, Apr 13, 2017 at 06:43:07PM +0200, Peter Rosin wrote: +config MUX_GPIO + tristate "GPIO-controlled Multiplexer"

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

On 2017-04-18 13:44, Greg Kroah-Hartman wrote: > On Tue, Apr 18, 2017 at 12:59:50PM +0200, Peter Rosin wrote: >> On 2017-04-18 10:51, Greg Kroah-Hartman wrote: >>> On Thu, Apr 13, 2017 at 06:43:07PM +0200, Peter Rosin wrote: +config MUX_GPIO + tristate "GPIO-controlled Multiplexer"

Re: [PATCH net-next v6 01/11] bpf: Add eBPF program subtype and is_valid_subtype() verifier

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > The goal of the program subtype is to be able to have different static > fine-grained verifications for a unique program type. > > The struct bpf_verifier_ops gets a new optional function: > is_valid_subtype(). This new

Re: [PATCH net-next v6 01/11] bpf: Add eBPF program subtype and is_valid_subtype() verifier

On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote: > The goal of the program subtype is to be able to have different static > fine-grained verifications for a unique program type. > > The struct bpf_verifier_ops gets a new optional function: > is_valid_subtype(). This new verifier is called

[PATCH] x86/build: convert function graph '-Os' error to warning

On Tue, Apr 18, 2017 at 01:25:19PM -0700, Andi Kleen wrote: > On Tue, Apr 18, 2017 at 03:19:42PM -0500, Josh Poimboeuf wrote: > > On Tue, Apr 18, 2017 at 11:52:41AM -0700, Andi Kleen wrote: > > > Josh Poimboeuf writes: > > > > > > > > The error is working as designed. gcc <

[PATCH] x86/build: convert function graph '-Os' error to warning

On Tue, Apr 18, 2017 at 01:25:19PM -0700, Andi Kleen wrote: > On Tue, Apr 18, 2017 at 03:19:42PM -0500, Josh Poimboeuf wrote: > > On Tue, Apr 18, 2017 at 11:52:41AM -0700, Andi Kleen wrote: > > > Josh Poimboeuf writes: > > > > > > > > The error is working as designed. gcc < 4.6.0 doesn't have

Latency in logical volume layer?

I am trying to figure out a storage latency issue I am seeing with oVirt and iSCSI storage, and I am looking for a little help (or to be told "you're doing it wrong" as usual). I have an oVirt virtualization cluster running with 7 CentOS 7 servers, a dedicated storage LAN (separate switches), and

Latency in logical volume layer?

I am trying to figure out a storage latency issue I am seeing with oVirt and iSCSI storage, and I am looking for a little help (or to be told "you're doing it wrong" as usual). I have an oVirt virtualization cluster running with 7 CentOS 7 servers, a dedicated storage LAN (separate switches), and

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

On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe wrote: > On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: >> > I think this opens an even bigger can of worms.. >> >> No, I don't think it does. You'd only shim when the target page is >> backed by a

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

On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe wrote: > On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: >> > I think this opens an even bigger can of worms.. >> >> No, I don't think it does. You'd only shim when the target page is >> backed by a device, not host memory, and you

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

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 swapping anonymous memory rather than trashing the file lru. > > > > If all anonymous

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

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 swapping anonymous memory rather than trashing the file lru. > > > > If all anonymous

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

On 18/04/17 03:03 PM, Jason Gunthorpe wrote: > What about something more incremental like this instead: > - dma_ops will set map_sg_p2p == map_sg when they are updated to > support p2p, otherwise DMA on P2P pages will fail for those ops. > - When all ops support p2p we remove the if and

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

On 18/04/17 03:03 PM, Jason Gunthorpe wrote: > What about something more incremental like this instead: > - dma_ops will set map_sg_p2p == map_sg when they are updated to > support p2p, otherwise DMA on P2P pages will fail for those ops. > - When all ops support p2p we remove the if and

[CFP] LPC Power Management and Energy-Awareness microconferece: Call for topics

Hi All, As this has been a tradition for the last few years, we (I, Morten and Kevin) are proposing a Power Management and Energy-Awareness microconferece for the LPC this year, but of course it can only be successful if there is enough material to cover. If the recent OSPM-summit is any

[CFP] LPC Power Management and Energy-Awareness microconferece: Call for topics

Hi All, As this has been a tradition for the last few years, we (I, Morten and Kevin) are proposing a Power Management and Energy-Awareness microconferece for the LPC this year, but of course it can only be successful if there is enough material to cover. If the recent OSPM-summit is any

[PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be used in subsequent patches to mark pages as encrypted. Signed-off-by: Tom Lendacky

[PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be used in subsequent patches to mark pages as encrypted. Signed-off-by: Tom Lendacky --- arch/x86/Kconfig

[PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

Changes to the existing page table macros will allow the SME support to be enabled in a simple fashion with minimal changes to files that use these macros. Since the memory encryption mask will now be part of the regular pagetable macros, we introduce two new macros (_PAGE_TABLE_NOENC and

[PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

Changes to the existing page table macros will allow the SME support to be enabled in a simple fashion with minimal changes to files that use these macros. Since the memory encryption mask will now be part of the regular pagetable macros, we introduce two new macros (_PAGE_TABLE_NOENC and

[PATCH v5 10/32] x86/mm: Extend early_memremap() support with additional attrs

Add early_memremap() support to be able to specify encrypted and decrypted mappings with and without write-protection. The use of write-protection is necessary when encrypting data "in place". The write-protect attribute is considered cacheable for loads, but not stores. This implies that the

[PATCH v5 10/32] x86/mm: Extend early_memremap() support with additional attrs

Add early_memremap() support to be able to specify encrypted and decrypted mappings with and without write-protection. The use of write-protection is necessary when encrypting data "in place". The write-protect attribute is considered cacheable for loads, but not stores. This implies that the

RE: [RFC PATCH] x86/mce: Check MCi_STATUS[MISCV] for usable addr on Intel only

> -Original Message- > From: linux-edac-ow...@vger.kernel.org [mailto:linux-edac- > ow...@vger.kernel.org] On Behalf Of Borislav Petkov > Sent: Tuesday, April 18, 2017 2:39 PM > To: Ghannam, Yazen > Cc: Tony Luck ; linux-edac

RE: [RFC PATCH] x86/mce: Check MCi_STATUS[MISCV] for usable addr on Intel only

> -Original Message- > From: linux-edac-ow...@vger.kernel.org [mailto:linux-edac- > ow...@vger.kernel.org] On Behalf Of Borislav Petkov > Sent: Tuesday, April 18, 2017 2:39 PM > To: Ghannam, Yazen > Cc: Tony Luck ; linux-edac e...@vger.kernel.org>; lkml > Subject: [RFC PATCH] x86/mce:

[PATCH v5 14/32] efi: Add an EFI table address match function

Add a function that will determine if a supplied physical address matches the address of an EFI table. Signed-off-by: Tom Lendacky --- drivers/firmware/efi/efi.c | 33 + include/linux/efi.h|7 +++ 2 files changed, 40

[PATCH v5 14/32] efi: Add an EFI table address match function

Add a function that will determine if a supplied physical address matches the address of an EFI table. Signed-off-by: Tom Lendacky --- drivers/firmware/efi/efi.c | 33 + include/linux/efi.h|7 +++ 2 files changed, 40 insertions(+) diff --git

[PATCH v5 19/32] x86/mm: Add support to access persistent memory in the clear

Persistent memory is expected to persist across reboots. The encryption key used by SME will change across reboots which will result in corrupted persistent memory. Persistent memory is handed out by block devices through memory remapping functions, so be sure not to map this memory as encrypted.

[PATCH v5 19/32] x86/mm: Add support to access persistent memory in the clear

Persistent memory is expected to persist across reboots. The encryption key used by SME will change across reboots which will result in corrupted persistent memory. Persistent memory is handed out by block devices through memory remapping functions, so be sure not to map this memory as encrypted.

[PATCH v5 18/32] x86, mpparse: Use memremap to map the mpf and mpc data

The SMP MP-table is built by UEFI and placed in memory in a decrypted state. These tables are accessed using a mix of early_memremap(), early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses to use early_memremap()/early_memunmap(). This allows for proper setting of the

[PATCH v5 18/32] x86, mpparse: Use memremap to map the mpf and mpc data

The SMP MP-table is built by UEFI and placed in memory in a decrypted state. These tables are accessed using a mix of early_memremap(), early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses to use early_memremap()/early_memunmap(). This allows for proper setting of the

[PATCH v5 20/32] x86/mm: Add support for changing the memory encryption attribute

Add support for changing the memory encryption attribute for one or more memory pages. This will be useful when we have to change the AP trampoline area to not be encrypted. Or when we need to change the SWIOTLB area to not be encrypted in support of devices that can't support the encryption mask

[PATCH v5 20/32] x86/mm: Add support for changing the memory encryption attribute

Add support for changing the memory encryption attribute for one or more memory pages. This will be useful when we have to change the AP trampoline area to not be encrypted. Or when we need to change the SWIOTLB area to not be encrypted in support of devices that can't support the encryption mask

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