Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

lock for args. The downside is growth of mm_struct. i.e. the code can be refactored to just hold the lock and relock only if necessary (unable to copy to user without faulting) -- Mateusz Guzik

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

lock for args. The downside is growth of mm_struct. i.e. the code can be refactored to just hold the lock and relock only if necessary (unable to copy to user without faulting) -- Mateusz Guzik

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

t; already have dedicated lock to protect them, it is safe to change back > to down_read. > > Signed-off-by: Yang Shi <yang@linux.alibaba.com> > Cc: Alexey Dobriyan <adobri...@gmail.com> > Cc: Michal Hocko <mho...@kernel.org> > Cc: Matthew Wilcox <wi...@infradea

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

already have dedicated lock to protect them, it is safe to change back > to down_read. > > Signed-off-by: Yang Shi > Cc: Alexey Dobriyan > Cc: Michal Hocko > Cc: Matthew Wilcox > Cc: Mateusz Guzik > Cc: Cyrill Gorcunov > --- > v1 --> v2: > * Use spinl

Re: linux-next: build failure after merge of the vfs tree

} } +#endif /* * Unnamed block devices are dummy devices used by virtual -- Mateusz Guzik

Re: linux-next: build failure after merge of the vfs tree

} } +#endif /* * Unnamed block devices are dummy devices used by virtual -- Mateusz Guzik

[PATCH] proc: get rid of task lock/unlock pair to read umask for the "status" file

get_task_umask locks/unlocks the task on its own. The only caller does the same thing immediately after. Utilize the fact the task has to be locked anyway and just do it once. Since there are no other users and the code is short, fold it in. Signed-off-by: Mateusz Guzik <mgu...@redhat.

[PATCH] proc: get rid of task lock/unlock pair to read umask for the "status" file

get_task_umask locks/unlocks the task on its own. The only caller does the same thing immediately after. Utilize the fact the task has to be locked anyway and just do it once. Since there are no other users and the code is short, fold it in. Signed-off-by: Mateusz Guzik --- fs/proc/array.c

Re: [RESEND PATCH 05/13] vfs: Replace array of file pointers with an IDR

__close_fd fd_install __close_fd will either see a NULL pointer and return -EBADF or will see an installed pointer and proceed with the close. Your proposed patch seems to be buggy in this regard. You call idr_remove, which from what I understand will free up the slot no matter what. You only detect an error based on whether there was a non-NULL pointer there or not. If so, fd_install can proceed to play with a deallocated entry. -- Mateusz Guzik

Re: [RESEND PATCH 05/13] vfs: Replace array of file pointers with an IDR

__close_fd fd_install __close_fd will either see a NULL pointer and return -EBADF or will see an installed pointer and proceed with the close. Your proposed patch seems to be buggy in this regard. You call idr_remove, which from what I understand will free up the slot no matter what. You only detect an error based on whether there was a non-NULL pointer there or not. If so, fd_install can proceed to play with a deallocated entry. -- Mateusz Guzik

[PATCH 0/2] fix emergency unfreezing

ing in order to keep the sb locked the whole time. The first patch moves sb iteration found in emergency remount to a dedicated func for code reuse. This patch patch is a no-op. The second employs factored out code to do both bdev and sb thaws. Mateusz Guzik (2): vfs: factor sb iteration

[PATCH 0/2] fix emergency unfreezing

ing in order to keep the sb locked the whole time. The first patch moves sb iteration found in emergency remount to a dedicated func for code reuse. This patch patch is a no-op. The second employs factored out code to do both bdev and sb thaws. Mateusz Guzik (2): vfs: factor sb iteration

[PATCH 2/2] buffer.c: call thaw_super during emergency thaw

is employed. Signed-off-by: Mateusz Guzik <mgu...@redhat.com> --- fs/buffer.c| 25 + fs/super.c | 44 ++-- include/linux/fs.h | 1 + 3 files changed, 44 insertions(+), 26 deletions(-) diff --git a/fs/buffer.

[PATCH 2/2] buffer.c: call thaw_super during emergency thaw

is employed. Signed-off-by: Mateusz Guzik --- fs/buffer.c| 25 + fs/super.c | 44 ++-- include/linux/fs.h | 1 + 3 files changed, 44 insertions(+), 26 deletions(-) diff --git a/fs/buffer.c b/fs/buffer.c index 170df85

