All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: zhengbin <zhengbin13@huawei.com>,
	bvanassche@acm.org, jejb@linux.ibm.com,
	linux-scsi@vger.kernel.org, yi.zhang@huawei.com,
	yanaijie@huawei.com, Johannes Thumshirn <jthumshirn@suse.de>
Subject: Re: [PATCH v5 00/13] scsi: core: fix uninit-value access of variable sshdr
Date: Fri, 18 Oct 2019 16:05:51 +0200	[thread overview]
Message-ID: <053798e1-a06a-b870-a1bc-ac8561240504@suse.de> (raw)
In-Reply-To: <yq1lftii2yi.fsf@oracle.com>

On 10/18/19 3:43 PM, Martin K. Petersen wrote:
> 
> Hannes,
> 
>> The one thing which I patently don't like is the ambivalence between
>> DRIVER_SENSE and scsi_sense_valid().  What shall we do if only _one_
>> of them is set?  IE what would be the correct way of action if
>> DRIVER_SENSE is not set, but we have a valid sense code?  Or the other
>> way around?
> 
> I agree, it's a mess.
> 
> (Sorry, zhengbin, you opened a can of worms. This is some of our oldest
> and most arcane code in SCSI)
> 
>> But more important, from a quick glance not all drivers set the
>> DRIVER_SENSE bit; so for things like hpsa or smartpqi the sense code is
>> never evaluated after this patchset.
> 
> And yet we appear to have several code paths where sense evaluation is
> contingent on DRIVER_SENSE. So no matter what, behavior might
> change if we enforce consistent semantics. *sigh*
> 
>> I _really_ would prefer to ditch the 'DRIVER_SENSE' bit, and rely on
>> scsi_sense_valid() only.
> 
> I would really like to get rid of DRIVER_* completely. Except for
> DRIVER_SENSE, few are actually in use:
> 
> DRIVER_OK: 	0
> DRIVER_BUSY:	0
> DRIVER_SOFT:	0
> DRIVER_MEDIA:	0
> DRIVER_ERROR:	6

Three less now :-)

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

  reply	other threads:[~2019-10-18 14:05 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18  8:24 [PATCH v5 00/13] scsi: core: fix uninit-value access of variable sshdr zhengbin
2019-10-18  8:24 ` [PATCH v5 01/13] scsi: core: need to check the result of scsi_execute in scsi_report_opcode zhengbin
2019-10-18  8:24 ` [PATCH v5 02/13] scsi: core: need to check the result of scsi_execute in scsi_test_unit_ready zhengbin
2019-10-18  8:24 ` [PATCH v5 03/13] scsi: core: need to check the result of scsi_execute in scsi_report_lun_scan zhengbin
2019-10-18  8:24 ` [PATCH v5 04/13] scsi: sr: need to check the result of scsi_execute in sr_get_events zhengbin
2019-10-18  8:24 ` [PATCH v5 05/13] scsi: sr: need to check the result of scsi_execute in sr_do_ioctl zhengbin
2019-10-18  8:24 ` [PATCH v5 06/13] scsi: scsi_dh_emc: need to check the result of scsi_execute in send_trespass_cmd zhengbin
2019-10-18  8:24 ` [PATCH v5 07/13] scsi: scsi_dh_rdac: need to check the result of scsi_execute in send_mode_select zhengbin
2019-10-18  8:24 ` [PATCH v5 08/13] scsi: scsi_dh_hp_sw: need to check the result of scsi_execute in hp_sw_tur,hp_sw_start_stop zhengbin
2019-10-21  9:08   ` kbuild test robot
2019-10-21  9:08     ` [PATCH v5 08/13] scsi: scsi_dh_hp_sw: need to check the result of scsi_execute in hp_sw_tur, hp_sw_start_stop kbuild test robot
2019-10-18  8:24 ` [PATCH v5 09/13] scsi: scsi_dh_alua: need to check the result of scsi_execute in alua_rtpg,alua_stpg zhengbin
2019-10-18  8:24 ` [PATCH v5 10/13] scsi: scsi_transport_spi: need to check whether sshdr is valid in spi_execute zhengbin
2019-10-18  8:24 ` [PATCH v5 11/13] scsi: cxlflash: need to check whether sshdr is valid in read_cap16 zhengbin
2019-10-18  8:24 ` [PATCH v5 12/13] scsi: ufs: need to check whether sshdr is valid in ufshcd_set_dev_pwr_mode zhengbin
2019-10-18  8:24 ` [PATCH v5 13/13] scsi: ch: need to check whether sshdr is valid in ch_do_scsi zhengbin
2019-10-18  9:41 ` [PATCH v5 00/13] scsi: core: fix uninit-value access of variable sshdr Hannes Reinecke
2019-10-18 13:43   ` Martin K. Petersen
2019-10-18 14:05     ` Hannes Reinecke [this message]
2019-10-18 23:17     ` [RFC] scsi: Avoid sign extension when setting command result bytes, was " Finn Thain
2019-10-21  1:49     ` zhengbin (A)
2019-10-21 13:06       ` Hannes Reinecke
2019-10-22  1:59         ` zhengbin (A)
2019-10-23  6:51           ` zhengbin (A)
2019-10-21  6:57     ` Johannes Thumshirn
2019-10-18 12:33 ` Damien Le Moal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=053798e1-a06a-b870-a1bc-ac8561240504@suse.de \
    --to=hare@suse.de \
    --cc=bvanassche@acm.org \
    --cc=jejb@linux.ibm.com \
    --cc=jthumshirn@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=yanaijie@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=zhengbin13@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.