Received: by 2002:a19:771d:0:0:0:0:0 with SMTP id s29csp4506534lfc; Mon, 6 Jun 2022 10:57:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3FGPulBX2rKT+4b4gzejoEMpSKWQ6tW58AdB0tljXW7bTTNYtX5HRBPogOI71ZorAm+OC X-Received: by 2002:a63:9043:0:b0:3fc:7a8d:e744 with SMTP id a64-20020a639043000000b003fc7a8de744mr22307777pge.603.1654538247027; Mon, 06 Jun 2022 10:57:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654538247; cv=none; d=google.com; s=arc-20160816; b=KKYehCdUu6HCxaoJ9L62FI4M4gry0MefmbQt67qg+6hJy1jK0K6VG1byh5+tygeytT FQRAFbqoehCXW3Y4CxanwwVgoZjAHiImKVK/aPSElGMf9hhZ4arSNmK2j3NGv9R81dVE CehmtWp+QZdwOmWWzHq44+j75seM5lu5lar0UU6lGDWB3ygVLX/ZELCthNGOtx/PziOX oW9xr8I89j7BfgGQewFaEv0LhsALpeqY5D8iNFn5+BY3HhJ5WQHU/YbZcTlqK1UX+1iD OZmQ9wW4m2uiKi4GUNRp9l9OeyWmY+dvgx11EeZg5FSoMKHCGdvER84vFH+/17nTUQP4 9acQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=h4C9WpLUh/VIc8qz9wWANgWf77RNe31qiFw7MR8/RHI=; b=Kyss1afV9gZUX22dKXqnS0ZTZbenYZlxdVCtmuhxkxhPgD5qIijryUuGIKKnaUcNP4 GVJdUUkmQ8MAOoU66DukqiZucqXyr1z3kbprU9RySLaCbLWAY3kj5gSRxOY4ng0e0DAD S3d5uZd5KLsDUL6tRkTlqN2zoVTXM+aJBCyMiX4WbgUCAMJ/9LmoHuZ2hNxE2COHbADg lvhZLs/F7eJtCoBzzKVsfMwbxskkeytsgoaDd8kXnHwamXXCgc9O2LV4sBIF52URYMej tAeSnjZQDjvC1RobZhj6mvLqow+5cusRhouLaFDQZum62h4i4lWJiYjL7rMwgbYvABV6 pf8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=apHOPXnR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y198-20020a62cecf000000b004fa3a8e004csi21672996pfg.259.2022.06.06.10.57.11; Mon, 06 Jun 2022 10:57:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=apHOPXnR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229654AbiFFRcJ (ORCPT + 99 others); Mon, 6 Jun 2022 13:32:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229678AbiFFRcF (ORCPT ); Mon, 6 Jun 2022 13:32:05 -0400 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C79B71A45F4 for ; Mon, 6 Jun 2022 10:32:02 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id a30so8163109ybj.3 for ; Mon, 06 Jun 2022 10:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h4C9WpLUh/VIc8qz9wWANgWf77RNe31qiFw7MR8/RHI=; b=apHOPXnRIiSdZ45R4m8vufwr+NeG8y1pzCQXi+GrC852y1Xl9f9LsfqG9me1qaLzoh 8+ABu67BD5sTDqxowSSwbPqKxcasK8w2GAsOqdSP0hLndoa0EtCa2+BwsK2gFolE4pHK MyQA5SJMyqdvkrg6txryVjkZMms3+fW2PzqSTz7GiB2iJhkpr/BfDOR+nBYFU0BI/U35 Kvzf3ek1xq8H44vc7oevhKT4Zc3yt1djSQEpcGAcQljoe/1v37kRRBZRf+k3acRGyM9L YYr+/T8gGjQ1wsfAe7i6SArugJMmB9kO930+XrArPjwuVhqfo33/MTTBi20KocaK+jXW cGHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h4C9WpLUh/VIc8qz9wWANgWf77RNe31qiFw7MR8/RHI=; b=FrWP3VSvMi4YYqceU0/whwpHKIE6bIizRhvS8elS2jsGrh9fPtZjsdsGA95We0m75I QLIqfvIRmzj7o/2Add17shADK3bzTOzQIhdUGBupHxLoqMkQNw/MWoy9L6xCtfQ1RsZy tzNZwYfy7DlLA8O9KqTIQuMu2ry2T7BXkdfRxq0XJSDIsi8mOkWCD155UMLIUFDgQuNt POQlBbFHs0PhyFebrFZqQUjUHDDpYaQMHxvgxy/jYxNEB2uC5RiFqMJDNxozI0RDQbqX reGcFo/o/z5RGvE6vUMZohNBPSpLkjD1IToxF7xj28BAcYpIz/MX67bH72wWwyiO9xcF 1Chg== X-Gm-Message-State: AOAM531+XvYNxYDVfjLXiO/QSFHVLA1DxQgJnSz8KM0aAH+5UCEGKZk3 g0T7rdQrwG1hgGPRNKX3v3eR0Gimepoot3B7V5IGkQ== X-Received: by 2002:a05:6902:c9:b0:641:1998:9764 with SMTP id i9-20020a05690200c900b0064119989764mr25712824ybs.427.1654536721612; Mon, 06 Jun 2022 10:32:01 -0700 (PDT) MIME-Version: 1.0 References: <20220606162138.81505-1-duoming@zju.edu.cn> In-Reply-To: <20220606162138.81505-1-duoming@zju.edu.cn> From: Eric Dumazet Date: Mon, 6 Jun 2022 10:31:49 -0700 Message-ID: Subject: Re: [PATCH net-next] ax25: Fix deadlock caused by skb_recv_datagram in ax25_recvmsg To: Duoming Zhou Cc: LKML , jreuter@yaina.de, Ralf Baechle , David Miller , Jakub Kicinski , Paolo Abeni , netdev , linux-hams@vger.kernel.org, thomas@osterried.de Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 6, 2022 at 9:21 AM Duoming Zhou wrote: > > The skb_recv_datagram() in ax25_recvmsg() will hold lock_sock > and block until it receives a packet from the remote. If the client > doesn`t connect to server and calls read() directly, it will not > receive any packets forever. As a result, the deadlock will happen. > > The fail log caused by deadlock is shown below: > > [ 861.122612] INFO: task ax25_deadlock:148 blocked for more than 737 seconds. > [ 861.124543] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 861.127764] Call Trace: > [ 861.129688] > [ 861.130743] __schedule+0x2f9/0xb20 > [ 861.131526] schedule+0x49/0xb0 > [ 861.131640] __lock_sock+0x92/0x100 > [ 861.131640] ? destroy_sched_domains_rcu+0x20/0x20 > [ 861.131640] lock_sock_nested+0x6e/0x70 > [ 861.131640] ax25_sendmsg+0x46/0x420 > [ 861.134383] ? ax25_recvmsg+0x1e0/0x1e0 > [ 861.135658] sock_sendmsg+0x59/0x60 > [ 861.136791] __sys_sendto+0xe9/0x150 > [ 861.137212] ? __schedule+0x301/0xb20 > [ 861.137710] ? __do_softirq+0x4a2/0x4fd > [ 861.139153] __x64_sys_sendto+0x20/0x30 > [ 861.140330] do_syscall_64+0x3b/0x90 > [ 861.140731] entry_SYSCALL_64_after_hwframe+0x46/0xb0 > [ 861.141249] RIP: 0033:0x7fdf05ee4f64 > [ 861.141249] RSP: 002b:00007ffe95772fc0 EFLAGS: 00000246 ORIG_RAX: 000000000000002c > [ 861.141249] RAX: ffffffffffffffda RBX: 0000565303a013f0 RCX: 00007fdf05ee4f64 > [ 861.141249] RDX: 0000000000000005 RSI: 0000565303a01678 RDI: 0000000000000005 > [ 861.141249] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 > [ 861.141249] R10: 0000000000000000 R11: 0000000000000246 R12: 0000565303a00cf0 > [ 861.141249] R13: 00007ffe957730e0 R14: 0000000000000000 R15: 0000000000000000 > > This patch moves the skb_recv_datagram() before lock_sock() in order > that other functions that need lock_sock could be executed. > Why is this targeting net-next tree ? 1) A fix should target net tree 2) It should include a Fixes: tag Also: - this patch bypasses tests in ax25_recvmsg() - This might break applications depending on blocking read() operations. I feel a real fix is going to be slightly more difficult than that. Thank you > Reported-by: Thomas Habets > Signed-off-by: Duoming Zhou > --- > net/ax25/af_ax25.c | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c > index 95393bb2760..02cd6087512 100644 > --- a/net/ax25/af_ax25.c > +++ b/net/ax25/af_ax25.c > @@ -1665,6 +1665,11 @@ static int ax25_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, > int copied; > int err = 0; > > + /* Now we can treat all alike */ > + skb = skb_recv_datagram(sk, flags, &err); > + if (!skb) > + goto done; > + > lock_sock(sk); > /* > * This works for seqpacket too. The receiver has ordered the > @@ -1675,11 +1680,6 @@ static int ax25_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, > goto out; > } > > - /* Now we can treat all alike */ > - skb = skb_recv_datagram(sk, flags, &err); > - if (skb == NULL) > - goto out; > - > if (!sk_to_ax25(sk)->pidincl) > skb_pull(skb, 1); /* Remove PID */ > > @@ -1725,6 +1725,7 @@ static int ax25_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, > out: > release_sock(sk); > > +done: > return err; > } > > -- > 2.17.1 >