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 E3011C021A0 for ; Sun, 16 Feb 2025 01:43:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0BE6428001B; Sat, 15 Feb 2025 20:43:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0465728001A; Sat, 15 Feb 2025 20:43:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E024228001B; Sat, 15 Feb 2025 20:43:06 -0500 (EST) 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 BFD6228001A for ; Sat, 15 Feb 2025 20:43:06 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 324121A2724 for ; Sun, 16 Feb 2025 01:43:06 +0000 (UTC) X-FDA: 83124109572.25.2233B48 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf14.hostedemail.com (Postfix) with ESMTP id 54F9C100008 for ; Sun, 16 Feb 2025 01:43:04 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RRvvSibP; spf=pass (imf14.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739670184; 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=Oz8gPdV3LRbojLNIjkuNDOulXZh/XmAXdk7uHwTbEGc=; b=PXx5p11SEJMLm/DJgIZDkaFbsucDB9gr08tKG46OGMXwye3XpixLEEAG/Ye+mjDToA1ACi T7FfOJhh5VHFSrqbzUXWgmy1qRhNimNMt1v1T8iVyzoT8A2VwPbq2dMNliLFqtp3aArUPi TzXMtp0t10FxOfRJuMIBymSzwY4turQ= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RRvvSibP; spf=pass (imf14.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739670184; a=rsa-sha256; cv=none; b=zuXMt/Zi9V0tY3OMMo7CN43kVSNw02ddBUbdqZKm+xSrHR6q1IOf4wacw2SSfc8ffDr4Fw cgnjiKR9COq+A2qmDqabZZhfCqPu/ycemt2OFnD3JMUK8zWp3wZwZqW/Avi8lyWZ9JPTlM AR+57wsJPQcDSmrv/eImKH1F+e2QhuI= Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-4bbd3cff198so2120338137.2 for ; Sat, 15 Feb 2025 17:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739670183; x=1740274983; 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=Oz8gPdV3LRbojLNIjkuNDOulXZh/XmAXdk7uHwTbEGc=; b=RRvvSibPQQumc8yh7kwW6S1D73nlXN+kfOdhRMhQ15TCQRz0VnM6QjZVDSLKfdOVOw 3Uc4OQ13CX8esY49MX52rJ57RbdnHa4hd2ZABbliR7WNmts0mqjOuAQB1+zaLYLlsSRe wDims17VCoPeOqeahTFaKh5kVOmgLUxTxzdVwQUHRtZu0P0GvGETlc0mUML1Vvh5sCN0 kGnGKI1AyJeaoBIyPjc37+ZIDXD2Fn4gJGFwN4Ow53UmZZ+5EDLNlA17exzGp1MrLjmE OPxo5Ml/nTeY/YcvTUE7ZgfKz1VOIU0/Ezd8OvrBoFnl1aj11kzYq0SnKw4Y2UsdDxKt ICMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739670183; x=1740274983; 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=Oz8gPdV3LRbojLNIjkuNDOulXZh/XmAXdk7uHwTbEGc=; b=FvGXtklX7RIP534vLTOJ7GIv5ugkRa1gcDVn0kQY4CXeVBt7emyZdMna91Cdr96YV0 uLBe9hVqy6MkAkZZbt5OJDdxKT0h2oY0plBu3ULbSOogXAciJbg5Qkvb8NhVY1CQ+BPn TtHp5DW8LUh1CJFJhS5ACMxJuNC9mEJm5rDH5Xm0bGJOt2MuBI+CHNy1HZ7UZxtXmF1E 06sIJnF3f0yQ6VZdj6vu5LZHtnKzi5SLpMXptfp8Guwg3gqy5rchaOBjP/Hug4SceSuf aeA+pNLYBJcNxMVNSkDIS0b0vblt8NgvZS3Yf8Nq5l7z4mxHzpAiPxI5uCHB6F4A37hJ SXnQ== X-Forwarded-Encrypted: i=1; AJvYcCXivxnOX8ic+OU79wtwNQODhOWBHz1S0Asy4EffLFELGJ41W2l5xsxXzKZiFcJOl3BdwOf/Md2TDw==@kvack.org X-Gm-Message-State: AOJu0YyVaH7OSiPqyXJnP00rmWdpt45DDLrSzPJdeFU3vvXMtb7gAO3H mIk+HJkShXY82N8KI/pUYWJEmeNybrWKFpyLffOLt1sOtzD4SiSCBJBN/GMFp3mhEUO6DjrU7XL ToKypoTJBXSzCpLssO0PrdWw4JRQ= X-Gm-Gg: ASbGnct+6ADiX64QPsj4Rb74dN/E1K8YiOkadpBHP40vvl9arrWH3xg8d2SZ/ObJCTw +4spYD79MS6oQE6zfkB/QEnVQciHku9in5F10Yt1CGKHr8gsKz98letHa8v3IkEKi78am7O6N X-Google-Smtp-Source: AGHT+IELZfSG9qgadmAGFgRgUBNleVJU39u54xzNpXFaf7xgM7ahJlVK8AQUwUHHT6+iot3V0FRVllvA89mBVAE0tP0= X-Received: by 2002:a05:6102:150f:b0:4bb:c8e5:aa6d with SMTP id ada2fe7eead31-4bd3fe46605mr2964097137.17.1739670183375; Sat, 15 Feb 2025 17:43:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sun, 16 Feb 2025 14:42:52 +1300 X-Gm-Features: AWEUYZl-ufMVHWw-G1aIPwkogcyGLMRPv76oh35rbF_LJDBXhkOEznJIxHy20O0 Message-ID: Subject: Re: [PATCH v3] mm: Fix possible NULL pointer dereference in __swap_duplicate To: gaoxu Cc: Andrew Morton , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Suren Baghdasaryan , Yosry Ahmed , yipengxiang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 54F9C100008 X-Stat-Signature: znjz7zm7oeyn1po9ezxmyadaqdtjk53w X-HE-Tag: 1739670184-928912 X-HE-Meta: U2FsdGVkX18kwRll3xr2D2c7hXb8bCPwq/XvDjB7wu5/U5ESku3y41ipXazdSpML/1A6RYRtyFmPjT02NH4bcTgM0YBMkPPTWxTQl95ykJnB3gnL7oeSMKFxJcR8y1Ht5w6b/WkmTirh14QjgomGce6kKJbojlSrqZspuyZhwWT4229baEXA8QDlMPbI/+Jccn7fRFh3ITgL3wKexCncUAJET3pTyrpDYpBaJ7urTm15x29ZHifs23j09gbFDrflpVEqh44RAHtJo8zJG5RuDD+NskQmt86GoA0xyRuWnL7VE00VP+4iUUwVidAx3PpOf5U+/MLNmm0fEko6LutTosLDm7SEJiRCuM84bHYTneGv9TK0zajws9p+dDWGxOrZcTWJiQ9tK7fe0BBOthddXa8294243ZV7B5z0Wt8DEMbrQSb0jIfSeC/vP85vbM11L4UnZFVu0yid6Qr0oAio4pN+YiHWE8dbrEWnKysI1Wa8itVWSLui1nMIAQPZVZyWZVsawfpAJQl2OaYU62uGQPI63ROHAy82HSh54MrNH6yhGY8JB9kxQE1SbE3I+z3p/DrvLPM5GHiEC7ExDJWwGGQtaFuKIsiD3meH9/KkzRFM2nE+tq+Jc8M8NQfEtcYKKRAeQin0vulvhCFD0WygaY2AmzOwujqX6+gtNTMuJo7EFgscdKbF/aV0metgb0mQh5FKD5+8AdAjLUZnwFlFYdqrcTMFAy6PHZghQWnWHKqqn9M8YIEM4x/8BxTHS+Z3bMt1Jeo0XLvYM7sZlMqAxULeKDszVJanGCydw7BPv+6/vHRk+z6sb8Nmnjw+DnGsKPvWt+RAf375K+q830sMLKfBHvnwRTK1tGfk0V7/yXOB68ISEOJhTGzbstHae5VfJaJZk1dR3+J4/VDzbJ/g1swfDX2TkXMbNCpMG2a7ZIv35oWyBF8jx2Y0JVF//JwHRNjNO8FtZCoEh/5Ea2L ajJH8Dt2 6MtFFmL6jiinRXZnxxPZKKviDJyBImtmB/46x3L/xI10TqP+QcGvhVsiSP1ZCPyneWN4TFjx7Wyb4+rNLmM+xWfjr/jLpPOL1v30Rtl6vyUT7Jmp+yqbZ+wGMTuROpTSR9Bs7JI0sFDpBCs8Wfewv7kcHkor5xlMN/CQxkl+c8oAU6q2XY4gQ2tXiZrCjlAyLvT71KU4XkgtEM9Hus1Un6mMI/bg69eTWaR5w1Dx5PHNFcg/Nb+jHPH9XD0CddE23cHAFF22lNoxpWxh9N3muPSC79PX7mrDDDgjnxTlIL0fC3TvpyIvuuFMTeCDvRyYTJHzSSbJ4qFroOVLhOoxbLNYGdSj2lqRHXY/ekA4yOsJEnw3oigqGUY8CQ6Apsqt6lP/4gFoVRmEwoqswD0Zcf4YaN30YW66/zZ+hblVB4TgEzhZQyGwSDJ75SyqU4Qh2hdgmKLP7Vs+/KlJUhQcbMQsoNw== 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 Sat, Feb 15, 2025 at 10:05=E2=80=AFPM gaoxu wrote: > > Add a NULL check on the return value of swp_swap_info in __swap_duplicate > to prevent crashes caused by NULL pointer dereference. > > The reason why swp_swap_info() returns NULL is unclear; it may be due to > CPU cache issues or DDR bit flips. The probability of this issue is very > small, and the stack info we encountered is as follows=EF=BC=9A > Unable to handle kernel NULL pointer dereference at virtual address > 0000000000000058 > [RB/E]rb_sreason_str_set: sreason_str set null_pointer > Mem abort info: > ESR =3D 0x0000000096000005 > EC =3D 0x25: DABT (current EL), IL =3D 32 bits > SET =3D 0, FnV =3D 0 > EA =3D 0, S1PTW =3D 0 > FSC =3D 0x05: level 1 translation fault > Data abort info: > ISV =3D 0, ISS =3D 0x00000005, ISS2 =3D 0x00000000 > CM =3D 0, WnR =3D 0, TnD =3D 0, TagAccess =3D 0 > GCS =3D 0, Overlay =3D 0, DirtyBit =3D 0, Xs =3D 0 > user pgtable: 4k pages, 39-bit VAs, pgdp=3D00000008a80e5000 > [0000000000000058] pgd=3D0000000000000000, p4d=3D0000000000000000, > pud=3D0000000000000000 > Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP > Skip md ftrace buffer dump for: 0x1609e0 > ... > pc : swap_duplicate+0x44/0x164 > lr : copy_page_range+0x508/0x1e78 > sp : ffffffc0f2a699e0 > x29: ffffffc0f2a699e0 x28: ffffff8a5b28d388 x27: ffffff8b06603388 > x26: ffffffdf7291fe70 x25: 0000000000000006 x24: 0000000000100073 > x23: 00000000002d2d2f x22: 0000000000000008 x21: 0000000000000000 > x20: 00000000002d2d2f x19: 18000000002d2d2f x18: ffffffdf726faec0 > x17: 0000000000000000 x16: 0010000000000001 x15: 0040000000000001 > x14: 0400000000000001 x13: ff7ffffffffffb7f x12: ffeffffffffffbff > x11: ffffff8a5c7e1898 x10: 0000000000000018 x9 : 0000000000000006 > x8 : 1800000000000000 x7 : 0000000000000000 x6 : ffffff8057c01f10 > x5 : 000000000000a318 x4 : 0000000000000000 x3 : 0000000000000000 > x2 : 0000006daf200000 x1 : 0000000000000001 x0 : 18000000002d2d2f > Call trace: > swap_duplicate+0x44/0x164 > copy_page_range+0x508/0x1e78 This is really strange since we already have a swap entry check before calling swap_duplicate(). copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm, pte_t *dst_pte, pte_t *src_pte, struct vm_area_struct *dst_= vma, struct vm_area_struct *src_vma, unsigned long addr, int *rs= s) { unsigned long vm_flags =3D dst_vma->vm_flags; pte_t orig_pte =3D ptep_get(src_pte); pte_t pte =3D orig_pte; struct folio *folio; struct page *page; swp_entry_t entry =3D pte_to_swp_entry(orig_pte); if (likely(!non_swap_entry(entry))) { if (swap_duplicate(entry) < 0) return -EIO; ... } likely the swap_type is larger than MAX_SWAPFILES so we get a NULL? static struct swap_info_struct *swap_type_to_swap_info(int type) { if (type >=3D MAX_SWAPFILES) return NULL; return READ_ONCE(swap_info[type]); /* rcu_dereference() */ } But non_swap_entry() guarantees that swp_type is smaller than MAX_SWAPFILES= . static inline int non_swap_entry(swp_entry_t entry) { return swp_type(entry) >=3D MAX_SWAPFILES; } So another possibility is that we have an overflow of swap_info[] where typ= e is < MAX_SWAPFILES but is not a valid existing swapfile? I don't see how the current patch contributes to debugging or fixing anything related to this dumped stack. Can we dump swp_type() as well? > copy_process+0x1278/0x21cc > kernel_clone+0x90/0x438 > __arm64_sys_clone+0x5c/0x8c > invoke_syscall+0x58/0x110 > do_el0_svc+0x8c/0xe0 > el0_svc+0x38/0x9c > el0t_64_sync_handler+0x44/0xec > el0t_64_sync+0x1a8/0x1ac > Code: 9139c35a 71006f3f 54000568 f8797b55 (f9402ea8) > ---[ end trace 0000000000000000 ]--- > Kernel panic - not syncing: Oops: Fatal exception > SMP: stopping secondary CPUs > > The patch seems to only provide a workaround, but there are no more > effective software solutions to handle the bit flips problem. This path > will change the issue from a system crash to a process exception, thereby > reducing the impact on the entire machine. > > Signed-off-by: gao xu > --- > v1 -> v2: > - Add WARN_ON_ONCE. > - update the commit info. > v2 -> v3: Delete the review tags (This is my issue, and I apologize). > --- > > mm/swapfile.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/swapfile.c b/mm/swapfile.c > index 7448a3876..a0bfdba94 100644 > --- a/mm/swapfile.c > +++ b/mm/swapfile.c > @@ -3521,6 +3521,8 @@ static int __swap_duplicate(swp_entry_t entry, unsi= gned char usage, int nr) > int err, i; > > si =3D swp_swap_info(entry); > + if (WARN_ON_ONCE(!si)) I mean, printk something related to swp_type(). This is really strange, but the current stack won't help with debugging. > + return -EINVAL; > > offset =3D swp_offset(entry); > VM_WARN_ON(nr > SWAPFILE_CLUSTER - offset % SWAPFILE_CLUSTER); > -- > 2.17.1 Thanks Barry