From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72677CA9EA0 for ; Tue, 22 Oct 2019 06:24:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3EE7F2184C for ; Tue, 22 Oct 2019 06:24:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729056AbfJVGYX (ORCPT ); Tue, 22 Oct 2019 02:24:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:40210 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725788AbfJVGYW (ORCPT ); Tue, 22 Oct 2019 02:24:22 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 00E5AAFE1; Tue, 22 Oct 2019 06:24:20 +0000 (UTC) Subject: Re: [PATCH RFC 00/24] scsi: Revamp result values To: dgilbert@interlog.com, "Martin K. Petersen" Cc: Christoph Hellwig , James Bottomley , Johannes Thumshirn , linux-scsi@vger.kernel.org References: <20191021095322.137969-1-hare@suse.de> <8e07f2ba-cdef-6faa-559d-3beabc173edf@interlog.com> From: Hannes Reinecke Openpgp: preference=signencrypt Autocrypt: addr=hare@suse.de; prefer-encrypt=mutual; keydata= mQINBE6KyREBEACwRN6XKClPtxPiABx5GW+Yr1snfhjzExxkTYaINHsWHlsLg13kiemsS6o7 qrc+XP8FmhcnCOts9e2jxZxtmpB652lxRB9jZE40mcSLvYLM7S6aH0WXKn8bOqpqOGJiY2bc 6qz6rJuqkOx3YNuUgiAxjuoYauEl8dg4bzex3KGkGRuxzRlC8APjHlwmsr+ETxOLBfUoRNuE b4nUtaseMPkNDwM4L9+n9cxpGbdwX0XwKFhlQMbG3rWA3YqQYWj1erKIPpgpfM64hwsdk9zZ QO1krgfULH4poPQFpl2+yVeEMXtsSou915jn/51rBelXeLq+cjuK5+B/JZUXPnNDoxOG3j3V VSZxkxLJ8RO1YamqZZbVP6jhDQ/bLcAI3EfjVbxhw9KWrh8MxTcmyJPn3QMMEp3wpVX9nSOQ tzG72Up/Py67VQe0x8fqmu7R4MmddSbyqgHrab/Nu+ak6g2RRn3QHXAQ7PQUq55BDtj85hd9 W2iBiROhkZ/R+Q14cJkWhzaThN1sZ1zsfBNW0Im8OVn/J8bQUaS0a/NhpXJWv6J1ttkX3S0c QUratRfX4D1viAwNgoS0Joq7xIQD+CfJTax7pPn9rT////hSqJYUoMXkEz5IcO+hptCH1HF3 qz77aA5njEBQrDRlslUBkCZ5P+QvZgJDy0C3xRGdg6ZVXEXJOQARAQABtCpIYW5uZXMgUmVp bmVja2UgKFN1U0UgTGFicykgPGhhcmVAc3VzZS5kZT6JAkEEEwECACsCGwMFCRLMAwAGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheABQJOisquAhkBAAoJEGz4yi9OyKjPOHoQAJLeLvr6JNHx GPcHXaJLHQiinz2QP0/wtsT8+hE26dLzxb7hgxLafj9XlAXOG3FhGd+ySlQ5wSbbjdxNjgsq FIjqQ88/Lk1NfnqG5aUTPmhEF+PzkPogEV7Pm5Q17ap22VK623MPaltEba+ly6/pGOODbKBH ak3gqa7Gro5YCQzNU0QVtMpWyeGF7xQK76DY/atvAtuVPBJHER+RPIF7iv5J3/GFIfdrM+wS BubFVDOibgM7UBnpa7aohZ9RgPkzJpzECsbmbttxYaiv8+EOwark4VjvOne8dRaj50qeyJH6 HLpBXZDJH5ZcYJPMgunghSqghgfuUsd5fHmjFr3hDb5EoqAfgiRMSDom7wLZ9TGtT6viDldv hfWaIOD5UhpNYxfNgH6Y102gtMmN4o2P6g3UbZK1diH13s9DA5vI2mO2krGz2c5BOBmcctE5 iS+JWiCizOqia5Op+B/tUNye/YIXSC4oMR++Fgt30OEafB8twxydMAE3HmY+foawCpGq06yM vAguLzvm7f6wAPesDAO9vxRNC5y7JeN4Kytl561ciTICmBR80Pdgs/Obj2DwM6dvHquQbQrU Op4XtD3eGUW4qgD99DrMXqCcSXX/uay9kOG+fQBfK39jkPKZEuEV2QdpE4Pry36SUGfohSNq xXW+bMc6P+irTT39VWFUJMcSuQINBE6KyREBEACvEJggkGC42huFAqJcOcLqnjK83t4TVwEn JRisbY/VdeZIHTGtcGLqsALDzk+bEAcZapguzfp7cySzvuR6Hyq7hKEjEHAZmI/3IDc9nbdh EgdCiFatah0XZ/p4vp7KAelYqbv8YF/ORLylAdLh9rzLR6yHFqVaR4WL4pl4kEWwFhNSHLxe 55G56/dxBuoj4RrFoX3ynerXfbp4dH2KArPc0NfoamqebuGNfEQmDbtnCGE5zKcR0zvmXsRp qU7+caufueZyLwjTU+y5p34U4PlOO2Q7/bdaPEdXfpgvSpWk1o3H36LvkPV/PGGDCLzaNn04 BdiiiPEHwoIjCXOAcR+4+eqM4TSwVpTn6SNgbHLjAhCwCDyggK+3qEGJph+WNtNU7uFfscSP k4jqlxc8P+hn9IqaMWaeX9nBEaiKffR7OKjMdtFFnBRSXiW/kOKuuRdeDjL5gWJjY+IpdafP KhjvUFtfSwGdrDUh3SvB5knSixE3qbxbhbNxmqDVzyzMwunFANujyyVizS31DnWC6tKzANkC k15CyeFC6sFFu+WpRxvC6fzQTLI5CRGAB6FAxz8Hu5rpNNZHsbYs9Vfr/BJuSUfRI/12eOCL IvxRPpmMOlcI4WDW3EDkzqNAXn5Onx/b0rFGFpM4GmSPriEJdBb4M4pSD6fN6Y/Jrng/Bdwk SQARAQABiQIlBBgBAgAPBQJOiskRAhsMBQkSzAMAAAoJEGz4yi9OyKjPgEwQAIP/gy/Xqc1q OpzfFScswk3CEoZWSqHxn/fZasa4IzkwhTUmukuIvRew+BzwvrTxhHcz9qQ8hX7iDPTZBcUt ovWPxz+3XfbGqE+q0JunlIsP4N+K/I10nyoGdoFpMFMfDnAiMUiUatHRf9Wsif/nT6oRiPNJ T0EbbeSyIYe+ZOMFfZBVGPqBCbe8YMI+JiZeez8L9JtegxQ6O3EMQ//1eoPJ5mv5lWXLFQfx f4rAcKseM8DE6xs1+1AIsSIG6H+EE3tVm+GdCkBaVAZo2VMVapx9k8RMSlW7vlGEQsHtI0FT c1XNOCGjaP4ITYUiOpfkh+N0nUZVRTxWnJqVPGZ2Nt7xCk7eoJWTSMWmodFlsKSgfblXVfdM 9qoNScM3u0b9iYYuw/ijZ7VtYXFuQdh0XMM/V6zFrLnnhNmg0pnK6hO1LUgZlrxHwLZk5X8F uD/0MCbPmsYUMHPuJd5dSLUFTlejVXIbKTSAMd0tDSP5Ms8Ds84z5eHreiy1ijatqRFWFJRp ZtWlhGRERnDH17PUXDglsOA08HCls0PHx8itYsjYCAyETlxlLApXWdVl9YVwbQpQ+i693t/Y PGu8jotn0++P19d3JwXW8t6TVvBIQ1dRZHx1IxGLMn+CkDJMOmHAUMWTAXX2rf5tUjas8/v2 azzYF4VRJsdl+d0MCaSy8mUh Message-ID: Date: Tue, 22 Oct 2019 08:24:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <8e07f2ba-cdef-6faa-559d-3beabc173edf@interlog.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org On 10/21/19 8:32 PM, Douglas Gilbert wrote: > On 2019-10-21 5:52 a.m., Hannes Reinecke wrote: >> Hi all, >> >> the 'result' field in the SCSI command is defined as having >> 4 fields. The top byte is declared as a 'driver_byte', where the >> driver can signal some internal status back to the midlayer. >> However, there is quite a bit of overlap between the driver_byte >> and the host_byte, resulting in the driver_byte being used in >> very few places, and mostly in legacy drivers. >> Additionally, we have _two_ sets of definitions for the >> last byte (status byte), which can specified either in SAM terms >> or in the linux-specific terms, which are shifted right by one >> from the SAM ones. >> Needless to say, the linux-specific ones are declared obsolete >> for years now. >> And to make the confusion complete, both the status byte and >> the driver byte have a byte for a valid sense code, resulting >> in quite some confusion which of those bits to check. >> >> This patchset does several things: >> - remove the linux-specific status byte definitions, and use >>    the SAM values throughout >> - replace the driver-byte values with either SAM ones (for sense >>    code checking) or host-byte definitions >> - remove the driver-byte definitions > > This is a brave change proposal. The masked_status has been tricked > up so it won't break user code. However the driver byte is exposed > by the sg v2, v3 and v4 interfaces which means via bsg device nodes, > sg devices nodes and many other block storage device nodes (e.g. > /dev/sdc and /dev/st1) via: >       ioctl(, SG_IO, ptr_to_v3_interface) . > > So if there is any user space code out there that checks the > driver byte (e.g. 'sg_io_hdr::driver_status & DRIVER_SENSE') do we > have a problem? > > If so, we could hack the DRIVER_SENSE case *** by putting it back > for the user space to see when the driver (e.g. sg) knows there > is sense data. What about the other values? > >> As usual, comments and reviews are welcome. > > It is hard to make an omelette without breaking some eggs. > > Doug Gilbert > >> Please note, commit 66cf50e65b18 ("scsi: qla2xxx: fixup incorrect >> usage of host_byte") from 5.4/scsi-fixes is a prerequisite for >> this patch series. > > > > *** Here is a snippet from sg3_utils library code: > >     if ((SAM_STAT_CHECK_CONDITION == scsi_status) || >         (SAM_STAT_COMMAND_TERMINATED == scsi_status) || >         (SG_LIB_DRIVER_SENSE == masked_driver_status)) >         return sg_err_category_sense(sense_buffer, sb_len); > > Due to the logical OR, as long as SAM_STAT_CHECK_CONDITION is set > whenever there is sense, then we don't care about DRIVER_SENSE. > > I believe this code comes from the days before auto-sense when say a > READ(6) would fail, send back a CHECK_CONDITION and the host would then > need to issue a REQUEST SENSE command to get the sense data. However > REQUEST SENSE could itself yield a CHECK_CONDITION. Hence DRIVER_SENSE > set, SAM_STAT_CHECK_CONDITION clear could be interpreted as the > initial command failing and the follow-up REQUEST SENSE succeeded; if > they are both set, then both commands failed (e.g. the disk has gone > away). Well, the easier explanation is that not every driver sets DRIVER_SENSE; some do, some don't, relying on CHECK_CONDITION here. Which also means that any code relying on DRIVER_SENSE alone would break even today. So really I don't think this should break anything; but if the consensus is that we need to fake DRIVER_SENSE for userland ABI stability so be it. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 247165 (AG München), GF: Felix Imendörffer