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=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 12198C38A30 for ; Tue, 21 Apr 2020 01:14:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CA260208E4 for ; Tue, 21 Apr 2020 01:14:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZN/8TJ3o" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CA260208E4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7C7888E0012; Mon, 20 Apr 2020 21:14:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74FBE8E0003; Mon, 20 Apr 2020 21:14:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 666418E0012; Mon, 20 Apr 2020 21:14:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 4DFA18E0003 for ; Mon, 20 Apr 2020 21:14:16 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 195BC180ACF62 for ; Tue, 21 Apr 2020 01:14:16 +0000 (UTC) X-FDA: 76730091312.24.glass95_5f700d3065104 X-HE-Tag: glass95_5f700d3065104 X-Filterd-Recvd-Size: 4271 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Tue, 21 Apr 2020 01:14:15 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D29962070B; Tue, 21 Apr 2020 01:14:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587431655; bh=ukUuVHcQBzoAXzBsMpRx5fKzkEj19PpHl2HFA7+fs6A=; h=Date:From:To:Subject:In-Reply-To:From; b=ZN/8TJ3ouk18vGfrQTJpgpXWwGJ7RMAdQWv16ELV2SmIfzRxixc32HNLI0EwdTcFC oK0Y5tnv6Tthpy73BK3eVcMLVPbCL5nylLXcW25km384kgo5g+eAAXg262OUI/IwjW AzGGbuwINYQReyi37WzhkDKb4qK8GwsGRdZ9NwKQ= Date: Mon, 20 Apr 2020 18:14:14 -0700 From: Andrew Morton To: akpm@linux-foundation.org, hughd@google.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, torvalds@linux-foundation.org, yang.shi@linux.alibaba.com Subject: [patch 12/15] shmem: fix possible deadlocks on shmlock_user_lock Message-ID: <20200421011414.R2zEkJGM2%akpm@linux-foundation.org> In-Reply-To: <20200420181310.c18b3c0aa4dc5b3e5ec1be10@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Hugh Dickins Subject: shmem: fix possible deadlocks on shmlock_user_lock Recent commit 71725ed10c40 ("mm: huge tmpfs: try to split_huge_page() when punching hole") has allowed syzkaller to probe deeper, uncovering a long-standing lockdep issue between the irq-unsafe shmlock_user_lock, the irq-safe xa_lock on mapping->i_pages, and shmem inode's info->lock which nests inside xa_lock (or tree_lock) since 4.8's shmem_uncharge(). user_shm_lock(), servicing SysV shmctl(SHM_LOCK), wants shmlock_user_lock while its caller shmem_lock() holds info->lock with interrupts disabled; but hugetlbfs_file_setup() calls user_shm_lock() with interrupts enabled, and might be interrupted by a writeback endio wanting xa_lock on i_pages. This may not risk an actual deadlock, since shmem inodes do not take part in writeback accounting, but there are several easy ways to avoid it. Requiring interrupts disabled for shmlock_user_lock would be easy, but it's a high-level global lock for which that seems inappropriate. Instead, recall that the use of info->lock to guard info->flags in shmem_lock() dates from pre-3.1 days, when races with SHMEM_PAGEIN and SHMEM_TRUNCATE could occur: nowadays it serves no purpose, the only flag added or removed is VM_LOCKED itself, and calls to shmem_lock() an inode are already serialized by the caller. Take info->lock out of the chain and the possibility of deadlock or lockdep warning goes away. Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2004161707410.16322@eggly.anvils Reported-by: syzbot+c8a8197c8852f566b9d9@syzkaller.appspotmail.com Link: https://lore.kernel.org/lkml/000000000000e5838c05a3152f53@google.com/ Reported-by: syzbot+40b71e145e73f78f81ad@syzkaller.appspotmail.com Link: https://lore.kernel.org/lkml/0000000000003712b305a331d3b1@google.com/ Fixes: 4595ef88d136 ("shmem: make shmem_inode_info::lock irq-safe") Signed-off-by: Hugh Dickins Cc: Yang Shi Acked-by: Yang Shi Signed-off-by: Andrew Morton --- mm/shmem.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/mm/shmem.c~shmem-fix-possible-deadlocks-on-shmlock_user_lock +++ a/mm/shmem.c @@ -2179,7 +2179,11 @@ int shmem_lock(struct file *file, int lo struct shmem_inode_info *info = SHMEM_I(inode); int retval = -ENOMEM; - spin_lock_irq(&info->lock); + /* + * What serializes the accesses to info->flags? + * ipc_lock_object() when called from shmctl_do_lock(), + * no serialization needed when called from shm_destroy(). + */ if (lock && !(info->flags & VM_LOCKED)) { if (!user_shm_lock(inode->i_size, user)) goto out_nomem; @@ -2194,7 +2198,6 @@ int shmem_lock(struct file *file, int lo retval = 0; out_nomem: - spin_unlock_irq(&info->lock); return retval; } _