Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp9046282ybc; Fri, 29 Nov 2019 23:27:32 -0800 (PST) X-Google-Smtp-Source: APXvYqzkZhumC5tbUGTNsCXTqOqFziontlcoWXla2JN0RebEU4bmH1rk/neOxRSRlRdYeqmoALMd X-Received: by 2002:aa7:c6c5:: with SMTP id b5mr5909061eds.281.1575098852348; Fri, 29 Nov 2019 23:27:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575098852; cv=none; d=google.com; s=arc-20160816; b=WzTLCF4zuacxLu+EslU1uzoQAcwHO8vEtZd+rGEx9kY8wV1UiDWVzaNGBKuzymEXO0 3z09YU3z7URnU2mshWr12/nVDaPInNEvr6Ivo0UaCdmHg0EGvAYUv9h6ZNoNubZPphAc 5zd5oBx0IkQy187HJtDwYdJbPxducXcNb2a/VTL6+UZtaJWQKnkG3HVl/NzyOYoUxDOM A34uau2AabcNnMhzZ2xgNcQou9yeyfEa6z5xKKWGEGEvQtUzjXU2GS57jLqY9sxfqxzp 0LqvAEegxVNKpyOxiQmoHodbFBAvy0Uht90shd2OlnV1zwQhf4YWGO0DpfVgISvEqNCk pyDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=XsS1lYJECmL6MfNMGWbxf5wndB4o57u4gPqU98muVa0=; b=Ii5uWxiiW2uA6vWPy+oKOSJ5f8CFvUEymaKvmyTn04QDJhqlVM2UQv8zPoBOJrKzdm fe6OlpD+kq3ZYiYlIrXrSmf3os0szRyujsMqmFkTqvDbrLSa6H0lOEj9sEP9Rh9FPEoS GNqo3TGAy0qdUHGi+VgiQScV6Q0rpfspOQPoay9TTeurGEkdwAXfjIKvTca1KEUcoESL Kvplgcd85/r5gWpIQFJ+hKQwmLxkpaUDV5Src6rWb7fgS3RRdRV1h6c43iDhc64lCh9U jowaIXyC1fo+/qm9x4WZXsPvdNJHUQjPhyzQuxFyYtw8MaYdr0a6ayOEtDi4CXfTLDSG rBcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ce3si19517360edb.441.2019.11.29.23.27.09; Fri, 29 Nov 2019 23:27:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726008AbfK3HZk convert rfc822-to-8bit (ORCPT + 99 others); Sat, 30 Nov 2019 02:25:40 -0500 Received: from szxga03-in.huawei.com ([45.249.212.189]:2098 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725298AbfK3HZk (ORCPT ); Sat, 30 Nov 2019 02:25:40 -0500 Received: from DGGEML403-HUB.china.huawei.com (unknown [172.30.72.53]) by Forcepoint Email with ESMTP id 69B62B5CE3B3A718B691; Sat, 30 Nov 2019 15:25:38 +0800 (CST) Received: from DGGEML505-MBX.china.huawei.com ([169.254.12.88]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0439.000; Sat, 30 Nov 2019 15:25:27 +0800 From: "wubo (T)" To: Lee Duncan , "cleech@redhat.com" , "jejb@linux.ibm.com" , "martin.petersen@oracle.com" , "open-iscsi@googlegroups.com" , "linux-scsi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Ulrich Windl CC: Mingfangsen , "liuzhiqiang (I)" Subject: RE: [PATCH V4] scsi: avoid potential deadlock in iscsi_if_rx func Thread-Topic: [PATCH V4] scsi: avoid potential deadlock in iscsi_if_rx func Thread-Index: AdWnTxEsStx3PExLTm21jFNMmytp6A== Date: Sat, 30 Nov 2019 07:25:26 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.221.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Friendy ping... > > In iscsi_if_rx func, after receiving one request through iscsi_if_recv_msg func, > iscsi_if_send_reply will be called to try to reply the request in do-loop. > If the return of iscsi_if_send_reply func return -EAGAIN all the time, one > deadlock will occur. > > For example, a client only send msg without calling recvmsg func, then it will > result in the watchdog soft lockup. > The details are given as follows, > > Details of the special case which can cause deadlock: > > sock_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ISCSI); retval = > bind(sock_fd, (struct sock addr*) & src_addr, sizeof(src_addr); while (1) { > state_msg = sendmsg(sock_fd, &msg, 0); > //Note: recvmsg(sock_fd, &msg, 0) is not processed here. > } > close(sock_fd); > > watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [netlink_test:253305] > Sample time: 4000897528 ns(HZ: 250) Sample stat: > curr: user: 675503481560, nice: 321724050, sys: 448689506750, idle: > 4654054240530, iowait: 40885550700, irq: 14161174020, softirq: 8104324140, > st: 0 > deta: user: 0, nice: 0, sys: 3998210100, idle: 0, iowait: 0, irq: 1547170, softirq: > 242870, st: 0 Sample softirq: > TIMER: 992 > SCHED: 8 > Sample irqstat: > irq 2: delta 1003, curr: 3103802, arch_timer > CPU: 7 PID: 253305 Comm: netlink_test Kdump: loaded Tainted: G > OE > Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 > pstate: 40400005 (nZcv daif +PAN -UAO) > pc : __alloc_skb+0x104/0x1b0 > lr : __alloc_skb+0x9c/0x1b0 > sp : ffff000033603a30 > x29: ffff000033603a30 x28: 00000000000002dd > x27: ffff800b34ced810 x26: ffff800ba7569f00 > x25: 00000000ffffffff x24: 0000000000000000 > x23: ffff800f7c43f600 x22: 0000000000480020 > x21: ffff0000091d9000 x20: ffff800b34eff200 > x19: ffff800ba7569f00 x18: 0000000000000000 > x17: 0000000000000000 x16: 0000000000000000 > x15: 0000000000000000 x14: 0001000101000100 > x13: 0000000101010000 x12: 0101000001010100 > x11: 0001010101010001 x10: 00000000000002dd > x9 : ffff000033603d58 x8 : ffff800b34eff400 > x7 : ffff800ba7569200 x6 : ffff800b34eff400 > x5 : 0000000000000000 x4 : 00000000ffffffff > x3 : 0000000000000000 x2 : 0000000000000001 > x1 : ffff800b34eff2c0 x0 : 0000000000000300 Call trace: > __alloc_skb+0x104/0x1b0 > iscsi_if_rx+0x144/0x12bc [scsi_transport_iscsi] > netlink_unicast+0x1e0/0x258 > netlink_sendmsg+0x310/0x378 > sock_sendmsg+0x4c/0x70 > sock_write_iter+0x90/0xf0 > __vfs_write+0x11c/0x190 > vfs_write+0xac/0x1c0 > ksys_write+0x6c/0xd8 > __arm64_sys_write+0x24/0x30 > el0_svc_common+0x78/0x130 > el0_svc_handler+0x38/0x78 > el0_svc+0x8/0xc > > Here, we add one limit of retry times in do-loop to avoid the deadlock. > > V4: > - modify the patch subject, no code change. > > V3: > - replace the error with warning as suggested by Ulrich > > V2: > - add some debug kernel message as suggested by Lee Duncan > > Signed-off-by: Bo Wu > Reviewed-by: Zhiqiang Liu > Reviewed-by: Lee Duncan > --- > drivers/scsi/scsi_transport_iscsi.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/scsi/scsi_transport_iscsi.c > b/drivers/scsi/scsi_transport_iscsi.c > index 417b868d8735..ed8d9709b9b9 100644 > --- a/drivers/scsi/scsi_transport_iscsi.c > +++ b/drivers/scsi/scsi_transport_iscsi.c > @@ -24,6 +24,8 @@ > > #define ISCSI_TRANSPORT_VERSION "2.0-870" > > +#define ISCSI_SEND_MAX_ALLOWED 10 > + > #define CREATE_TRACE_POINTS > #include > > @@ -3682,6 +3684,7 @@ iscsi_if_rx(struct sk_buff *skb) > struct nlmsghdr *nlh; > struct iscsi_uevent *ev; > uint32_t group; > + int retries = ISCSI_SEND_MAX_ALLOWED; > > nlh = nlmsg_hdr(skb); > if (nlh->nlmsg_len < sizeof(*nlh) + sizeof(*ev) || @@ > -3712,6 +3715,10 @@ iscsi_if_rx(struct sk_buff *skb) > break; > err = iscsi_if_send_reply(portid, > nlh->nlmsg_type, > ev, > sizeof(*ev)); > + if (err == -EAGAIN && --retries < 0) { > + printk(KERN_WARNING "Send > reply failed, error %d\n", err); > + break; > + } > } while (err < 0 && err != -ECONNREFUSED && err != > -ESRCH); > skb_pull(skb, rlen); > } > -- > 1.8.3.1