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 0197EC369DC for ; Mon, 28 Apr 2025 21:08:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 018956B0028; Mon, 28 Apr 2025 17:08:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F0B306B002A; Mon, 28 Apr 2025 17:08:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DFA2D6B002B; Mon, 28 Apr 2025 17:08:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C09276B0028 for ; Mon, 28 Apr 2025 17:08:18 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 036B9C90EB for ; Mon, 28 Apr 2025 21:08:19 +0000 (UTC) X-FDA: 83384690760.16.FFEBAF2 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf02.hostedemail.com (Postfix) with ESMTP id 36CA680008 for ; Mon, 28 Apr 2025 21:08:18 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JNfPHk4l; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745874498; a=rsa-sha256; cv=none; b=KFcJRxNs9cytPt9kPNAJr80iEYFDAlGdvsXNksFojpv6j43QTZNGLas0fdHxK+btWtIdMF YIhVnO5DHb4P82ZBVkvNuF+q9f/7OliMxFCvlfE7WyVH2pJz+VEqyAy33PmHIldBBu/jZW SR02QBHn3VIiaXo1Fxm/sU1rWqFPqAE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JNfPHk4l; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745874498; 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=FT0CaeuueSO43RohZzjCWW30DBf6Dm/pusaOGrzO4mw=; b=FxZAxqnBRFYn+Uz5jt5Bs6dc0ekj1NpG0E5Nrm7F56ugXyPPME09V/zNreIlIcgiErosCi EQ/v5sur1TDkXDFiOJO0Lh8LvFpzi1t5a7vTeYPDau3lrpgIS0gkcIKyfHIjKa8mVTDStD FUCRuzvVFXKXrGNKclkFNllsUCgWxDs= Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-47681dba807so23411cf.1 for ; Mon, 28 Apr 2025 14:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745874497; x=1746479297; 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=FT0CaeuueSO43RohZzjCWW30DBf6Dm/pusaOGrzO4mw=; b=JNfPHk4lggObf7FKlvCaLGj4OCxSM4Kv86SykqaXZBycB2lMJ7ZXMyog5CJzu92wMu 4E1EOqpoueCSm2zc+a3lGEKRLMiF63cvT2NEgNZDfNpe1F9zulW9z3DOEt7L2vgXg6Qs noGBtTauLzN8J4NBcjA6DrfJrK601PBDxQ/Hep1B/2MauT/uWrmESNZlJ7YgsyjGAI65 RcQF6IKHQamwiwd9o4zLEjUlLqi5iwGHn1lglZ21gdiLJUh+KwAYVpVCtj8jeCVsgoGT FzV+1hAYQHj69qMC+Iw86okioCvykqphpwfGJzcDduYclTdgAcSL19QCNxGzBJvNnOVV q45w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745874497; x=1746479297; 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=FT0CaeuueSO43RohZzjCWW30DBf6Dm/pusaOGrzO4mw=; b=H/19PdBG0sTa+TDJ47gbzlBu3rs4L9sxcTEEdq5Aw/GaN8L/lSpz7sfsqlsyx58tBG VcbvaaQiCptsSnZkrtqCjtL3Wnc0CLWQ1lavZQ730rz37PLu6mD68ed6W/4FaFsgosZY 3VcD8ZcfArBPtmQ6ouT8yrh+eR2nJ1MP08OeZhvr1Zf2A6ApB5b+9BKp8iO545PtAQq0 gs0xOEW+HbLYm3uotnpYFEfeQMQQYI7bOPeDjUQxlROWwNNvPtzulAn38cQFauUr4c+Z dtknXJ3lLrUn3eJWM41tFTLAcaMCDlgn9ee38vC/+cDTl4xbk5dB4PJLk/rzQi5cxRE1 uNeg== X-Forwarded-Encrypted: i=1; AJvYcCXADc3tFhZV66vMRd0jDSr7qYEm6uyYsJpyZNF8ZVwow59AojmyMaMecg5vkIkcIPrD8o2CsIRkXA==@kvack.org X-Gm-Message-State: AOJu0YyUu8w2VpiEiK9TQq1xZrXoUEiITt3qNPtBgAxjSQG2110rF1wm hs720FJuPWX9D6CZId6ERdSNmASlNYLsIr5tlPh05ZhFserOD4NkqKBZzZr3JEP13zEpbDoSy2k HjwiyeiHvYu/gJnloipghBwq5FQs0RG+8dsan X-Gm-Gg: ASbGncvukV4Y2JfgdulxyeXm5ct/78OqEwHyn9M/R5NI4gbj6sXzThmcq8QgYO9Bg80 yu0AIvVnm2tfDgtPDAgfVCHo7j5FF610wug+uxnsvqIJ03dD+K5slk2ww1hpqxJiYSxihRSu/oe xCN4Pn3P/ZsfKJ0cEEfwGG X-Google-Smtp-Source: AGHT+IF7nEeNN5IoHYUZOsksCwxGnP76MH/oM4Ag+TLub1j6OYkYCBReXTbDlN3KDAptidyK0UifPW7MNggZmdZ4WsA= X-Received: by 2002:ac8:7dd3:0:b0:486:adf7:36a4 with SMTP id d75a77b69052e-4885e5a2f5amr1100811cf.18.1745874496976; Mon, 28 Apr 2025 14:08:16 -0700 (PDT) MIME-Version: 1.0 References: <20250428184058.1416274-1-Liam.Howlett@oracle.com> In-Reply-To: <20250428184058.1416274-1-Liam.Howlett@oracle.com> From: Suren Baghdasaryan Date: Mon, 28 Apr 2025 14:08:06 -0700 X-Gm-Features: ATxdqUG5yGDhO1Uwi8IbUUJ9HWVg6HGCcUvY-98PnsAZxbZMsP2M7PaJRH1Z8Jw Message-ID: Subject: Re: [RFC PATCH v6.6] maple_tree: Fix mas_prealloc() reset To: "Liam R. Howlett" Cc: sidhartha.kumar@oracle.com, maple-tree@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhaoyang Huang , Hailong Liu , Lorenzo Stoakes , "zhangpeng . 00 @ bytedance . com" , Steve Kang , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 36CA680008 X-Stat-Signature: hmrdtmxwnui14fnrnpcygzwgkhafs1ax X-Rspam-User: X-HE-Tag: 1745874498-883000 X-HE-Meta: U2FsdGVkX1/gT/FEAhTggk7k2Y/TqoY+4N4/6TdR1AYWKLDYQHqJiyf2vxMVg7M9QTdYUnTiKkTgVxKAFcn/BXuDqV6lmxfqSUKjWOCbjCQdMwNKwKVQpZaLeyx8yCdoOwaM1Pyt0w0XzwP3SW74eHgS4OK5Q7yZ6H951SI7v2IsSR81sFMu/wEe4qqloum4MIe1/weFHIrDoA6HbDl8zGJdOu18wqglSmgJEXi3zYQiVs70jhVz/aCgRCR4CW6XEl1TuEL8E7f5g8hcvUz2ebuq6D09s5far01Hg9syNqGJlKDYOt+hMtdGiYdj9s/bXMprnL17ehG7hHhF92KQFt9dlFc8DsSVSehmlD0lmRXPIfwtz85XLa2is9JOrg43n26sukpsqyNMew/kc8+uwO6kECfduPzr0T0+5Zo1Ijk/v3HfAaEAxRz94fxt5GfH/Uu+OY6YROpiAshIZPz6o3cZJhkYATr6wYodR/W+ao/9gBpHN7HXSEWj7x9Ss6tzpIFGiPDaSIfijkdrkFs/aXMqYtclgXOWZh2FJPvC1aL/daRk5nQmnRlN4FLx4ATzSrE32zlNUn1XgFtUMrk/b2kg2iJUP0EE7HDpDXQqY+Dgb7dgQHdUpaPk5/45gvRbhSdRwgU5f5Fo0e7XfSZa4Dw+IOe7t32/CaQxOzaHGu5Ece+S0kzYkUV7Tao4w6y1iHhRoLhAq/9HHHQCL+SpRH/D1vSU3cZwGsjBySAdZbMvHOxco2JLpRcSD7fU4sZKnBPlfhmoBmMGgw3Q+OiAVb1jhyrFZUA6qM8QVxW1oCvzWgc+Ti7a3e1FL5Kqaa+LGIHcTdf05XQ3n4O0i/5YbXMX61nOItAf/zCT0hbXmY8iK/W4T4YRk1TgJAU/JeXvN2bpU374cXPz0LtwhNuenTbT3Rfxo1q5Pb/4cxCtFsl2j1Xi7+D84SfPMIQYIs4aX9gVsj4OrTUZkxskfE8 lmxSJmmC k5ryYQNd0b8xTg5sNnOxrWS0feSSe7p+v6pF8m8um+EMu5njAanzXXONVULxC++KT72hLiF8TjYiV45UIeeUT7m5q3bbbHP/EYFCV9v2jALTCL+FVDEI/WwKXRlrGYgWzTYPRQOvgdSZp5MyCV+bI3Z4AAOzB2ZAlCx0aoSX8+kYJhiOXBqtciie+sBBkejawKygRdIqwAk3SSxRlooIt1hx3Y3ubAAFuGGqiGNq4G/EIWI0qdM6mDoX1fCBhV/4gkh8oKcSFBdsULKi4DHhQYDbM5en+KWFyDLN+pdb/O2L9oLXLFUCT/bKSLpUuDFgHM0cw4TT6A0LAxxq45WAejx1DTc3ACkxeeIl9D0h+kMDXuoYBWhGUt8yVXKGf0mkDeTXCOPoQWuebLui/IdlypiKOE+vfp7whOKWIHtiVZ96doRVvzsN/7osNO9fAie4yLvuFysiLJeRHU8+IaH/lEI0jFekOQpU98iN/ 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 Mon, Apr 28, 2025 at 12:02=E2=80=AFPM Liam R. Howlett wrote: > > A previously used maple state may not be in the correct state for the > preallocation to correctly calculate the number of nodes necessary for th= e > configured store operation. > > The user visible effect of which is warning that there are no nodes > allocated followed by a crash when there is a null pointer dereference > shortly after. > > The NULL pointer dereference has been reported to happen when a vma > iterator is used to preallocate after walking to a leaf node but then > requesting to preallocate for a store across node boundaries (in v6.6. > of the kernel). The altered range means that there may not been enough > nodes as the maple state has been incorrectly configured. A critical > step is that the vma iterator then detects the misconfigured maple state > and resets, thus ensuring the tree is not corrupted - but ultimately > causes a failure when there are no nodes left. > > Detect a misconfigured maple state in the mas_preallocate() code by > examining the current location and planned write to ensure a reset is > done if required. The performance impacts are minimal and within the > noise in initial testing. With this fix applied I can still see the issue using Hailong's reproducers, both the userspace one that he shared over the weekend and the one posted at https://lore.kernel.org/all/1652f7eb-a51b-4fee-8058-c73af63bacd1@oppo.com/ > > Reported-by: Zhaoyang Huang > Reported-by: Hailong Liu > Fixes: fec29364348fe ("maple_tree: reduce resets during store setup") > Link: https://lore.kernel.org/all/1652f7eb-a51b-4fee-8058-c73af63bacd1@op= po.com/ > Cc: Lorenzo Stoakes > Cc: Suren Baghdasaryan > Cc: Hailong Liu > Cc: zhangpeng.00@bytedance.com > Cc: Steve Kang > Cc: Matthew Wilcox > Signed-off-by: Liam R. Howlett > --- > lib/maple_tree.c | 35 +++++++++++++++++++++++++++++++---- > 1 file changed, 31 insertions(+), 4 deletions(-) > > diff --git a/lib/maple_tree.c b/lib/maple_tree.c > index 4eda949063602..17af9073494f5 100644 > --- a/lib/maple_tree.c > +++ b/lib/maple_tree.c > @@ -5350,6 +5350,8 @@ static inline void mte_destroy_walk(struct maple_en= ode *enode, > > static void mas_wr_store_setup(struct ma_wr_state *wr_mas) > { > + unsigned char node_size; > + > if (!mas_is_active(wr_mas->mas)) { > if (mas_is_start(wr_mas->mas)) > return; > @@ -5372,17 +5374,42 @@ static void mas_wr_store_setup(struct ma_wr_state= *wr_mas) > * writes within this node. This is to stop partial walks in > * mas_prealloc() from being reset. > */ > + > + /* Leaf root node is safe */ > + if (mte_is_root(wr_mas->mas->node)) > + return; > + > + /* Cannot span beyond this node */ > if (wr_mas->mas->last > wr_mas->mas->max) > goto reset; > > - if (wr_mas->entry) > + /* Cannot span before this node */ > + if (wr_mas->mas->index < wr_mas->mas->min) > + goto reset; > + > + wr_mas->type =3D mte_node_type(wr_mas->mas->node); > + /* unfinished walk is okay */ > + if (!ma_is_leaf(wr_mas->type)) > return; > > - if (mte_is_leaf(wr_mas->mas->node) && > - wr_mas->mas->last =3D=3D wr_mas->mas->max) > + /* Leaf node that ends in 0 means a spanning store */ > + if (!wr_mas->entry && > + (wr_mas->mas->last =3D=3D wr_mas->mas->max)) > goto reset; > > - return; > + mas_wr_node_walk(wr_mas); > + if (wr_mas->r_min =3D=3D wr_mas->mas->index && > + wr_mas->r_max =3D=3D wr_mas->mas->last) > + return; /* exact fit, no allocations */ > + > + wr_mas->slots =3D ma_slots(wr_mas->node, wr_mas->type); > + mas_wr_end_piv(wr_mas); > + node_size =3D mas_wr_new_end(wr_mas); > + if (node_size >=3D mt_slots[wr_mas->type]) > + goto reset; /* Not going to fit */ > + > + if (node_size - 1 > mt_min_slots[wr_mas->type]) > + return; /* sufficient and will fit */ > > reset: > mas_reset(wr_mas->mas); > -- > 2.47.2 >