[PATCH 1/2] vfs: factor sb iteration out of do_emergency_remount

The intent is to reduce code duplication with other code iterating the list. No functional changes. Signed-off-by: Mateusz Guzik <mgu...@redhat.com> --- fs/super.c | 61 - 1 file changed, 36 insertions(+), 25 deletions(-) diff

[PATCH 1/2] vfs: factor sb iteration out of do_emergency_remount

The intent is to reduce code duplication with other code iterating the list. No functional changes. Signed-off-by: Mateusz Guzik --- fs/super.c | 61 - 1 file changed, 36 insertions(+), 25 deletions(-) diff --git a/fs/super.c b/fs

[PATCH 0/2] minor fd cleanup

not be enforced. I don't see any benefits from sleeping over locking and not sleeping makes the function slightly nicer. Mateusz Guzik (2): vfs: stop clearing close on exec when closing a fd vfs: grab the lock instead of blocking in __fd_install during resizing Documentation/filesystems/porting | 4

[PATCH 0/2] minor fd cleanup

not be enforced. I don't see any benefits from sleeping over locking and not sleeping makes the function slightly nicer. Mateusz Guzik (2): vfs: stop clearing close on exec when closing a fd vfs: grab the lock instead of blocking in __fd_install during resizing Documentation/filesystems/porting | 4

[PATCH 2/2] vfs: grab the lock instead of blocking in __fd_install during resizing

be removed. Signed-off-by: Mateusz Guzik <mgu...@redhat.com> --- Documentation/filesystems/porting | 4 fs/file.c | 11 +++ 2 files changed, 7 insertions(+), 8 deletions(-) diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting

[PATCH 2/2] vfs: grab the lock instead of blocking in __fd_install during resizing

be removed. Signed-off-by: Mateusz Guzik --- Documentation/filesystems/porting | 4 fs/file.c | 11 +++ 2 files changed, 7 insertions(+), 8 deletions(-) diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index 93e0a24..17bb4dc

[PATCH 1/2] vfs: stop clearing close on exec when closing a fd

Codepaths allocating a fd always make sure the bit is set/unset depending on flags, thus clearing on close is redundant. Signed-off-by: Mateusz Guzik <mgu...@redhat.com> --- fs/file.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/file.c b/fs/file.c index 1fc7fbb..9d047bd 100644 --

[PATCH 1/2] vfs: stop clearing close on exec when closing a fd

Codepaths allocating a fd always make sure the bit is set/unset depending on flags, thus clearing on close is redundant. Signed-off-by: Mateusz Guzik --- fs/file.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/file.c b/fs/file.c index 1fc7fbb..9d047bd 100644 --- a/fs/file.c +++ b/fs

Re: fs, net: deadlock between bind/splice on af_unix

On Sun, Feb 05, 2017 at 11:22:12PM -0800, Cong Wang wrote: > On Tue, Jan 31, 2017 at 10:14 AM, Mateusz Guzik <mgu...@redhat.com> wrote: > > On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote: > >> Mind being more specific? > > > > Consider

Re: fs, net: deadlock between bind/splice on af_unix

On Sun, Feb 05, 2017 at 11:22:12PM -0800, Cong Wang wrote: > On Tue, Jan 31, 2017 at 10:14 AM, Mateusz Guzik wrote: > > On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote: > >> Mind being more specific? > > > > Consider 2 threads which bind the same so

Re: fs, net: deadlock between bind/splice on af_unix

On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote: > On Thu, Jan 26, 2017 at 10:41 PM, Mateusz Guzik <mgu...@redhat.com> wrote: > > On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote: > >> On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik <mgu...@redhat.c

Re: fs, net: deadlock between bind/splice on af_unix

On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote: > On Thu, Jan 26, 2017 at 10:41 PM, Mateusz Guzik wrote: > > On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote: > >> On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik wrote: > >> > Currently the f

Re: timerfd: use-after-free in timerfd_remove_cancel

On Mon, Jan 30, 2017 at 07:41:59PM +0100, Dmitry Vyukov wrote: > Hello, > > The following program triggers use-after-free in timerfd_remove_cancel: > https://gist.githubusercontent.com/dvyukov/202576d437c84ffbbe52e9ccd77e1b44/raw/5562bff8626a73627157331ea2b837f59080ac84/gistfile1.txt > > BUG:

