[PATCH bpf-next v8 02/11] fs,security: Add a new file access type: MAY_CHROOT

For compatibility reason, MAY_CHROOT is always set with MAY_CHDIR. However, this new flag enable to differentiate a chdir form a chroot. This is needed for the Landlock LSM to be able to evaluate a new root directory. Signed-off-by: Mickaël Salaün Cc: Alexander Viro

[PATCH bpf-next v8 02/11] fs,security: Add a new file access type: MAY_CHROOT

For compatibility reason, MAY_CHROOT is always set with MAY_CHDIR. However, this new flag enable to differentiate a chdir form a chroot. This is needed for the Landlock LSM to be able to evaluate a new root directory. Signed-off-by: Mickaël Salaün Cc: Alexander Viro Cc: Casey Schaufler Cc:

[PATCH bpf-next v8 06/11] bpf,landlock: Add a new map type: inode

This new map store arbitrary 64-bits values referenced by inode keys. The map can be updated from user space with file descriptor pointing to inodes tied to a file system. From an eBPF (Landlock) program point of view, such a map is read-only and can only be used to retrieved a 64-bits value tied

[PATCH bpf-next v8 06/11] bpf,landlock: Add a new map type: inode

This new map store arbitrary 64-bits values referenced by inode keys. The map can be updated from user space with file descriptor pointing to inodes tied to a file system. From an eBPF (Landlock) program point of view, such a map is read-only and can only be used to retrieved a 64-bits value tied

[RFC -mm] mm: Fix races between swapoff and flush dcache

From: Huang Ying >From commit 4b3ef9daa4fc ("mm/swap: split swap cache into 64MB trunks") on, after swapoff, the address_space associated with the swap device will be freed. So page_mapping() users which may touch the address_space need some kind of mechanism to prevent

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

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 is needed for the Landlock LSM to be able to restrict access to file

[RFC -mm] mm: Fix races between swapoff and flush dcache

From: Huang Ying >From commit 4b3ef9daa4fc ("mm/swap: split swap cache into 64MB trunks") on, after swapoff, the address_space associated with the swap device will be freed. So page_mapping() users which may touch the address_space need some kind of mechanism to prevent the address_space from

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

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 is needed for the Landlock LSM to be able to restrict access to file

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

Test basic context access, ptrace protection and filesystem hooks and Landlock program chaining with multiple cases. Signed-off-by: Mickaël Salaün Cc: Alexei Starovoitov Cc: Andy Lutomirski Cc: Daniel Borkmann Cc:

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

Test basic context access, ptrace protection and filesystem hooks and Landlock program chaining with multiple cases. Signed-off-by: Mickaël Salaün Cc: Alexei Starovoitov Cc: Andy Lutomirski Cc: Daniel Borkmann Cc: David S. Miller Cc: James Morris Cc: Kees Cook Cc: Serge E. Hallyn Cc:

[PATCH bpf-next v8 11/11] landlock: Add user and kernel documentation for Landlock

This documentation can be built with the Sphinx framework. Signed-off-by: Mickaël Salaün Cc: Alexei Starovoitov Cc: Andy Lutomirski Cc: Daniel Borkmann Cc: David S. Miller Cc: James Morris

[PATCH bpf-next v8 11/11] landlock: Add user and kernel documentation for Landlock

This documentation can be built with the Sphinx framework. Signed-off-by: Mickaël Salaün Cc: Alexei Starovoitov Cc: Andy Lutomirski Cc: Daniel Borkmann Cc: David S. Miller Cc: James Morris Cc: Jonathan Corbet Cc: Kees Cook Cc: Serge E. Hallyn --- Changes since v7: * update documentation

[PATCH bpf-next v8 07/11] landlock: Handle filesystem access control

This add three Landlock: FS_WALK, FS_PICK and FS_GET. The FS_WALK hook is used to walk through a file path. A program tied to this hook will be evaluated for each directory traversal except the last one if it is the leaf of the path. The FS_PICK hook is used to validate a set of actions

[PATCH bpf-next v8 07/11] landlock: Handle filesystem access control

This add three Landlock: FS_WALK, FS_PICK and FS_GET. The FS_WALK hook is used to walk through a file path. A program tied to this hook will be evaluated for each directory traversal except the last one if it is the leaf of the path. The FS_PICK hook is used to validate a set of actions

[PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

A landlocked process has less privileges than a non-landlocked process and must then be subject to additional restrictions when manipulating processes. To be allowed to use ptrace(2) and related syscalls on a target process, a landlocked process must have a subset of the target process' rules.

[PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

A landlocked process has less privileges than a non-landlocked process and must then be subject to additional restrictions when manipulating processes. To be allowed to use ptrace(2) and related syscalls on a target process, a landlocked process must have a subset of the target process' rules.

[PATCH bpf-next v8 09/11] bpf: Add a Landlock sandbox example

Add a basic sandbox tool to launch a command which is only allowed to access in a read only or read-write way a whitelist of file hierarchies. Add to the bpf_load library the ability to handle a BPF program subtype. Signed-off-by: Mickaël Salaün Cc: Alexei Starovoitov

[PATCH bpf-next v8 09/11] bpf: Add a Landlock sandbox example

Add a basic sandbox tool to launch a command which is only allowed to access in a read only or read-write way a whitelist of file hierarchies. Add to the bpf_load library the ability to handle a BPF program subtype. Signed-off-by: Mickaël Salaün Cc: Alexei Starovoitov Cc: Andy Lutomirski Cc:

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

Hi Thomas, On 2/20/2018 9:15 AM, Thomas Gleixner wrote: > Let's look at the existing crtl/mon groups which are each represented by a > directory already. > > - Adding a 'size' file to the ctrl groups would be a natural extension >which makes sense for regular cache allocations as well. > >

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

Hi Thomas, On 2/20/2018 9:15 AM, Thomas Gleixner wrote: > Let's look at the existing crtl/mon groups which are each represented by a > directory already. > > - Adding a 'size' file to the ctrl groups would be a natural extension >which makes sense for regular cache allocations as well. > >

Re: [PATCH v15 00/11] fw_cfg: add DMA operations & etc/vmcoreinfo support

On Thu, Feb 15, 2018 at 10:33:01PM +0100, Marc-André Lureau wrote: > Hi, > > This series adds DMA operations support to the qemu fw_cfg kernel > module and populates "etc/vmcoreinfo" with vmcoreinfo location > details (entry added since qemu 2.11 with -device vmcoreinfo). Pls reorder with

Re: [PATCH v15 00/11] fw_cfg: add DMA operations & etc/vmcoreinfo support

On Thu, Feb 15, 2018 at 10:33:01PM +0100, Marc-André Lureau wrote: > Hi, > > This series adds DMA operations support to the qemu fw_cfg kernel > module and populates "etc/vmcoreinfo" with vmcoreinfo location > details (entry added since qemu 2.11 with -device vmcoreinfo). Pls reorder with

Re: [PATCH v15 10/11] fw_cfg: write vmcoreinfo details

On Thu, Feb 15, 2018 at 10:33:11PM +0100, Marc-André Lureau wrote: > If the "etc/vmcoreinfo" fw_cfg file is present and we are not running > the kdump kernel, write the addr/size of the vmcoreinfo ELF note. > > The DMA operation is expected to run synchronously with today qemu, > but the

Re: [PATCH v15 10/11] fw_cfg: write vmcoreinfo details

On Thu, Feb 15, 2018 at 10:33:11PM +0100, Marc-André Lureau wrote: > If the "etc/vmcoreinfo" fw_cfg file is present and we are not running > the kdump kernel, write the addr/size of the vmcoreinfo ELF note. > > The DMA operation is expected to run synchronously with today qemu, > but the

[PATCH 3/4 v2] fs: proc: use down_read_killable() in environ_read()

Like reading /proc/*/cmdline, it is possible to be blocked for long time when reading /proc/*/environ when manipulating large mapping at the mean time. The environ reading process will be waiting for mmap_sem become available for a long time then it may cause the reading task hung. Convert

[PATCH 3/4 v2] fs: proc: use down_read_killable() in environ_read()

Like reading /proc/*/cmdline, it is possible to be blocked for long time when reading /proc/*/environ when manipulating large mapping at the mean time. The environ reading process will be waiting for mmap_sem become available for a long time then it may cause the reading task hung. Convert

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

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 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"

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

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 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"

[PATCH 2/4 v2] fs: proc: use down_read_killable in proc_pid_cmdline_read()

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 > /proc/sys/kernel/hung_task_timeout_secs" disables this

[PATCH 2/4 v2] fs: proc: use down_read_killable in proc_pid_cmdline_read()

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 > /proc/sys/kernel/hung_task_timeout_secs" disables this

[PATCH 4/4 v2] mm: use access_remote_vm() in get_cmdline()

get_cmdline() is using access_process_vm() which increases mm reference count, but the mm reference count has been increased before calling access_process_vm() and it is kept across get_cmdline(). It sounds unnecessary to get mm reference count increased twice, so replace access_process_vm() to

[PATCH 1/4 v2] mm: add access_remote_vm_killable APIs

Extracted common part (without acquiring mmap_sem) of __access_remote_vm() into raw_access_remote_vm() then create __access_remote_vm_killable() and access_remote_vm_killable() with acquiring mmap_sem by down_read_killable(). Keep non-killable versions using down_read(). The killable version will

[PATCH 4/4 v2] mm: use access_remote_vm() in get_cmdline()

get_cmdline() is using access_process_vm() which increases mm reference count, but the mm reference count has been increased before calling access_process_vm() and it is kept across get_cmdline(). It sounds unnecessary to get mm reference count increased twice, so replace access_process_vm() to

[PATCH 1/4 v2] mm: add access_remote_vm_killable APIs

Extracted common part (without acquiring mmap_sem) of __access_remote_vm() into raw_access_remote_vm() then create __access_remote_vm_killable() and access_remote_vm_killable() with acquiring mmap_sem by down_read_killable(). Keep non-killable versions using down_read(). The killable version will

Re: [PATCH v15 08/11] fw_cfg: handle fw_cfg_read_blob() error

On Thu, Feb 15, 2018 at 10:33:09PM +0100, Marc-André Lureau wrote: > fw_cfg_read_blob() may fail, but does not return error. This may lead > to undefined behaviours, such as a memcmp(sig, "QEMU") on uninitilized > memory. I don't think that's true - there's a memset there that will initialize the

Re: [PATCH v15 08/11] fw_cfg: handle fw_cfg_read_blob() error

On Thu, Feb 15, 2018 at 10:33:09PM +0100, Marc-André Lureau wrote: > fw_cfg_read_blob() may fail, but does not return error. This may lead > to undefined behaviours, such as a memcmp(sig, "QEMU") on uninitilized > memory. I don't think that's true - there's a memset there that will initialize the

Re: [PATCH v5 0/4] ARM: OMAP2+: AM33XX/AM43XX: Add suspend-resume support

On 2/26/18 1:26 PM, Tony Lindgren wrote: * Santosh Shilimkar [180225 23:36]: Dave Gerlach (4): ARM: OMAP2+: Introduce low-level suspend code for AM33XX ARM: OMAP2+: Introduce low-level suspend code for AM43XX ARM: OMAP2+: pm33xx-core: Add platform code

Re: [PATCH v5 0/4] ARM: OMAP2+: AM33XX/AM43XX: Add suspend-resume support

On 2/26/18 1:26 PM, Tony Lindgren wrote: * Santosh Shilimkar [180225 23:36]: Dave Gerlach (4): ARM: OMAP2+: Introduce low-level suspend code for AM33XX ARM: OMAP2+: Introduce low-level suspend code for AM43XX ARM: OMAP2+: pm33xx-core: Add platform code needed for PM soc: ti:

Re: [PATCH v2 char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer signaling

On Fri, 16 Feb 2018 23:05:33 + Michael Kelley wrote: > Fix bugs in signaling the Hyper-V host when freeing space in the > host->guest ring buffer: > > 1. The interrupt_mask must not be used to determine whether to signal >on the host->guest ring buffer > 2. The

Re: [PATCH v2 char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer signaling

On Fri, 16 Feb 2018 23:05:33 + Michael Kelley wrote: > Fix bugs in signaling the Hyper-V host when freeing space in the > host->guest ring buffer: > > 1. The interrupt_mask must not be used to determine whether to signal >on the host->guest ring buffer > 2. The ring buffer write_index

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

On Mon, Feb 26, 2018 at 09:16:00PM +0100, 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

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

On Mon, Feb 26, 2018 at 09:16:00PM +0100, 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

Re: [PATCH v15 02/11] fw_cfg: add a public uapi header

On Thu, Feb 15, 2018 at 10:33:03PM +0100, Marc-André Lureau wrote: > Create a common header file for well-known values and structures to be > shared by the Linux kernel with qemu or other projects. > > It is based from qemu/docs/specs/fw_cfg.txt which references >

Re: [PATCH v15 02/11] fw_cfg: add a public uapi header

On Thu, Feb 15, 2018 at 10:33:03PM +0100, Marc-André Lureau wrote: > Create a common header file for well-known values and structures to be > shared by the Linux kernel with qemu or other projects. > > It is based from qemu/docs/specs/fw_cfg.txt which references >

[PATCH 1/3] console: SisUSB2VGA: Drop dummy con_font_get()

As done in commit: 724ba8b30b04 ("console/dummy: leave .con_font_get set to NULL") This drops the dummy .con_font_get(), as it could leave arguments uninitialized. Cc: Thomas Winischhofer Signed-off-by: Kees Cook ---

[PATCH 1/3] console: SisUSB2VGA: Drop dummy con_font_get()

As done in commit: 724ba8b30b04 ("console/dummy: leave .con_font_get set to NULL") This drops the dummy .con_font_get(), as it could leave arguments uninitialized. Cc: Thomas Winischhofer Signed-off-by: Kees Cook --- drivers/usb/misc/sisusbvga/sisusb_con.c | 1 - 1 file changed, 1

[PATCH 2/3] console: Fill in struct consw argument names

Reading the function declarations for the console callbacks lacks any hints as to what the arguments are. Instead of going and digging around in various implementations that may each only have a subset of the callbacks, name all the arguments in the declaration. This has no functional change.

[PATCH 2/3] console: Fill in struct consw argument names

Reading the function declarations for the console callbacks lacks any hints as to what the arguments are. Instead of going and digging around in various implementations that may each only have a subset of the callbacks, name all the arguments in the declaration. This has no functional change.

[PATCH 0/3] console: Expand dummy functions for CFI

This is a small series that cleans up struct consw a bit and prepares it for Control Flow Integrity checking (i.e. Clang's -fsanitize=cfi). Thanks! -Kees

[PATCH 0/3] console: Expand dummy functions for CFI

This is a small series that cleans up struct consw a bit and prepares it for Control Flow Integrity checking (i.e. Clang's -fsanitize=cfi). Thanks! -Kees

Re: [PATCH v15 11/11] RFC: fw_cfg: do DMA read operation

On Thu, Feb 15, 2018 at 10:33:12PM +0100, Marc-André Lureau wrote: > Modify fw_cfg_read_blob() to use DMA if the device supports it. > Return errors, because the operation may fail. > > So far, only one call in fw_cfg_register_dir_entries() is using > kmalloc'ed buf and is thus clearly eligible

Re: [PATCH v15 11/11] RFC: fw_cfg: do DMA read operation

On Thu, Feb 15, 2018 at 10:33:12PM +0100, Marc-André Lureau wrote: > Modify fw_cfg_read_blob() to use DMA if the device supports it. > Return errors, because the operation may fail. > > So far, only one call in fw_cfg_register_dir_entries() is using > kmalloc'ed buf and is thus clearly eligible

[PATCH 3/3] console: Expand dummy functions for CFI

This expands the no-op dummy functions into full prototypes to avoid indirect call mismatches when running under Control Flow Integrity checking, like with Clang's -fsanitize=cfi. Co-Developed-by: Sami Tolvanen Signed-off-by: Sami Tolvanen

[PATCH 3/3] console: Expand dummy functions for CFI

This expands the no-op dummy functions into full prototypes to avoid indirect call mismatches when running under Control Flow Integrity checking, like with Clang's -fsanitize=cfi. Co-Developed-by: Sami Tolvanen Signed-off-by: Sami Tolvanen Signed-off-by: Kees Cook ---

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

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] > extern atomic_long_t num_poisoned_pages

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

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] > extern atomic_long_t num_poisoned_pages

[PATCH v7 2/7] fuse: Fail all requests with invalid uids or gids

Upon a cursory examinination the uid and gid of a fuse request are necessary for correct operation. Failing a fuse request where those values are not reliable seems a straight forward and reliable means of ensuring that fuse requests with bad data are not sent or processed. In most cases the vfs

[PATCH v7 6/7] fuse: Support fuse filesystems outside of init_user_ns

In order to support mounts from namespaces other than init_user_ns, fuse must translate uids and gids to/from the userns of the process servicing requests on /dev/fuse. This patch does that, with a couple of restrictions on the namespace: - The userns for the fuse connection is fixed to the

[PATCH v7 2/7] fuse: Fail all requests with invalid uids or gids

Upon a cursory examinination the uid and gid of a fuse request are necessary for correct operation. Failing a fuse request where those values are not reliable seems a straight forward and reliable means of ensuring that fuse requests with bad data are not sent or processed. In most cases the vfs

[PATCH v7 6/7] fuse: Support fuse filesystems outside of init_user_ns

In order to support mounts from namespaces other than init_user_ns, fuse must translate uids and gids to/from the userns of the process servicing requests on /dev/fuse. This patch does that, with a couple of restrictions on the namespace: - The userns for the fuse connection is fixed to the

Re: [PATCH] rcu: Remove the unnecessary separate function, rcu_preempt_do_callback()

On Tue, Feb 27, 2018 at 08:40:47AM +0900, Byungchul Park wrote: > On 2/27/2018 8:35 AM, Byungchul Park wrote: > >On 2/27/2018 3:22 AM, Paul E. McKenney wrote: > >>On Mon, Feb 26, 2018 at 12:15:14PM -0500, Steven Rostedt wrote: > >>>On Mon, 26 Feb 2018 14:11:36 +0900 > >>>Byungchul Park

Re: [PATCH] rcu: Remove the unnecessary separate function, rcu_preempt_do_callback()

On Tue, Feb 27, 2018 at 08:40:47AM +0900, Byungchul Park wrote: > On 2/27/2018 8:35 AM, Byungchul Park wrote: > >On 2/27/2018 3:22 AM, Paul E. McKenney wrote: > >>On Mon, Feb 26, 2018 at 12:15:14PM -0500, Steven Rostedt wrote: > >>>On Mon, 26 Feb 2018 14:11:36 +0900 > >>>Byungchul Park wrote: >

[PATCH v7 5/7] fuse: Simplfiy the posix acl handling logic.

Rename the fuse connection flag posix_acl to cached_posix_acl as that is what it actually means. That fuse will cache and operate on the cached value of the posix acl. When fc->cached_posix_acl is not set, set ACL_DONT_CACHE on the inode so that get_acl and friends won't cache the acl values

[PATCH v7 5/7] fuse: Simplfiy the posix acl handling logic.

Rename the fuse connection flag posix_acl to cached_posix_acl as that is what it actually means. That fuse will cache and operate on the cached value of the posix acl. When fc->cached_posix_acl is not set, set ACL_DONT_CACHE on the inode so that get_acl and friends won't cache the acl values

[PATCH v7 7/7] fuse: Restrict allow_other to the superblock's namespace or a descendant

From: Seth Forshee Unprivileged users are normally restricted from mounting with the allow_other option by system policy, but this could be bypassed for a mount done with user namespace root permissions. In such cases allow_other should not allow users outside the

[PATCH v7 7/7] fuse: Restrict allow_other to the superblock's namespace or a descendant

From: Seth Forshee Unprivileged users are normally restricted from mounting with the allow_other option by system policy, but this could be bypassed for a mount done with user namespace root permissions. In such cases allow_other should not allow users outside the userns to access the mount as

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

Fuse is about to join overlayfs in relying on get_acl respecting ACL_DONT_CACHE so update the documentation in get_acl to reflect that fact. The comment and this change description should give people a clue that respecting ACL_DONT_CACHE in get_acl is important, and they should audit the

[PATCH v7 4/7] fuse: Cache a NULL acl when FUSE_GETXATTR returns -ENOSYS

When FUSE_GETXATTR will never return anything call cache_no_acl to cache that state in the vfs as well in fuse with fc->no_getxattr. The only code path this affects are the code paths that call fuse_get_acl and caching a NULL or returning it immediately is exactly the same effect so this should

[PATCH v7 4/7] fuse: Cache a NULL acl when FUSE_GETXATTR returns -ENOSYS

When FUSE_GETXATTR will never return anything call cache_no_acl to cache that state in the vfs as well in fuse with fc->no_getxattr. The only code path this affects are the code paths that call fuse_get_acl and caching a NULL or returning it immediately is exactly the same effect so this should

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

Fuse is about to join overlayfs in relying on get_acl respecting ACL_DONT_CACHE so update the documentation in get_acl to reflect that fact. The comment and this change description should give people a clue that respecting ACL_DONT_CACHE in get_acl is important, and they should audit the

[PATCH v7 1/7] fuse: Remove the buggy retranslation of pids in fuse_dev_do_read

At the point of fuse_dev_do_read the user space process that initiated the action on the fuse filesystem may no longer exist. The process have been killed or may have fired an asynchronous request and exited. If the initial process has exited the code "pid_vnr(find_pid_ns(in->h.pid, fc->pid_ns)"

[PATCH v7 1/7] fuse: Remove the buggy retranslation of pids in fuse_dev_do_read

At the point of fuse_dev_do_read the user space process that initiated the action on the fuse filesystem may no longer exist. The process have been killed or may have fired an asynchronous request and exited. If the initial process has exited the code "pid_vnr(find_pid_ns(in->h.pid, fc->pid_ns)"

[PATCH v7 0/7] fuse: mounts from non-init user namespaces

This patchset builds on the work by Donsu Park and Seth Forshee and is reduced to the set of patches that just affect fuse. The non-fuse patches are far enough along we can ignore them except possibly for the question of when does FS_USERNS_MOUNT get set in fuse_fs_type. Fuse with a block

[PATCH v7 0/7] fuse: mounts from non-init user namespaces

This patchset builds on the work by Donsu Park and Seth Forshee and is reduced to the set of patches that just affect fuse. The non-fuse patches are far enough along we can ignore them except possibly for the question of when does FS_USERNS_MOUNT get set in fuse_fs_type. Fuse with a block

[GIT PULL] TPM: Bug fixes

Please pull these bugfixes for TPM, from Jeremy Boone, via Jarkko Sakkinen. The following changes since commit 4c3579f6cadd5eb8250a36e789e6df66f660237a: Merge tag 'edac_fixes_for_4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp (2018-02-26 10:19:15 -0800) are available in the

[GIT PULL] TPM: Bug fixes

Please pull these bugfixes for TPM, from Jeremy Boone, via Jarkko Sakkinen. The following changes since commit 4c3579f6cadd5eb8250a36e789e6df66f660237a: Merge tag 'edac_fixes_for_4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp (2018-02-26 10:19:15 -0800) are available in the

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote: > On 02/23/2018 05:26 PM, Boris Ostrovsky wrote: >> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: >>> +static struct xen_gem_object *gem_create(struct drm_device *dev, >>> size_t size) >>> +{ >>> +struct xen_drm_front_drm_info

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote: > On 02/23/2018 05:26 PM, Boris Ostrovsky wrote: >> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: >>> +static struct xen_gem_object *gem_create(struct drm_device *dev, >>> size_t size) >>> +{ >>> +struct xen_drm_front_drm_info

Re: [PATCH] rcu: Remove the unnecessary separate function, rcu_preempt_do_callback()

On 2/27/2018 8:35 AM, Byungchul Park wrote: On 2/27/2018 3:22 AM, Paul E. McKenney wrote: On Mon, Feb 26, 2018 at 12:15:14PM -0500, Steven Rostedt wrote: On Mon, 26 Feb 2018 14:11:36 +0900 Byungchul Park wrote: rcu_preemptp_do_callback() was introduced in commit

Re: [PATCH] rcu: Remove the unnecessary separate function, rcu_preempt_do_callback()

On 2/27/2018 8:35 AM, Byungchul Park wrote: On 2/27/2018 3:22 AM, Paul E. McKenney wrote: On Mon, Feb 26, 2018 at 12:15:14PM -0500, Steven Rostedt wrote: On Mon, 26 Feb 2018 14:11:36 +0900 Byungchul Park wrote: rcu_preemptp_do_callback() was introduced in commit 09223371dea(rcu: Use softirq

Re: [PATCH] rcu: Remove the unnecessary separate function, rcu_preempt_do_callback()

On 2/27/2018 3:22 AM, Paul E. McKenney wrote: On Mon, Feb 26, 2018 at 12:15:14PM -0500, Steven Rostedt wrote: On Mon, 26 Feb 2018 14:11:36 +0900 Byungchul Park wrote: rcu_preemptp_do_callback() was introduced in commit 09223371dea(rcu: Use softirq to address

Re: [PATCH] rcu: Remove the unnecessary separate function, rcu_preempt_do_callback()

On 2/27/2018 3:22 AM, Paul E. McKenney wrote: On Mon, Feb 26, 2018 at 12:15:14PM -0500, Steven Rostedt wrote: On Mon, 26 Feb 2018 14:11:36 +0900 Byungchul Park wrote: rcu_preemptp_do_callback() was introduced in commit 09223371dea(rcu: Use softirq to address performance regression), where it

Re: [GIT PULL] tpmdd fixes for 4.16

On Mon, 26 Feb 2018, James Bottomley wrote: > On Tue, 2018-02-27 at 05:52 +1100, James Morris wrote: > > On Mon, 26 Feb 2018, Jarkko Sakkinen wrote: > > > > > > > > Hi > > > > > > Here is a batch of critical fixes for 4.16. > > > > > > > Do you have CVEs for these?  If so, please include

Re: [GIT PULL] tpmdd fixes for 4.16

On Mon, 26 Feb 2018, James Bottomley wrote: > On Tue, 2018-02-27 at 05:52 +1100, James Morris wrote: > > On Mon, 26 Feb 2018, Jarkko Sakkinen wrote: > > > > > > > > Hi > > > > > > Here is a batch of critical fixes for 4.16. > > > > > > > Do you have CVEs for these?  If so, please include

Re: [alsa-devel] regression v4.16 on Nokia N900: sound does not work

Hi! > > >> JFYI: This issues is tracked in the regression reports for Linux 4.16 > > >> (http://bit.ly/lnxregrep416 ) with this id: > > >> > > >> Linux-Regression-ID: lr#4b650f > > > > > > Ok, so it seems that issue is bigger: whole sound subsystem does not > > > work. /proc/asound/cards is

Re: [alsa-devel] regression v4.16 on Nokia N900: sound does not work

Hi! > > >> JFYI: This issues is tracked in the regression reports for Linux 4.16 > > >> (http://bit.ly/lnxregrep416 ) with this id: > > >> > > >> Linux-Regression-ID: lr#4b650f > > > > > > Ok, so it seems that issue is bigger: whole sound subsystem does not > > > work. /proc/asound/cards is

Re: linux-next: manual merge of the bpf-next tree with the bpf tree

Hi Dave, On Mon, 26 Feb 2018 11:41:47 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the bpf-next tree got a conflict in: > > tools/testing/selftests/bpf/test_verifier.c > > between commit: > > ca36960211eb ("bpf: allow xadd only on aligned memory")

Re: linux-next: manual merge of the bpf-next tree with the bpf tree

Hi Dave, On Mon, 26 Feb 2018 11:41:47 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the bpf-next tree got a conflict in: > > tools/testing/selftests/bpf/test_verifier.c > > between commit: > > ca36960211eb ("bpf: allow xadd only on aligned memory") > > from the bpf tree

[PATCH] x86/mm/sme: Disable stack protection for mem_encrypt_identity.c

Stack protection is not compatible with early boot code. All of the early SME boot code is now isolated in a separate file, mem_encrypt_identity.c, so arch/x86/mm/Makefile can be updated to turn off stack protection for the entire file. This eliminates the need to worry about other functions

[PATCH] x86/mm/sme: Disable stack protection for mem_encrypt_identity.c

Stack protection is not compatible with early boot code. All of the early SME boot code is now isolated in a separate file, mem_encrypt_identity.c, so arch/x86/mm/Makefile can be updated to turn off stack protection for the entire file. This eliminates the need to worry about other functions

Re: [PATCH 2/2] kbuild: simplify ld-option implementation

Nice! Now we don't need to invoke $CC to find out info about linker support. Signed-off-by: Nick Desaulniers Tested-by: Nick Desaulniers On Thu, Feb 22, 2018 at 8:57 PM Masahiro Yamada < yamada.masah...@socionext.com> wrote: > Currently,

Re: [PATCH 2/2] kbuild: simplify ld-option implementation

Nice! Now we don't need to invoke $CC to find out info about linker support. Signed-off-by: Nick Desaulniers Tested-by: Nick Desaulniers On Thu, Feb 22, 2018 at 8:57 PM Masahiro Yamada < yamada.masah...@socionext.com> wrote: > Currently, linker options are tested by the coordination of $(CC)

Re: linux-next: Signed-off-by missing for commit in the rcu tree

On Tue, Feb 27, 2018 at 09:38:16AM +1100, Stephen Rothwell wrote: > Hi Paul, > > Commit > > 2a84d1aef423 ("rcu: Inline rcu_preempt_do_callback() into its sole caller") > > is missing a Signed-off-by from its committer. That would be because idiot here left the "-s" off of "git am"...

Re: linux-next: Signed-off-by missing for commit in the rcu tree

On Tue, Feb 27, 2018 at 09:38:16AM +1100, Stephen Rothwell wrote: > Hi Paul, > > Commit > > 2a84d1aef423 ("rcu: Inline rcu_preempt_do_callback() into its sole caller") > > is missing a Signed-off-by from its committer. That would be because idiot here left the "-s" off of "git am"...

[PATCH] sparc64: Oracle DAX driver depends on SPARC64

sparc:allmodconfig fails to build as follows. ERROR: "mdesc_release" [drivers/sbus/char/oradax.ko] undefined! ERROR: "sun4v_hvapi_register" [drivers/sbus/char/oradax.ko] undefined! ERROR: "mdesc_get_property" [drivers/sbus/char/oradax.ko] undefined! ERROR: "mdesc_node_by_name"

[PATCH] sparc64: Oracle DAX driver depends on SPARC64

sparc:allmodconfig fails to build as follows. ERROR: "mdesc_release" [drivers/sbus/char/oradax.ko] undefined! ERROR: "sun4v_hvapi_register" [drivers/sbus/char/oradax.ko] undefined! ERROR: "mdesc_get_property" [drivers/sbus/char/oradax.ko] undefined! ERROR: "mdesc_node_by_name"

[PATCH] PCI: Move declaration of of_irq_parse_and_map_pci under OF_IRQ

Since commit 4670d610d5923 ("PCI: Move OF-related PCI functions into PCI core"), sparc:allmodconfig fails to build with the following error. pcie-cadence-host.c:(.text+0x4c4): undefined reference to `of_irq_parse_and_map_pci' pcie-cadence-host.c:(.text+0x4c8): undefined reference

[PATCH] PCI: Move declaration of of_irq_parse_and_map_pci under OF_IRQ

Since commit 4670d610d5923 ("PCI: Move OF-related PCI functions into PCI core"), sparc:allmodconfig fails to build with the following error. pcie-cadence-host.c:(.text+0x4c4): undefined reference to `of_irq_parse_and_map_pci' pcie-cadence-host.c:(.text+0x4c8): undefined reference

Re: [alsa-devel] regression v4.16 on Nokia N900: sound does not work

On Mon 2018-02-26 16:02:22, Daniel Baluta wrote: > On Mon, Feb 26, 2018 at 3:13 PM, Pavel Machek wrote: > > Hi! > > > >> JFYI: This issues is tracked in the regression reports for Linux 4.16 > >> (http://bit.ly/lnxregrep416 ) with this id: > >> > >> Linux-Regression-ID: lr#4b650f >

Re: [alsa-devel] regression v4.16 on Nokia N900: sound does not work

On Mon 2018-02-26 16:02:22, Daniel Baluta wrote: > On Mon, Feb 26, 2018 at 3:13 PM, Pavel Machek wrote: > > Hi! > > > >> JFYI: This issues is tracked in the regression reports for Linux 4.16 > >> (http://bit.ly/lnxregrep416 ) with this id: > >> > >> Linux-Regression-ID: lr#4b650f > > > > Ok, so

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