From patchwork Fri Apr 17 00:11:48 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hugh Dickins X-Patchwork-Id: 11493939 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A80621392 for ; Fri, 17 Apr 2020 00:12:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6A95C221F9 for ; Fri, 17 Apr 2020 00:12:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="jV/Am+Kr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A95C221F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6CF728E0003; Thu, 16 Apr 2020 20:12:16 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 681018E0001; Thu, 16 Apr 2020 20:12:16 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 596E08E0003; Thu, 16 Apr 2020 20:12:16 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0061.hostedemail.com [216.40.44.61]) by kanga.kvack.org (Postfix) with ESMTP id 3B2788E0001 for ; Thu, 16 Apr 2020 20:12:16 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D3F6518016BC5 for ; Fri, 17 Apr 2020 00:12:15 +0000 (UTC) X-FDA: 76715419830.12.price14_30d66e08b4413 X-Spam-Summary: 2,0,0,af350298f1e797f9,d41d8cd98f00b204,hughd@google.com,,RULES_HIT:41:355:379:800:960:967:968:973:988:989:1260:1277:1313:1314:1345:1437:1516:1518:1535:1542:1593:1594:1711:1730:1747:1777:1792:2194:2199:2393:2525:2553:2559:2564:2682:2685:2859:2902:2904:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3152:3354:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:5007:6117:6119:6261:6653:7903:8778:9025:10004:10400:11026:11658:11914:12043:12050:12296:12297:12438:12517:12519:12555:12679:12740:12895:12986:13161:13221:13229:13439:14096:14097:14181:14394:14659:14721:21060:21080:21444:21450:21451:21627:21795:21939:21966:21990:30051:30054:30075:30090,0,RBL:209.85.167.193:@google.com:.lbl8.mailshell.net-66.100.201.100 62.18.0.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: price14_30d66e08b4413 X-Filterd-Recvd-Size: 5500 Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Fri, 17 Apr 2020 00:12:15 +0000 (UTC) Received: by mail-oi1-f193.google.com with SMTP id r66so596187oie.5 for ; Thu, 16 Apr 2020 17:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:user-agent:mime-version; bh=weS8ut8MyVdtR/8doQhR0Yj9vQW+AHpAC1tZDODgP9A=; b=jV/Am+Kry4hgFkIjG1xx/9ispjIuh+h4eGTkndY8rZ3lBXukhWlinYgu4EUeJ+cpMl VMhjMhwgHz2rR3TTF5lJpS8iqxsgBLpNn1UK7ukvxSIpgRtZYPAgXaVl58hAjJocch8W GoLWfHBNXdTD1WUrSkOy4ChIc9ZEPreaZkjUEWsyC/a5NljzoMxKY1msUZz1T81ZioTa KAX/DjTLb7dsmXx4e5fIO6IG8AcnQvsw3LGV0EvXoFWmvzexT9qeyeUYCQsYRariLDoU UWl5DkXLfJdBki9IEjJZnfFYmpPchJBfE6afrLtEzBVLv/ijXCVcV3eE42qEJBKCy3KG 2b/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:user-agent :mime-version; bh=weS8ut8MyVdtR/8doQhR0Yj9vQW+AHpAC1tZDODgP9A=; b=XWCtraXz6JznylPFd3FAW3f4Glqkxsznlfqs9htHExraEUeqYGlKZ8TJ7yV/KcSDWC g+ZSrfp15nsPdTfk+CaaJGcsM5nCeCVGkgagZ7DEBLRQqWj+5FqgKGnFlMiR54ymQL69 Sw3Mr2FzhpeW5dKtyVvwybZ9Fe4AqzIRGNUUuyXIJTpRP1OL6DwJ7Jz/1CkLh7tEB1b4 52c1jCZwAE86glU9mbI5pGbEoF5roQ8xX8Id/e5j+vTZ1irEFqb0Qb2oI9GlRy8KhAc0 YuV3dxmzSO4eYzBVT3rdMq2nAezbT3X+AorGKvr9SD4jZPP+5lMDdh62v77SpKf+qsP0 FNPA== X-Gm-Message-State: AGi0PuYzjA5QK+rY11+vw3uErc55jCq5seRQynnV8d+4fB5GJTZjO5h1 H0tthK7qfIuBRZU+tvldhz0Kkw== X-Google-Smtp-Source: APiQypLfi7wlQaXIPxwNmWqq8gtANHdhI+E0cUE6j5KkfiS6tNu4sWaylED/JXY9TIYSTDMABpmCGw== X-Received: by 2002:aca:f4c4:: with SMTP id s187mr496947oih.83.1587082334538; Thu, 16 Apr 2020 17:12:14 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 26sm8241549oot.25.2020.04.16.17.12.13 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 16 Apr 2020 17:12:13 -0700 (PDT) Date: Thu, 16 Apr 2020 17:11:48 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Andrew Morton cc: Yang Shi , Hugh Dickins , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH] shmem: fix possible deadlocks on shmlock_user_lock Message-ID: User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 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: 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. 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 --- mm/shmem.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- 5.7-rc1/mm/shmem.c 2020-04-11 12:58:26.415524805 -0700 +++ linux/mm/shmem.c 2020-04-16 11:04:06.729738730 -0700 @@ -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; }