Bug 1263189

Summary:	blktrace gets stuck after a trace-file is replaced by a directory of the same name
Product:	Red Hat Enterprise Linux 7	Reporter:	Milos Malik <mmalik>
Component:	blktrace	Assignee:	Eric Sandeen <esandeen>
Status:	CLOSED ERRATA	QA Contact:	Karel Srot <ksrot>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	CC:	esandeen
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	blktrace-1.0.5-8.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-11-04 07:41:11 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Milos Malik 2015-09-15 09:44:37 UTC

Description of problem:

Version-Release number of selected component (if applicable):
blktrace-1.0.5-6.el7
kernel-3.10.0-315.el7

How reproducible:
always

Steps to Reproduce:
# cat /proc/partitions 
major minor  #blocks  name

   8        0  117220824 sda
   8        1     204800 sda1
   8        2     512000 sda2
   8        3  116502528 sda3
 253        0   52428800 dm-0
 253        1   11722752 dm-1
 253        2   52285440 dm-2
# blktrace -d /dev/sda -w 5
=== sda ===
  CPU  0:                    0 events,        0 KiB data
  CPU  1:                    0 events,        0 KiB data
  CPU  2:                    0 events,        0 KiB data
  CPU  3:                    0 events,        0 KiB data
  CPU  4:                    0 events,        0 KiB data
  CPU  5:                    1 events,        1 KiB data
  CPU  6:                    0 events,        0 KiB data
  CPU  7:                    0 events,        0 KiB data
  Total:                     1 events (dropped 0),        1 KiB data
# ls -l *.blktrace.*
-rw-r--r--. 1 root root  0 Sep 15 05:31 sda.blktrace.0
-rw-r--r--. 1 root root  0 Sep 15 05:31 sda.blktrace.1
-rw-r--r--. 1 root root  0 Sep 15 05:31 sda.blktrace.2
-rw-r--r--. 1 root root  0 Sep 15 05:31 sda.blktrace.3
-rw-r--r--. 1 root root  0 Sep 15 05:31 sda.blktrace.4
-rw-r--r--. 1 root root 56 Sep 15 05:31 sda.blktrace.5
-rw-r--r--. 1 root root  0 Sep 15 05:31 sda.blktrace.6
-rw-r--r--. 1 root root  0 Sep 15 05:31 sda.blktrace.7
# rm -f *.blktrace.1
# mkdir sda.blktrace.1
# blktrace -d /dev/sda -w 5
Open output file ./sda.blktrace.1 failed: 21/Is a directory
FAILED to start thread on CPU 1: 1/Operation not permitted

Actual results:
x86_64, s390x - the blktrace process terminates almost immediately
ppc64, ppc64le, aarch64 - the blktrace process gets stuck forever (CTRL+C does not interrupt it)

Expected results:
 * the blktrace process terminates almost immediately on all architectures

Comment 2 Eric Sandeen 2016-05-19 16:39:22 UTC

Fixed up by upstream commit

commit 838361c6cfb1319eadd59daaf9074dcdb92746e6
Author: Robert Schiele <rschiele>
Date:   Mon Sep 8 09:38:52 2014 +0200

    signal condition variable at end of stop_tracers
    
    stop_tracers modifies tp->is_done and thus must signal the condition
    variable tracer_wait_unblock is waiting on to monitor tp->is_done.
    Not doing so might cause the tool to deadlock if stop_tracers is
    called while a tracer thread is in tracer_wait_unblock.
    
    Signed-off-by: Robert Schiele <rschiele>
    Signed-off-by: Jens Axboe <axboe>

It's a one-liner :)

Comment 4 Karel Srot 2016-06-29 07:25:01 UTC

Hi Eric,
I have encountered following behaviour during the testing on non-intel architectures:

1. have the bogus blktrace version installed
2. run the reproducer for this bug (the blktrace would stuck and would have to be killed as reported in #c0)
3. run blktrace command again and it will fail with:

BLKTRACESETUP(2) /dev/vda2 failed: 2/No such file or directory
Thread 0 failed open /sys/kernel/debug/block/(null)/trace0: 2/No such file or directory
Thread 1 failed open /sys/kernel/debug/block/(null)/trace1: 2/No such file or directory
FAILED to start thread on CPU 0: 1/Operation not permitted
FAILED to start thread on CPU 1: 1/Operation not permitted

4. another blktrace command would succeed.

It seems that after killing blktrace there were some remaining "locks" in place that prevented next blktrace to run properly but the same unsuccessful execution had removed these "locks".

I am just curious whether this is something expected.

Comment 5 Eric Sandeen 2016-06-29 14:27:17 UTC

Karel, that's only with the old version, right?

Yes, I think that when it fails, it leaves the kernel in an inconsistent state; then the next run fails due to the inconsistency but cleans up correctly, which makes it all consistent again.

I think I have seen this as well; I would need to dig into it a bit more to get the exact sequence of what happens.

Comment 6 Karel Srot 2016-06-29 14:47:51 UTC

(In reply to Eric Sandeen from comment #5)
> Karel, that's only with the old version, right?

Well, yes and no. As the new version has fixed the bug and doesn't stuck I don't need to kill it. 
OTOH, I could reproduce it artificially even with the new version using

# blktrace -d /dev/vda2 -w 30 &
[1] 1280
# kill -9 1280
# 
[1]+  Killed                  blktrace -d /dev/vda2 -w 30
# 
# blktrace -d /dev/vda2 -w 5 
BLKTRACESETUP(2) /dev/vda2 failed: 2/No such file or directory
Thread 0 failed open /sys/kernel/debug/block/(null)/trace0: 2/No such file or directory
FAILED to start thread on CPU 0: 1/Operation not permitted
# 
# blktrace -d /dev/vda2 -w 5 
=== vda2 ===
  CPU  0:                   32 events,        2 KiB data
  Total:                    32 events (dropped 0),        2 KiB data

Just to clarify, I consider the bug to be successfully fixed. I was just curious what is going on here. Maybe blktrace could be updated to do the "cleanup" on start - that would be clearly a new bug/rfe report and maybe not trivial to implement.

Comment 10 errata-xmlrpc 2016-11-04 07:41:11 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2499.html