Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp560080ybx; Wed, 30 Oct 2019 00:59:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqw5VLt4DKG3ofJd2kmuIoj/QZCxMIoLOWL7UzVaWM/BXFkUSZDHBe1XF44ZfIpw+zw98a6/ X-Received: by 2002:a50:890c:: with SMTP id e12mr30862414ede.277.1572422399810; Wed, 30 Oct 2019 00:59:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572422399; cv=none; d=google.com; s=arc-20160816; b=jgcaFjfY3yVVxSCVu9rk4B1Z1qkJVQJACBekZwOEs4cPIfYwjuvDN+dqBPPC2DMa9Z Pd3FmznwOOxp+FtVM4FhRXf7r/gKe7X6QeABc8Zs/AsYWkzrrBGS8fmy6Gnm7XQMkbp5 GawpVSxH13fftOAjEZwTp9p6h/8f+8ASTUY97vU14ful5sEydK9mhdv70rwrGbqpx1XG S6pUDPrCcUAgsqDP3hKG5EjSPjalF9PESERoh5Jmy5ulWosq2tM+XUxbhzqa4mZJvOSJ HJcJ2xClRv1OeKAI0t/pbIK7K6l5iIXtDDpvxaWiWRcjejDqn3OdkiJs0CUJN+ZcWtrs W2eA== 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=nfQHDKNTAVERG1ZdvSJ7R5zGYcK9zu7dazP+2nCkLJU=; b=iw/G9VFdCskHPpHSC1k1KsDQD4V4SFEdrILeu8KNBPjDhZ2AKY2f9GXSRVQzfcTaMJ Md5Qcl7uI3OKSR/bQ2m1JK2mxsU8/cZlig2EbiYS0Dnk7qjgOzrHerLfxy6ALqdzexHZ GhHBVKYf+RTNGzcokl/m8hZws19uWhRUGSdQmxDK84aMcigUd+FWIcfYwPjiVrqNfO2R sMzKUsQKk8fG8iGqyM/cBq25cYeVTBjT1SBK/QRWaYthOrmETwUZ8VN6Zei2hj+DsVS8 N1DCF/JZiDfthJ4D8v/WqKXYpnu9lBnn4eBI+5W5e00mMc7JlEw8WJwmj6VhFz3I3mK3 ZEtQ== 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 v16si774684ejx.96.2019.10.30.00.59.36; Wed, 30 Oct 2019 00:59:59 -0700 (PDT) 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 S1726073AbfJ3H5C convert rfc822-to-8bit (ORCPT + 99 others); Wed, 30 Oct 2019 03:57:02 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:2500 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725822AbfJ3H5B (ORCPT ); Wed, 30 Oct 2019 03:57:01 -0400 Received: from DGGEML401-HUB.china.huawei.com (unknown [172.30.72.56]) by Forcepoint Email with ESMTP id 96AD06923E5053B4AAD1; Wed, 30 Oct 2019 15:56:59 +0800 (CST) Received: from DGGEML505-MBS.china.huawei.com ([169.254.11.138]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0439.000; Wed, 30 Oct 2019 15:56:53 +0800 From: "wubo (T)" To: "lduncan@suse.com" , "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" CC: Mingfangsen , "liuzhiqiang (I)" Subject: [PATCH v2] scsi: avoid potential deadloop in iscsi_if_rx func Thread-Topic: [PATCH v2] scsi: avoid potential deadloop in iscsi_if_rx func Thread-Index: AdWO9lESg1/320hTRWyI93hubYXiRQAAM+TA Date: Wed, 30 Oct 2019 07:56:52 +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 From: Bo Wu 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 fails all the time, one deadloop 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 deadloop: 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 deadloop. Signed-off-by: Bo Wu Reviewed-by: Zhiqiang Liu Suggested-by: Lee Duncan --- drivers/scsi/scsi_transport_iscsi.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c index 417b868d8735..85482bcfc727 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) || @@ -3710,6 +3713,16 @@ iscsi_if_rx(struct sk_buff *skb) break; if (ev->type == ISCSI_UEVENT_GET_CHAP && !err) break; + /* + * special case for sending reply failed too many times, + * on error - fall through. + */ + if (--retries < 0) { + printk(KERN_ERR "Send reply failed too many times. " + "Max supported retries %u\n", ISCSI_SEND_MAX_ALLOWED); + break; + } + err = iscsi_if_send_reply(portid, nlh->nlmsg_type, ev, sizeof(*ev)); } while (err < 0 && err != -ECONNREFUSED && err != -ESRCH); -- 1.8.3.1