[stgt] tgtd CPU 100% problem

[李春]

Sorry for the wrong CC'd lists.
Is CC'd lists correct this email?

When tgtd received the DEVICE_REMOVAL event, we found that the tgtd
cost 100% of one CPU

When we attach to the process with gdb, we found that process run a
infinite loop in usr/iscsi/iser.c:iser_nop_work_handler() to check if
the conn state is STATE_FULL.

it is a infinite loop code in iser_nop_work_handler()：

```
list_for_each_entry(conn, &iser_conn_list, conn_list) {
```

 gdb show that:
```
gdb attach 31629
...
3511                    if (conn->h.state != STATE_FULL)
(gdb) l
3506    {
3507            struct iser_conn *conn;
3508            struct iser_task *task;
3509
3510            list_for_each_entry(conn, &iser_conn_list, conn_list) {
3511                    if (conn->h.state != STATE_FULL)
3512                            continue;
3513                    task = conn->nop_in_task;
3514                    if (!task)
3515                            continue;

(gdb) p iser_conn_list->next
$1 = (struct list_head *) 0x1edc6e0
(gdb) p iser_conn_list->next->next
$2 = (struct list_head *) 0x1edc6e0
(gdb) p iser_conn_list->next->next->next
$3 = (struct list_head *) 0x1edc6e0

```

the iser_conn_list is a endless loop.

2017-07-11 18:41 GMT+08:00 Sagi Grimberg <sagi at grimberg.me>:
>
>> Thanks very much for reply.
>> I think it may be better to  assert failed to exit problem than run
>> the endless loop after receivered DEVICE_REMOVAL event.
>> Or we can sleep 5 ms to check if the conn->h.state is STATE_FULL.
>
>
> Note that neither of the CC'd lists are the correct list
> for stgt, you should correspond stgt at lists.wpkg.org
>
> Regarding your observation, not sure why you think this is
> happening, the work is queued once in 5 seconds and the loop
> is finite.



-- 
pickup.lichun 李春