On Mon, Dec 7, 2020 at 1:10 AM Peter Zijlstra wrote:
>
> > PeterZ, is there something I'm missing?
>
> Like this?
>
>
> https://lkml.kernel.org/r/20200828123720.gz1362...@hirez.programming.kicks-ass.net
Yes, except I think you should remove the old ptrace_may_access() check.
Because
On Sat, Dec 05, 2020 at 12:05:32PM -0600, Eric W. Biederman wrote:
> I am trying to understand why the permission check is there.
It's about observability, is task A allowed to observe state of task B?
By installing a perf event on another task, we can very accurately tell
what it's doing, and
On Fri, Dec 04, 2020 at 12:48:18PM -0800, Linus Torvalds wrote:
> On Fri, Dec 4, 2020 at 12:30 PM Bernd Edlinger
> wrote:
> >>
> > >perf_event_open (exec_update_mutex -> ovl_i_mutex)
>
> Side note: this one looks like it should be easy to fix.
> PeterZ, is there something I'm missing?
Davidlohr Bueso writes:
> On Fri, 04 Dec 2020, Linus Torvalds wrote:
>
>>On Fri, Dec 4, 2020 at 12:30 PM Bernd Edlinger
>> wrote:
>>> >perf_event_open (exec_update_mutex -> ovl_i_mutex)
>>
>>Side note: this one looks like it should be easy to fix.
>>
>>Is there any real reason why
Linus Torvalds writes:
> On Fri, Dec 4, 2020 at 11:35 AM Eric W. Biederman
> wrote:
>>
>> From a deadlock perspective the change is strictly better than what we
>> have today. The readers will no longer block on each other.
>
> No, agreed, it's better regardless.
>
>> For the specific case
On Fri, 04 Dec 2020, Linus Torvalds wrote:
On Fri, Dec 4, 2020 at 12:30 PM Bernd Edlinger
wrote:
>perf_event_open (exec_update_mutex -> ovl_i_mutex)
Side note: this one looks like it should be easy to fix.
Is there any real reason why exec_update_mutex is actually gotten that
early,
On Fri, Dec 4, 2020 at 12:30 PM Bernd Edlinger
wrote:
>>
> >perf_event_open (exec_update_mutex -> ovl_i_mutex)
Side note: this one looks like it should be easy to fix.
Is there any real reason why exec_update_mutex is actually gotten that
early, and held for that long in the perf event
On 12/4/20 9:10 PM, Linus Torvalds wrote:
> On Fri, Dec 4, 2020 at 11:35 AM Eric W. Biederman
> wrote:
>>
>> From a deadlock perspective the change is strictly better than what we
>> have today. The readers will no longer block on each other.
>
> No, agreed, it's better regardless.
>
>> For
On Fri, Dec 4, 2020 at 11:35 AM Eric W. Biederman wrote:
>
> From a deadlock perspective the change is strictly better than what we
> have today. The readers will no longer block on each other.
No, agreed, it's better regardless.
> For the specific case that syzbot reported it is readers who
Linus Torvalds writes:
> On Fri, Dec 4, 2020 at 8:08 AM Bernd Edlinger
> wrote:
>>
>> >
>> > -static void kcmp_unlock(struct mutex *m1, struct mutex *m2)
>> > +static void kcmp_unlock(struct rw_semaphore *l1, struct rw_semaphore *l2)
>> > {
>> > - if (likely(m2 != m1))
>> > -
Bernd Edlinger writes:
> Hi Eric,
>
> I think I remembered from a previous discussion about this topic,
> that it was unclear if the rw_semaphores are working the same
> in RT-Linux. Will this fix work in RT as well?
The locks should work close enough to the same that correct code is also
On Fri, Dec 4, 2020 at 8:08 AM Bernd Edlinger wrote:
>
> >
> > -static void kcmp_unlock(struct mutex *m1, struct mutex *m2)
> > +static void kcmp_unlock(struct rw_semaphore *l1, struct rw_semaphore *l2)
> > {
> > - if (likely(m2 != m1))
> > - mutex_unlock(m2);
> > -
Hi Eric,
I think I remembered from a previous discussion about this topic,
that it was unclear if the rw_semaphores are working the same
in RT-Linux. Will this fix work in RT as well?
On 12/3/20 9:12 PM, Eric W. Biederman wrote:
> --- a/kernel/kcmp.c
> +++ b/kernel/kcmp.c
> @@ -70,25 +70,25 @@
Recently syzbot reported[0] that there is a deadlock amongst the users
of exec_update_mutex. The problematic lock ordering found by lockdep
was:
perf_event_open (exec_update_mutex -> ovl_i_mutex)
chown(ovl_i_mutex -> sb_writes)
sendfile (sb_writes ->
14 matches
Mail list logo
