On 2019/10/22 9:59, zhengbin (A) wrote:
> On 2019/10/21 21:06, Hannes Reinecke wrote:
>> On 10/21/19 3:49 AM, zhengbin (A) wrote:
>>> On 2019/10/18 21:43, Martin K. Petersen wrote:
Hannes,
> The one thing which I patently don't like is the ambivalence between
> DRIVER_SENSE and
On 2019/10/21 21:06, Hannes Reinecke wrote:
> On 10/21/19 3:49 AM, zhengbin (A) wrote:
>> On 2019/10/18 21:43, 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 _o
On 10/21/19 3:49 AM, zhengbin (A) wrote:
>
> On 2019/10/18 21:43, 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 corr
On 18/10/2019 15:43, Martin K. Petersen wrote:
[...]
> Johannes: Whatever happened to your efforts at cleaning all this up? Do
> you have a patch series or a working tree we could use as starting
> point?
I'll have to look. I think it's still floating around in some git tree.
Let me search for it
On 2019/10/18 21:43, 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,
On Fri, 18 Oct 2019, Martin K. Petersen wrote:
>
> (Sorry, zhengbin, you opened a can of worms. This is some of our oldest
> and most arcane code in SCSI)
>
A call to set_host_byte(cmd, x) or set_msg_byte(cmd, x) when x & 0x80 is
set clobbers the most significant bytes in cmd->result.
Avoid t
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
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 ar
On 2019/10/18 17:17, zhengbin wrote:
> v1->v2: modify the comments suggested by Bart
> v2->v3: fix bug in sr_do_ioctl
> v3->v4: let "fix bug in sr_do_ioctl" be a separate patch
> v4->v5: fix uninit-value access bug in callers, not in __scsi_execute
An explanation text of the series would be great.
On 10/18/19 10:24 AM, zhengbin wrote:
> v1->v2: modify the comments suggested by Bart
> v2->v3: fix bug in sr_do_ioctl
> v3->v4: let "fix bug in sr_do_ioctl" be a separate patch
> v4->v5: fix uninit-value access bug in callers, not in __scsi_execute
>
> zhengbin (13):
> scsi: core: need to check
v1->v2: modify the comments suggested by Bart
v2->v3: fix bug in sr_do_ioctl
v3->v4: let "fix bug in sr_do_ioctl" be a separate patch
v4->v5: fix uninit-value access bug in callers, not in __scsi_execute
zhengbin (13):
scsi: core: need to check the result of scsi_execute in
scsi_report_opcod
11 matches
Mail list logo