Re: timerfd: use-after-free in timerfd_remove_cancel

On Mon, Jan 30, 2017 at 07:41:59PM +0100, Dmitry Vyukov wrote: > Hello, > > The following program triggers use-after-free in timerfd_remove_cancel: > https://gist.githubusercontent.com/dvyukov/202576d437c84ffbbe52e9ccd77e1b44/raw/5562bff8626a73627157331ea2b837f59080ac84/gistfile1.txt > > BUG:

Re: fs, net: deadlock between bind/splice on af_unix

On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote: > On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik <mgu...@redhat.com> wrote: > > On Tue, Jan 17, 2017 at 01:21:48PM -0800, Cong Wang wrote: > >> On Mon, Jan 16, 2017 at 1:32 AM, Dmitry Vyukov <dvyu...@google.com&g

Re: fs, net: deadlock between bind/splice on af_unix

On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote: > On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik wrote: > > On Tue, Jan 17, 2017 at 01:21:48PM -0800, Cong Wang wrote: > >> On Mon, Jan 16, 2017 at 1:32 AM, Dmitry Vyukov wrote: > >> > On Fri, Dec 9, 2

Re: fs, net: deadlock between bind/splice on af_unix

On Tue, Jan 17, 2017 at 01:21:48PM -0800, Cong Wang wrote: > On Mon, Jan 16, 2017 at 1:32 AM, Dmitry Vyukov wrote: > > On Fri, Dec 9, 2016 at 7:41 AM, Al Viro wrote: > >> On Thu, Dec 08, 2016 at 10:32:00PM -0800, Cong Wang wrote: > >> > >>> > Why do

Re: fs, net: deadlock between bind/splice on af_unix

On Tue, Jan 17, 2017 at 01:21:48PM -0800, Cong Wang wrote: > On Mon, Jan 16, 2017 at 1:32 AM, Dmitry Vyukov wrote: > > On Fri, Dec 9, 2016 at 7:41 AM, Al Viro wrote: > >> On Thu, Dec 08, 2016 at 10:32:00PM -0800, Cong Wang wrote: > >> > >>> > Why do we do autobind there, anyway, and why is it

Re: [PATCH] fs/block_dev.c: return the right error in thaw_bdev()

introduce nesting limit for freezes (say 2048 or whatever, just to have something) The ioctl used use freeze_bdev but this was changed with 18e9e5104fcd "Introduce freeze_super and thaw_super for the fsfreeze ioctl" which cites btrfs as the reason for freeze_super as opposed to freeze_bdev. CC'ing the author for comments. -- Mateusz Guzik

Re: [PATCH] fs/block_dev.c: return the right error in thaw_bdev()

introduce nesting limit for freezes (say 2048 or whatever, just to have something) The ioctl used use freeze_bdev but this was changed with 18e9e5104fcd "Introduce freeze_super and thaw_super for the fsfreeze ioctl" which cites btrfs as the reason for freeze_super as opposed to freeze_bdev. CC'ing the author for comments. -- Mateusz Guzik

Re: [PATCH] fs/block_dev.c: always return error in thaw_bdev()

> out: > mutex_unlock(>bd_fsfreeze_mutex); > - return 0; > + return error; > } > EXPORT_SYMBOL(thaw_bdev); > Apparently this never got in. The bug is still there, reproducible with mere: echo j > /proc/sysrq-trigger -- Mateusz Guzik

Re: [PATCH] fs/block_dev.c: always return error in thaw_bdev()

; > } > EXPORT_SYMBOL(thaw_bdev); > Apparently this never got in. The bug is still there, reproducible with mere: echo j > /proc/sysrq-trigger -- Mateusz Guzik

Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware

this code. Perhaps it will be perfectly fine performance wise to just drop out of RCU lookup in this case. -- Mateusz Guzik

Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware

this code. Perhaps it will be perfectly fine performance wise to just drop out of RCU lookup in this case. -- Mateusz Guzik

Re: fs: GPF in bd_mount

a7f0e146f of linux-next. > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html I think this is fixed with: commit e9e5e3fae8da7e237049e00e0bfc9e32fd808fe8 Author: Vegard Nossum <vegard.nos...@oracle.com> Date: Mon Aug 22 12:47:43 2016 +0200 bdev: fix NULL pointer dereference in mainline. The commit is absent in linux-next. -- Mateusz Guzik

