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 7EE4CC25B75 for ; Fri, 31 May 2024 18:07:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E21376B00A2; Fri, 31 May 2024 14:07:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DCCF26B00A3; Fri, 31 May 2024 14:07:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C943D6B00A4; Fri, 31 May 2024 14:07:38 -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 A74BD6B00A2 for ; Fri, 31 May 2024 14:07:38 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5FD5E1A17C4 for ; Fri, 31 May 2024 18:07:38 +0000 (UTC) X-FDA: 82179473796.10.F7D3656 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf18.hostedemail.com (Postfix) with ESMTP id 7E7211C0014 for ; Fri, 31 May 2024 18:07:36 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DDagcBmI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717178856; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ya2Mxculd7njAcy1+bzu0IEd1bx5A+sr4iky2perI8k=; b=M/lzjkmB9rGu4gO469hI6VrOGymb8e7UISvid/3jhjWEkWS+4RUTzStb+4mAGVtYUCJYx1 eRa1NPIAFd7kiSz2yZGyGA6Doa+OW9VX2pWlUfjwPcoL/Na0XRhbo1vqE7wzHOBnKlhPtT 7/btk4crWJyjdBafw83Yo94zlgwAUE0= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DDagcBmI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717178856; a=rsa-sha256; cv=none; b=zdz7xp2H+Ogsu78LidodwqrxiDf9JiyV3yUmVgiRUX+UYbiCCQld2k9ikg1gkERr7oujWW xhszzzaG2HH2qINaI3395RRFsN9jo10HJgqT35wFENoCoaMjYTfVp2ZR126J5wVQC6ozaj dMCJuIikvyw6P4IBQMN/WBV83n7TCTs= Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-579fa270e53so2825513a12.3 for ; Fri, 31 May 2024 11:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717178855; x=1717783655; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ya2Mxculd7njAcy1+bzu0IEd1bx5A+sr4iky2perI8k=; b=DDagcBmImNHxz/ARVu6Yg0zeChi4DF5bUtZGOTxbJkg+4tRe4ykjXSZkALugOJWcpS Mm3+A27Mel0KgtkUYRgOIidML6Pgp6lZCcaIUdNiIBKHOcRbTeEcoZnBNhDPO/6Gum/p dwbF+TW0PyJABp7/cy7gHB4D9L0bqP7p5rDdEIhTNTMNqvKtlkavBZys8oE/d+INQK5+ rB4Z5/JI9DpeS8b0GgbIzLx/9KKCDFQw7RfBcWePuZ1/QF1lvd+q8n0dWpeKtTqSYcIM uagMY4hxNa/JaiQz+UTMhnnlxx5JgZYN1l3qFzq7DZKKgA3GgAbkqgBgf6XSPyhvlsdm 9juA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717178855; x=1717783655; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ya2Mxculd7njAcy1+bzu0IEd1bx5A+sr4iky2perI8k=; b=IRtMh6OvC83yb5lkDuaMV7Vt6heEFT30SIu3Jw57w1ExoikxsYvYcD9A0kif4Zr1Ae vBbLCchdwSMIv1NQI2TqbRc1vD9eA1Pt2AM850D/LSh27S5i9utFfnKlfgAPA6Vj9LRC 1mkVj1QrL8DUtZDRUgu2VwE7YKjg1zg9lMr0LxJgEgCSYP4e31sBNDnnh1rwMgcsfkky 0hdgQOeNIz57Xb93hqWcALAATTTn0kZ+7cwwQfEKDhTYqGbbBQRbW34v1Unv5kESrOwS 23A+0bZ/fJJqZw3jVZh1/wvGzMprKEQkwMnVzcxgoG3AgiCGdQE/P9kz2K348ny3WFIR N8Ww== X-Forwarded-Encrypted: i=1; AJvYcCV/fpQPnE8PaFX1hXMgpgnr4ZE98RuOa5XgVIXPQDhEHPZh7ZcUZ9K6V9ATb9w9bxamYx/b+8JZK49iU83+QKMvKq4= X-Gm-Message-State: AOJu0YxXelGPNXcM4uEXFoDGvPPGtzKQyVE1dBrZbDJ5bEDeXYmin8he 9pQ395HIIqv89Kd+ZEckzzBMfFuZyJ/iYmkEAj0UFonPMkrrWIONptsxGUfHo5vbnOUDWBkaCVQ wPSzVJjh9oYA0j7IQIGq8j0NfoEw= X-Google-Smtp-Source: AGHT+IFK1e4A8rjTqX9SajY77+rAqXwkGJv+JNpnpHYgH5EmOryrZi4WtBi42nt1SjSxMGbiDC0I+6wtCLTgRZkjMzc= X-Received: by 2002:a50:f691:0:b0:578:6410:1d50 with SMTP id 4fb4d7f45d1cf-57a365c5ecdmr2109652a12.34.1717178854568; Fri, 31 May 2024 11:07:34 -0700 (PDT) MIME-Version: 1.0 References: <202405311534.86cd4043-lkp@intel.com> <890e5a79-8574-4a24-90ab-b9888968d5e5@redhat.com> In-Reply-To: <890e5a79-8574-4a24-90ab-b9888968d5e5@redhat.com> From: Yang Shi Date: Fri, 31 May 2024 11:07:22 -0700 Message-ID: Subject: Re: [linus:master] [mm] efa7df3e3b: kernel_BUG_at_include/linux/page_ref.h To: David Hildenbrand Cc: kernel test robot , Peter Xu , Jason Gunthorpe , Vivek Kasireddy , Rik van Riel , oe-lkp@lists.linux.dev, lkp@intel.com, linux-kernel@vger.kernel.org, Andrew Morton , Matthew Wilcox , Christopher Lameter , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7E7211C0014 X-Stat-Signature: bkg7t97juffecco4y33x4xahzykbbekr X-HE-Tag: 1717178856-109681 X-HE-Meta: U2FsdGVkX1/palDhXClpbhRLc3TcO93I8rZRN+dr4tluWLhDGY+I0e2EGEsV2O4T9iSSHoNnQwUci20MAL7F7SUox0BxgtnlheUogwOlU0aprLprtCGt+S/ZDwqiLL2IdZD10OZk/ON7Sc2i7ycra+7H4PT0IMC/4+/kKEEKSgZQunh2cBzV+nKo9JeaHgfH0RGG4RdGynJT2EycybGeL4fom5iKIxLLm/FHYDmQh7igBEwTmihVhjRkvpIRT3D3PHUXzCiU1fmfTVrtiuKaX+txvsX2iN6Z42jYJ0jZiEje2gpMEDupsxPst/N8fn+UHNwPkMgVWGG4ygRRX4/V0Uor+jyozV3qojILzJ+iwTcdtVtf8A03SzN/nvWmHIZDB5XPkx//cfunXvGe9JDQiTPcsV+vn+czYTbuKW3mRm+gDwZLGaF0ctrdQjCQqHwqj1PN4qKiemMe3TL+ESf6UrS2yOZ7ZYyd1BcNE2gneVQRGrtqi4/GHRYW5R6U9LfNPKsVfP/waZi8seRPEzGNVEu9O9gLR7nZPyyyVJKG7g3Gm6L//8KWG2EAFp+b8m88njDosXPFCJN0gGIm3iK1xsSZ0CFMkn9Wlu6QnQ6Z+Lvn4hIr0tEwLEQQ13vrBqS5vIiHsGT2MhCDUz+6JepJjJaW0pKJIIPxjI3jKhdsO9Jqc3IQleSp5OOkdCONGQmXq1EeC8/cywZix+V6CkfEHl5s6NWgIHaWkbO7nr3b58fnH+iSY8aXP1PbZ3wVxeyqRLt1D+plcfqXx+B5KF4J121WUWuQzQRox6X7+RyiZ8dPmiM5kJZmQf3gZhbyeeY1kZc1YJ9vI5bqiVxtxa3q9fCDzp2wurVyC3famm+4G1nWPQdhD0vv5mqh1wTiWh3uYcOTwCxiouiuExgIqtazB+ILpgXdibftGqiHUj0BnrAwUhiACOAZcpGDu5eoBdelrMTg/FcU5ESXgpIyJ6w Zje2y9gS T9jd5oTw34icJcsifmWS/HPe6HeiAGzrk6e8NpeiK+k0r3+sk+rTUNwN3yw2DutMvnBfg09IgDjo2OnX8Wh7LtlJ8kJ5Hampaf/DVWg1VfKYVtvvjD4YritMYKlhgOSqjn0IqSxKmJY+Gn6ArxGj7JmCtG6NgC/1gwEKkIn9Ut3zMlXh3WaIHilzl7aq23VBqT7BFfiz56PPj18HsVDHqPo6A1HfH+I5GkjPTUYKxn9YPUrsGJ4Nw5dj3ntAEcBBJhzJw8ZZzZ8D4quQYAFgSl9uIoasYGqxCArY7F39VWEk5ibzuvVqurUZsJYYPZ3pDIxao/l4fx56SzdUIHnRpqwCwQbY/bOG0STgVTiUDf8bLiMZis5LoIjjXjisUsxwbpV5FefkI4KI225WCAwahjyR+O1V8rfs1J39SwE7Gn2/GXtjHzU2qmomTFYCbIKHDXOrtiVbRV5mDkcPOy87w/CAmxyYteiAHYETazDGc+6Q6xWfcW5QgrMQmNgJnJL3dxBAZ 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: List-Subscribe: List-Unsubscribe: On Fri, May 31, 2024 at 10:46=E2=80=AFAM David Hildenbrand wrote: > > On 31.05.24 18:50, Yang Shi wrote: > > On Fri, May 31, 2024 at 1:24=E2=80=AFAM kernel test robot wrote: > >> > >> > >> > >> Hello, > >> > >> kernel test robot noticed "kernel_BUG_at_include/linux/page_ref.h" on: > >> > >> commit: efa7df3e3bb5da8e6abbe37727417f32a37fba47 ("mm: align larger an= onymous mappings on THP boundaries") > >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master > >> > >> [test failed on linus/master e0cce98fe279b64f4a7d81b7f5c3a23d80b9= 2fbc] > >> [test failed on linux-next/master 6dc544b66971c7f9909ff038b62149105272= d26a] > >> > >> in testcase: trinity > >> version: trinity-x86_64-6a17c218-1_20240527 > >> with following parameters: > >> > >> runtime: 300s > >> group: group-00 > >> nr_groups: 5 > >> > >> > >> > >> compiler: gcc-13 > >> test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -= m 16G > >> > >> (please refer to attached dmesg/kmsg for entire log/backtrace) > >> > >> > >> we noticed the issue does not always happen. 34 times out of 50 runs a= s below. > >> the parent is clean. > >> > >> 1803d0c5ee1a3bbe efa7df3e3bb5da8e6abbe377274 > >> ---------------- --------------------------- > >> fail:runs %reproduction fail:runs > >> | | | > >> :50 68% 34:50 dmesg.Kernel_panic-not_= syncing:Fatal_exception > >> :50 68% 34:50 dmesg.RIP:try_get_folio > >> :50 68% 34:50 dmesg.invalid_opcode:#[= ##] > >> :50 68% 34:50 dmesg.kernel_BUG_at_inc= lude/linux/page_ref.h > >> > >> > >> > >> If you fix the issue in a separate patch/commit (i.e. not just a new v= ersion of > >> the same patch/commit), kindly add following tags > >> | Reported-by: kernel test robot > >> | Closes: https://lore.kernel.org/oe-lkp/202405311534.86cd4043-lkp@int= el.com > >> > >> > >> [ 275.267158][ T4335] ------------[ cut here ]------------ > >> [ 275.267949][ T4335] kernel BUG at include/linux/page_ref.h:275! > >> [ 275.268526][ T4335] invalid opcode: 0000 [#1] KASAN PTI > >> [ 275.269001][ T4335] CPU: 0 PID: 4335 Comm: trinity-c3 Not tainted 6= .7.0-rc4-00061-gefa7df3e3bb5 #1 > >> [ 275.269787][ T4335] Hardware name: QEMU Standard PC (i440FX + PIIX,= 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 > >> [ 275.270679][ T4335] RIP: 0010:try_get_folio (include/linux/page_ref.= h:275 (discriminator 3) mm/gup.c:79 (discriminator 3)) > >> [ 275.271159][ T4335] Code: c3 cc cc cc cc 44 89 e6 48 89 df e8 e4 54 = 11 00 eb ae 90 0f 0b 90 31 db eb d5 9c 58 0f 1f 40 00 f6 c4 02 0f 84 46 ff = ff ff 90 <0f> 0b 48 c7 c6 a0 54 d2 87 48 89 df e8 a9 e9 ff ff 90 0f 0b be 0= 4 > > > > If I read this BUG correctly, it is: > > > > VM_BUG_ON(!in_atomic() && !irqs_disabled()); > > > > Yes, that seems to be the one. > > > try_grab_folio() actually assumes it is in an atomic context (irq > > disabled or preempt disabled) for this call path. This is achieved by > > disabling irq in gup fast or calling it in rcu critical section in > > page cache lookup path > > try_grab_folio()->try_get_folio()->folio_ref_try_add_rcu() > > Is called (mm-unstable) from: > > (1) gup_fast function, here IRQs are disable > (2) gup_hugepte(), possibly problematic > (3) memfd_pin_folios(), possibly problematic > (4) __get_user_pages(), likely problematic > > (1) should be fine. > > (2) is possibly problematic on the !fast path. If so, due to commit > a12083d721d7 ("mm/gup: handle hugepd for follow_page()") ? CCing Pet= er. > > (3) is possibly wrong. CCing Vivek. > > (4) is what we hit here > > > > > And try_grab_folio() is used when the folio is a large folio. The > > > We come via process_vm_rw()->pin_user_pages_remote()->__get_user_pages()-= >try_grab_folio() > > That code was added in > > commit 57edfcfd3419b4799353d8cbd6ce49da075cfdbd > Author: Peter Xu > Date: Wed Jun 28 17:53:07 2023 -0400 > > mm/gup: accelerate thp gup even for "pages !=3D NULL" > > The acceleration of THP was done with ctx.page_mask, however it'll b= e > ignored if **pages is non-NULL. > > > Likely the try_grab_folio() in __get_user_pages() is wrong? > > As documented, we already hold a refcount. Likely we should better do a > folio_ref_add() and sanity check the refcount. Yes, a plain folio_ref_add() seems ok for these cases. In addition, the comment of folio_try_get_rcu() says, which is just a wrapper of folio_ref_try_add_rcu(): You can also use this function if you're holding a lock that prevents pages being frozen & removed; eg the i_pages lock for the page cache or the mmap_lock or page table lock for page tables. In this case, it will always succeed, and you could have used a plain folio_get(), but it's sometimes more convenient to have a common function called from both locked and RCU-protected contexts. So IIUC we can use the plain folio_get() at least for process_vm_readv/writev since mmap_lock is held in this path. > > > In essence, I think: try_grab_folio() should only be called from GUP-fast= where > IRQs are disabled. Yes, I agree. Just the fast path should need to call try_grab_folio(). > > (2), (3) and (4) are possible offenders of that. > > > Or am I getting it all wrong? :) > > -- > Cheers, > > David / dhildenb >