Re: [PATCH v3] KVM: X86: Allow userspace to define the microcode version

2018-02-27 9:30 GMT+08:00 Nadav Amit : > Wanpeng Li wrote: > >> From: Wanpeng Li >> >> Linux (among the others) has checks to make sure that certain features >> aren't enabled on a certain family/model/stepping if the microcode

Re: [PATCH v3] KVM: X86: Allow userspace to define the microcode version

2018-02-27 9:30 GMT+08:00 Nadav Amit : > Wanpeng Li wrote: > >> From: Wanpeng Li >> >> Linux (among the others) has checks to make sure that certain features >> aren't enabled on a certain family/model/stepping if the microcode version >> isn't greater than or equal to a known good version. >>

Re: [PATCH v4 01/24] docs: fpga: add a document for FPGA Device Feature List (DFL) Framework Overview

On Mon, Feb 26, 2018 at 04:48:55PM -0600, Alan Tull wrote: > On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao wrote: > > Hi Hao, > > The new overview and diagrams are a great improvement, thanks! > > Some comments below. Hi Alan Thanks a lot for the comments. > > > Add a document

Re: [PATCH v4 01/24] docs: fpga: add a document for FPGA Device Feature List (DFL) Framework Overview

On Mon, Feb 26, 2018 at 04:48:55PM -0600, Alan Tull wrote: > On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao wrote: > > Hi Hao, > > The new overview and diagrams are a great improvement, thanks! > > Some comments below. Hi Alan Thanks a lot for the comments. > > > Add a document for FPGA Device

Re: [PATCH 04/11] signal/parisc: Document a conflict with SI_USER with SIGFPE

Helge Deller writes: > On 23.02.2018 01:15, Eric W. Biederman wrote: >> Helge Deller writes: >> >>> * Eric W. Biederman : Setting si_code to 0 results in a userspace seeing an si_code of 0. This is the same si_code as SI_USER.

Re: [PATCH 04/11] signal/parisc: Document a conflict with SI_USER with SIGFPE

Helge Deller writes: > On 23.02.2018 01:15, Eric W. Biederman wrote: >> Helge Deller writes: >> >>> * Eric W. Biederman : Setting si_code to 0 results in a userspace seeing an si_code of 0. This is the same si_code as SI_USER. Posix and common sense requires that SI_USER not be

Re: [PATCH 12/15] drm/sun4i: Allow building on arm64