Re: fs: GPF in bd_mount

f linux-next. > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html I think this is fixed with: commit e9e5e3fae8da7e237049e00e0bfc9e32fd808fe8 Author: Vegard Nossum Date: Mon Aug 22 12:47:43 2016 +0200 bdev: fix NULL pointer dereference in mainline. The commit is absent in linux-next. -- Mateusz Guzik

Re: [PACTH v4 1/3] mm, proc: Implement /proc//totmaps

string then, like in case of smaps. > > > > Thanks for the testing Jacek! > > I had a look around the corresponding smaps code, but I'm not seeing any > checks, do you know where that check actually is made? > See m_start in f/sproc/task_mmu.c. It not only check for non-null mm, but also tries to bump ->mm_users and only then proceeds to walk the mm. -- Mateusz Guzik

Re: [PACTH v4 1/3] mm, proc: Implement /proc//totmaps

string then, like in case of smaps. > > > > Thanks for the testing Jacek! > > I had a look around the corresponding smaps code, but I'm not seeing any > checks, do you know where that check actually is made? > See m_start in f/sproc/task_mmu.c. It not only check for non-null mm, but also tries to bump ->mm_users and only then proceeds to walk the mm. -- Mateusz Guzik

Re: [PATCHv2 0/2] introduce get_task_exe_file and use it to fix audit_exe_compare

On Tue, Aug 30, 2016 at 02:50:21PM -0400, Richard Guy Briggs wrote: > On 2016-08-23 16:20, Mateusz Guzik wrote: > > audit_exe_compare directly accesses mm->exe_file without making sure the > > object is stable. Fixing it using current primitives results in > > pa

Re: [PATCHv2 0/2] introduce get_task_exe_file and use it to fix audit_exe_compare

On Tue, Aug 30, 2016 at 02:50:21PM -0400, Richard Guy Briggs wrote: > On 2016-08-23 16:20, Mateusz Guzik wrote: > > audit_exe_compare directly accesses mm->exe_file without making sure the > > object is stable. Fixing it using current primitives results in > > pa

Re: [PATCHv2 1/2] mm: introduce get_task_exe_file

