On Fri, May 31, 2019 at 3:35 PM Oleg Nesterov wrote:
> On 05/31, Jann Horn wrote:
> >
> > So I guess I should make a v2 that still adds the smp_rmb() in
> > __ptrace_may_access(), but gets rid of the smp_wmb() in
> > commit_creds()? (With a comment above the rcu_assign_pointer() that
> > explains
On Thu, May 30, 2019 at 3:42 AM Eric W. Biederman wrote:
> Jann Horn writes:
>
> > I'm actually trying to get rid of the ->mm access in
> > __ptrace_may_access() entirely by moving the dumpability and the
> > user_ns into the signal_struct, but I don't have patches for that
> > ready (yet).
>
> D
On 05/31, Jann Horn wrote:
>
> So I guess I should make a v2 that still adds the smp_rmb() in
> __ptrace_may_access(), but gets rid of the smp_wmb() in
> commit_creds()? (With a comment above the rcu_assign_pointer() that
> explains the ordering?)
I am fine either way, whatever you like more.
If
On Thu, May 30, 2019 at 2:35 PM Oleg Nesterov wrote:
> On 05/29, Jann Horn wrote:
> > --- a/kernel/cred.c
> > +++ b/kernel/cred.c
> > @@ -450,6 +450,15 @@ int commit_creds(struct cred *new)
> > if (task->mm)
> > set_dumpable(task->mm, suid_dumpable);
> >
On 05/31, Peter Zijlstra wrote:
>
> On Thu, May 30, 2019 at 02:05:31PM +0200, Oleg Nesterov wrote:
> > > Anyway, looking at it, I think smp_acquire__after_ctrl_dep() doesn't
> > > make sense here;
> >
> > Well I still _think_ it should work, it provides the LOAD-LOAD ordering
> > and this is what w
On Thu, May 30, 2019 at 02:05:31PM +0200, Oleg Nesterov wrote:
> > Anyway, looking at it, I think smp_acquire__after_ctrl_dep() doesn't
> > make sense here;
>
> Well I still _think_ it should work, it provides the LOAD-LOAD ordering
> and this is what we need.
So it hard relies on being part of a
On Thu, May 30, 2019 at 12:34:05PM +0200, Andrea Parri wrote:
> On Wed, May 29, 2019 at 07:38:46PM +0200, Jann Horn wrote:
> > On Wed, May 29, 2019 at 6:21 PM Oleg Nesterov wrote:
> > > (I am wondering if smp_acquire__after_ctrl_dep() could be used instead,
> > > just to
> > > make this code lo
On 05/29, Jann Horn wrote:
>
> --- a/kernel/cred.c
> +++ b/kernel/cred.c
> @@ -450,6 +450,15 @@ int commit_creds(struct cred *new)
> if (task->mm)
> set_dumpable(task->mm, suid_dumpable);
> task->pdeath_signal = 0;
> + /*
> +
On 05/29, Jann Horn wrote:
>
> > (I am wondering if smp_acquire__after_ctrl_dep() could be used instead,
> > just to
> > make this code look more confusing)
>
> Uuh, I had no idea that that barrier type exists. The helper isn't
> even explicitly mentioned in Documentation/memory-barriers.rst. I
>
On Wed, May 29, 2019 at 07:38:46PM +0200, Jann Horn wrote:
> On Wed, May 29, 2019 at 6:21 PM Oleg Nesterov wrote:
> > On 05/29, Jann Horn wrote:
> > > (I have no clue whatsoever what the relevant tree for this is, but I
> > > guess Oleg is the relevant maintainer?)
> >
> > we usually route ptrace
Jann Horn writes:
> I'm actually trying to get rid of the ->mm access in
> __ptrace_may_access() entirely by moving the dumpability and the
> user_ns into the signal_struct, but I don't have patches for that
> ready (yet).
Do you have a plan for dealing with old linux-threads style threads
where
On Wed, May 29, 2019 at 6:21 PM Oleg Nesterov wrote:
> On 05/29, Jann Horn wrote:
> > --- a/kernel/ptrace.c
> > +++ b/kernel/ptrace.c
> > @@ -324,6 +324,16 @@ static int __ptrace_may_access(struct task_struct
> > *task, unsigned int mode)
[...]
> > mm = task->mm;
>
> while at it, could you
On Wed, May 29, 2019 at 01:31:57PM +0200, Jann Horn wrote:
> Restore the read memory barrier in __ptrace_may_access() that was deleted
> a couple years ago. Also add comments on this barrier and the one it pairs
> with to explain why they're there (as far as I understand).
>
> Fixes: bfedb589252c
On Wed, May 29, 2019 at 6:21 PM Oleg Nesterov wrote:
> On 05/29, Jann Horn wrote:
> > (I have no clue whatsoever what the relevant tree for this is, but I
> > guess Oleg is the relevant maintainer?)
>
> we usually route ptrace changes via -mm tree, plus I lost my account on korg.
>
> > --- a/kerne
On 05/29, Jann Horn wrote:
>
> (I have no clue whatsoever what the relevant tree for this is, but I
> guess Oleg is the relevant maintainer?)
we usually route ptrace changes via -mm tree, plus I lost my account on korg.
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -324,6 +324,16 @@ static
On Wed, May 29, 2019 at 5:59 PM Eric W. Biederman wrote:
> Jann Horn writes:
>
> > Restore the read memory barrier in __ptrace_may_access() that was deleted
> > a couple years ago. Also add comments on this barrier and the one it pairs
> > with to explain why they're there (as far as I understand
Jann Horn writes:
> Restore the read memory barrier in __ptrace_may_access() that was deleted
> a couple years ago. Also add comments on this barrier and the one it pairs
> with to explain why they're there (as far as I understand).
My bad.
When I made that change I could not figure out what th
17 matches
Mail list logo
