All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.g.garry@oracle.com>
To: yangxingui <yangxingui@huawei.com>,
	jejb@linux.ibm.com, martin.petersen@oracle.com,
	damien.lemoal@opensource.wdc.com, linux-ide@vger.kernel.org,
	hare@suse.com, hch@lst.de
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxarm@huawei.com, prime.zeng@hisilicon.com,
	kangfenglong@huawei.com
Subject: Re: [PATCH V2] scsi: libsas: Directly kick-off EH when ATA device fell off
Date: Mon, 19 Dec 2022 14:53:32 +0000	[thread overview]
Message-ID: <9b8da72d-f251-9c1b-0727-28254d7007c3@oracle.com> (raw)
In-Reply-To: <f15c142c-669d-6bc7-f9b9-c05cc3df1542@huawei.com>

On 19/12/2022 12:59, yangxingui wrote:
>> Firstly, I think that there is a bug in sas_ata_device_link_abort() -> 
>> ata_link_abort() code in that the host lock in not grabbed, as the 
>> comment in ata_port_abort() mentions. Having said that, libsas had 
>> already some dodgy host locking usage - specifically dropping the lock 
>> for the queuing path (that's something else to be fixed up ... I think 
>> that is due to queue command CB calling task_done() in some cases), 
>> but I still think that sas_ata_device_link_abort() should be fixed (to 
>> grab the host lock).
> ok, I agree with you very much for this, I had doubts about whether we 
> needed to grab lock before.

ok, I hope that you can fix this up separately.

>>
>> Secondly, this just seems like a half solution to the age-old problem 
>> - that is, EH eventually kicking in only after 30 seconds when a disk 
>> is removed with active IO. I say half solution as SAS disks still have 
>> this issue for libsas. Can we instead push to try to solve both of 
>> them now?
> 
> Jason said you must have such an opinion "a half solution". As libsas 
> does not have any interface to mark all outstanding commands as failed 
> for SAS disk currently and SAS disk support I/O resumable transmission 
> after intermittent disconnections

I don't know what you mean by "resumable transmission after intermittent 
disconnections".

> , so I want to optimize sata disk first.
> If we want to achieve a complete solution, perhaps we need to define 
> such an interface in libsas and implement it by lldd. My current idea is 
> to call sas_abort_task() for all outstanding commands in lldd. I wonder 
> if you approve of this?

Are you sure you mean sas_abort_task()? That is for the LLDD to issue an 
abort TMF. I assume that you mean sas_task_abort(). If so, I am not too 
keen on the idea of libsas calling into the LLDD to inform of such an 
event. Note that maybe a tagset iter function could be used by libsas to 
abort each active IO, but I don't like libsas messing with such a thing; 
in addition, there may be some conflict between libsas aborting the IO 
and the IO completing with error in the LLDD.

Please note that I need to refresh my memory on this whole EH topic...

Thanks,
John


  reply	other threads:[~2022-12-19 14:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-16 10:03 [PATCH V2] scsi: libsas: Directly kick-off EH when ATA device fell off Xingui Yang
2022-12-19  2:19 ` Jason Yan
2022-12-19  9:23 ` John Garry
2022-12-19 12:59   ` yangxingui
2022-12-19 14:53     ` John Garry [this message]
2022-12-20  2:34       ` yangxingui
2022-12-20  9:49       ` Jason Yan
2022-12-21  9:40         ` John Garry
2022-12-21 10:29           ` Jason Yan
2022-12-21  9:28       ` yangxingui
2022-12-19 15:28   ` Jason Yan
2022-12-19 15:55     ` John Garry
2022-12-19 23:00       ` Damien Le Moal
2022-12-20  8:43         ` John Garry
2022-12-19 22:59     ` Damien Le Moal
2022-12-20  2:39   ` Jason Yan

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=9b8da72d-f251-9c1b-0727-28254d7007c3@oracle.com \
    --to=john.g.garry@oracle.com \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=hare@suse.com \
    --cc=hch@lst.de \
    --cc=jejb@linux.ibm.com \
    --cc=kangfenglong@huawei.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=martin.petersen@oracle.com \
    --cc=prime.zeng@hisilicon.com \
    --cc=yangxingui@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.