From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2732CC2BA19 for ; Thu, 9 Apr 2020 18:51:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DF52120757 for ; Thu, 9 Apr 2020 18:51:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="St1+WyQn" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726521AbgDISvc (ORCPT ); Thu, 9 Apr 2020 14:51:32 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:52348 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725987AbgDISvc (ORCPT ); Thu, 9 Apr 2020 14:51:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=UThGtuKmzrY2tbYaUi/vOzlVPrlMS79aTYBebv6WLZc=; b=St1+WyQneC1T/0LuqZqacoW0LO RusuaoOaleeipF3nWAZcKac+erz+gWX/y7/J0/JqXaHr8H9kn/Pr7NOqGTmsafijXY/EhoysZ+Vte YxmCh55b6WTkMsEK/q03H0HbzAZNzyK60w/uawCA5CUqzHNWNCxbZmqrhJHkxEDVnKiQ7ghfX4BZz uVSgvEi49tQ+ruSkOSzw8j84hFKXn/nMYnUyE+T4vG3vTnsSi7JVwcZsGBEOAtSvKN0Kx1hmCaT2n 09L2hXQewJNLEDAHGxKDcEcEj42pgvEeeVtXTPuxCneOvVQCbZchbCEX0Y2VlotyUnkfizvuvzZgP 6tTEzWhQ==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jMcGy-0002z1-W4; Thu, 09 Apr 2020 18:51:32 +0000 Date: Thu, 9 Apr 2020 11:51:32 -0700 From: Matthew Wilcox To: Olga Kornievskaia Cc: linux-fsdevel Subject: Re: is this hang in a rename syscall is known? Message-ID: <20200409185132.GY21484@bombadil.infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Apr 09, 2020 at 12:44:25PM -0400, Olga Kornievskaia wrote: > Hi folks, > > Getting this hang on a 5.5 kernel, is this a known issue? Thank you. I haven't seen it reported. > Apr 7 13:34:53 scspr1865142002 kernel: Not tainted 5.5.7 #1 > Apr 7 13:34:53 scspr1865142002 kernel: "echo 0 > > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Apr 7 13:34:53 scspr1865142002 kernel: dt D 0 24788 > 24323 0x00000080 > Apr 7 13:34:53 scspr1865142002 kernel: Call Trace: > Apr 7 13:34:53 scspr1865142002 kernel: ? __schedule+0x2ca/0x6e0 > Apr 7 13:34:53 scspr1865142002 kernel: schedule+0x4a/0xb0 > Apr 7 13:34:53 scspr1865142002 kernel: schedule_preempt_disabled+0xa/0x10 > Apr 7 13:34:53 scspr1865142002 kernel: __mutex_lock.isra.11+0x233/0x4e0 > Apr 7 13:34:53 scspr1865142002 kernel: ? strncpy_from_user+0x47/0x160 > Apr 7 13:34:53 scspr1865142002 kernel: lock_rename+0x28/0xd0 This task is doing a cross-directory rename() operation. We only allow one of those in progress per filesystem at any given time (because they're quite rare and rearranging the tree like that plays merry havoc with the locking, which you need to prevent a directory becoming its own ancestor). So the question is, who else is in the middle of a rename operation and has blocked for a long time while holding the s_vfs_rename_mutex? As I recall, you work on NFS, so has something weird been going on with your network?