lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 24 Apr 2017 00:05:48 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Anatoly Pugachev <matorola@...il.com>
Cc:     Sparc kernel list <sparclinux@...r.kernel.org>,
        linux-ext4@...r.kernel.org
Subject: Re: [sparc64] ext4 TPC and call trace (process blocked/stuck) on git
 kernel 4.8.0-rc3+

On Fri, Apr 21, 2017 at 07:38:50PM +0300, Anatoly Pugachev wrote:
> On Wed, Aug 24, 2016 at 11:13 AM, Anatoly Pugachev <matorola@...il.com> wrote:
> > Hello!
> >
> > Running fstests (xfstests) suite on sparc64 debian sid/unstable with
> > linux kernel 4.8.0-rc3+ , I'm getting the following call trace and TPC
> > on server console and system logs:
> 
> 
> got another hung task (sys)log, but not with xfstests and with some
> debug (kernel locks) output (kernel is 4.10.0-git-something). Can
> someone knowing kernel have a look and maybe spot something. If not,
> thanks anyway and machine still works. Thanks!

When you say that the system still works, I assume that means that
writes to root file system (or what ever file system syslog was trying
to log to, typically /var/log) are still succeeding?

These messages are soft lockup messages, and doesn't necessarily means
that the system was locked up forever:

> Apr 19 19:30:43 landau kernel: INFO: task ostree:107749 blocked for
> more than 120 seconds.

It could just mean that a "sync" command took longer than two minutes
to complete.

> Apr 19 19:30:43 landau kernel:       Tainted: G        W
> 4.10.0-10531-g86292b33d4b7 #77
> Apr 19 19:30:43 landau kernel: "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Apr 19 19:30:43 landau kernel: ostree          D    0 107749  92509
> 0x208000103000000
> Apr 19 19:30:43 landau kernel: Call Trace:
> Apr 19 19:30:43 landau kernel:  [0000000000a8e790] schedule+0x30/0xc0
> Apr 19 19:30:43 landau kernel:  [0000000000681798]
> wb_wait_for_completion+0x58/0xa0
> Apr 19 19:30:43 landau kernel:  [0000000000682048]
> __writeback_inodes_sb_nr+0x88/0xc0
> Apr 19 19:30:43 landau kernel:  [00000000006820e0] writeback_inodes_sb+0x20/0x40
> Apr 19 19:30:43 landau kernel:  [000000000068a5f4] sync_filesystem+0x34/0xc0
> Apr 19 19:30:43 landau kernel:  [000000000068a7f8] SyS_syncfs+0x38/0x80
> Apr 19 19:30:43 landau kernel:  [0000000000406234] linux_sparc_syscall+0x34/0x44


Without any more details about the system, its workload, whether or
not the system really was hung forever, or it was functioning normally
when you discovered it, it's hard to really say much else given the
lack of information in your e-mail.

Also note that this stack trace has nothing to do with the e-mail
thread from last August which you replied to.  At first I thought
there was a connection, which confused me as I tried to look at the
very small amount of information in your bug report.

Cheers,

					- Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