Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1320381imm; Wed, 23 May 2018 14:07:41 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq9fEP5s1YMf4PN/UYpITuMuFHJ/LlJLhaVqtAkpG90mAs84qGfeJdOuTYqR/TE4Zr5QOza X-Received: by 2002:a63:a807:: with SMTP id o7-v6mr3451676pgf.83.1527109661021; Wed, 23 May 2018 14:07:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527109660; cv=none; d=google.com; s=arc-20160816; b=gFQIzZZStQuQTQ8yQvdaoeV/5nttW2B1NiqU1DVwJfGPWou/+PEqco9VqNPqtjXjNj pHtRL4nUTjPK8HTKSs02v98X5TjOStdcK9arvQ9rxUHqtotxn6/8LdQvsu4NKFa904xn 1GPHhSFXtfqZqKuB5a95COfq7PQJwMfGJDXLP+9sNe1FyTs6sQIHpY5dlCGtHa06J8S9 c60Edr3D561esXybXRZPu2N6SErkfCFp4P0XPiC3hAO51ohHDkVqhnrcMp9x5FqhM1AR rAi94BQTWQkG8zm0hQ0vJ1rwEukIhzdTGhPVgHE7gQOYYa+rSsjKYlimlc+PP8QSDYb/ tbNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:organization:from:subject:cc:to :dkim-signature:arc-authentication-results; bh=5Sf4uYU3Q3PbQ8g8nY+c/nqV4Cf1p1nMwnOt2bjaiho=; b=AuMZMWk3YazQ1my5jkhMtbuZJ4mIaq4KMPT3lJcUggd/0CfnmS3QjMqVbDi1Fhop7t A9kGPfSf/Yga4lI4XLOElPlv6GZRCSNNqC4LTDK91htgu8HL7DcsflTeZm3VZD2bDbHj 4UtclZB1lpmOdDSx0GXn75tIAMIMGMI+apQLnAdlRnQPS4ZVefhmrN7hkvgPwHLJHpi9 ATlm7ktst3vBpL0kZWhxxHT+4pVLwZdZbZs0vypQTPx7CYJQFhoWQoIea0fPljjNG4rZ qcfeQt2bUVPr1I4C71IHh53UvvxIbOIBMGkIPuAtZtHcAJ8P9OQ9kJZWJ1htb8qI/Qfr SZZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=jlmnVF+W; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p67-v6si18780002pfp.72.2018.05.23.14.07.25; Wed, 23 May 2018 14:07:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=jlmnVF+W; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934980AbeEWVHL (ORCPT + 99 others); Wed, 23 May 2018 17:07:11 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:35238 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934930AbeEWVHE (ORCPT ); Wed, 23 May 2018 17:07:04 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4NL19kA105619; Wed, 23 May 2018 21:06:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=to : cc : subject : from : references : date : in-reply-to : message-id : mime-version : content-type; s=corp-2017-10-26; bh=5Sf4uYU3Q3PbQ8g8nY+c/nqV4Cf1p1nMwnOt2bjaiho=; b=jlmnVF+WH58MZxU0mWG0g6JNRQmr6qkE1DfCMSwsECc3mTpUVtkyp367pSwjSZP4m7By YdlGn8+AvdMwwuKM5O6d0BREkdKMvvoSTT2FqQQXdgeY/88pbma+t9ixFIdu60ZzXsvG iWy0BMfdBYjnm/3xCjhmeJtKU3tDD5smJVTNKwUbE6DHlIbaczUXjRpLkvrgoI/nagPb wR8QNV1PhLFi+Z9B7c+UAL0N5BqnEb54kXT3O0ovjAfN11Upg4smtiy8P6NevLiGliyi qedfm+9AACY2Ws421tkw7VW92/x3lCEXOX/VG9lH7dJp23o6lGttIhgx1nwUfJeHXZNG jQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2j4nh7nukd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 May 2018 21:06:09 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w4NL67VC020993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 May 2018 21:06:08 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w4NL650d008727; Wed, 23 May 2018 21:06:06 GMT Received: from ca-mkp.ca.oracle.com (/10.159.214.123) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 May 2018 14:06:05 -0700 To: Kees Cook Cc: Jens Axboe , Christoph Hellwig , "Martin K. Petersen" , James Bottomley , Tejun Heo , Borislav Petkov , "David S. Miller" , "Manoj N. Kumar" , "Matthew R. Ochs" , Uma Krishnan , linux-block , linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, LKML Subject: Re: [PATCH 3/6] block: Create scsi_sense.h for SCSI and ATAPI From: "Martin K. Petersen" Organization: Oracle Corporation References: <20180522183613.GA3784@infradead.org> <732f4249-5681-4a54-ec21-4ecc3d3a74e5@kernel.dk> <20180522191309.GA23615@infradead.org> <8d4af5c4-96fa-54ee-d5c1-b887b1de5a3c@kernel.dk> <9A0BC289-4203-4C77-A012-AAB07F42061F@kernel.dk> <20180523142545.GA16248@infradead.org> <24d36869-e037-042d-cb16-20a81b34eb76@kernel.dk> Date: Wed, 23 May 2018 17:06:02 -0400 In-Reply-To: (Kees Cook's message of "Wed, 23 May 2018 13:52:02 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8902 signatures=668700 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=991 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805230206 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kees, > obj-$(CONFIG_SCSI) += scsi/ > > So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's > scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll > still need to move the code from drivers/scsi/ to block/. Is this > okay? The reason this sucks is that scsi_normalize_sense() is an inherent core feature in the SCSI layer. Dealing with sense data for ioctls is just a fringe use case. I don't want to get too hung up on what goes where. But architecturally it really irks me to move a core piece of SCSI state machine functionality out of the subsystem to accommodate ioctl handling. I'm traveling today so I probably won't get a chance to look closely until tomorrow morning. -- Martin K. Petersen Oracle Linux Engineering