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

Hello, On Thu, Mar 15, 2018 at 12:51 PM, kbuild test robot <l...@intel.com> wrote: > > Hi Joel, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.16-rc5 next-20180315] > [if your patch is

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

Hello, On Thu, Mar 15, 2018 at 12:51 PM, kbuild test robot wrote: > > Hi Joel, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.16-rc5 next-20180315] > [if your patch is applied to the wrong

Re: [PATCH v4.16-rc5 (3)] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Jason, On Thu, 15 Mar 2018, jason.vas.d...@gmail.com wrote: > Resent to address reviewer comments. I was being patient so far and tried to guide you through the patch submission process, but unfortunately this turns out to be just waste of my time. You have not addressed any of the comments

Re: [PATCH v4.16-rc5 (3)] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Jason, On Thu, 15 Mar 2018, jason.vas.d...@gmail.com wrote: > Resent to address reviewer comments. I was being patient so far and tried to guide you through the patch submission process, but unfortunately this turns out to be just waste of my time. You have not addressed any of the comments

Re: [patch -mm v3 1/3] mm, memcg: introduce per-memcg oom policy tunable

On Thu, 15 Mar 2018, Roman Gushchin wrote: > > - Does not lock the entire system into a single methodology. Users > >working in a subtree can default to what they are used to: per-process > >oom selection even though their subtree might be targeted by a system > >policy level

Re: [patch -mm v3 1/3] mm, memcg: introduce per-memcg oom policy tunable

On Thu, 15 Mar 2018, Roman Gushchin wrote: > > - Does not lock the entire system into a single methodology. Users > >working in a subtree can default to what they are used to: per-process > >oom selection even though their subtree might be targeted by a system > >policy level

[PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload

In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host port 0 egress (RX) before the packet data if RX_VLAN_ENCAP bit is set in CPSW_CONTROL register. VLAN header encapsulation word has following format: HDR_PKT_Priority bits 29-31 - Header Packet VLAN prio (Highest prio: 7)

[PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload

In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host port 0 egress (RX) before the packet data if RX_VLAN_ENCAP bit is set in CPSW_CONTROL register. VLAN header encapsulation word has following format: HDR_PKT_Priority bits 29-31 - Header Packet VLAN prio (Highest prio: 7)

[PATCH -mm] proc: shotgun test read/readdir/readlink + a little write

Interact with nearly everything in /proc. Hopefully memleak checkers and KASAN will find something. Signed-off-by: Alexey Dobriyan --- tools/testing/selftests/proc/.gitignore |1 tools/testing/selftests/proc/Makefile |1 tools/testing/selftests/proc/read.c

[PATCH -mm] proc: shotgun test read/readdir/readlink + a little write

Interact with nearly everything in /proc. Hopefully memleak checkers and KASAN will find something. Signed-off-by: Alexey Dobriyan --- tools/testing/selftests/proc/.gitignore |1 tools/testing/selftests/proc/Makefile |1 tools/testing/selftests/proc/read.c | 146

Re: [PATCH 00/13] staging: add drivers to support Mediatek mt7621 in gnubee-pc1

On Thu, Mar 15 2018, John Crispin wrote: > On 15/03/18 11:48, Dan Carpenter wrote: >> This all seems fine. Generally the requirements for staging are that it >> has a TODO, someone to work on it, and it doesn't break the build. But >> some of the patches don't have commit message and those are

Re: [PATCH 00/13] staging: add drivers to support Mediatek mt7621 in gnubee-pc1

On Thu, Mar 15 2018, John Crispin wrote: > On 15/03/18 11:48, Dan Carpenter wrote: >> This all seems fine. Generally the requirements for staging are that it >> has a TODO, someone to work on it, and it doesn't break the build. But >> some of the patches don't have commit message and those are

Re: [PATCH v2 14/36] fs: add ksys_mount() helper; remove in-kernel calls to sys_mount()

On Thu, Mar 15, 2018 at 8:05 PM, Dominik Brodowski wrote: > Using this helper allows us to avoid the in-kernel calls to the sys_mount() > syscall. > > Cc: Alexander Viro > Signed-off-by: Dominik Brodowski > diff

Re: [PATCH v2 14/36] fs: add ksys_mount() helper; remove in-kernel calls to sys_mount()

On Thu, Mar 15, 2018 at 8:05 PM, Dominik Brodowski wrote: > Using this helper allows us to avoid the in-kernel calls to the sys_mount() > syscall. > > Cc: Alexander Viro > Signed-off-by: Dominik Brodowski > diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c > index

Re: [RFC v2 03/83] Add super.h.

On Mar 15, 2018, at 11:51 AM, Andiry Xu wrote: > > On Thu, Mar 15, 2018 at 2:05 AM, Arnd Bergmann wrote: >> On Thu, Mar 15, 2018 at 7:11 AM, Andiry Xu wrote: >>> On Wed, Mar 14, 2018 at 9:54 PM, Darrick J. Wong >>>

Re: [RFC v2 03/83] Add super.h.

On Mar 15, 2018, at 11:51 AM, Andiry Xu wrote: > > On Thu, Mar 15, 2018 at 2:05 AM, Arnd Bergmann wrote: >> On Thu, Mar 15, 2018 at 7:11 AM, Andiry Xu wrote: >>> On Wed, Mar 14, 2018 at 9:54 PM, Darrick J. Wong >>> wrote: On Sat, Mar 10, 2018 at 10:17:44AM -0800, Andiry Xu wrote: >>

[PATCH v2] Documentation/CodingStyle: Add an example for braces

Add another example of required braces when using a compound statements. Signed-off-by: Gary R Hook --- Changes since v1: - Move the new example up, and make it more generic Documentation/process/coding-style.rst |9 + 1 file changed, 9 insertions(+) diff --git

[PATCH v2] Documentation/CodingStyle: Add an example for braces

Add another example of required braces when using a compound statements. Signed-off-by: Gary R Hook --- Changes since v1: - Move the new example up, and make it more generic Documentation/process/coding-style.rst |9 + 1 file changed, 9 insertions(+) diff --git

Re: [PATCH] platform/x86: dell: avoid link error with modular ACPI_SMI

On Thu, Mar 15, 2018 at 7:36 PM, wrote: > > > On March 15, 2018 8:39:07 AM PDT, Arnd Bergmann wrote: >>The new DELL_LAPTOP dependencies allowed one configuration that should >>not >>have been possible, with DELL_SMBIOS_WMI built-in, but ACPI_SMI as a

Re: [PATCH] platform/x86: dell: avoid link error with modular ACPI_SMI

On Thu, Mar 15, 2018 at 7:36 PM, wrote: > > > On March 15, 2018 8:39:07 AM PDT, Arnd Bergmann wrote: >>The new DELL_LAPTOP dependencies allowed one configuration that should >>not >>have been possible, with DELL_SMBIOS_WMI built-in, but ACPI_SMI as a >>module: > > > Hi Arnd, do you have the

Re: [PATCH 00/13] staging: add drivers to support Mediatek mt7621 in gnubee-pc1

On Thu, Mar 15 2018, Dan Carpenter wrote: > On Thu, Mar 15, 2018 at 10:04:33PM +1100, NeilBrown wrote: >> On Thu, Mar 15 2018, Dan Carpenter wrote: >> >> > This all seems fine. Generally the requirements for staging are that it >> > has a TODO, someone to work on it, and it doesn't break the

Re: [PATCH 00/13] staging: add drivers to support Mediatek mt7621 in gnubee-pc1

On Thu, Mar 15 2018, Dan Carpenter wrote: > On Thu, Mar 15, 2018 at 10:04:33PM +1100, NeilBrown wrote: >> On Thu, Mar 15 2018, Dan Carpenter wrote: >> >> > This all seems fine. Generally the requirements for staging are that it >> > has a TODO, someone to work on it, and it doesn't break the

Re: [patch -mm] mm, memcg: evaluate root and leaf memcgs fairly on oom

On Thu, 15 Mar 2018, Roman Gushchin wrote: > > Seems like it was dropped from the patch somehow. It is intended to do > > atomic_long_add(nr_pages) in mem_cgroup_charge_skmem() and > > atomic_long_add(-nr_pages) mem_cgroup_uncharge_skmem(). > > > > > I also doubt that global atomic variable

Re: [patch -mm] mm, memcg: evaluate root and leaf memcgs fairly on oom

On Thu, 15 Mar 2018, Roman Gushchin wrote: > > Seems like it was dropped from the patch somehow. It is intended to do > > atomic_long_add(nr_pages) in mem_cgroup_charge_skmem() and > > atomic_long_add(-nr_pages) mem_cgroup_uncharge_skmem(). > > > > > I also doubt that global atomic variable

Re: sparc64 MM regression...

From: David Miller Date: Thu, 15 Mar 2018 15:28:15 -0400 (EDT) > > So I bisected a userspace corruption regression down to commit: > > commit a8e654f01cb725d0bfd741ebca1bf4c9337969cc > >

Re: sparc64 MM regression...

From: David Miller Date: Thu, 15 Mar 2018 15:28:15 -0400 (EDT) > > So I bisected a userspace corruption regression down to commit: > > commit a8e654f01cb725d0bfd741ebca1bf4c9337969cc > > Author: Nitin Gupta

Re: [PATCH] arm64: rename the function arm64_is_ras_serror() to avoid confusion

Hi gengdongjiu, On 26/02/18 16:13, gengdongjiu wrote: > 2018-02-24 1:58 GMT+08:00 James Morse : >> On 22/02/18 18:02, Dongjiu Geng wrote: >>> The RAS SError Syndrome can be Implementation-Defined, >>> arm64_is_ras_serror() is used to judge whether it is RAS SError, >>> but

Re: [PATCH] arm64: rename the function arm64_is_ras_serror() to avoid confusion

Hi gengdongjiu, On 26/02/18 16:13, gengdongjiu wrote: > 2018-02-24 1:58 GMT+08:00 James Morse : >> On 22/02/18 18:02, Dongjiu Geng wrote: >>> The RAS SError Syndrome can be Implementation-Defined, >>> arm64_is_ras_serror() is used to judge whether it is RAS SError, >>> but arm64_is_ras_serror()

Re: [PATCH] Documentation/CodingStyle: Add an example for braces

On 03/15/2018 05:26 AM, Jani Nikula wrote: On Wed, 14 Mar 2018, Gary R Hook wrote: Add another example of required braces when using a compound statement in a loop. Signed-off-by: Gary R Hook --- Documentation/process/coding-style.rst |9 +

Re: [PATCH] Documentation/CodingStyle: Add an example for braces

On 03/15/2018 05:26 AM, Jani Nikula wrote: On Wed, 14 Mar 2018, Gary R Hook wrote: Add another example of required braces when using a compound statement in a loop. Signed-off-by: Gary R Hook --- Documentation/process/coding-style.rst |9 + 1 file changed, 9 insertions(+)

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

Hi Joel, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc5 next-20180315] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

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

Hi Joel, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc5 next-20180315] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

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

On 03/15/2018 03:20 PM, Eric W. Biederman wrote: Stefan Berger writes: On 03/15/2018 03:01 PM, James Bottomley wrote: On Thu, 2018-03-15 at 14:51 -0400, Stefan Berger wrote: On 03/15/2018 02:45 PM, James Bottomley wrote: [...] going to need some type of keyring

Re: [PATCH] Staging: comedi: drivers: ni_atmio.c: fixed multi-line derefernce issue

Resending the email because it was sent only to Greg. Context: In my previous patch, I had removed an extra newline at the end of the code. My Reply: It was unintentional, but does it violate any coding or other standard?

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

On 03/15/2018 03:20 PM, Eric W. Biederman wrote: Stefan Berger writes: On 03/15/2018 03:01 PM, James Bottomley wrote: On Thu, 2018-03-15 at 14:51 -0400, Stefan Berger wrote: On 03/15/2018 02:45 PM, James Bottomley wrote: [...] going to need some type of keyring namespace and there's

Re: [PATCH] Staging: comedi: drivers: ni_atmio.c: fixed multi-line derefernce issue

Resending the email because it was sent only to Greg. Context: In my previous patch, I had removed an extra newline at the end of the code. My Reply: It was unintentional, but does it violate any coding or other standard?

[PATCH v4 2/2] Remove false-positive VLAs when using max()

As part of removing VLAs from the kernel[1], we want to build with -Wvla, but it is overly pessimistic and only accepts constant expressions for stack array sizes, instead of also constant values. The max() macro triggers the warning, so this refactors these uses of max() to use the new

[PATCH v4 2/2] Remove false-positive VLAs when using max()

As part of removing VLAs from the kernel[1], we want to build with -Wvla, but it is overly pessimistic and only accepts constant expressions for stack array sizes, instead of also constant values. The max() macro triggers the warning, so this refactors these uses of max() to use the new

[PATCH v4 0/2] Remove false-positive VLAs when using max()

I'm calling this "v4" since the last effort at this was v3, even if it's a different approach. Patch 1 adds const_max(), patch 2 uses it in all the places max() was used for stack arrays. Commit log from patch 1: ---snip--- kernel.h: Introduce const_max() for VLA removal In the effort to remove

[PATCH v4 0/2] Remove false-positive VLAs when using max()

I'm calling this "v4" since the last effort at this was v3, even if it's a different approach. Patch 1 adds const_max(), patch 2 uses it in all the places max() was used for stack arrays. Commit log from patch 1: ---snip--- kernel.h: Introduce const_max() for VLA removal In the effort to remove

[PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is overly pessimistic, in that it is only happy with stack array sizes that are declared as constant expressions, and not constant values. One case of this is the evaluation of the max()

[PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is overly pessimistic, in that it is only happy with stack array sizes that are declared as constant expressions, and not constant values. One case of this is the evaluation of the max()

Re: [RFC][PATCH] ipc: Remove IPCMNI

On Wed, Mar 14, 2018 at 07:49:29PM -0500, Eric W. Biederman wrote: > @@ -109,20 +109,13 @@ void free_ipcs(struct ipc_namespace *ns, struct ipc_ids > *ids, > { > struct kern_ipc_perm *perm; > int next_id; > - int total, in_use; > > down_write(>rwsem); > - > - in_use =

Re: [RFC][PATCH] ipc: Remove IPCMNI

On Wed, Mar 14, 2018 at 07:49:29PM -0500, Eric W. Biederman wrote: > @@ -109,20 +109,13 @@ void free_ipcs(struct ipc_namespace *ns, struct ipc_ids > *ids, > { > struct kern_ipc_perm *perm; > int next_id; > - int total, in_use; > > down_write(>rwsem); > - > - in_use =

Re: [PATCH v3 7/7] x86/kvm: use Enlightened VMCS when running on Hyper-V

2018-03-15 20:28+0100, Thomas Gleixner: > On Thu, 15 Mar 2018, Radim Krčmář wrote: > > 2018-03-15 16:19+0100, Vitaly Kuznetsov: > > > This works. But hell, this is a crude hack :-) Not sure if there's a > > > cleaner way to find what needs to be patched without something like jump > > > label

Re: [PATCH v3 7/7] x86/kvm: use Enlightened VMCS when running on Hyper-V

2018-03-15 20:28+0100, Thomas Gleixner: > On Thu, 15 Mar 2018, Radim Krčmář wrote: > > 2018-03-15 16:19+0100, Vitaly Kuznetsov: > > > This works. But hell, this is a crude hack :-) Not sure if there's a > > > cleaner way to find what needs to be patched without something like jump > > > label

Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim

On 15.03.2018 22:32, Michal Hocko wrote: > On Thu 15-03-18 22:28:43, Kirill Tkhai wrote: >> On 15.03.2018 20:49, Michal Hocko wrote: >>> On Thu 15-03-18 18:01:34, Kirill Tkhai wrote: xfs_reclaim_inodes_count(XFS_M(sb)) does not care about memcg. So, it's called for memcg reclaim too,

Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim

On 15.03.2018 22:32, Michal Hocko wrote: > On Thu 15-03-18 22:28:43, Kirill Tkhai wrote: >> On 15.03.2018 20:49, Michal Hocko wrote: >>> On Thu 15-03-18 18:01:34, Kirill Tkhai wrote: xfs_reclaim_inodes_count(XFS_M(sb)) does not care about memcg. So, it's called for memcg reclaim too,

[tip:smp/hotplug] cpu/hotplug: Fix unused function warning

Commit-ID: fcb3029a8d89487470f2e175645a9a993949233c Gitweb: https://git.kernel.org/tip/fcb3029a8d89487470f2e175645a9a993949233c Author: Arnd Bergmann AuthorDate: Thu, 15 Mar 2018 16:38:04 +0100 Committer: Thomas Gleixner CommitDate: Thu, 15 Mar 2018

[tip:smp/hotplug] cpu/hotplug: Fix unused function warning

Commit-ID: fcb3029a8d89487470f2e175645a9a993949233c Gitweb: https://git.kernel.org/tip/fcb3029a8d89487470f2e175645a9a993949233c Author: Arnd Bergmann AuthorDate: Thu, 15 Mar 2018 16:38:04 +0100 Committer: Thomas Gleixner CommitDate: Thu, 15 Mar 2018 20:34:40 +0100 cpu/hotplug: Fix

Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim

On Thu 15-03-18 22:28:43, Kirill Tkhai wrote: > On 15.03.2018 20:49, Michal Hocko wrote: > > On Thu 15-03-18 18:01:34, Kirill Tkhai wrote: > >> xfs_reclaim_inodes_count(XFS_M(sb)) does not care about memcg. > >> So, it's called for memcg reclaim too, e.g. this list is shrinked > >>

Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim

On Thu 15-03-18 22:28:43, Kirill Tkhai wrote: > On 15.03.2018 20:49, Michal Hocko wrote: > > On Thu 15-03-18 18:01:34, Kirill Tkhai wrote: > >> xfs_reclaim_inodes_count(XFS_M(sb)) does not care about memcg. > >> So, it's called for memcg reclaim too, e.g. this list is shrinked > >>

Re: [PATCH v3 7/7] x86/kvm: use Enlightened VMCS when running on Hyper-V

On Thu, 15 Mar 2018, Radim Krčmář wrote: > 2018-03-15 16:19+0100, Vitaly Kuznetsov: > > This works. But hell, this is a crude hack :-) Not sure if there's a > > cleaner way to find what needs to be patched without something like jump > > label table ... > > Yeah, I can see us accidently patching

Re: [PATCH v3 7/7] x86/kvm: use Enlightened VMCS when running on Hyper-V

On Thu, 15 Mar 2018, Radim Krčmář wrote: > 2018-03-15 16:19+0100, Vitaly Kuznetsov: > > This works. But hell, this is a crude hack :-) Not sure if there's a > > cleaner way to find what needs to be patched without something like jump > > label table ... > > Yeah, I can see us accidently patching

Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim

On 15.03.2018 20:49, Michal Hocko wrote: > On Thu 15-03-18 18:01:34, Kirill Tkhai wrote: >> xfs_reclaim_inodes_count(XFS_M(sb)) does not care about memcg. >> So, it's called for memcg reclaim too, e.g. this list is shrinked >> disproportionality to another lists. >> >> This looks confusing, so I'm

Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim

On 15.03.2018 20:49, Michal Hocko wrote: > On Thu 15-03-18 18:01:34, Kirill Tkhai wrote: >> xfs_reclaim_inodes_count(XFS_M(sb)) does not care about memcg. >> So, it's called for memcg reclaim too, e.g. this list is shrinked >> disproportionality to another lists. >> >> This looks confusing, so I'm

sparc64 MM regression...

So I bisected a userspace corruption regression down to commit: commit a8e654f01cb725d0bfd741ebca1bf4c9337969cc Author: Nitin Gupta

sparc64 MM regression...

So I bisected a userspace corruption regression down to commit: commit a8e654f01cb725d0bfd741ebca1bf4c9337969cc Author: Nitin Gupta

Re: [REPOST PATCH] arm/arm64: KVM: Add PSCI version selection API

On 15/03/18 19:13, Peter Maydell wrote: > On 15 March 2018 at 19:00, Marc Zyngier wrote: >> On 06/03/18 09:21, Andrew Jones wrote: >>> On Mon, Mar 05, 2018 at 04:47:55PM +, Peter Maydell wrote: On 2 March 2018 at 11:11, Marc Zyngier wrote:

Re: [REPOST PATCH] arm/arm64: KVM: Add PSCI version selection API

On 15/03/18 19:13, Peter Maydell wrote: > On 15 March 2018 at 19:00, Marc Zyngier wrote: >> On 06/03/18 09:21, Andrew Jones wrote: >>> On Mon, Mar 05, 2018 at 04:47:55PM +, Peter Maydell wrote: On 2 March 2018 at 11:11, Marc Zyngier wrote: > On Fri, 02 Mar 2018 10:44:48 +, >

Re: [tip:irq/core 12/14] arch/arm/kernel/entry-armv.S:26:10: fatal error: mach/entry-macro.S: No such file or directory

On Fri, 16 Mar 2018, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core > head: d9af5838180359c6be1c07989c91b28eee93d7e7 > commit: 886d70aac148f6015ae3d1379c81b98af3e70981 [12/14] ARM: irq: Convert to > GENERIC_IRQ_MULTI_HANDLER > config:

Re: [tip:irq/core 12/14] arch/arm/kernel/entry-armv.S:26:10: fatal error: mach/entry-macro.S: No such file or directory

On Fri, 16 Mar 2018, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core > head: d9af5838180359c6be1c07989c91b28eee93d7e7 > commit: 886d70aac148f6015ae3d1379c81b98af3e70981 [12/14] ARM: irq: Convert to > GENERIC_IRQ_MULTI_HANDLER > config:

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

Stefan Berger writes: > On 03/15/2018 03:01 PM, James Bottomley wrote: >> On Thu, 2018-03-15 at 14:51 -0400, Stefan Berger wrote: >>> On 03/15/2018 02:45 PM, James Bottomley wrote: >> [...] >> going to need some type of keyring namespace and there's >> already

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

Stefan Berger writes: > On 03/15/2018 03:01 PM, James Bottomley wrote: >> On Thu, 2018-03-15 at 14:51 -0400, Stefan Berger wrote: >>> On 03/15/2018 02:45 PM, James Bottomley wrote: >> [...] >> going to need some type of keyring namespace and there's >> already >> one hanging off the

Re: [PATCH v2] net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface

On 03/15/2018 01:29 PM, Florian Fainelli wrote: > On 03/15/2018 11:18 AM, Grygorii Strashko wrote: >> >> >> On 03/15/2018 12:39 PM, Grygorii Strashko wrote: >>> >>> >>> On 03/15/2018 11:56 AM, SZ Lin (林上智) wrote: According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and DRA7

Re: [PATCH v2] net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface

On 03/15/2018 01:29 PM, Florian Fainelli wrote: > On 03/15/2018 11:18 AM, Grygorii Strashko wrote: >> >> >> On 03/15/2018 12:39 PM, Grygorii Strashko wrote: >>> >>> >>> On 03/15/2018 11:56 AM, SZ Lin (林上智) wrote: According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and DRA7

Re: [PATCH 3/4] ima: Improvements in ima_appraise_measurement()

On Wed, 2018-03-14 at 21:03 -0300, Thiago Jung Bauermann wrote: > Hello Serge, > > Thanks for quickly reviewing these patches! > > Serge E. Hallyn writes: > > > Quoting Thiago Jung Bauermann (bauer...@linux.vnet.ibm.com): > >> From: Mimi Zohar > >>

Re: [PATCH 3/4] ima: Improvements in ima_appraise_measurement()

On Wed, 2018-03-14 at 21:03 -0300, Thiago Jung Bauermann wrote: > Hello Serge, > > Thanks for quickly reviewing these patches! > > Serge E. Hallyn writes: > > > Quoting Thiago Jung Bauermann (bauer...@linux.vnet.ibm.com): > >> From: Mimi Zohar > >> @@ -241,16 +241,20 @@ int

[PATCH RFC rebase 2/9] powerpc: Use barrier_nospec in copy_from_user

This is based on x86 patch doing the same. Signed-off-by: Michal Suchanek --- arch/powerpc/include/asm/uaccess.h | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h index

[PATCH RFC rebase 0/9] powerpc barrier_nospec

Yes, it is good idea to add some commit messages. Also I rebased the patches on top v3 of series Setup RFI flush after PowerVM LPM migration Thanks Michal Michal Suchanek (9): powerpc: Add barrier_nospec powerpc: Use barrier_nospec in copy_from_user powerpc/64: Use barrier_nospec in

[PATCH RFC rebase 2/9] powerpc: Use barrier_nospec in copy_from_user

This is based on x86 patch doing the same. Signed-off-by: Michal Suchanek --- arch/powerpc/include/asm/uaccess.h | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h index

[PATCH RFC rebase 0/9] powerpc barrier_nospec

Yes, it is good idea to add some commit messages. Also I rebased the patches on top v3 of series Setup RFI flush after PowerVM LPM migration Thanks Michal Michal Suchanek (9): powerpc: Add barrier_nospec powerpc: Use barrier_nospec in copy_from_user powerpc/64: Use barrier_nospec in

[PATCH RFC rebase 3/9] powerpc/64: Use barrier_nospec in syscall entry

On powerpc syscall entry is done in assembly so patch in an explicit barrier_nospec. Signed-off-by: Michal Suchanek --- arch/powerpc/kernel/entry_64.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index

[PATCH RFC rebase 3/9] powerpc/64: Use barrier_nospec in syscall entry

On powerpc syscall entry is done in assembly so patch in an explicit barrier_nospec. Signed-off-by: Michal Suchanek --- arch/powerpc/kernel/entry_64.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index

[PATCH RFC rebase 4/9] powerpc/64s: Use barrier_nospec in RFI_FLUSH_SLOT

The RFI flush support patches the speculation barrier into RFI_FLUSH_SLOT as part of the RFI flush. Use separate barrier_nospec instead. Signed-off-by: Michal Suchanek --- arch/powerpc/include/asm/exception-64s.h | 2 +- arch/powerpc/lib/feature-fixups.c| 9 +++--

[PATCH RFC rebase 4/9] powerpc/64s: Use barrier_nospec in RFI_FLUSH_SLOT

The RFI flush support patches the speculation barrier into RFI_FLUSH_SLOT as part of the RFI flush. Use separate barrier_nospec instead. Signed-off-by: Michal Suchanek --- arch/powerpc/include/asm/exception-64s.h | 2 +- arch/powerpc/lib/feature-fixups.c| 9 +++-- 2 files changed, 4

[PATCH RFC rebase 1/9] powerpc: Add barrier_nospec

When the firmware supports it an otherwise useless combination of ORI instruction arguments is interpreted as speculation barrier. Implement barrier_nospec using this instruction. Based on the out-of-tree gmb() implementation. Signed-off-by: Michal Suchanek ---

[PATCH RFC rebase 1/9] powerpc: Add barrier_nospec

When the firmware supports it an otherwise useless combination of ORI instruction arguments is interpreted as speculation barrier. Implement barrier_nospec using this instruction. Based on the out-of-tree gmb() implementation. Signed-off-by: Michal Suchanek ---

[PATCH v2] ARM: davinci: DA8XX: fix oops in USB PHY driver due to stack allocated platform platform_data

This fixes a possible kernel oops due to using stack allocated platform data for the USB PHY driver on DA8XX devices. If the platform device probe is deferred, then we get a corrupt pointer for the platform data. We now use a global static struct for the platform data so that the platform data

[PATCH v2] ARM: davinci: DA8XX: fix oops in USB PHY driver due to stack allocated platform platform_data

This fixes a possible kernel oops due to using stack allocated platform data for the USB PHY driver on DA8XX devices. If the platform device probe is deferred, then we get a corrupt pointer for the platform data. We now use a global static struct for the platform data so that the platform data

[PATCH RFC rebase 9/9] powerpc/64: barrier_nospec: Add commandline trigger

Add commandline options spectre_v2 and nospectre_v2 These are named same as similar x86 options regardless of actual effect to not require platform-specific configuration. Supported options: nospectre_v2 or spectre_v2=off - speculation barrier not used spectre_v2=on or spectre_v2=auto -

[PATCH RFC rebase 9/9] powerpc/64: barrier_nospec: Add commandline trigger

Add commandline options spectre_v2 and nospectre_v2 These are named same as similar x86 options regardless of actual effect to not require platform-specific configuration. Supported options: nospectre_v2 or spectre_v2=off - speculation barrier not used spectre_v2=on or spectre_v2=auto -

[PATCH RFC rebase 5/9] powerpc/64s: Add support for ori barrier_nospec patching

Based on the RFI patching. This is required to be able to disable the speculation barrier. Only one barrier type is supported and it does nothing when the firmware does not enable it. Also re-patching modules is not supported So the only meaningful thing that can be done is patching out the

[PATCH RFC rebase 5/9] powerpc/64s: Add support for ori barrier_nospec patching

Based on the RFI patching. This is required to be able to disable the speculation barrier. Only one barrier type is supported and it does nothing when the firmware does not enable it. Also re-patching modules is not supported So the only meaningful thing that can be done is patching out the

[PATCH RFC rebase 6/9] powerpc/64: Patch barrier_nospec in modules

Note that unlike RFI which is patched only in kernel the nospec state reflects settings at the time the module was loaded. Iterating all modules and re-patching every time the settings change is not implemented. Based on lwsync patching. Signed-off-by: Michal Suchanek ---

[PATCH RFC rebase 6/9] powerpc/64: Patch barrier_nospec in modules

Note that unlike RFI which is patched only in kernel the nospec state reflects settings at the time the module was loaded. Iterating all modules and re-patching every time the settings change is not implemented. Based on lwsync patching. Signed-off-by: Michal Suchanek ---

[PATCH RFC rebase 8/9] powerpc/64s: barrier_nospec: Add hcall triggerr

Adapted from the RFI implementation Signed-off-by: Michal Suchanek --- arch/powerpc/platforms/pseries/mobility.c | 2 +- arch/powerpc/platforms/pseries/pseries.h | 2 +- arch/powerpc/platforms/pseries/setup.c| 37 ++- 3 files changed, 29

[PATCH RFC rebase 8/9] powerpc/64s: barrier_nospec: Add hcall triggerr

Adapted from the RFI implementation Signed-off-by: Michal Suchanek --- arch/powerpc/platforms/pseries/mobility.c | 2 +- arch/powerpc/platforms/pseries/pseries.h | 2 +- arch/powerpc/platforms/pseries/setup.c| 37 ++- 3 files changed, 29 insertions(+), 12

[PATCH RFC rebase 7/9] powerpc/64: barrier_nospec: Add debugfs trigger

Copypasta from rfi implementation Signed-off-by: Michal Suchanek --- arch/powerpc/kernel/setup_64.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c index

[PATCH RFC rebase 7/9] powerpc/64: barrier_nospec: Add debugfs trigger

Copypasta from rfi implementation Signed-off-by: Michal Suchanek --- arch/powerpc/kernel/setup_64.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c index f60e0e3b5ad2..f6678a7b6114 100644

[PATCH v2 33/36] fs: add ksys_ftruncate() wrapper; remove in-kernel calls to sys_ftruncate()

Using the ksys_ftruncate() wrapper allows us to get rid of in-kernel calls to the sys_ftruncate() syscall. Cc: Al Viro Cc: Andrew Morton Signed-off-by: Dominik Brodowski --- arch/mips/kernel/linux32.c | 2 +-

[PATCH v2 33/36] fs: add ksys_ftruncate() wrapper; remove in-kernel calls to sys_ftruncate()

Using the ksys_ftruncate() wrapper allows us to get rid of in-kernel calls to the sys_ftruncate() syscall. Cc: Al Viro Cc: Andrew Morton Signed-off-by: Dominik Brodowski --- arch/mips/kernel/linux32.c | 2 +- arch/parisc/kernel/sys_parisc.c | 4 ++-- arch/powerpc/kernel/sys_ppc32.c | 2

[PATCH v2 21/36] mm: add ksys_mmap_pgoff() helper; remove in-kernel calls to sys_mmap_pgoff()

Using this helper allows us to avoid the in-kernel calls to the sys_mmap_pgoff() syscall. Cc: Andrew Morton Cc: linux...@kvack.org Signed-off-by: Dominik Brodowski --- arch/alpha/kernel/osf_sys.c | 2 +-

[PATCH v2 21/36] mm: add ksys_mmap_pgoff() helper; remove in-kernel calls to sys_mmap_pgoff()

Using this helper allows us to avoid the in-kernel calls to the sys_mmap_pgoff() syscall. Cc: Andrew Morton Cc: linux...@kvack.org Signed-off-by: Dominik Brodowski --- arch/alpha/kernel/osf_sys.c | 2 +- arch/arm64/kernel/sys.c | 2 +- arch/ia64/kernel/sys_ia64.c

Re: [PATCH] ARM: davinci: DA8XX: fix oops in USB PHY driver due to stack allocated platform platform_data

On 03/15/2018 01:02 PM, David Lechner wrote: This fixes a possible kernel oops due to using stack allocated platform data for the USB PHY driver on DA8XX devices. If the platform device probe is deferred, then we get a corrupt pointer for the platform data. We now use a global static struct for

[PATCH v2 22/36] fs: add ksys_chdir() helper; remove in-kernel calls to sys_chdir()

Using this helper allows us to avoid the in-kernel calls to the sys_chdir() syscall. Cc: Al Viro Cc: Andrew Morton Signed-off-by: Dominik Brodowski --- drivers/base/devtmpfs.c | 2 +- fs/open.c| 7

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

On 03/15/2018 03:01 PM, James Bottomley wrote: On Thu, 2018-03-15 at 14:51 -0400, Stefan Berger wrote: On 03/15/2018 02:45 PM, James Bottomley wrote: [...] going to need some type of keyring namespace and there's already one hanging off the user_ns: commit

[PATCH v2 22/36] fs: add ksys_chdir() helper; remove in-kernel calls to sys_chdir()

Using this helper allows us to avoid the in-kernel calls to the sys_chdir() syscall. Cc: Al Viro Cc: Andrew Morton Signed-off-by: Dominik Brodowski --- drivers/base/devtmpfs.c | 2 +- fs/open.c| 7 ++- include/linux/syscalls.h | 1 + init/do_mounts.c | 2 +-

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

On 03/15/2018 03:01 PM, James Bottomley wrote: On Thu, 2018-03-15 at 14:51 -0400, Stefan Berger wrote: On 03/15/2018 02:45 PM, James Bottomley wrote: [...] going to need some type of keyring namespace and there's already one hanging off the user_ns: commit

Re: [PATCH] ARM: davinci: DA8XX: fix oops in USB PHY driver due to stack allocated platform platform_data

On 03/15/2018 01:02 PM, David Lechner wrote: This fixes a possible kernel oops due to using stack allocated platform data for the USB PHY driver on DA8XX devices. If the platform device probe is deferred, then we get a corrupt pointer for the platform data. We now use a global static struct for

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