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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D38EBC38A2D for ; Sat, 22 Oct 2022 00:17:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 442168E0002; Fri, 21 Oct 2022 20:17:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CB018E0001; Fri, 21 Oct 2022 20:17:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 244548E0002; Fri, 21 Oct 2022 20:17:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0E8268E0001 for ; Fri, 21 Oct 2022 20:17:49 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CD13F8082B for ; Sat, 22 Oct 2022 00:17:48 +0000 (UTC) X-FDA: 80046672216.13.1F5CAAF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 585924001B for ; Sat, 22 Oct 2022 00:17:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666397867; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=amHJWELNNBFQ5oGfku8rGjqSoo/TG8P6T1HoY4z+rSA=; b=ShXwyvRFgM20zqZxey5KxO3J3NJwc/IG2ppXRMJCwK0Ffks2xU9Fl0FxROo4UOb4o0arOg RQAe1WCy9O5+iq8iDN41WLkUnGHllV6KWhHw4/MyzUqrn+5bOwi857IvmFAh6QfWtNUObM ZzIhawpFB00u3HS7iK/AjOO/RUqwGgQ= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-578-ZuKph0zYO9W-vJYW47rwxQ-1; Fri, 21 Oct 2022 20:17:46 -0400 X-MC-Unique: ZuKph0zYO9W-vJYW47rwxQ-1 Received: by mail-qk1-f197.google.com with SMTP id de21-20020a05620a371500b006eed31abb72so4676097qkb.6 for ; Fri, 21 Oct 2022 17:17:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=amHJWELNNBFQ5oGfku8rGjqSoo/TG8P6T1HoY4z+rSA=; b=4GsSBOx6fmXaZRdCDylWgXQSmsNMoIR9Ossagx/jhDLLB17n1AhUoIgarB8TJKulhj WZ6+4yZY2qI7i3oobT9yqgWBZw8J8u5DbgaA5PfZDdRB1ykMewlCAktdJboBgXq/fEG5 1vgysveADzrpzHsFHz0hZUEsiO2Sl9H4qDuwdg7fqbSGUgRGwMBbHHsx9tTVQWV1aelm AJxDoLDsxYCFAVfFvP3KvVLay3zDjudSNi5ZvU2BUm8ZmOZTZJlbHf8btcGqhF4sSWec c832QxZha+Vea5NVN3wgPHUiubv2+fYBys0j7ywmXf29xVlrh2EzIbDauZOHwAiSFVEU beOw== X-Gm-Message-State: ACrzQf08J5bY/fYxsj2MueCxLnjpMrrHTdCuGuignpBisQwY73A/FTwW t7rhlOLRmzRbuto4GSw4tkWdjgRcVRPg5ED3NnJvFm54jI6Do7n9GzyFP2mIPDqCL05Fnq09wD8 jIBXQREiKxtQ= X-Received: by 2002:a05:620a:2809:b0:6bc:5e0d:d7b1 with SMTP id f9-20020a05620a280900b006bc5e0dd7b1mr16107995qkp.545.1666397865900; Fri, 21 Oct 2022 17:17:45 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4LAqprsVjIuNi4CfZOqxzbSbnJyVRuhCWZ+JoKJ64ng9n/C/AMy8gQVHgM7ynf0up0xY/mQg== X-Received: by 2002:a05:620a:2809:b0:6bc:5e0d:d7b1 with SMTP id f9-20020a05620a280900b006bc5e0dd7b1mr16107981qkp.545.1666397865638; Fri, 21 Oct 2022 17:17:45 -0700 (PDT) Received: from x1n (bras-base-aurron9127w-grc-46-70-31-27-79.dsl.bell.ca. [70.31.27.79]) by smtp.gmail.com with ESMTPSA id y21-20020a05620a44d500b006eed75805a2sm10874152qkp.126.2022.10.21.17.17.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Oct 2022 17:17:44 -0700 (PDT) Date: Fri, 21 Oct 2022 20:17:43 -0400 From: Peter Xu To: Ira Weiny Cc: Andrew Morton , Matthew Wilcox , kernel test robot , "Fabio M. De Francesco" , lkp@lists.01.org, lkp@intel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrea Arcangeli Subject: Re: [shmem] 7a7256d5f5: WARNING:possible_recursive_locking_detected Message-ID: References: <202210211215.9dc6efb5-yujie.liu@intel.com> <20221021133041.5811e1fb291eb6aaf122a59c@linux-foundation.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ShXwyvRF; spf=pass (imf11.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666397868; a=rsa-sha256; cv=none; b=MO9j7lRpG6sQyBHZhDKByE+NeKMWzP2tOz7445QCk2gcAdVPTvE7KxQayOKiEvrp7iynWI 3kr6SMdjPkIYpCd5pJ0kS08HhhXcgQTbxsPVP7x0QfKPchTpfPmMjm3lv/cGIlVSOLxDiZ xenDEEhVvya6KWnccPvXQZZbz8eq7tc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666397868; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=amHJWELNNBFQ5oGfku8rGjqSoo/TG8P6T1HoY4z+rSA=; b=bXgq5UC0c2C0w0JDpBP5naUFhU1C2UlRuxqTffSQ6DStIj1l+uPH0s2fA3WkDwKHHhlZrL G65LVa3qDxuN28JFlhTxBRC3PMGut7BAYylaim6fYXdHcP7EFYtU8lVizFJu6Qf5zVgwsz lv4tvu4LqHpT8NgKmhBO7eglpgUjyvQ= X-Rspamd-Queue-Id: 585924001B Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ShXwyvRF; spf=pass (imf11.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam09 X-Stat-Signature: sajipbeyrzuruis6hr8rcimco798rjem X-HE-Tag: 1666397868-834672 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: On Fri, Oct 21, 2022 at 05:00:24PM -0700, Ira Weiny wrote: > On Fri, Oct 21, 2022 at 03:48:57PM -0700, Ira wrote: > > On Fri, Oct 21, 2022 at 01:30:41PM -0700, Andrew Morton wrote: > > > On Fri, 21 Oct 2022 14:09:16 +0100 Matthew Wilcox wrote: > > > > > > > On Fri, Oct 21, 2022 at 12:10:17PM +0800, kernel test robot wrote: > > > > > FYI, we noticed WARNING:possible_recursive_locking_detected due to commit (built with gcc-11): > > > > > > > > > > commit: 7a7256d5f512b6c17957df7f59cf5e281b3ddba3 ("shmem: convert shmem_mfill_atomic_pte() to use a folio") > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master > > > > > > > > Ummm. Looks to me like this now occurs because of this part of the > > > > change: > > > > > > > > if (!zeropage) { /* COPY */ > > > > - page_kaddr = kmap_atomic(page); > > > > + page_kaddr = kmap_local_folio(folio, 0); > > > > ret = copy_from_user(page_kaddr, > > > > (const void __user *)src_addr, > > > > PAGE_SIZE); > > > > - kunmap_atomic(page_kaddr); > > > > + kunmap_local(page_kaddr); > > > > > > > > Should I be using __copy_from_user_inatomic() here? > > > > I would say not. I'm curious why copy_from_user() was safe (at least did not > > fail the checkers). :-/ > > > > > > > > Caller __mcopy_atomic() is holding mmap_read_lock(dst_mm) and this > > > copy_from_user() calls > > > might_fault()->might_lock_read(current->mm->mmap_lock). > > > > > > And I guess might_lock_read() gets upset because we're holding another > > > mm's mmap_lock. Which sounds OK to me, unless a concurrent > > > mmap_write_lock() could jam things up. > > > > > > But I cannot see why your patch would suddenly trigger this warning - > > > kmap_local_folio() and kmap_atomic() are basically the same thing. > > > > It is related to your patch but I think what you did made sense on the surface. > > > > On the surface copy_from_user() should not require pagefaults to be disabled. > > But that side affect of kmap_atomic() was being used here because it looks like > > the code is designed to fallback if the fault was not allowed:[1] > > > > mm/shmem.c > > ... > > page_kaddr = kmap_local_folio(folio, 0); > > ret = copy_from_user(page_kaddr, > > (const void __user *)src_addr, > > PAGE_SIZE); > > kunmap_local(page_kaddr); > > > > /* fallback to copy_from_user outside mmap_lock */ > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > if (unlikely(ret)) { > > *pagep = &folio->page; > > ret = -ENOENT; > > /* don't free the page */ > > goto out_unacct_blocks; > > } > > ... > > > > So this is one of those rare places where the kmap_atomic() side effects were > > being depended on... :-( > > > > [1] might_fault() does not actually mean the code completes the fault. > > > > mm/memory.c > > ... > > void __might_fault(const char *file, int line) > > { > > if (pagefault_disabled()) > > return; > > ... > > > > > > > > I see that __mcopy_atomic() is using plain old kmap(), perhaps to work > > > around this? But that's 2015 code and I'm not sure we had such > > > detailed lock checking in those days. > > > > No kmap() can't work around this. That works because the lock is released just > > above that. > > > > mm/userfaultfd.c > > ... > > mmap_read_unlock(dst_mm); > > BUG_ON(!page); > > > > page_kaddr = kmap(page); > > err = copy_from_user(page_kaddr, > > (const void __user *) src_addr, > > PAGE_SIZE); > > kunmap(page); > > ... > > > > So I think the correct solution is below because we want to prevent the page > > fault. > > I was about to get this patch ready to send when I found this: > > commit b6ebaedb4cb1a18220ae626c3a9e184ee39dd248 > Author: Andrea Arcangeli > Date: Fri Sep 4 15:47:08 2015 -0700 > > userfaultfd: avoid mmap_sem read recursion in mcopy_atomic > > If the rwsem starves writers it wasn't strictly a bug but lockdep > doesn't like it and this avoids depending on lowlevel implementation > details of the lock. > > [akpm@linux-foundation.org: delete weird BUILD_BUG_ON()] > Signed-off-by: Andrea Arcangeli > Acked-by: Pavel Emelyanov > ... > > So I wonder if the true fix is something to lockdep? I think lockdep used to complain because we can be taking the same mmap_sem twice in this case (the 2nd one during the useraddr page fault). So to answer the other question - yeah the current->mm and dest_mm can definitely be the same one in this context. > > Regardless I'll send the below patch because it will restore things to a > working order. > > But I'm CC'ing Andrea for comments. Open-code disabling of pagefault sounds okay to me. pagefault_disable() used to be covering the kmap procedure too as done in kmap_atomic(), but frankly I don't know whether there's a real difference. Yeah, let's see whether we can get a confirmation from Andrea. Thanks, -- Peter Xu