[PATCH v2 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly

Andreas Krebbel1 Andreas.Krebbel at de.ibm.com
Sat Oct 29 03:29:38 AEDT 2016


> On 10/28/2016 01:31 PM, Hannes Reinecke wrote:
> > On 10/28/2016 11:53 AM, Steffen Maier wrote:
> >> On 10/13/2016 06:24 PM, Johannes Thumshirn wrote:
> >>> On Thu, Oct 13, 2016 at 05:15:25PM +0200, Steffen Maier wrote:
...
> fc_bsg_request_handler()
>                          req->errors = -ENXIO;
> 
> > 0x7c8e6e <fc_bsg_request_handler+0x86>: mvhi    260(%r12),-6
> 
> crash> struct -od request.errors
> struct request {
>    [260] int errors;
> }
> 
> ********************************************************************
> 
> BUT this seems the first time %r12 is used in fc_bsg_request_handler(),
> especially I seem to miss %r12 being initalized with anything.
> But then again I'm not at all well versed in disassembly.
> Maybe fc_bsg_request_handler() is itself in turn inlined and I would 
> need to start disassembling even earlier to get to %r12 init?
> s390x ELF ABI says %r12:
> usage: Local variable, commonly used as GOT pointer;
> call effect: saved.
> Even if it wasn't initialized and remained NULL below why did it not 
> already page fault at above instruction? Silly me, we did not execute 
> this instruction as it's "if" conditional. This makes me wonder even 
> more where the content of %r12 comes from.
> 
> Ulli, Andreas, could you please shed some light on this?
> 
> ********************************************************************

r12 holds variable req for that access. It is initialized here:

  req = blk_fetch_request(q);    
  if (!req)   
    break;

The asm code ends up down below in the function and loads the return value 
into r12. The code
invoking blk_fetch_request got duplicated and there are three jumps before 
the r12 access to these
locations.

  7c8e48:       ec a8 02 14 00 7c       cgije   %r10,0,7c9270 
<fc_bsg_request_handler+0x488>  <--- x
  7c8e4e:       d5 03 d0 04 a0 28       clc     4(4,%r13),40(%r10)
  7c8e54:       a7 74 02 02             jne     7c9258 
<fc_bsg_request_handler+0x470>         <--- y
  7c8e58:       91 04 a0 48             tm      72(%r10),4
  7c8e5c:       a7 74 01 fe             jne     7c9258 
<fc_bsg_request_handler+0x470>         <--- y
  7c8e60:       a7 f4 01 d5             j       7c920a 
<fc_bsg_request_handler+0x422>
  7c8e64:       d5 03 d0 00 a0 28       clc     0(4,%r13),40(%r10)
  7c8e6a:       a7 84 00 1a             je      7c8e9e 
<fc_bsg_request_handler+0xb6>
  7c8e6e:       e5 4c c1 04 ff fa       mvhi    260(%r12),-6
...

  7c9258:       b9 04 00 29             lgr     %r2,%r9
  7c925c:       c0 e5 ff f7 b3 a6       brasl   %r14,6bf9a8 
<blk_fetch_request>
  7c9262:       b9 04 00 c2             lgr     %r12,%r2
  7c9266:       ec 26 fd ff 00 7c       cgijne  %r2,0,7c8e64 
<fc_bsg_request_handler+0x7c>
  7c926c:       a7 f4 ff cf             j       7c920a 
<fc_bsg_request_handler+0x422>

  7c9270:       b9 04 00 29             lgr     %r2,%r9
  7c9274:       c0 e5 ff f7 b3 9a       brasl   %r14,6bf9a8 
<blk_fetch_request>
  7c927a:       b9 04 00 c2             lgr     %r12,%r2
  7c927e:       ec 26 fe 10 00 7c       cgijne  %r2,0,7c8e9e 
<fc_bsg_request_handler+0xb6>

-Andreas-




More information about the Linuxppc-dev mailing list