> 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-
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
