[PATCH 3/3] seccomp: add a selftest for get_metadata

Let's test that we get the flags correctly, and that we preserve the filter index across the ptrace(PTRACE_SECCOMP_GET_METADATA) correctly. Signed-off-by: Tycho Andersen CC: Kees Cook --- tools/testing/selftests/seccomp/seccomp_bpf.c | 61

[PATCH 3/3] seccomp: add a selftest for get_metadata

Let's test that we get the flags correctly, and that we preserve the filter index across the ptrace(PTRACE_SECCOMP_GET_METADATA) correctly. Signed-off-by: Tycho Andersen CC: Kees Cook --- tools/testing/selftests/seccomp/seccomp_bpf.c | 61 +++ 1 file changed, 61

[PATCH] x86/entry/64: Simplify ENCODE_FRAME_POINTER

On Tue, Feb 20, 2018 at 02:25:03PM -0800, Linus Torvalds wrote: > On Tue, Feb 20, 2018 at 1:01 PM, Dominik Brodowski > wrote: > > +ENTRY(interrupt_entry) > > + UNWIND_HINT_FUNC > > + > > + PUSH_AND_CLEAR_REGS save_ret=1 > > + ENCODE_FRAME_POINTER 8 >

[PATCH] x86/entry/64: Simplify ENCODE_FRAME_POINTER

On Tue, Feb 20, 2018 at 02:25:03PM -0800, Linus Torvalds wrote: > On Tue, Feb 20, 2018 at 1:01 PM, Dominik Brodowski > wrote: > > +ENTRY(interrupt_entry) > > + UNWIND_HINT_FUNC > > + > > + PUSH_AND_CLEAR_REGS save_ret=1 > > + ENCODE_FRAME_POINTER 8 > > + > > + ret > >

[PATCH v2] fork: Unconditionally clear stack on fork

One of the classes of kernel stack content leaks[1] is exposing the contents of prior heap or stack contents when a new process stack is allocated. Normally, those stacks are not zeroed, and the old contents remain in place. In the face of stack content exposure flaws, those contents can leak to

[PATCH v2] fork: Unconditionally clear stack on fork

One of the classes of kernel stack content leaks[1] is exposing the contents of prior heap or stack contents when a new process stack is allocated. Normally, those stacks are not zeroed, and the old contents remain in place. In the face of stack content exposure flaws, those contents can leak to

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 5:05 PM, Luck, Tony wrote: >>> EFI[1] stinks. Reading any file in /sys/firmware/efi/efivars/ generates >>> 4 (yes FOUR!) SMIs. > >> Is that actualkly the normal implementation? > > I don't know if there are other implementations. This is what I see on

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 5:05 PM, Luck, Tony wrote: >>> EFI[1] stinks. Reading any file in /sys/firmware/efi/efivars/ generates >>> 4 (yes FOUR!) SMIs. > >> Is that actualkly the normal implementation? > > I don't know if there are other implementations. This is what I see on my > lab system. Ok.

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

On 02/20/2018 03:21 PM, Thomas Gleixner wrote: > On Tue, 20 Feb 2018, Reinette Chatre wrote: >> On 2/20/2018 9:15 AM, Thomas Gleixner wrote: >>> On Tue, 13 Feb 2018, Reinette Chatre wrote: >>> >>> Now the remaining thing is the memory allocation and the mmap itself. I >>> really dislike the

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

On 02/20/2018 03:21 PM, Thomas Gleixner wrote: > On Tue, 20 Feb 2018, Reinette Chatre wrote: >> On 2/20/2018 9:15 AM, Thomas Gleixner wrote: >>> On Tue, 13 Feb 2018, Reinette Chatre wrote: >>> >>> Now the remaining thing is the memory allocation and the mmap itself. I >>> really dislike the

Re: [PATCH] fork: Allow stack to be wiped on fork

On Wed, Feb 21, 2018 at 12:31 AM, Andrew Morton wrote: > On Tue, 16 Jan 2018 21:50:15 -0800 Kees Cook wrote: > >> One of the classes of kernel stack content leaks is exposing the contents >> of prior heap or stack contents when a new process