On Tue, Aug 23, 2016 at 04:48:13PM +0200, Oleg Nesterov wrote: > On 08/23, Mateusz Guzik wrote: > > > > +struct file *get_task_exe_file(struct task_struct *task) > > +{ > > + struct file *exe_file = NULL; > > + struct mm_struct *mm; > > + > &g

Re: [PATCHv2 1/2] mm: introduce get_task_exe_file

On Tue, Aug 23, 2016 at 04:48:13PM +0200, Oleg Nesterov wrote: > On 08/23, Mateusz Guzik wrote: > > > > +struct file *get_task_exe_file(struct task_struct *task) > > +{ > > + struct file *exe_file = NULL; > > + struct mm_struct *mm; > > + > &g

[PATCHv2 0/2] introduce get_task_exe_file and use it to fix audit_exe_compare

v1: * removed an unused 'out' label which crept in Mateusz Guzik (2): mm: introduce get_task_exe_file audit: fix exe_file access in audit_exe_compare fs/proc/base.c | 7 +-- include/linux/mm.h | 1 + kernel/audit_watch.c | 8 +--- kernel/fork.c|

[PATCHv2 0/2] introduce get_task_exe_file and use it to fix audit_exe_compare

v1: * removed an unused 'out' label which crept in Mateusz Guzik (2): mm: introduce get_task_exe_file audit: fix exe_file access in audit_exe_compare fs/proc/base.c | 7 +-- include/linux/mm.h | 1 + kernel/audit_watch.c | 8 +--- kernel/fork.c|

[PATCHv2 1/2] mm: introduce get_task_exe_file

For more convenient access if one has a pointer to the task. As a minor nit take advantage of the fact that only task lock + rcu are needed to safely grab ->exe_file. This saves mm refcount dance. Use the helper in proc_exe_link. Signed-off-by: Mateusz Guzik <mgu...@redhat.com&

[PATCHv2 1/2] mm: introduce get_task_exe_file

For more convenient access if one has a pointer to the task. As a minor nit take advantage of the fact that only task lock + rcu are needed to safely grab ->exe_file. This saves mm refcount dance. Use the helper in proc_exe_link. Signed-off-by: Mateusz Guzik Acked-by: Konstantin Khlebni

[PATCHv2 2/2] audit: fix exe_file access in audit_exe_compare

Prior to the change the function would blindly deference mm, exe_file and exe_file->f_inode, each of which could have been NULL or freed. Use get_task_exe_file to safely obtain stable exe_file. Signed-off-by: Mateusz Guzik <mgu...@redhat.com> Acked-by: Konstantin Khlebnikov <khleb

[PATCHv2 2/2] audit: fix exe_file access in audit_exe_compare

Prior to the change the function would blindly deference mm, exe_file and exe_file->f_inode, each of which could have been NULL or freed. Use get_task_exe_file to safely obtain stable exe_file. Signed-off-by: Mateusz Guzik Acked-by: Konstantin Khlebnikov --- kernel/audit_watch.c

[PATCH 2/2] audit: fix exe_file access in audit_exe_compare

Prior to the change the function would blindly deference mm, exe_file and exe_file->f_inode, each of which could have been NULL or freed. Use get_task_exe_file to safely obtain stable exe_file. Signed-off-by: Mateusz Guzik <mgu...@redhat.com> --- kernel/audit_watch.c | 8 +--

[PATCH 2/2] audit: fix exe_file access in audit_exe_compare

Prior to the change the function would blindly deference mm, exe_file and exe_file->f_inode, each of which could have been NULL or freed. Use get_task_exe_file to safely obtain stable exe_file. Signed-off-by: Mateusz Guzik --- kernel/audit_watch.c | 8 +--- 1 file changed, 5 inserti

[PATCH 0/2] introduce get_task_exe_file and use it to fix audit_exe_compare

audit_exe_compare directly accesses mm->exe_file without making sure the object is stable. Fixing it using current primitives results in partially duplicating what proc_exe_link is doing. As such, introduce a trivial helper which can be used in both places and fix the func. Mateusz Guzik

[PATCH 1/2] mm: introduce get_task_exe_file

For more convenient access if one has a pointer to the task. As a minor nit take advantage of the fact that only task lock + rcu are needed to safely grab ->exe_file. This saves mm refcount dance. Use the helper in proc_exe_link. Signed-off-by: Mateusz Guzik <mgu...@redhat.com> ---

[PATCH 0/2] introduce get_task_exe_file and use it to fix audit_exe_compare

audit_exe_compare directly accesses mm->exe_file without making sure the object is stable. Fixing it using current primitives results in partially duplicating what proc_exe_link is doing. As such, introduce a trivial helper which can be used in both places and fix the func. Mateusz Guzik

[PATCH 1/2] mm: introduce get_task_exe_file

For more convenient access if one has a pointer to the task. As a minor nit take advantage of the fact that only task lock + rcu are needed to safely grab ->exe_file. This saves mm refcount dance. Use the helper in proc_exe_link. Signed-off-by: Mateusz Guzik --- fs/proc/base.c |

Re: [PATCH] audit: fix audit_exe_compare using get_mm_exe_file

get_task_exe_file. task_lock held guarantees the stability of mm struct itself, and then we can we can try to grab the file without mm refcount dance. I'll implement this later today. -- Mateusz Guzik

Re: [PATCH] audit: fix audit_exe_compare using get_mm_exe_file

;s_dev; > - rcu_read_unlock(); > + fput(exe_file); > return audit_mark_compare(mark, ino, dev); > } I think this works but I have a better idea. This basically duplicates a part of proc_exe_link and does unnecessary work. Instead, one can introduce get_task_exe_file. task_lo

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

> > mm = get_task_mm(priv->task) is needed to iterate through all of the > mappings. Is there a preferable way of doing that? In the other part of the mail I stated smaps goes to proc_maps_open which has: priv->mm = proc_mem_open(inode, PTRACE_MODE_READ); This gives you stable access to mm and all needed permission checks. Then, in the read routine you can just: if (!atomic_inc_not_zero(>mm_users)) goto thats_it; See smaps routines or e.g. environ_read. -- Mateusz Guzik

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

> > mm = get_task_mm(priv->task) is needed to iterate through all of the > mappings. Is there a preferable way of doing that? In the other part of the mail I stated smaps goes to proc_maps_open which has: priv->mm = proc_mem_open(inode, PTRACE_MODE_READ); This gives you stable access to mm and all needed permission checks. Then, in the read routine you can just: if (!atomic_inc_not_zero(>mm_users)) goto thats_it; See smaps routines or e.g. environ_read. -- Mateusz Guzik

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

from there. > + if (!priv->task) { > + kfree(priv->mss); > + kfree(priv); > + return -ESRCH; > + } > + > + ret = single_open(file, totmaps_proc_show, priv); > + if (ret) { > + put_task_struct(priv->task); > + kfree(priv->mss); > + kfree(priv); > + } > + } > + return ret; > +} > + -- Mateusz Guzik

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

