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
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
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 2019/10/18 10:40, Martin K. Petersen wrote:
> zhengbin,
>
>> We can init sshdr in sr_get_events, but there have many callers of
>> scsi_execute, scsi_execute_req, we have to troubleshoot all callers,
>> the simpler way is init sshdr in __scsi_execute.
> There aren't that many callers. I'd pref
On 2019/10/17 10:45, Bart Van Assche wrote:
> On 2019-10-11 20:25, zhengbin wrote:
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index 5447738..d5e29c5 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -255,6 +255,13 @@ int __scsi_execute(struct
On 2019/10/17 8:05, Finn Thain wrote:
> On Sat, 12 Oct 2019, zhengbin wrote:
>
>> kmsan report a warning in 5.1-rc4:
>>
>> BUG: KMSAN: uninit-value in sr_get_events drivers/scsi/sr.c:207 [inline]
>> BUG: KMSAN: uninit-value in sr_check_events+0x2cf/0x1090
>> drivers/scsi/sr.c:243
>> CPU: 1 PID:
On 2019/10/12 10:06, James Bottomley wrote:
> On Sat, 2019-10-12 at 10:03 +0800, zhengbin (A) wrote:
>> On 2019/10/12 9:58, James Bottomley wrote:
>>> On Sat, 2019-10-12 at 09:26 +0800, zhengbin wrote:
>>>> BTW: we can't just init sshdr->response_code,
On 2019/10/12 9:58, James Bottomley wrote:
> On Sat, 2019-10-12 at 09:26 +0800, zhengbin wrote:
>> BTW: we can't just init sshdr->response_code, sr_do_ioctl use
>> sshdr->sense_key
> That's an actual bug, isn't it?
If we init sshdr in __scsi_execute, this will be ok
>
> James
>
>
> .
>
On 2019/10/11 1:03, Bart Van Assche wrote:
> On 10/10/19 5:05 AM, zhengbin wrote:
>> kmsan report a warning in 5.1-rc4:
>>
>> BUG: KMSAN: uninit-value in sr_get_events drivers/scsi/sr.c:207 [inline]
>> BUG: KMSAN: uninit-value in sr_check_events+0x2cf/0x1090
>> drivers/scsi/sr.c:243
>> CPU: 1 PI
ping
On 2019/8/20 13:43, zhengbin wrote:
> In fcoe_if_init, if fc_attach_transport(&fcoe_vport_fc_functions)
> fails, need to free the previously memory and return fail,
> otherwise will trigger null-ptr-deref Read in fc_release_transport.
>
> fcoe_exit
> fcoe_if_exit
> fc_release_transport(
On 2019/8/19 12:08, Ming Lei wrote:
> On Mon, Aug 19, 2019 at 10:39:05AM +0800, zhengbin wrote:
>> KASAN reports a use-after-free in 4.19-stable,
>> which won't happen after commit 47cdee29ef9d
>> ("block: move blk_exit_queue into __blk_release_queue").
>> However, backport this patch to 4.19-sta
On 2019/8/17 1:09, Bart Van Assche wrote:
> On 8/12/19 8:35 PM, zhengbin wrote:
>> KASAN reports a use-after-free in 4.19-stable,
>> which won't happen after commit 47cdee29ef9d
>> ("block: move blk_exit_queue into __blk_release_queue").
>
> This patch doesn't apply on top of kernel v4.19.67:
>
> $
On 2019/8/15 23:40, Bart Van Assche wrote:
> On 8/14/19 6:50 PM, zhengbin (A) wrote:
>> ping
>
> Sending a "ping" after 46 hours is way too soon and only causes irritation.
> What would help though is more information about how this patch has been
> tested. Does i
ping
On 2019/3/26 21:29, zhengbin (A) wrote:
> On 2019/3/25 19:55, zhengbin (A) wrote:
>> On 2019/3/25 18:02, Pavel Tikhomirov wrote:
>>> Likely we should do the same for host_eh_scheduled++ as we do for
>>> host_failed++ in scsi_eh_inc_host_failed. Just put it
ping
On 2019/3/22 11:01, Ming Lei wrote:
> On Fri, Mar 22, 2019 at 10:56:46AM +0800, zhengbin wrote:
>> When I use dd test a SCSI device which use blk-mq in the following steps:
>> 1.echo "blocked" >/sys/block/sda/device/state
>> 2.dd if=/dev/sda of=/mnt/t.log bs=1M count=10
>> 3.echo "running" >/
On 2019/3/25 19:55, zhengbin (A) wrote:
> On 2019/3/25 18:02, Pavel Tikhomirov wrote:
>> Likely we should do the same for host_eh_scheduled++ as we do for
>> host_failed++ in scsi_eh_inc_host_failed. Just put it in call_rcu. These
>> way rcu_read_lock would be enough: if
On 2019/3/25 20:20, John Garry wrote:
> On 25/03/2019 11:55, zhengbin (A) wrote:
>> On 2019/3/25 18:02, Pavel Tikhomirov wrote:
>>> Likely we should do the same for host_eh_scheduled++ as we do for
>>> host_failed++ in scsi_eh_inc_host_failed. Just put it in call_rcu.
On 2019/3/25 18:02, Pavel Tikhomirov wrote:
> Likely we should do the same for host_eh_scheduled++ as we do for
> host_failed++ in scsi_eh_inc_host_failed. Just put it in call_rcu. These
> way rcu_read_lock would be enough: if we don't see RECOVERY state in
> scsi_dec_host_busy, that means that
Hi,
When I use fio test kernel in the following steps:
1.The sas controller mixes SAS/SATA disks
2.Use fio test all disks
3.Simultaneous enable/disable/link_reset/hard_reset PHY
it will hung in ata_port_wait_eh
Call trace:
__switch_to+0xb4/0x1b8
__schedule+0x1e8/0x718
schedule+0x38/0x90
ata_p
So blk_mq_run_hw_queues should still be in mutex_lock(&sdev->state_mutex)??
On 2019/3/22 10:11, Ming Lei wrote:
> On Fri, Mar 22, 2019 at 09:45:54AM +0800, zhengbin wrote:
>> When I use dd test a SCSI device which use blk-mq in the following steps:
>> 1.echo "blocked" >/sys/block/sda/device/state
20 matches
Mail list logo