Re: [PATCH] fork: Allow stack to be wiped on fork

On Wed, Feb 21, 2018 at 12:31 AM, Andrew Morton wrote: > On Tue, 16 Jan 2018 21:50:15 -0800 Kees Cook wrote: > >> One of the classes of kernel stack content leaks is exposing the contents >> of prior heap or stack contents when a new process stack is allocated. >> Normally, those stacks are not

Re: [Intel-wired-lan] [PATCH net-queue] e1000e: Fix check_for_link return value with autoneg off.

On 2/19/2018 22:12, Benjamin Poirier wrote: When autoneg is off, the .check_for_link callback functions clear the get_link_status flag and systematically return a "pseudo-error". This means that the link is not detected as up until the next execution of the e1000_watchdog_task() 2 seconds later.

Re: [Intel-wired-lan] [PATCH net-queue] e1000e: Fix check_for_link return value with autoneg off.

On 2/19/2018 22:12, Benjamin Poirier wrote: When autoneg is off, the .check_for_link callback functions clear the get_link_status flag and systematically return a "pseudo-error". This means that the link is not detected as up until the next execution of the e1000_watchdog_task() 2 seconds later.

Re: [PATCH v3 1/2] mfd: arizona: Update reset pin to use GPIOD

Hi Charles, Thank you for the patch! Yet something to improve: [auto build test ERROR on ljones-mfd/for-mfd-next] [also build test ERROR on v4.16-rc2 next-20180220] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com

Re: [PATCH v3 1/2] mfd: arizona: Update reset pin to use GPIOD

Hi Charles, Thank you for the patch! Yet something to improve: [auto build test ERROR on ljones-mfd/for-mfd-next] [also build test ERROR on v4.16-rc2 next-20180220] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com

Re: [RFC PATCH v16 0/6] mm: security: ro protection for dynamic data

On Tue, Feb 20, 2018 at 03:56:00PM -0800, Matthew Wilcox wrote: > On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote: > > FWIW, I'm not wanting to use it to replace static variables. All the > > structures are dynamically allocated right now, and get assigned to > > other dynamically

Re: [RFC PATCH v16 0/6] mm: security: ro protection for dynamic data

On Tue, Feb 20, 2018 at 03:56:00PM -0800, Matthew Wilcox wrote: > On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote: > > FWIW, I'm not wanting to use it to replace static variables. All the > > structures are dynamically allocated right now, and get assigned to > > other dynamically

[GIT PULL 0/5] perf/core improvements and fixes

