Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966013AbcJ1QaB convert rfc822-to-8bit (ORCPT ); Fri, 28 Oct 2016 12:30:01 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57544 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S965777AbcJ1Q35 (ORCPT ); Fri, 28 Oct 2016 12:29:57 -0400 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: Andreas.Krebbel@de.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org In-Reply-To: <132d8dc4-e8d0-6eba-9ae2-4a7e2c9a589b@linux.vnet.ibm.com> To: Steffen Maier Cc: Anil Gurumurthy , Benjamin Herrenschmidt , Dick Kennedy , "open list:FCOE SUBSYSTEM (libfc, libfcoe, fcoe)" , Hannes Reinecke , Christoph Hellwig , heicars2@linux.vnet.ibm.com, James Smart , "James E.J. Bottomley" , Johannes Thumshirn , Johannes Thumshirn , Linux Kernel Mailinglist , "open list:S390 ZFCP DRIVER" , Linux SCSI Mailinglist , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "Martin K . Petersen" , Michael Ellerman , mschwid2@linux.vnet.ibm.com, Paul Mackerras , "supporter:QLOGIC QLA2XXX FC-SCSI DRIVER" , Richard Biener , Sudarsana Kalluru , Tyrel Datwyler , "Ulrich Weigand" Subject: Re: [PATCH v2 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly From: "Andreas Krebbel1" Date: Fri, 28 Oct 2016 18:29:38 +0200 References: <2ea07f3f-88eb-b795-fa37-a223bf80e581@linux.vnet.ibm.com> <20161013162405.aoxy3bdkc4bqtwsk@linux-x5ow.site> <4b411836-e76f-b67a-3d49-ad3d51b8f216@linux.vnet.ibm.com> <132d8dc4-e8d0-6eba-9ae2-4a7e2c9a589b@linux.vnet.ibm.com> MIME-Version: 1.0 X-KeepSent: 02C91110:A5599383-C125805A:00581A77; type=4; flags=0; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1 October 14, 2013 X-LLNOutbound: False X-Disclaimed: 58487 X-TNEFEvaluated: 1 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="US-ASCII" x-cbid: 16102816-0032-0000-0000-00000233041B X-IBM-ISS-SpamDetectors: Score=0.40962; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.40962; ST=0; TS=0; UL=0; ISC= X-IBM-ISS-DetailInfo: BY=3.00005995; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00773998; UDB=6.00371720; UTC=2016-10-28 16:29:43 x-cbparentid: 16102816-9718-0000-0000-0000018FBF88 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-28_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610280279 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3112 Lines: 80 > 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 : 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 <--- x 7c8e4e: d5 03 d0 04 a0 28 clc 4(4,%r13),40(%r10) 7c8e54: a7 74 02 02 jne 7c9258 <--- y 7c8e58: 91 04 a0 48 tm 72(%r10),4 7c8e5c: a7 74 01 fe jne 7c9258 <--- y 7c8e60: a7 f4 01 d5 j 7c920a 7c8e64: d5 03 d0 00 a0 28 clc 0(4,%r13),40(%r10) 7c8e6a: a7 84 00 1a je 7c8e9e 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 7c9262: b9 04 00 c2 lgr %r12,%r2 7c9266: ec 26 fd ff 00 7c cgijne %r2,0,7c8e64 7c926c: a7 f4 ff cf j 7c920a 7c9270: b9 04 00 29 lgr %r2,%r9 7c9274: c0 e5 ff f7 b3 9a brasl %r14,6bf9a8 7c927a: b9 04 00 c2 lgr %r12,%r2 7c927e: ec 26 fe 10 00 7c cgijne %r2,0,7c8e9e -Andreas-