Hi Jernej, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm/drm-next] [also build test WARNING on next-20180226] [cannot apply to robh/for-next v4.16-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system

Re: [PATCH 12/15] drm/sun4i: Allow building on arm64

Hi Jernej, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm/drm-next] [also build test WARNING on next-20180226] [cannot apply to robh/for-next v4.16-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system

Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote: > On 02/21/2018 03:44 AM, Andrew Morton wrote: > > On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport > > wrote: > > > >> This patches introduces new process_vmsplice system call that combines > >>

Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote: > On 02/21/2018 03:44 AM, Andrew Morton wrote: > > On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport > > wrote: > > > >> This patches introduces new process_vmsplice system call that combines > >> functionality of process_vm_read

Re: [PATCH bpf-next v2] samples/bpf: Add program for CPU state statistics

On Mon, Feb 26, 2018 at 11:26:52AM +0100, Daniel Borkmann wrote: > On 02/26/2018 02:19 AM, Leo Yan wrote: [...] > > CPU states statistics: > > state(ms) cstate-0cstate-1cstate-2pstate-0pstate-1 > > pstate-2pstate-3pstate-4 > > CPU-0 767 6111

Re: [PATCH bpf-next v2] samples/bpf: Add program for CPU state statistics

On Mon, Feb 26, 2018 at 11:26:52AM +0100, Daniel Borkmann wrote: > On 02/26/2018 02:19 AM, Leo Yan wrote: [...] > > CPU states statistics: > > state(ms) cstate-0cstate-1cstate-2pstate-0pstate-1 > > pstate-2pstate-3pstate-4 > > CPU-0 767 6111

[PATCH v8 2/2] media: V3s: Add support for Allwinner CSI.

Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2 interface and CSI1 is used for parallel interface. This is not documented in datasheet but by test and guess. This patch implement a v4l2 framework driver for it. Currently, the driver only support the parallel interface.

[PATCH v8 2/2] media: V3s: Add support for Allwinner CSI.

Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2 interface and CSI1 is used for parallel interface. This is not documented in datasheet but by test and guess. This patch implement a v4l2 framework driver for it. Currently, the driver only support the parallel interface.

Re: [PATCH] mm: Provide consistent declaration for num_poisoned_pages

On 02/26/2018 03:57 PM, David Rientjes wrote: On Mon, 26 Feb 2018, Guenter Roeck wrote: clang reports the following compile warning. In file included from mm/vmscan.c:56: ./include/linux/swapops.h:327:22: warning: section attribute is specified on redeclared variable [-Wsection]

Re: [PATCH] mm: Provide consistent declaration for num_poisoned_pages

On 02/26/2018 03:57 PM, David Rientjes wrote: On Mon, 26 Feb 2018, Guenter Roeck wrote: clang reports the following compile warning. In file included from mm/vmscan.c:56: ./include/linux/swapops.h:327:22: warning: section attribute is specified on redeclared variable [-Wsection]

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-25 06:38, Mark Rutland wrote: On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: Some PMUs events can be read from any CPU. So allow the PMU to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's CPU and cause

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-25 06:38, Mark Rutland wrote: On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: Some PMUs events can be read from any CPU. So allow the PMU to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's CPU and cause

Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

On Tue, Feb 27, 2018 at 01:41:15AM +0100, Mickaël Salaün wrote: > The seccomp(2) syscall can be used by a task to apply a Landlock program > to itself. As a seccomp filter, a Landlock program is enforced for the > current task and all its future children. A program is immutable and a > task can

Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

On Tue, Feb 27, 2018 at 01:41:15AM +0100, Mickaël Salaün wrote: > The seccomp(2) syscall can be used by a task to apply a Landlock program > to itself. As a seccomp filter, a Landlock program is enforced for the > current task and all its future children. A program is immutable and a > task can

[PATCH v8 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

Add binding documentation for Allwinner V3s CSI. Acked-by: Maxime Ripard Acked-by: Sakari Ailus Reviewed-by: Rob Herring Signed-off-by: Yong Deng ---

[PATCH v8 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

Add binding documentation for Allwinner V3s CSI. Acked-by: Maxime Ripard Acked-by: Sakari Ailus Reviewed-by: Rob Herring Signed-off-by: Yong Deng --- .../devicetree/bindings/media/sun6i-csi.txt| 59 ++ 1 file changed, 59 insertions(+) create mode 100644

[PATCH v8 0/2] Initial Allwinner V3s CSI Support

This patchset add initial support for Allwinner V3s CSI. Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2 interface and CSI1 is used for parallel interface. This is not documented in datasheet but by test and guess. This patchset implement a v4l2 framework driver and add a

[PATCH v8 0/2] Initial Allwinner V3s CSI Support

This patchset add initial support for Allwinner V3s CSI. Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2 interface and CSI1 is used for parallel interface. This is not documented in datasheet but by test and guess. This patchset implement a v4l2 framework driver and add a

Re: [PATCH v8 03/13] kexec_file, x86, powerpc: factor out kexec_file_ops functions

On Mon, Feb 26, 2018 at 12:17:18PM +0100, Philipp Rudo wrote: > Hi AKASHI > > On Thu, 22 Feb 2018 20:17:22 +0900 > AKASHI Takahiro wrote: > > [...] > > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > > index 990adae52151..a6d14a768b3e 100644 > > ---

Re: [PATCH v8 03/13] kexec_file, x86, powerpc: factor out kexec_file_ops functions

On Mon, Feb 26, 2018 at 12:17:18PM +0100, Philipp Rudo wrote: > Hi AKASHI > > On Thu, 22 Feb 2018 20:17:22 +0900 > AKASHI Takahiro wrote: > > [...] > > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > > index 990adae52151..a6d14a768b3e 100644 > > --- a/kernel/kexec_file.c > > +++

Re: [PATCH v3 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free

On Mon, Feb 26, 2018 at 01:53:10PM -0800, David Rientjes wrote: > On Mon, 26 Feb 2018, Aaron Lu wrote: > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 3154859cccd6..35576da0a6c9 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -1116,13 +1116,11 @@ static void

Re: [PATCH v3 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free

On Mon, Feb 26, 2018 at 01:53:10PM -0800, David Rientjes wrote: > On Mon, 26 Feb 2018, Aaron Lu wrote: > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 3154859cccd6..35576da0a6c9 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -1116,13 +1116,11 @@ static void

Re: [PATCH v3 1/3] mm/free_pcppages_bulk: update pcp->count inside

On Mon, Feb 26, 2018 at 01:48:14PM -0800, David Rientjes wrote: > On Mon, 26 Feb 2018, Aaron Lu wrote: > > > Matthew Wilcox found that all callers of free_pcppages_bulk() currently > > update pcp->count immediately after so it's natural to do it inside > > free_pcppages_bulk(). > > > > No

Re: [PATCH v3 1/3] mm/free_pcppages_bulk: update pcp->count inside

On Mon, Feb 26, 2018 at 01:48:14PM -0800, David Rientjes wrote: > On Mon, 26 Feb 2018, Aaron Lu wrote: > > > Matthew Wilcox found that all callers of free_pcppages_bulk() currently > > update pcp->count immediately after so it's natural to do it inside > > free_pcppages_bulk(). > > > > No

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-24 00:41, Peter Zijlstra wrote: On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: Some PMUs events can be read from any CPU. So allow the PMU to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's CPU and cause

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-24 00:41, Peter Zijlstra wrote: On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: Some PMUs events can be read from any CPU. So allow the PMU to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's CPU and cause

Re: [PATCH v2] Staging: bcm2048: Fix function argument alignment in radio-bcm2048.c.

Hans, Thank you very much for your input on the patch; however this patch has already been applied to the staging tree. Additionally: > What coding style problem? You should give a short description of > what you are fixing. The subject of the patch (which becomes the subject of the email when

Re: [PATCH v2] Staging: bcm2048: Fix function argument alignment in radio-bcm2048.c.

Hans, Thank you very much for your input on the patch; however this patch has already been applied to the staging tree. Additionally: > What coding style problem? You should give a short description of > what you are fixing. The subject of the patch (which becomes the subject of the email when

Re: [PATCH 2/2] selftests: ion: Add simple test with the vgem driver

On 02/26/2018 09:07 AM, Shuah Khan wrote: On 02/19/2018 11:33 AM, Daniel Vetter wrote: On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote: On 02/19/2018 07:31 AM, Daniel Vetter wrote: On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote: Ion is designed to be a framework

Re: [PATCH 2/2] selftests: ion: Add simple test with the vgem driver

On 02/26/2018 09:07 AM, Shuah Khan wrote: On 02/19/2018 11:33 AM, Daniel Vetter wrote: On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote: On 02/19/2018 07:31 AM, Daniel Vetter wrote: On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote: Ion is designed to be a framework

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

On Mon, 26 Feb 2018, Yang Shi wrote: > > Rather than killable, we have patches that introduce down_read_unfair() > > variants for the files you've modified (cmdline and environ) as well as > > others (maps, numa_maps, smaps). > > You mean you have such functionality used by google internally? >

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

On Mon, 26 Feb 2018, Yang Shi wrote: > > Rather than killable, we have patches that introduce down_read_unfair() > > variants for the files you've modified (cmdline and environ) as well as > > others (maps, numa_maps, smaps). > > You mean you have such functionality used by google internally? >

[PATCH v2] perf annotate: Support to display the IPC/Cycle in tui mode

Unlike the perf report interactive annotate mode, the perf annotate doesn't display the IPC/Cycle even if branch info is recorded in perf data file. perf record -b ... perf annotate function It should show IPC/cycle, but it doesn't. This patch lets perf annotate support the displaying of

[PATCH v2] perf annotate: Support to display the IPC/Cycle in tui mode

Unlike the perf report interactive annotate mode, the perf annotate doesn't display the IPC/Cycle even if branch info is recorded in perf data file. perf record -b ... perf annotate function It should show IPC/cycle, but it doesn't. This patch lets perf annotate support the displaying of

[PATCH] x86: devicetree: enable multiprocessing and interrupt setting in DT

The x86-specific Device Tree implementation only supported single CPU, and IRQ allocation from DT parameters was broken in recent versions. This change enables multiprocessing and fixes broken IRQ allocation. Signed-off-by: Ivan Gorinov ---  arch/x86/kernel/devicetree.c

[PATCH] x86: devicetree: enable multiprocessing and interrupt setting in DT

The x86-specific Device Tree implementation only supported single CPU, and IRQ allocation from DT parameters was broken in recent versions. This change enables multiprocessing and fixes broken IRQ allocation. Signed-off-by: Ivan Gorinov ---  arch/x86/kernel/devicetree.c | 41

Re: [PATCH v3] KVM: X86: Allow userspace to define the microcode version

Wanpeng Li wrote: > From: Wanpeng Li > > Linux (among the others) has checks to make sure that certain features > aren't enabled on a certain family/model/stepping if the microcode version > isn't greater than or equal to a known good version. > >

Re: [PATCH v3] KVM: X86: Allow userspace to define the microcode version

Wanpeng Li wrote: > From: Wanpeng Li > > Linux (among the others) has checks to make sure that certain features > aren't enabled on a certain family/model/stepping if the microcode version > isn't greater than or equal to a known good version. > > By exposing the real microcode version,

Re: [PATCH v5 2/9] watchdog/hpwdt: Remove legacy NMI sourcing.

On 02/26/2018 05:02 PM, Jerry Hoemann wrote: On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote: On 02/26/2018 06:11 AM, Arnd Bergmann wrote: On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann wrote: Gen8 and prior Proliant systems supported the "CRU" interface

Re: [PATCH v5 2/9] watchdog/hpwdt: Remove legacy NMI sourcing.

On 02/26/2018 05:02 PM, Jerry Hoemann wrote: On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote: On 02/26/2018 06:11 AM, Arnd Bergmann wrote: On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann wrote: Gen8 and prior Proliant systems supported the "CRU" interface to firmware. This

Re: [PATCH RFC] riscv/barrier: Define __smp_{mb,rmb,wmb}

On Mon, 26 Feb 2018 02:35:52 PST (-0800), parri.and...@gmail.com wrote: On Thu, Feb 22, 2018 at 03:14:52PM -0800, Palmer Dabbelt wrote: On Tue, 20 Feb 2018 02:17:28 PST (-0800), parri.and...@gmail.com wrote: >Introduce __smp_{mb,rmb,wmb}, and rely on the generic definitions >for

Re: [PATCH RFC] riscv/barrier: Define __smp_{mb,rmb,wmb}

On Mon, 26 Feb 2018 02:35:52 PST (-0800), parri.and...@gmail.com wrote: On Thu, Feb 22, 2018 at 03:14:52PM -0800, Palmer Dabbelt wrote: On Tue, 20 Feb 2018 02:17:28 PST (-0800), parri.and...@gmail.com wrote: >Introduce __smp_{mb,rmb,wmb}, and rely on the generic definitions >for

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

On 2/26/18 5:02 PM, David Rientjes wrote: On Tue, 27 Feb 2018, Yang Shi wrote: Background: When running vm-scalability with large memory (> 300GB), the below hung task issue happens occasionally. INFO: task ps:14018 blocked for more than 120 seconds. Tainted: GE

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

On 2/26/18 5:02 PM, David Rientjes wrote: On Tue, 27 Feb 2018, Yang Shi wrote: Background: When running vm-scalability with large memory (> 300GB), the below hung task issue happens occasionally. INFO: task ps:14018 blocked for more than 120 seconds. Tainted: GE

Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata

On Tue, Feb 27, 2018 at 12:57:21AM +, Al Viro wrote: > On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote: > > The function current_nameidata_security(struct inode *) can be used to > > retrieve a blob's pointer address tied to the inode being walk through. > > This enable to

Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata

On Tue, Feb 27, 2018 at 12:57:21AM +, Al Viro wrote: > On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote: > > The function current_nameidata_security(struct inode *) can be used to > > retrieve a blob's pointer address tied to the inode being walk through. > > This enable to

Re: [PATCH v2] KVM: X86: Allow userspace to define the microcode version

2018-02-26 19:42 GMT+08:00 Paolo Bonzini : > On 26/02/2018 11:17, Wanpeng Li wrote: >> From: Wanpeng Li >> >> Linux (among the others) has checks to make sure that certain features >> aren't enabled on a certain family/model/stepping if the microcode

Re: [PATCH v2] KVM: X86: Allow userspace to define the microcode version

2018-02-26 19:42 GMT+08:00 Paolo Bonzini : > On 26/02/2018 11:17, Wanpeng Li wrote: >> From: Wanpeng Li >> >> Linux (among the others) has checks to make sure that certain features >> aren't enabled on a certain family/model/stepping if the microcode version >> isn't greater than or equal to a

Re: [PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.

Hi, On Mon, 26 Feb 2018 12:06:37 +0100 Hans Verkuil wrote: > Hi all, > > On 01/30/2018 03:48 AM, Yong wrote: > > Hi, > > > > On Mon, 29 Jan 2018 13:49:14 -0800 > > Randy Dunlap wrote: > > > >> On 01/29/2018 01:21 AM, Yong Deng wrote: > >>>

Re: [PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.

Hi, On Mon, 26 Feb 2018 12:06:37 +0100 Hans Verkuil wrote: > Hi all, > > On 01/30/2018 03:48 AM, Yong wrote: > > Hi, > > > > On Mon, 29 Jan 2018 13:49:14 -0800 > > Randy Dunlap wrote: > > > >> On 01/29/2018 01:21 AM, Yong Deng wrote: > >>> Allwinner V3s SoC features two CSI module. CSI0 is

[PATCH v3] KVM: X86: Allow userspace to define the microcode version

From: Wanpeng Li Linux (among the others) has checks to make sure that certain features aren't enabled on a certain family/model/stepping if the microcode version isn't greater than or equal to a known good version. By exposing the real microcode version, we're

[PATCH v3] KVM: X86: Allow userspace to define the microcode version

From: Wanpeng Li Linux (among the others) has checks to make sure that certain features aren't enabled on a certain family/model/stepping if the microcode version isn't greater than or equal to a known good version. By exposing the real microcode version, we're preventing buggy guests that

Re: [PATCH 1/2 v3] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems

Tested-by: Vineet Gupta Fixes: ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files Signed-off-by: Evgeniy Didin CC: Alexey Brodkin CC: Eugeniy Paltsev CC: Douglas Anderson

Re: [PATCH 1/2 v3] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems

Tested-by: Vineet Gupta Fixes: ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files Signed-off-by: Evgeniy Didin CC: Alexey Brodkin CC: Eugeniy Paltsev CC: Douglas Anderson CC: Ulf Hansson CC: linux-kernel@vger.kernel.org CC: linux-snps-...@lists.infradead.org Cc: #

[GIT PULL] seccomp update for v4.16-rc4

Hi James, Please pull this seccomp change for v4.16-rc4. This disables the seccomp samples when cross compiling. We're seen too many build issues here, so it's best to just disable it, especially since they're just the samples. Thanks! -Kees The following changes since commit

Re: [PATCH v7 3/7] fs/posix_acl: Document that get_acl respects ACL_DONT_CACHE

On Mon, Feb 26, 2018 at 3:52 PM, Eric W. Biederman wrote: > > Additionaly update the comment above the call to get_acl itself and > remove the wrong information that an implementation of get_acl can > prevent caching by calling forget_cached_acl. This part is just

[GIT PULL] seccomp update for v4.16-rc4

Hi James, Please pull this seccomp change for v4.16-rc4. This disables the seccomp samples when cross compiling. We're seen too many build issues here, so it's best to just disable it, especially since they're just the samples. Thanks! -Kees The following changes since commit

Re: [PATCH v7 3/7] fs/posix_acl: Document that get_acl respects ACL_DONT_CACHE

On Mon, Feb 26, 2018 at 3:52 PM, Eric W. Biederman wrote: > > Additionaly update the comment above the call to get_acl itself and > remove the wrong information that an implementation of get_acl can > prevent caching by calling forget_cached_acl. This part is just confusing. First off, that

Re: [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU

On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote: > Hi Shawn, > > On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote: > > On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote: > > > On i.MX53 it is necessary to set the DBG_EN bit in the > > > platform GPC

Re: [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU

On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote: > Hi Shawn, > > On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote: > > On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote: > > > On i.MX53 it is necessary to set the DBG_EN bit in the > > > platform GPC

Re: [PATCH] ipmi: Add or fix SPDX-License-Identifier in all files

On Tue, Feb 27, 2018 at 1:54 AM, wrote: > From: Corey Minyard > > And get rid of the license text that is no longer necessary. > > Signed-off-by: Corey Minyard > Cc: Kees Cook > Cc: Alistair Popple

Re: [PATCH] ipmi: Add or fix SPDX-License-Identifier in all files

On Tue, Feb 27, 2018 at 1:54 AM, wrote: > From: Corey Minyard > > And get rid of the license text that is no longer necessary. > > Signed-off-by: Corey Minyard > Cc: Kees Cook > Cc: Alistair Popple > Cc: Jeremy Kerr > Cc: Joel Stanley > Cc: Rocky Craig > --- > > Just a cleanup of these

Re: [PATCH v5 2/9] watchdog/hpwdt: Remove legacy NMI sourcing.

On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote: > On 02/26/2018 06:11 AM, Arnd Bergmann wrote: > > On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann > > wrote: > > > Gen8 and prior Proliant systems supported the "CRU" interface > > > to firmware. This

Re: [PATCH v5 2/9] watchdog/hpwdt: Remove legacy NMI sourcing.

On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote: > On 02/26/2018 06:11 AM, Arnd Bergmann wrote: > > On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann > > wrote: > > > Gen8 and prior Proliant systems supported the "CRU" interface > > > to firmware. This interfaces allows linux to

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

On Tue, 27 Feb 2018, Yang Shi wrote: > > Background: > When running vm-scalability with large memory (> 300GB), the below hung > task issue happens occasionally. > > INFO: task ps:14018 blocked for more than 120 seconds. >Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1 >

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

On Tue, 27 Feb 2018, Yang Shi wrote: > > Background: > When running vm-scalability with large memory (> 300GB), the below hung > task issue happens occasionally. > > INFO: task ps:14018 blocked for more than 120 seconds. >Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1 >

[PATCH] ARM: dts: NSP: Fix amount of RAM on BCM958625HR

Jon attempted to fix the amount of RAM on the BCM958625HR in commit c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board") but it seems like we tripped over some poorly documented schematics. The top-level page of the schematics says the board has 2GB, but when you end-up

[PATCH] ARM: dts: NSP: Fix amount of RAM on BCM958625HR

Jon attempted to fix the amount of RAM on the BCM958625HR in commit c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board") but it seems like we tripped over some poorly documented schematics. The top-level page of the schematics says the board has 2GB, but when you end-up

Re: [PATCH 4.15 00/64] 4.15.7-stable review

On 02/26/2018 01:21 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.7 release. > There are 64 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.15 00/64] 4.15.7-stable review

On 02/26/2018 01:21 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.7 release. > There are 64 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata

On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote: > The function current_nameidata_security(struct inode *) can be used to > retrieve a blob's pointer address tied to the inode being walk through. > This enable to follow a path lookup and know where an inode access come > from. This

Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata

On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote: > The function current_nameidata_security(struct inode *) can be used to > retrieve a blob's pointer address tied to the inode being walk through. > This enable to follow a path lookup and know where an inode access come > from. This

Re: [PATCH 4.14 00/54] 4.14.23-stable review

On 02/26/2018 01:21 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.23 release. > There are 54 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.14 00/54] 4.14.23-stable review

On 02/26/2018 01:21 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.23 release. > There are 54 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 00/39] 4.9.85-stable review

On 02/26/2018 01:20 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.85 release. > There are 39 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 00/39] 4.9.85-stable review

On 02/26/2018 01:20 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.85 release. > There are 39 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/22] 4.4.119-stable review

On 02/26/2018 01:16 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.119 release. > There are 22 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/22] 4.4.119-stable review

On 02/26/2018 01:16 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.119 release. > There are 22 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/13] 3.18.97-stable review

On 02/26/2018 01:15 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.97 release. > There are 13 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/13] 3.18.97-stable review

On 02/26/2018 01:15 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.97 release. > There are 13 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH] perf stat: Ignore error thread when enabling system-wide --per-thread

On 1/23/2018 10:19 PM, Jiri Olsa wrote: On Mon, Jan 22, 2018 at 01:10:31PM +0800, Jin, Yao wrote: On 1/16/2018 9:17 PM, Jiri Olsa wrote: On Tue, Jan 16, 2018 at 09:06:09PM +0800, Jin, Yao wrote: Just tested. But looks it's not OK for '--per-thread' case. yea, I haven't tested much..

Re: [PATCH] perf stat: Ignore error thread when enabling system-wide --per-thread

On 1/23/2018 10:19 PM, Jiri Olsa wrote: On Mon, Jan 22, 2018 at 01:10:31PM +0800, Jin, Yao wrote: On 1/16/2018 9:17 PM, Jiri Olsa wrote: On Tue, Jan 16, 2018 at 09:06:09PM +0800, Jin, Yao wrote: Just tested. But looks it's not OK for '--per-thread' case. yea, I haven't tested much..

Re: [RFC 1/3] seccomp: add a return code to trap to userspace

On Wed, Feb 14, 2018 at 9:19 AM, Andy Lutomirski wrote: > On Wed, Feb 14, 2018 at 3:29 PM, Tycho Andersen wrote: >> On Tue, Feb 13, 2018 at 01:09:20PM -0800, Kees Cook wrote: >>> On Sun, Feb 4, 2018 at 2:49 AM, Tycho Andersen wrote: >>> I

Re: [RFC 1/3] seccomp: add a return code to trap to userspace

On Wed, Feb 14, 2018 at 9:19 AM, Andy Lutomirski wrote: > On Wed, Feb 14, 2018 at 3:29 PM, Tycho Andersen wrote: >> On Tue, Feb 13, 2018 at 01:09:20PM -0800, Kees Cook wrote: >>> On Sun, Feb 4, 2018 at 2:49 AM, Tycho Andersen wrote: >>> I wonder if this communication should be netlink, which

Re: [RFC PATCH] drivers: use 'depends on MFD_SYSCON' instead of 'select MFD_SYSCON'

2018-02-26 21:43 GMT+09:00 Arnd Bergmann : > On Mon, Feb 26, 2018 at 12:53 PM, Masahiro Yamada > wrote: >> 2018-02-26 17:43 GMT+09:00 Arnd Bergmann : >>> On Sat, Feb 24, 2018 at 3:50 PM, Masahiro Yamada >>>

Re: [RFC PATCH] drivers: use 'depends on MFD_SYSCON' instead of 'select MFD_SYSCON'

2018-02-26 21:43 GMT+09:00 Arnd Bergmann : > On Mon, Feb 26, 2018 at 12:53 PM, Masahiro Yamada > wrote: >> 2018-02-26 17:43 GMT+09:00 Arnd Bergmann : >>> On Sat, Feb 24, 2018 at 3:50 PM, Masahiro Yamada >>> wrote: As Documentation/kbuild/kconfig-language.txt notes, 'select' should be

[PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

The seccomp(2) syscall can be used by a task to apply a Landlock program to itself. As a seccomp filter, a Landlock program is enforced for the current task and all its future children. A program is immutable and a task can only add new restricting programs to itself, forming a list of programss.

[PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

Hi, This eight series is a major revamp of the Landlock design compared to the previous series [1]. This enables more flexibility and granularity of access control with file paths. It is now possible to enforce an access control according to a file hierarchy. Landlock uses the concept of inode

[PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

The seccomp(2) syscall can be used by a task to apply a Landlock program to itself. As a seccomp filter, a Landlock program is enforced for the current task and all its future children. A program is immutable and a task can only add new restricting programs to itself, forming a list of programss.

[PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

Hi, This eight series is a major revamp of the Landlock design compared to the previous series [1]. This enables more flexibility and granularity of access control with file paths. It is now possible to enforce an access control according to a file hierarchy. Landlock uses the concept of inode

[PATCH bpf-next v8 03/11] bpf: Add eBPF program subtype and is_valid_subtype() verifier

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 at the beginning of the eBPF program verification to check if the

[PATCH bpf-next v8 03/11] bpf: Add eBPF program subtype and is_valid_subtype() verifier

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 at the beginning of the eBPF program verification to check if the

[PATCH bpf-next v8 04/11] bpf,landlock: Define an eBPF program type for Landlock hooks

Add a new type of eBPF program used by Landlock hooks. This type of program can be chained with the same eBPF program type (according to subtype rules). A state can be kept with a value available in the program's context (e.g. named "cookie" for Landlock programs). This new BPF program type will

[PATCH bpf-next v8 04/11] bpf,landlock: Define an eBPF program type for Landlock hooks

Add a new type of eBPF program used by Landlock hooks. This type of program can be chained with the same eBPF program type (according to subtype rules). A state can be kept with a value available in the program's context (e.g. named "cookie" for Landlock programs). This new BPF program type will

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