Re: fix stgt crash in conn_close

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>Yep, now I use list_empty to check for list emptiness (it compares
>&c_hlist with c_hlist->head internally). Attaching the patch below.

>Are there any reasons for checking opcode then?

hi  Anton Kovalenko

we check task opcode in iscsi_free_task, if task opcode is
ISCSI_OP_SCSI_CMD, we do list list_del(&task->c_hlist);  because we
suppose iscsi_free_task is a generic interface to release task,thease
task include ISCSI_OP_SCSI_CMD,ISCSI_OP_NOOP_OUT, ISCSI_OP_SCSI_TMFUNC
and so on, but only ISCSI_OP_SCSI_CMD task is added to
adsession->cmd_list,  so, in iscsi_free_task, we check
ISCSI_OP_SCSI_CMD opcode and list_del, This logic is reasonable,

But carefully consider your modify,Logically it is not easy to
understand,only fix current bug(Currently, I'm not sure whether still
potential problems such modifications ),
Iwe carefully consider the logical,why  do below  task->c_hlist.prev
task->c_hlist.prev check in iscsi_free_task
+ if (task->c_hlist.prev && task->c_hlist.next
+    && !list_empty(&task->c_hlist)) {
+ list_del(&task->c_hlist);
+ }
+
Similarly,besides task->c_hlist, task have task->c_siblings, Why not
do below task->c_siblings relate check?
+ if (task->c_siblings.prev && task->c_siblings.next
+    && !list_empty(&task->c_siblings)) {
+ list_del(&task->c_siblings);
+ }
+
Similarly,besides task->c_hlist, task have task->c_list, Why not do
below task->c_list relate check?
+ if (task->c_list.prev && task->c_list.next
+    && !list_empty(&task->c_list)) {
+ list_del(&task->c_list);
+ }
+

Please think about our proposal!thank you

2016-07-26 16:02 GMT+08:00 Anton Kovalenko <anton.kovalenko@xxxxxxxxxxx>:
>
> Hi,
>
> fx chen <chenfx2014@xxxxxxxxx> writes:
>
>> we also consiger you idea,in iscsi_free_task, do task unlinking from
>> session->cmd_list(list_del(&task->c_hlist) ),but we must know,such as
>> ISCSI_OP_NOOP_OUT, ISCSI_OP_SCSI_TMFUNC,  ISCSI_OP_LOGOUT type task,
>> they don‘t add to session->cmd_list,   To solve the problem, we offer
>> patch<v2-0001-iscsi-fix-segfault-at-conn_close>。
>
> When a task is freshly allocated by iscsi_alloc_task, it has an empty
> c_hlist (see INIT_LIST_HEAD in iscsi_alloc_task), that will remain the
> same until iscsi_free_task if the task is never linked to a cmd_list.
>
> Therefore doing nothing with an empty c_hlist is enough (even list_del
> on an empty c_hlist would do no harm). That would skip ISCSI tasks which
> are not SCSI commands, exactly because they never get added to cmd_list.
>
> There are also two cases where c_hlist has prev == next == NULL, one of
> them when a task is allocated directly with iscsi_tcp_alloc_task (it
> happens for NOOP-IN "pings", and such a task should never be
> iscsi_free_task'ed), another one when a task used to be on a cmd_list,
> and then list_del was called (list_del sets prev == next == NULL).
>
> So I believe it's enough to check for NULL pointers and for an empty
> list, doing list_del if neither of these conditions is true.
>
>> in addition:after we carefully consideration: you below patch  still
>> may happen some task unlinking from session->cmd_list, when  there is
>> only one task in session->cmd_list,now task->c_hlist.next and
>> task->c_hlist.prev  is equal, according to you patch logic, this task
>> will not do list_del。
>
> Thank you for the heads up!
>
> Yep, now I use list_empty to check for list emptiness (it compares
> &c_hlist with c_hlist->head internally). Attaching the patch below.
>
> Are there any reasons for checking opcode then?
>
>
>
> --
> Regards, Anton Kovalenko | +7(916)345-34-02 | Elektrostal' MO, Russia
>

Attachment: v2-0001-iscsi-fix-segfault-at-conn_close.patch
Description: Binary data


[Index of Archives]     [Linux SCSI]     [Linux RAID]     [Linux Clusters]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]

  Powered by Linux