On 2019-01-30 18:56:54 [+0100], Thomas Gleixner wrote:
> TBH, no clue. Below are some more traceprintks which hopefully shed some
> light on that mystery. See kernel/futex.c line 30 ...
The robust list it somehow buggy. In the last trace we had the
handle_futex_death() of uaddr 3ff9e880140 as the
On Wed, 30 Jan 2019, Thomas Gleixner wrote:
> On Wed, 30 Jan 2019, Thomas Gleixner wrote:
> The last entries with that uaddr are:
>
> <...>-56956 [005] 658.923608: sys_futex(uaddr: 3ff9e880140,
> op: 7, val: 3ff0007, utime: 3ff9b078910, uaddr2: 3ff9b078910, val3:
> 3ffea67e3
On Wed, 30 Jan 2019, Thomas Gleixner wrote:
> On Wed, 30 Jan 2019, Sebastian Sewior wrote:
>
> > On 2019-01-30 13:59:55 [+0100], Heiko Carstens wrote:
> > > Last lines of trace below (full log attached):
> >
> > <...>-56956 [005] 658.931364: handle_futex_death: uaddr:
> > 3ff9
On Wed, 30 Jan 2019, Sebastian Sewior wrote:
> On 2019-01-30 13:59:55 [+0100], Heiko Carstens wrote:
> > Last lines of trace below (full log attached):
>
> <...>-56956 [005] 658.931364: handle_futex_death: uaddr:
> 3ff9e880c58 pi: 1
> …
> <...>-56956 [005] 6
On Wed, 30 Jan 2019, Heiko Carstens wrote:
> On Wed, Jan 30, 2019 at 01:15:18PM +0100, Thomas Gleixner wrote:
> > On Wed, 30 Jan 2019, Heiko Carstens wrote:
> > > On Tue, Jan 29, 2019 at 06:16:53PM +0100, Sebastian Sewior wrote:
> > > > if (unlikely(p->flags & PF_KTHREAD)) {
> > > >
On 2019-01-30 13:59:55 [+0100], Heiko Carstens wrote:
> Last lines of trace below (full log attached):
<...>-56956 [005] 658.931364: handle_futex_death: uaddr:
3ff9e880c58 pi: 1
…
<...>-56956 [005] 658.931369: handle_futex_death: uaddr:
3ff9e8808c0 success
On Wed, 30 Jan 2019, Heiko Carstens wrote:
> On Tue, Jan 29, 2019 at 06:16:53PM +0100, Sebastian Sewior wrote:
> > if (unlikely(p->flags & PF_KTHREAD)) {
> > put_task_struct(p);
>
> Last lines of the trace with your additional patch (full log attached):
>
><...>-50539
On Tue, 29 Jan 2019, Sebastian Sewior wrote:
> On 2019-01-29 16:10:58 [+0100], Heiko Carstens wrote:
> > Finally... the trace output is quite large with 26 MB... Therefore an
> > xz compressed attachment. Hope that's ok.
> >
> > The kernel used was linux-next 20190129 + your patch.
> |ld6
On 2019-01-29 16:10:58 [+0100], Heiko Carstens wrote:
> Finally... the trace output is quite large with 26 MB... Therefore an
> xz compressed attachment. Hope that's ok.
>
> The kernel used was linux-next 20190129 + your patch.
|ld64.so.1-10237 [006] 14232.031726: sys_futex(uaddr: 3ff
On Tue, Jan 29, 2019 at 02:03:01PM +0100, Thomas Gleixner wrote:
> On Tue, 29 Jan 2019, Peter Zijlstra wrote:
>
> > On Tue, Jan 29, 2019 at 11:24:09AM +0100, Heiko Carstens wrote:
> >
> > > Yes, sure. However ;) I reproduced the above with v5.0-rc4 + your
> > > patch. And now I am trying to repro
On Tue, 29 Jan 2019, Peter Zijlstra wrote:
> On Tue, Jan 29, 2019 at 11:24:09AM +0100, Heiko Carstens wrote:
>
> > Yes, sure. However ;) I reproduced the above with v5.0-rc4 + your
> > patch. And now I am trying to reproduce with linux-next 20190129 +
> > your patch and it doesn't trigger. Did I
On Tue, Jan 29, 2019 at 11:24:09AM +0100, Heiko Carstens wrote:
> Yes, sure. However ;) I reproduced the above with v5.0-rc4 + your
> patch. And now I am trying to reproduce with linux-next 20190129 +
> your patch and it doesn't trigger. Did I miss a patch which is only in
> linux-next which could
On Tue, Jan 29, 2019 at 10:45:44AM +0100, Thomas Gleixner wrote:
> On Tue, 29 Jan 2019, Heiko Carstens wrote:
> > On Mon, Jan 28, 2019 at 04:53:19PM +0100, Thomas Gleixner wrote:
> > > Patch below cures that.
> >
> > With your patch the kernel warning doesn't occur anymore. So if this
> > is suppo
On Tue, 29 Jan 2019, Heiko Carstens wrote:
> On Mon, Jan 28, 2019 at 04:53:19PM +0100, Thomas Gleixner wrote:
> > Patch below cures that.
>
> With your patch the kernel warning doesn't occur anymore. So if this
> is supposed to be the fix feel free to add:
Yes, it's supposed to be the fix.
>
> H
On Tue, Jan 29, 2019 at 10:01:08AM +0100, Heiko Carstens wrote:
> However now I see every now and then the following failure from the
> same test case:
>
> tst-robustpi8: ../nptl/pthread_mutex_lock.c:425: __pthread_mutex_lock_full:
> Assertion `INTERNAL_SYSCALL_ERRNO (e, __err) != ESRCH || !robu
On Mon, Jan 28, 2019 at 04:53:19PM +0100, Thomas Gleixner wrote:
> On Mon, 28 Jan 2019, Peter Zijlstra wrote:
> > On Mon, Jan 28, 2019 at 02:44:10PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 29, 2018 at 12:23:21PM +0100, Heiko Carstens wrote:
> > >
> > > > And indeed, if I run only this test
On Mon, Jan 28, 2019 at 04:53:19PM +0100, Thomas Gleixner wrote:
> Right after staring long enough at it, the commit simply forgot to give
> __rt_mutex_start_proxy_lock() the same treatment as it gave to
> rt_mutex_wait_proxy_lock().
>
> Patch below cures that.
Yes, that is a very nice solution.
On Mon, 28 Jan 2019, Peter Zijlstra wrote:
> On Mon, Jan 28, 2019 at 02:44:10PM +0100, Peter Zijlstra wrote:
> > On Thu, Nov 29, 2018 at 12:23:21PM +0100, Heiko Carstens wrote:
> >
> > > And indeed, if I run only this test case in an endless loop and do
> > > some parallel work (like kernel compil
On Mon, Jan 28, 2019 at 02:44:10PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 12:23:21PM +0100, Heiko Carstens wrote:
>
> > And indeed, if I run only this test case in an endless loop and do
> > some parallel work (like kernel compile) it currently seems to be
> > possible to reproduce
On Thu, Nov 29, 2018 at 12:23:21PM +0100, Heiko Carstens wrote:
> And indeed, if I run only this test case in an endless loop and do
> some parallel work (like kernel compile) it currently seems to be
> possible to reproduce the warning:
>
> while true; do time ./testrun.sh nptl/tst-robustpi8 --d
On Wed, Jan 23, 2019 at 01:33:15PM +0100, Thomas Gleixner wrote:
> Heiko,
>
> On Wed, 23 Jan 2019, Heiko Carstens wrote:
> > It doesn't look like it does. One occurrence was the one below when
> > using commit 7939f8beecf1 (which is post 5.0-rc2) for building the
> > kernel:
> >
> > WARNING: CPU:
Heiko,
On Wed, 23 Jan 2019, Heiko Carstens wrote:
> It doesn't look like it does. One occurrence was the one below when
> using commit 7939f8beecf1 (which is post 5.0-rc2) for building the
> kernel:
>
> WARNING: CPU: 14 PID: 23505 at kernel/futex.c:1483 do_futex+0xa9a/0xc50
> Kernel panic - not
On Tue, Jan 22, 2019 at 10:14:00PM +0100, Thomas Gleixner wrote:
> On Mon, 21 Jan 2019, Thomas Gleixner wrote:
> > On Mon, 21 Jan 2019, Heiko Carstens wrote:
> >
> > > Hi Thomas,
> > >
> > > [full quote below]
> > >
> > > Did you have any time to look into this yet? :)
> > >
> > > The warning i
On Mon, 21 Jan 2019, Thomas Gleixner wrote:
> On Mon, 21 Jan 2019, Heiko Carstens wrote:
>
> > Hi Thomas,
> >
> > [full quote below]
> >
> > Did you have any time to look into this yet? :)
> >
> > The warning is still reproducible.
>
> Yeah, it's on my list of stuff which I need to take care o
On Mon, 21 Jan 2019, Heiko Carstens wrote:
> Hi Thomas,
>
> [full quote below]
>
> Did you have any time to look into this yet? :)
>
> The warning is still reproducible.
Yeah, it's on my list of stuff which I need to take care of urgently. In
the next couple of days I hope...
Thanks,
Hi Thomas,
[full quote below]
Did you have any time to look into this yet? :)
The warning is still reproducible.
On Thu, Nov 29, 2018 at 12:23:21PM +0100, Heiko Carstens wrote:
> On Wed, Nov 28, 2018 at 03:32:45PM +0100, Thomas Gleixner wrote:
> > Heiko,
> >
> > On Tue, 27 Nov 2018, Heiko Cars
On Wed, Nov 28, 2018 at 03:32:45PM +0100, Thomas Gleixner wrote:
> Heiko,
>
> On Tue, 27 Nov 2018, Heiko Carstens wrote:
>
> > with the glibc self-tests I was able to trigger the "this should not
> > happen" warning ;) below on s390 (with panic_on_warn=1 set). It looks
> > like it is hardly repro
Heiko,
On Tue, 27 Nov 2018, Heiko Carstens wrote:
> with the glibc self-tests I was able to trigger the "this should not
> happen" warning ;) below on s390 (with panic_on_warn=1 set). It looks
> like it is hardly reproducible.
Any idea which self-test triggered that?
> This one happened with co
Hello,
with the glibc self-tests I was able to trigger the "this should not
happen" warning ;) below on s390 (with panic_on_warn=1 set). It looks
like it is hardly reproducible.
This one happened with commit d146194f31c9 for compiling the kernel.
Config can be re-created with "make ARCH=s390 perf
29 matches
Mail list logo