kfree(priv->mss); > + kfree(priv); > + return -ESRCH; > + } > + > + ret = single_open(file, totmaps_proc_show, priv); > + if (ret) { > + put_task_struct(priv->task); > + kfree(priv->mss); > + kfree(priv); > + } > + } > + return ret; > +} > + -- Mateusz Guzik

Re: Is reading from /proc/self/smaps thread-safe?

ranslates into kilobytes of memory which would have to allocated just to hold it, sounds like a non-starter to me. -- Mateusz Guzik

Re: Is reading from /proc/self/smaps thread-safe?

ranslates into kilobytes of memory which would have to allocated just to hold it, sounds like a non-starter to me. -- Mateusz Guzik

Re: [PATCH] prctl: remove one-shot limitation for changing exe link

ges. Modifying get_mm_exe_file to retry is trivial and in effect never return NULL is trivial. With arbitrary number of changes allowed this may require some cond_resched() or something. For comments I cc'ed Richard Guy Briggs, who is both an audit person and the author of audit_exe_compare. -- Mateusz Guzik

Re: [PATCH] prctl: remove one-shot limitation for changing exe link

ges. Modifying get_mm_exe_file to retry is trivial and in effect never return NULL is trivial. With arbitrary number of changes allowed this may require some cond_resched() or something. For comments I cc'ed Richard Guy Briggs, who is both an audit person and the author of audit_exe_compare. -- Mateusz Guzik

Re: [PATCH v2 3/3] Write dump into container's filesystem for pipe_type core_pattern

oot of processes outside of said container? The spawned process should be subject to all limitations imposed on the container (which may mean it just must be in the container). -- Mateusz Guzik

Re: [PATCH v2 3/3] Write dump into container's filesystem for pipe_type core_pattern

oot of processes outside of said container? The spawned process should be subject to all limitations imposed on the container (which may mean it just must be in the container). -- Mateusz Guzik

[PATCH] locking/barriers: evaluate the argument to lockless_dereference only once

The commit 25841ee0e9d2a ("Validate lockless_dereference() is used on a pointer type") added a second use of the parameter to the macro. This leads to trouble with consumers which use arguments with side effects. Instead, reuse the value which was read the first time. Signed-off-b

[PATCH] locking/barriers: evaluate the argument to lockless_dereference only once

The commit 25841ee0e9d2a ("Validate lockless_dereference() is used on a pointer type") added a second use of the parameter to the macro. This leads to trouble with consumers which use arguments with side effects. Instead, reuse the value which was read the first time. Signed-off-b

Re: [tip:locking/core] locking/barriers: Validate lockless_dereference() is used on a pointer type

ne lockless_dereference(p) \ ({ \ - __maybe_unused const void * const _p2 = p; \ typeof(p) _____p1 = READ_ONCE(p); \ + __maybe_unused const void * const _p2 = _p1; \ smp_read_barrier_depends(); /* Dependency order vs. p above. */ \ (_p1); \ }) -- Mateusz Guzik

Re: [tip:locking/core] locking/barriers: Validate lockless_dereference() is used on a pointer type

\ ({ \ - __maybe_unused const void * const _p2 = p; \ typeof(p) _p1 = READ_ONCE(p); \ + __maybe_unused const void * const _p2 = _p1; \ smp_read_barrier_depends(); /* Dependency order vs. p above. */ \ (_p1); \ }) -- Mateusz Guzik

[PATCH] coredump: fix dumping through pipes

