summaryrefslogtreecommitdiffstats
path: root/README
diff options
context:
space:
mode:
authorEric Farman <farman@linux.ibm.com>2019-02-22 19:39:40 +0100
committerCornelia Huck <cohuck@redhat.com>2019-02-26 18:30:11 +0100
commit48bd0eee8eca0920b6a15c4663e02ea434fe1fdf (patch)
tree92130e49b619791fb7eeb932610c1cb9ca35d5c3 /README
parent36360658eb5a6cf04bb9f2704d1e4ce54037ec99 (diff)
downloadlinux-48bd0eee8eca0920b6a15c4663e02ea434fe1fdf.tar.bz2
s390/cio: Fix vfio-ccw handling of recursive TICs
The routine ccwchain_calc_length() is tasked with looking at a channel program, seeing how many CCWs are chained together by the presence of the Chain-Command flag, and returning a count to the caller. Previously, it also considered a Transfer-in-Channel CCW as being an appropriate mechanism for chaining. The problem at the time was that the TIC CCW will almost certainly not go to the next CCW in memory (because the CC flag would be sufficient), and so advancing to the next 8 bytes will cause us to read potentially invalid memory. So that comparison was removed, and the target of the TIC is processed as a new chain. This is fine when a TIC goes to a new chain (consider a NOP+TIC to a channel program that is being redriven), but there is another scenario where this falls apart. A TIC can be used to "rewind" a channel program, for example to find a particular record on a disk with various orientation CCWs. In this case, we DO want to consider the memory after the TIC since the TIC will be skipped once the requested criteria is met. This is due to the Status Modifier presented by the device, though software doesn't need to operate on it beyond understanding the behavior change of how the channel program is executed. So to handle this, we will re-introduce the check for a TIC CCW but limit it by examining the target of the TIC. If the TIC doesn't go back into the current chain, then current behavior applies; we should stop counting CCWs and let the target of the TIC be handled as a new chain. But, if the TIC DOES go back into the current chain, then we need to keep looking at the memory after the TIC for when the channel breaks out of the TIC loop. We can't use tic_target_chain_exists() because the chain in question hasn't been built yet, so we will redefine that comparison with some small functions to make it more readable and to permit refactoring later. Fixes: 405d566f98ae ("vfio-ccw: Don't assume there are more ccws after a TIC") Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20190222183941.29596-2-farman@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions