linux-kernel - Filesystem lockup with CONFIG_PREEMPT

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-next>] [day] [month] [year] [list]

Message-ID: <CANGgnMbHckBQdKGN_N5Q6qEKc9n1CenxvMpeXog1NbSdL8UrTw@mail.gmail.com>
Date:	Tue, 13 May 2014 19:29:12 -0700
From:	Austin Schuh <austin@...oton-tech.com>
To:	linux-kernel@...r.kernel.org
Cc:	xfs <xfs@....sgi.com>
Subject: Filesystem lockup with CONFIG_PREEMPT_RT

Hi,

I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT
patched kernel.  I have currently only triggered it using dpkg.  Dave
Chinner on the XFS mailing list suggested that it was a rt-kernel
workqueue issue as opposed to a XFS problem after looking at the
kernel messages.

$ uname -a
Linux vpc5 3.10.24-rt22abs #15 SMP PREEMPT RT Tue May 13 14:42:22 PDT
2014 x86_64 GNU/Linux

The only modification to the kernel besides the RT patch is that I
have applied tglx's "genirq: Sanitize spurious interrupt detection of
threaded irqs" patch.

Any ideas on what could be wrong?

Is there any information that I can pull before I reboot the machine
that would be useful?  I have the output of triggering sysrq with l
and t if that would be useful.  Attached is the kernel blocked task
message output.

Thanks,
    Austin

Download attachment "vpc5_xfs_lockup_locks" of type "application/octet-stream" (31428 bytes)