uce ->pos field for this purpose since ->written was already reused. Fixes: a00839395103 ("get rid of coredump_params->written"). Reported-by: Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> Signed-off-by: Mateusz Guzik <mgu...@redhat.com> Reviewed-by: Omar San

[PATCH] coredump: fix dumping through pipes

uce ->pos field for this purpose since ->written was already reused. Fixes: a00839395103 ("get rid of coredump_params->written"). Reported-by: Zbigniew Jędrzejewski-Szmek Signed-off-by: Mateusz Guzik Reviewed-by: Omar Sandoval --- arch/powerpc/platforms/cell/spufs/coredu

[PATCH] coredump: fix dumping through pipes

tore explicit tracking of the offset in coredump_params. Introduce ->pos field for this purpose since ->written was already reused. Reported-by: Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> Signed-off-by: Mateusz Guzik <mgu...@redhat.com> --- arch/powerpc/platforms/cell/

[PATCH] coredump: fix dumping through pipes

tore explicit tracking of the offset in coredump_params. Introduce ->pos field for this purpose since ->written was already reused. Reported-by: Zbigniew Jędrzejewski-Szmek Signed-off-by: Mateusz Guzik --- arch/powerpc/platforms/cell/spufs/coredump.c | 2 +- fs/binfmt_elf.c

[tip:x86/asm] x86/arch_prctl/64: Restore accidentally removed put_cpu() in ARCH_SET_GS

Commit-ID: 4afd0565552c87f23834db9121dd9cf6955d0b43 Gitweb: http://git.kernel.org/tip/4afd0565552c87f23834db9121dd9cf6955d0b43 Author: Mateusz Guzik <mgu...@redhat.com> AuthorDate: Tue, 10 May 2016 22:56:43 +0200 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 13

[tip:x86/asm] x86/arch_prctl/64: Restore accidentally removed put_cpu() in ARCH_SET_GS

Commit-ID: 4afd0565552c87f23834db9121dd9cf6955d0b43 Gitweb: http://git.kernel.org/tip/4afd0565552c87f23834db9121dd9cf6955d0b43 Author: Mateusz Guzik AuthorDate: Tue, 10 May 2016 22:56:43 +0200 Committer: Ingo Molnar CommitDate: Fri, 13 May 2016 13:50:15 +0200 x86/arch_prctl/64

Re: [PATCH] x86/arch_prctl/64: restore accidentally removed put_cpu in ARCH_SET_GS

On Tue, May 10, 2016 at 01:58:24PM -0700, Andy Lutomirski wrote: > On Tue, May 10, 2016 at 1:56 PM, Mateusz Guzik <mgu...@redhat.com> wrote: > > This fixes 731e33e39a5b95ad770 "Remove FSBASE/GSBASE < 4G optimization" > > Indeed. How did that survive lockdep

Re: [PATCH] x86/arch_prctl/64: restore accidentally removed put_cpu in ARCH_SET_GS

On Tue, May 10, 2016 at 01:58:24PM -0700, Andy Lutomirski wrote: > On Tue, May 10, 2016 at 1:56 PM, Mateusz Guzik wrote: > > This fixes 731e33e39a5b95ad770 "Remove FSBASE/GSBASE < 4G optimization" > > Indeed. How did that survive lockdep? > lockdep_sy

[PATCH] x86/arch_prctl/64: restore accidentally removed put_cpu in ARCH_SET_GS

This fixes 731e33e39a5b95ad770 "Remove FSBASE/GSBASE < 4G optimization" Signed-off-by: Mateusz Guzik <mgu...@redhat.com> --- arch/x86/kernel/process_64.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 4285

[PATCH] x86/arch_prctl/64: restore accidentally removed put_cpu in ARCH_SET_GS

This fixes 731e33e39a5b95ad770 "Remove FSBASE/GSBASE < 4G optimization" Signed-off-by: Mateusz Guzik --- arch/x86/kernel/process_64.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 4285f6a..6b16c36 100644 -

[PATCH] rlimit: locking tidy ups

d: - do_prlimit: stop taking tasklist_lock at all and only lock sighand when necessary - proc_pid_limits: lock group leader in order to obtain a stable copy Signed-off-by: Mateusz Guzik <mgu...@redhat.com> --- fs/proc/base.c | 6 ++ kernel/s

[PATCH] rlimit: locking tidy ups