into perf/core (2018-02-17 11:39:47 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-4.17-20180220 for you to fetch changes up to 66dfdff03d196e51322c6a85c0d8db8bb2bdd655: perf tools: Add Python 3 support (2018

[GIT PULL 0/5] perf/core improvements and fixes

into perf/core (2018-02-17 11:39:47 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-4.17-20180220 for you to fetch changes up to 66dfdff03d196e51322c6a85c0d8db8bb2bdd655: perf tools: Add Python 3 support (2018

[PATCH 1/5] perf s390: Fix reading cpuid model information

From: Thomas Richter Commit eca0fa28cd0d (perf record: Provide detailed information on s390 CPU") fixed a build error on Ubuntu. However the fix uses the wrong size to print the model information. Signed-off-by: Thomas Richter Cc: Heiko

[PATCH 1/5] perf s390: Fix reading cpuid model information

From: Thomas Richter Commit eca0fa28cd0d (perf record: Provide detailed information on s390 CPU") fixed a build error on Ubuntu. However the fix uses the wrong size to print the model information. Signed-off-by: Thomas Richter Cc: Heiko Carstens Cc: Hendrik Brueckner Cc: Martin Schwidefsky

[PATCH 2/5] perf machine: Fix paranoid check in machine__set_kernel_mmap()

From: Namhyung Kim The machine__set_kernel_mmap() is to setup addresses of the kernel map using external info. But it has a check when the address is given from an incorrect input which should have the start and end address of 0 (i.e. machine__process_kernel_mmap_event).

[PATCH 3/5] perf ftrace: Append an EOL when write tracing files

From: Changbin Du Before this change, the '--graph-funcs', '--nograph-funcs' and '--trace-funcs' options didn't work as expected when the doesn't exist. Because the kernel side hid possible errors. $ sudo ./perf ftrace -a --graph-depth 1 --graph-funcs abcdefg 0)

[PATCH 4/5] perf python: Make twatch.py work with both python2 and python3

From: Arnaldo Carvalho de Melo Will be used to test patches allowing to build perf with python3, so that we make sure that we can build with both versions. Cc: Adrian Hunter Cc: David Ahern Cc: Jaroslav Škarvada

[PATCH 2/5] perf machine: Fix paranoid check in machine__set_kernel_mmap()

From: Namhyung Kim The machine__set_kernel_mmap() is to setup addresses of the kernel map using external info. But it has a check when the address is given from an incorrect input which should have the start and end address of 0 (i.e. machine__process_kernel_mmap_event). But we also use the

[PATCH 3/5] perf ftrace: Append an EOL when write tracing files

From: Changbin Du Before this change, the '--graph-funcs', '--nograph-funcs' and '--trace-funcs' options didn't work as expected when the doesn't exist. Because the kernel side hid possible errors. $ sudo ./perf ftrace -a --graph-depth 1 --graph-funcs abcdefg 0) 0.140 us|

[PATCH 4/5] perf python: Make twatch.py work with both python2 and python3

From: Arnaldo Carvalho de Melo Will be used to test patches allowing to build perf with python3, so that we make sure that we can build with both versions. Cc: Adrian Hunter Cc: David Ahern Cc: Jaroslav Škarvada Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 5/5] perf tools: Add Python 3 support

From: Jaroslav Škarvada Added Python 3 support while keeping Python 2.7 compatibility. Committer notes: This doesn't make it to auto detect python 3, one has to explicitely ask it to build with python 3 devel files, here are the instructions provided by Jaroslav: --- $

[PATCH 5/5] perf tools: Add Python 3 support

From: Jaroslav Škarvada Added Python 3 support while keeping Python 2.7 compatibility. Committer notes: This doesn't make it to auto detect python 3, one has to explicitely ask it to build with python 3 devel files, here are the instructions provided by Jaroslav: --- $ cp -a tools/perf

Re: [PATCH 1/4] watchdog: uniphier: change order for setting default timeout

2018-02-11 5:36 GMT+09:00 Marcus Folkesson : > watchdog_init_timeout() will preserve wdd->timeout value if no parameter > nor timeout-secs dt property is set. > > Signed-off-by: Marcus Folkesson > --- > drivers/watchdog/uniphier_wdt.c | 5

Re: [PATCH 1/4] watchdog: uniphier: change order for setting default timeout

2018-02-11 5:36 GMT+09:00 Marcus Folkesson : > watchdog_init_timeout() will preserve wdd->timeout value if no parameter > nor timeout-secs dt property is set. > > Signed-off-by: Marcus Folkesson > --- > drivers/watchdog/uniphier_wdt.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-)

Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range

On Tue, Feb 20, 2018 at 3:17 PM, Andrew Morton wrote: > On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long wrote: > >> Even with clamped sysctl parameters, it is still not that straight >> forward to figure out the exact range of those parameters. One

Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range

On Tue, Feb 20, 2018 at 3:17 PM, Andrew Morton wrote: > On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long wrote: > >> Even with clamped sysctl parameters, it is still not that straight >> forward to figure out the exact range of those parameters. One may >> try to write extreme parameter values to

Re: [PATCH 3/3] fs: fsnotify: account fsnotify metadata to kmemcg

Hi Shakeel, Thank you for the patch! Yet something to improve: [auto build test ERROR on mmotm/master] [also build test ERROR on next-20180220] [cannot apply to linus/master v4.16-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH 3/3] fs: fsnotify: account fsnotify metadata to kmemcg

Hi Shakeel, Thank you for the patch! Yet something to improve: [auto build test ERROR on mmotm/master] [also build test ERROR on next-20180220] [cannot apply to linus/master v4.16-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

[PATCH 2/2] arm64: Clear the stack

Implementation of stackleak based heavily on the x86 version Signed-off-by: Laura Abbott --- arch/arm64/Kconfig| 1 + arch/arm64/include/asm/processor.h| 6 ++ arch/arm64/kernel/asm-offsets.c | 3 + arch/arm64/kernel/entry.S |

[PATCH 2/2] arm64: Clear the stack

Implementation of stackleak based heavily on the x86 version Signed-off-by: Laura Abbott --- arch/arm64/Kconfig| 1 + arch/arm64/include/asm/processor.h| 6 ++ arch/arm64/kernel/asm-offsets.c | 3 + arch/arm64/kernel/entry.S | 108

[PATCH 0/2] Stackleak for arm64

This is the arm64 version of the STACKLEAK plugin originall from grsecurity. See https://marc.info/?l=kernel-hardening=151880470609808 for the full x86 version. This is based on top of Kees' branch for stackleak and has been cleaned up to use a few macros from that branch. Comments welcome, if

[PATCH 1/2] stackleak: Update for arm64

arm64 has another layer of indirection in the RTL. Account for this in the plugin. Signed-off-by: Laura Abbott --- scripts/gcc-plugins/stackleak_plugin.c | 5 + 1 file changed, 5 insertions(+) diff --git a/scripts/gcc-plugins/stackleak_plugin.c

[PATCH 1/2] stackleak: Update for arm64

arm64 has another layer of indirection in the RTL. Account for this in the plugin. Signed-off-by: Laura Abbott --- scripts/gcc-plugins/stackleak_plugin.c | 5 + 1 file changed, 5 insertions(+) diff --git a/scripts/gcc-plugins/stackleak_plugin.c b/scripts/gcc-plugins/stackleak_plugin.c

[PATCH 0/2] Stackleak for arm64

This is the arm64 version of the STACKLEAK plugin originall from grsecurity. See https://marc.info/?l=kernel-hardening=151880470609808 for the full x86 version. This is based on top of Kees' branch for stackleak and has been cleaned up to use a few macros from that branch. Comments welcome, if

RE: [PATCH 1/2] fs/efivarfs: restrict inode permissions

>> EFI[1] stinks. Reading any file in /sys/firmware/efi/efivars/ generates >> 4 (yes FOUR!) SMIs. > Is that actualkly the normal implementation? I don't know if there are other implementations. This is what I see on my lab system. > Also, if these are just synchronous SMI's, then don't we just

RE: [PATCH 1/2] fs/efivarfs: restrict inode permissions

>> EFI[1] stinks. Reading any file in /sys/firmware/efi/efivars/ generates >> 4 (yes FOUR!) SMIs. > Is that actualkly the normal implementation? I don't know if there are other implementations. This is what I see on my lab system. > Also, if these are just synchronous SMI's, then don't we just

[PATCH] media: dw9714: Update to SPDX license identifier

Remove the GPL v2 license boilerplate and update with the SPDX license identifier. Signed-off-by: Rajmohan Mani --- drivers/media/i2c/dw9714.c | 14 ++ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/drivers/media/i2c/dw9714.c

[PATCH] media: dw9714: Update to SPDX license identifier

Remove the GPL v2 license boilerplate and update with the SPDX license identifier. Signed-off-by: Rajmohan Mani --- drivers/media/i2c/dw9714.c | 14 ++ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/drivers/media/i2c/dw9714.c b/drivers/media/i2c/dw9714.c index

Re: [PATCH 2/3] mm: memcg: plumbing memcg for kmalloc allocations

Hi Shakeel, Thank you for the patch! Yet something to improve: [auto build test ERROR on mmotm/master] [also build test ERROR on v4.16-rc2 next-20180220] [cannot apply to linus/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH 2/3] mm: memcg: plumbing memcg for kmalloc allocations

Hi Shakeel, Thank you for the patch! Yet something to improve: [auto build test ERROR on mmotm/master] [also build test ERROR on v4.16-rc2 next-20180220] [cannot apply to linus/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 02:01:51PM -0800, Linus Torvalds wrote: > Which variables are actually used by user space tools? It sounds like > it may be exactly those boot order things that we already have flags > and special behavior for. Not that many are really part of a non-root workflow. The

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 02:01:51PM -0800, Linus Torvalds wrote: > Which variables are actually used by user space tools? It sounds like > it may be exactly those boot order things that we already have flags > and special behavior for. Not that many are really part of a non-root workflow. The

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 3:30 PM, Luck, Tony wrote: > > Too much weasel there. Should say: > > EFI[1] stinks. Reading any file in /sys/firmware/efi/efivars/ generates > 4 (yes FOUR!) SMIs. Is that actualkly the normal implementation? Also, if these are just synchronous

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 3:30 PM, Luck, Tony wrote: > > Too much weasel there. Should say: > > EFI[1] stinks. Reading any file in /sys/firmware/efi/efivars/ generates > 4 (yes FOUR!) SMIs. Is that actualkly the normal implementation? Also, if these are just synchronous SMI's, then don't we just

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

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 and vmsplice. All seems fairly strightforward. The big question is: do we know that people will actually

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

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 and vmsplice. All seems fairly strightforward. The big question is: do we know that people will actually use this, and get

Re: [PATH 0/4] usbip: make vhci_hcd.* objects independent of vhci_hcd.0

Hi Salvador, On 01/30/2018 01:36 AM, Salvador Fandino wrote: > Let me start by explaining the problem that have motivated me to write > this patches: > > I work on the QVD, a virtual desktop platform for Linux. This software > runs Linux desktops (i.e. XFCE, KDE) and their applications inside

Re: [PATH 0/4] usbip: make vhci_hcd.* objects independent of vhci_hcd.0

Hi Salvador, On 01/30/2018 01:36 AM, Salvador Fandino wrote: > Let me start by explaining the problem that have motivated me to write > this patches: > > I work on the QVD, a virtual desktop platform for Linux. This software > runs Linux desktops (i.e. XFCE, KDE) and their applications inside

Re: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero

On Tue, 2018-02-20 at 14:54 +0530, Chintan Pandya wrote: > > On 12/28/2017 4:54 PM, Hanjun Guo wrote: > > From: Hanjun Guo > > > > When we using iounmap() to free the 4K mapping, it just clear the PTEs > > but leave P4D/PUD/PMD unchanged, also will not free the memory of

Re: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero

On Tue, 2018-02-20 at 14:54 +0530, Chintan Pandya wrote: > > On 12/28/2017 4:54 PM, Hanjun Guo wrote: > > From: Hanjun Guo > > > > When we using iounmap() to free the 4K mapping, it just clear the PTEs > > but leave P4D/PUD/PMD unchanged, also will not free the memory of page > > tables. > > >

[PATCH v5] rtc: isl12026: Add driver.

The ISL12026 is a combination RTC and EEPROM device with I2C interface. The standard RTC driver interface is provided. The EEPROM is accessed via the NVMEM interface via the "eeprom0" directory in the sysfs entry for the device. Reviewed-by: Rob Herring Reviewed-by: Andy

[PATCH v5] rtc: isl12026: Add driver.

The ISL12026 is a combination RTC and EEPROM device with I2C interface. The standard RTC driver interface is provided. The EEPROM is accessed via the NVMEM interface via the "eeprom0" directory in the sysfs entry for the device. Reviewed-by: Rob Herring Reviewed-by: Andy Shevchenko

Re: [PATCH] fork: Allow stack to be wiped on fork

On Tue, 16 Jan 2018 21:50:15 -0800 Kees Cook wrote: > One of the classes of kernel stack content leaks is exposing the contents > of prior heap or stack contents when a new process stack is allocated. > Normally, those stacks are not zeroed, and the old contents remain in

Re: [PATCH] fork: Allow stack to be wiped on fork

On Tue, 16 Jan 2018 21:50:15 -0800 Kees Cook wrote: > One of the classes of kernel stack content leaks is exposing the contents > of prior heap or stack contents when a new process stack is allocated. > Normally, those stacks are not zeroed, and the old contents remain in > place. With some

Re: [PATCH 3/4] kernel/fork: switch vmapped stack callation to __vmalloc_area()

On Tue, 23 Jan 2018 16:57:21 +0300 Konstantin Khlebnikov wrote: > # stress-ng --clone 100 -t 10s --metrics-brief > at 32-core machine shows boost 35000 -> 36000 bogo ops > > Patch 4/4 is a kind of RFC. > Actually per-cpu cache of preallocated stacks works faster than

Re: [PATCH 3/4] kernel/fork: switch vmapped stack callation to __vmalloc_area()

On Tue, 23 Jan 2018 16:57:21 +0300 Konstantin Khlebnikov wrote: > # stress-ng --clone 100 -t 10s --metrics-brief > at 32-core machine shows boost 35000 -> 36000 bogo ops > > Patch 4/4 is a kind of RFC. > Actually per-cpu cache of preallocated stacks works faster than buddy > allocator thus >

Re: [PATCH v2 0/3] new driver for Valve Steam Controller

On 02/20/2018 03:20 PM, Rodrigo Rivas Costa wrote: On Tue, Feb 20, 2018 at 02:29:48PM -0800, Pierre-Loup A. Griffais wrote: Hi Rodrigo, Thanks for working on that! I have a few questions and remarks. For the reverse-engineering part, there's a lot of existing reference in existing

Re: [PATCH v2 0/3] new driver for Valve Steam Controller

On 02/20/2018 03:20 PM, Rodrigo Rivas Costa wrote: On Tue, Feb 20, 2018 at 02:29:48PM -0800, Pierre-Loup A. Griffais wrote: Hi Rodrigo, Thanks for working on that! I have a few questions and remarks. For the reverse-engineering part, there's a lot of existing reference in existing

[PATCH 0/3] Update TPS68470 PMIC drivers with SPDX tags

This patch series update the TPS68470 PMIC drivers with SPDX license identifiers, while removing the GPL v2 boilerplate license text. Rajmohan Mani (3): mfd: Update to SPDX license identifier gpio: Update to SPDX license identifier ACPI / PMIC: Update to SPDX license identifier

[PATCH 1/3] mfd: Update to SPDX license identifier

Remove the GPL v2 license boilerplate and update with the SPDX license identifier. Signed-off-by: Rajmohan Mani --- drivers/mfd/tps68470.c | 10 +- include/linux/mfd/tps68470.h | 17 +++-- 2 files changed, 4 insertions(+), 23 deletions(-) diff

[PATCH 0/3] Update TPS68470 PMIC drivers with SPDX tags

This patch series update the TPS68470 PMIC drivers with SPDX license identifiers, while removing the GPL v2 boilerplate license text. Rajmohan Mani (3): mfd: Update to SPDX license identifier gpio: Update to SPDX license identifier ACPI / PMIC: Update to SPDX license identifier

[PATCH 1/3] mfd: Update to SPDX license identifier

Remove the GPL v2 license boilerplate and update with the SPDX license identifier. Signed-off-by: Rajmohan Mani --- drivers/mfd/tps68470.c | 10 +- include/linux/mfd/tps68470.h | 17 +++-- 2 files changed, 4 insertions(+), 23 deletions(-) diff --git

[PATCH 2/3] gpio: Update to SPDX license identifier

Remove the GPL v2 license boilerplate and update with the SPDX license identifier. Signed-off-by: Rajmohan Mani --- drivers/gpio/gpio-tps68470.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/gpio/gpio-tps68470.c

[PATCH 2/3] gpio: Update to SPDX license identifier

Remove the GPL v2 license boilerplate and update with the SPDX license identifier. Signed-off-by: Rajmohan Mani --- drivers/gpio/gpio-tps68470.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/gpio/gpio-tps68470.c b/drivers/gpio/gpio-tps68470.c index

[PATCH 3/3] ACPI / PMIC: Update to SPDX license identifier

Remove the GPL v2 license boilerplate and update with the SPDX license identifier. Signed-off-by: Rajmohan Mani --- drivers/acpi/pmic/tps68470_pmic.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/acpi/pmic/tps68470_pmic.c

[PATCH 3/3] ACPI / PMIC: Update to SPDX license identifier

Remove the GPL v2 license boilerplate and update with the SPDX license identifier. Signed-off-by: Rajmohan Mani --- drivers/acpi/pmic/tps68470_pmic.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/acpi/pmic/tps68470_pmic.c

Re: [PATCH 2/2] proc: use set_puts() at /proc/*/wchan

On Sat, 17 Feb 2018 16:06:42 +0200 Andy Shevchenko wrote: > On Sat, Feb 17, 2018 at 9:20 AM, Alexey Dobriyan wrote: > > Signed-off-by: Alexey Dobriyan > > > > - seq_printf(m, "%s", symname); > > +

Re: [PATCH 2/2] proc: use set_puts() at /proc/*/wchan

On Sat, 17 Feb 2018 16:06:42 +0200 Andy Shevchenko wrote: > On Sat, Feb 17, 2018 at 9:20 AM, Alexey Dobriyan wrote: > > Signed-off-by: Alexey Dobriyan > > > > - seq_printf(m, "%s", symname); > > + seq_puts(m, symname); > > While this might have no security

Re: [PATCH] proc/kpageflags: add KPF_WAITERS

On Sat, 17 Feb 2018 11:14:10 +0300 Konstantin Khlebnikov wrote: > On 17.02.2018 02:57, Andrew Morton wrote: > > On Sun, 11 Feb 2018 13:36:41 +0300 Konstantin Khlebnikov > > wrote: > > > >> KPF_WAITERS indicates tasks are waiting for a

Re: [PATCH] proc/kpageflags: add KPF_WAITERS

On Sat, 17 Feb 2018 11:14:10 +0300 Konstantin Khlebnikov wrote: > On 17.02.2018 02:57, Andrew Morton wrote: > > On Sun, 11 Feb 2018 13:36:41 +0300 Konstantin Khlebnikov > > wrote: > > > >> KPF_WAITERS indicates tasks are waiting for a page lock or writeback. > >> This might be

Re: [PATCH] fs: proc: use down_read_killable in proc_pid_cmdline_read()

On 2/20/18 11:49 AM, Yang Shi wrote: 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 "echo 0 >

Re: [PATCH] fs: proc: use down_read_killable in proc_pid_cmdline_read()

On 2/20/18 11:49 AM, Yang Shi wrote: 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 "echo 0 >

Re: [RFC PATCH v16 0/6] mm: security: ro protection for dynamic data

On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote: > FWIW, I'm not wanting to use it to replace static variables. All the > structures are dynamically allocated right now, and get assigned to > other dynamically allocated pointers. I'd likely split the current > structures into a "ro

Re: [RFC PATCH v16 0/6] mm: security: ro protection for dynamic data

On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote: > FWIW, I'm not wanting to use it to replace static variables. All the > structures are dynamically allocated right now, and get assigned to > other dynamically allocated pointers. I'd likely split the current > structures into a "ro

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote: > On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote: > > Am 20.02.2018 um 15:54 schrieb Peter Zijlstra: > > > On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote: > > > > > OK, but neither case would in fact

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote: > On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote: > > Am 20.02.2018 um 15:54 schrieb Peter Zijlstra: > > > On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote: > > > > > OK, but neither case would in fact

Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range

On Tue, Feb 20, 2018 at 03:17:05PM -0800, Andrew Morton wrote: > On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long wrote: > > > Even with clamped sysctl parameters, it is still not that straight > > forward to figure out the exact range of those parameters. One may > > try to

Re: [PATCH v2 01/21] lib/vsprintf: Print time and date in human readable format via %pt

On Tue, 2018-02-20 at 23:43 +0200, Andy Shevchenko wrote: > There are users which print time and date represented by content of > struct rtc_time in human readable format. > > Instead of open coding that each time introduce %ptR[dt][rv] specifier. > > Note, users have to select

Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range

On Tue, Feb 20, 2018 at 03:17:05PM -0800, Andrew Morton wrote: > On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long wrote: > > > Even with clamped sysctl parameters, it is still not that straight > > forward to figure out the exact range of those parameters. One may > > try to write extreme

Re: [PATCH v2 01/21] lib/vsprintf: Print time and date in human readable format via %pt

On Tue, 2018-02-20 at 23:43 +0200, Andy Shevchenko wrote: > There are users which print time and date represented by content of > struct rtc_time in human readable format. > > Instead of open coding that each time introduce %ptR[dt][rv] specifier. > > Note, users have to select

RE: [PATCH 1/2] fs/efivarfs: restrict inode permissions

> read() will make two calls - one to obtain the size of the variable, the > other to read it. It looks like cat will also trigger an fstat(), so we're > probably also making a call for that. There's presumably some optimisation > that could be made there if we trust the firmware not to change the

RE: [PATCH 1/2] fs/efivarfs: restrict inode permissions

> read() will make two calls - one to obtain the size of the variable, the > other to read it. It looks like cat will also trigger an fstat(), so we're > probably also making a call for that. There's presumably some optimisation > that could be made there if we trust the firmware not to change the

Re: [PATCH 5/6] powerpc: Implement DISCONTIGMEM and allow selection on PPC32

Hi Jonathan, Thank you for the patch! Yet something to improve: [auto build test ERROR on powerpc/next] [also build test ERROR on v4.16-rc2 next-20180220] [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

Re: [PATCH 5/6] powerpc: Implement DISCONTIGMEM and allow selection on PPC32

Hi Jonathan, Thank you for the patch! Yet something to improve: [auto build test ERROR on powerpc/next] [also build test ERROR on v4.16-rc2 next-20180220] [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

metag build errors in mainline kernel

The following errors are seen when building the kernel with the latest available metag toolchain (4.2.4 (IMG-1.4.0.700)). Kernel version tested is (v4.16-rc2-64-gaf3e79d29555). metag:allmodconfig arch/metag/kernel/devtree.c:54: error: implicit declaration of function 'pr_info'

metag build errors in mainline kernel

The following errors are seen when building the kernel with the latest available metag toolchain (4.2.4 (IMG-1.4.0.700)). Kernel version tested is (v4.16-rc2-64-gaf3e79d29555). metag:allmodconfig arch/metag/kernel/devtree.c:54: error: implicit declaration of function 'pr_info'

Re: [PATCH 1/3] sysctl: Add range clamping intvec helper functions

On Mon, Feb 19, 2018 at 11:53:49AM -0500, Waiman Long wrote: > The current intvec range helper functions will fail with error when > users try to assign an out-of-range value. As designed. > The following new non-failing range helper functions are now added: > - proc_dointvec_clamp_minmax() >

Re: [PATCH 1/3] sysctl: Add range clamping intvec helper functions

On Mon, Feb 19, 2018 at 11:53:49AM -0500, Waiman Long wrote: > The current intvec range helper functions will fail with error when > users try to assign an out-of-range value. As designed. > The following new non-failing range helper functions are now added: > - proc_dointvec_clamp_minmax() >

Re: [PATCH v1 0/2] PCI: Sparc 64-bit resource fixups

[+cc David Ahern, TJ] On Thu, Feb 15, 2018 at 09:17:58AM -0600, Bjorn Helgaas wrote: > I'm trying to make some progress on this old series from Yinghai [1]. > There's a lot more to do than just these first two patches, but maybe a > tiny bit of incremental progress is better than none. > > The

Re: [PATCH v1 0/2] PCI: Sparc 64-bit resource fixups

[+cc David Ahern, TJ] On Thu, Feb 15, 2018 at 09:17:58AM -0600, Bjorn Helgaas wrote: > I'm trying to make some progress on this old series from Yinghai [1]. > There's a lot more to do than just these first two patches, but maybe a > tiny bit of incremental progress is better than none. > > The

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 3:30 PM Luck, Tony wrote: > [1] I didn't dig through the Linux code to check whether we manage to > get those four SMIs from a single EFI call, or whether we make multiple > EFI calls to open/read/close one file. It is possible that we stink a > bit

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 3:30 PM Luck, Tony wrote: > [1] I didn't dig through the Linux code to check whether we manage to > get those four SMIs from a single EFI call, or whether we make multiple > EFI calls to open/read/close one file. It is possible that we stink a > bit too if we are doing

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