d: - do_prlimit: stop taking tasklist_lock at all and only lock sighand when necessary - proc_pid_limits: lock group leader in order to obtain a stable copy Signed-off-by: Mateusz Guzik --- fs/proc/base.c | 6 ++ kernel/sys.c | 22 ++

Re: linux-next: Tree for May 2 [WARNING: at fs/dcache.c]

0x0800 /* being looked up (with parent locked shared) */ Verified with switching one to 0x1000 and the warning went away. -- Mateusz Guzik

Re: linux-next: Tree for May 2 [WARNING: at fs/dcache.c]

0x0800 /* being looked up (with parent locked shared) */ Verified with switching one to 0x1000 and the warning went away. -- Mateusz Guzik

Re: [PATCH] proc: prevent accessing /proc//environ until it's ready

!mm->env_end) > return 0; > > page = (char *)__get_free_page(GFP_TEMPORARY); In this case get_cmdline in mm/util.c should also be patched for completness. It tests for arg_end, but later accesses env_end. -- Mateusz Guzik

Re: [PATCH] proc: prevent accessing /proc//environ until it's ready

!mm->env_end) > return 0; > > page = (char *)__get_free_page(GFP_TEMPORARY); In this case get_cmdline in mm/util.c should also be patched for completness. It tests for arg_end, but later accesses env_end. -- Mateusz Guzik

Re: [PATCH] fs: reintroduce freezing nesting

ers; >   >   char s_id[32]; /* Informational > name */ >   u8 s_uuid[16]; /* UUID */ > --  > 2.8.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Mateusz Guzik

Re: [PATCH] fs: reintroduce freezing nesting

ers; >   >   char s_id[32]; /* Informational > name */ >   u8 s_uuid[16]; /* UUID */ > --  > 2.8.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Mateusz Guzik

Re: [PATCH] fs: add the FIGETFROZEN ioctl call

feature you are looking for would count how many times the fs is frozen. -- Mateusz Guzik

Re: [PATCH] fs: add the FIGETFROZEN ioctl call

feature you are looking for would count how many times the fs is frozen. -- Mateusz Guzik

Re: [PATCH] Make core_pattern support namespace

On Wed, Feb 17, 2016 at 02:15:24PM -0600, Eric W. Biederman wrote: > Mateusz Guzik <mgu...@redhat.com> writes: > > On Tue, Feb 16, 2016 at 07:33:39PM +0800, Zhao Lei wrote: > >> For container based on namespace design, it is good to allow > >> each container k

Re: [PATCH] Make core_pattern support namespace

On Wed, Feb 17, 2016 at 02:15:24PM -0600, Eric W. Biederman wrote: > Mateusz Guzik writes: > > On Tue, Feb 16, 2016 at 07:33:39PM +0800, Zhao Lei wrote: > >> For container based on namespace design, it is good to allow > >> each container keeping their own core

Re: [PATCH] Make core_pattern support namespace

have a buffer on the stack. Finally, the code setting it could simply xchg the pointer to avoid locks if there is no good lock to be taken here, and then kfree_rcu the old buffer. Just my $0,03. -- Mateusz Guzik

Re: [PATCH] Make core_pattern support namespace

have a buffer on the stack. Finally, the code setting it could simply xchg the pointer to avoid locks if there is no good lock to be taken here, and then kfree_rcu the old buffer. Just my $0,03. -- Mateusz Guzik

[PATCH] xattr handlers: plug a lock leak in simple_xattr_list

The code could leak xattrs->lock on error. Problem introduced with 786534b92f3ce68f4 "tmpfs: listxattr should include POSIX ACL xattrs". Signed-off-by: Mateusz Guzik --- fs/xattr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/xattr.c b/fs/xattr.c

Re: [PATCH 1/3] mm: migrate: do not touch page->mem_cgroup of live pages

_pmd_anonymous_page+0x13e/0x540 [ 106.660497] [] handle_mm_fault+0x7e4/0x980 [ 106.672585] [] ? handle_mm_fault+0x59/0x980 [ 106.684595] [] __do_page_fault+0x1cd/0x470 [ 106.696524] [] trace_do_page_fault+0x6e/0x250 [ 106.708477] [] do_async_page_fault+0x1a/0xb0 [ 106.720407] [] async_page_fault+0x28/0x30 -- Mateusz Guzik

  1   2   3   4   >