: 24 --ce0b5f3d365d57cd5bde3f6209cc8f2659389e847da67442ef769afe21ea Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Try our most intelligent model yet and enjoy $50 in extra usage. =20 We're introducing Claude Opus 4.6=E2=80=94our most intelligent model yet, a= nd the=20 world=E2=80=99s best model for coding. We=E2=80=99re also introducing agent= teams, a new=20 feature in preview for speeding up your coding workflows. Here=E2=80=99s what=E2=80=99s launching on Claude Code: * Claude Opus 4.6: The latest version of our most intelligent model, and t= he=20 world=E2=80=99s best model for coding, enterprise agents, and professional = work.=20 Available now as the default model in Claude Code. * Agent teams (research preview): Claude Code can now parallelize tasks=20 across multiple agents that communicate peer-to-peer. Note that running=20 multiple agents may increase token usage proportionately. Agent teams are o= ff=20 by default and can be enabled in user settings.Learn more=20 =2E=20 * $50 of extra usage: We=E2=80=99re giving $50 in extra usage=20 to current* Pro and Max users so you can try out the latest features in Cl= aude=20 Code and Claude apps. This will automatically be added to your account if y= ou=20 haveextra usage enabled=20 =2E=20 Read blog =20 Claude Opus 4.6 is now available in Claude Code. To learn more, check out = the=20 Claude Code docs=20 =2E * To be eligible, you need to be a Pro or Max subscriber before Wednesday, = Feb=20 4, 11:59pm PT. =20 =E2=80=8A This email was sent to pfeifferj@archlinux.ch. To opt out of future emails,= =20 clickunsubscribe=20 =2E Anthropic PBC, 548 Market St, PMB 90375, San Francisco, CA 94104 --ce0b5f3d365d57cd5bde3f6209cc8f2659389e847da67442ef769afe21ea Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" *{box-sizing:border-box}body{margin:0;padding:0}a[x-apple-data-detecto= rs]{color:inherit!important;text-decoration:inherit!important}#MessageViewB= ody a{color:inherit;text-decoration:none}p{line-height:inherit}.desktop_hid= e,.desktop_hide table{mso-hide:all;display:none;max-height:0;overflow:hidde= n}.image_block img+div{display:none}sub,sup{font-size:75%;line-height:0}@me= dia(max-width:620px){.desktop_hide table.icons-outer{display:inline-table!i= mportant}.image_block div.fullWidth{max-width:100%!important}.mobile_hide{d= isplay:none}.row-content{width:100%!important}.stack .column{width:100%;dis= play:block}.mobile_hide{min-height:0;max-height:0;max-width:0;overflow:hidd= en;font-size:0}.desktop_hide,.desktop_hide table{display:table!important;ma= x-height:none!important}.row-1 .column-1,.row-1 .column-1 .block-1.image_bl= ock td.pad,.row-5 .column-2,.row-6 .column-1{padding:0!important}.row-1 .co= lumn-1 .block-1.image_block .alignment div{margin:0 auto 0 0!important}.row= -2 .column-1 .block-1.text_block td.pad,.row-4 .column-1 .block-1.text_bloc= k td.pad{padding:20px 25px!important}.row-6 .column-1 .block-1.divider_bloc= k td.pad{padding:0 15px 5px!important}.row-6 .column-1 .block-1.divider_blo= ck .alignment table{display:inline-table}.row-5 .column-2 .block-1.icons_bl= ock td.pad{text-align:center!important;padding:5px 15px 10px!important}.row= -5 .column-1 .block-1.icons_block td.pad{padding:10px 15px 0!important}.row= -7 .column-1 .block-1.text_block td.pad{padding:10px 15px 20px!important}.r= ow-5 .column-1{padding:10px 0 0!important}.row-7 .column-1{padding:0 0 5px!= important}}Try our most intelligent model yet and e= njoy $50 in extra usage.
<= /table>

We're introducing Claude Opus 4.6=E2=80=94our most intellige= nt model yet, and the world=E2=80=99s best model for coding. We=E2=80=99re = also introducing agent teams, a new feature in preview for speeding up your= coding workflows.

 

Here= =E2=80=99s what=E2=80=99s launching on Claude Code:

  • Claude Opus 4.6: The latest version o= f our most intelligent model, and the world=E2=80=99s best model for coding= , enterprise agents, and professional work. Available now as the default mo= del in Claude Code.
  • Agent teams (research preview): Claude Code can now parallelize tasks across multiple agents that commun= icate peer-to-peer. Note that running multiple agents may increase token us= age proportionately. Agent teams are off by default and can be enabled in u= ser settings. Learn more.
  • $50 of = extra usage: We=E2=80=99re giving $50 in extra usage to current* Pro and Max users so you can try= out the latest features in Claude Code and Claude apps. This will automati= cally be added to your account if you have extra usage enabled.
=
Read blog

Claude Opus 4.6 is now avail= able in Claude Code. To learn more, check out the Claude Code docs.

 

* To be eli= gible, you need to be a Pro or Max subscriber before Wednesday, Feb 4, 11:5= 9pm PT.

=
<= /table>
=
3D"Anthropic
3D"X 3D"LinkedIn3D"YouTube
 <= /td>
<= tbody style=3D"box-sizing: border-box;">

This email was sent to pfeifferj@archlinux= =2Ech. To opt out of future emails, cl= ick unsub= scribe.

 

Anthropic PBC, = 548 Market St, PMB 90375, San Francisco, CA 94104

--ce0b5f3d365d57cd5bde3f6209cc8f2659389e847da67442ef769afe21ea-- From - Fri Feb 06 08:32:31 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id sMuPJlNOhWmA4DwAYBR5ng (envelope-from ); Fri, 06 Feb 2026 02:13:39 +0000 Return-path: Envelope-to: pfeifferj@archlinux.ch Delivery-datedJMnfwCCJ8T4H3hpGMH4YUP7pTSQby2vYVt0QQlO5d5vVYI6I2FugCDlzX7LJw9ZtRDj2h6K5uc+yzzJb0c52EWkSsFyEkcaXlgnrZLuALSk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=eprCYDNV; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7C26C116D0; Thu, 15 Jan 2026 17:49:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1768499354; bh=iF1iNor81klozqIxnmAo7xwx2Jz18hiLh6UZmLmUu/8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eprCYDNVwE454EXVclapgyYy15EjfZJp2O/zl5eL9U7p4Ve8/dMBVsGEIdh2KUrgv uSLo1Fp5D2iJB3SslifCpt0t3aFExwMKh/q0qjM9VfdO8H+X6iPKOc/G0amqxQYq1H 5xTQKyKxMKlWuYnd9AZNYOCVGGRLDKI07F1mjnAc= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, syzbot , Tetsuo Handa , Viacheslav Dubeyko , Sasha Levin Subject: [PATCH 5.10 164/451] hfsplus: Verify inode mode when loading from disk Date: Thu, 15 Jan 2026 17:46:05 +0100 Message-ID: <20260115164236.842271051@linuxfoundation.org> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260115164230.864985076@linuxfoundation.org> References: <20260115164230.864985076@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: syzkaller.appspot.com] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.234.253.10 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tetsuo Handa [ Upstream commit 005d4b0d33f6b4a23d382b7930f7a96b95b01f39 ] syzbot is reporting that S_IFMT bits of inode->i_mode can become bogus when the S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted. According to [1], the permissions field was treated as reserved in Mac OS 8 and 9. According to [2], the reserved field was explicitly initialized with 0, and that field must remain 0 as long as reserved. Therefore, when the "mode" field is not 0 (i.e. no longer reserved), the file must be S_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/ S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Link: https://developer.apple.com/library/archive/technotes/tn/tn1150.html#HFSPlusPermissions [1] Link: https://developer.apple.com/library/archive/technotes/tn/tn1150.html#ReservedAndPadFields [2] Signed-off-by: Tetsuo Handa Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/04ded9f9-73fb-496c-bfa5-89c4f5d1d7bb@I-love.SAKURA.ne.jp Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin --- fs/hfsplus/inode.c | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c index 7e1d889dcc07a..0ba324ee7dffb 100644 --- a/fs/hfsplus/inode.c +++ b/fs/hfsplus/inode.c @@ -178,13 +178,29 @@ const struct dentry_operations hfsplus_dentry_operations = { .d_compare = hfsplus_compare_dentry, }; -static void hfsplus_get_perms(struct inode *inode, - struct hfsplus_perm *perms, int dir) +static int hfsplus_get_perms(struct inode *inode, + struct hfsplus_perm *perms, int dir) { struct hfsplus_sb_info *sbi = HFSPLUS_SB(inode->i_sb); u16 mode; mode = be16_to_cpu(perms->mode); + if (dir) { + if (mode && !S_ISDIR(mode)) + goto bad_type; + } else if (mode) { + switch (mode & S_IFMT) { + case S_IFREG: + case S_IFLNK: + case S_IFCHR: + case S_IFBLK: + case S_IFIFO: + case S_IFSOCK: + break; + default: + goto bad_type; + } + } i_uid_write(inode, be32_to_cpu(perms->owner)); if ((test_bit(HFSPLUS_SB_UID, &sbi->flags)) || (!i_uid_read(inode) && !mode)) @@ -210,6 +226,10 @@ static void hfsplus_get_perms(struct inode *inode, inode->i_flags |= S_APPEND; else inode->i_flags &= ~S_APPEND; + return 0; +bad_type: + pr_err("invalid file type 0%04o for inode %lu\n", mode, inode->i_ino); + return -EIO; } static int hfsplus_file_open(struct inode *inode, struct file *file) @@ -504,7 +524,9 @@ int hfsplus_cat_read_inode(struct inode *inode, struct hfs_find_data *fd) } hfs_bnode_read(fd->bnode, &entry, fd->entryoffset, sizeof(struct hfsplus_cat_folder)); - hfsplus_get_perms(inode, &folder->permissions, 1); + res = hfsplus_get_perms(inode, &folder->permissions, 1); + if (res) + goto out; set_nlink(inode, 1); inode->i_size = 2 + be32_to_cpu(folder->valence); inode->i_atime = hfsp_mt2ut(folder->access_date); @@ -531,7 +553,9 @@ int hfsplus_cat_read_inode(struct inode *inode, struct hfs_find_data *fd) hfsplus_inode_read_fork(inode, HFSPLUS_IS_RSRC(inode) ? &file->rsrc_fork : &file->data_fork); - hfsplus_get_perms(inode, &file->permissions, 0); + res = hfsplus_get_perms(inode, &file->permissions, 0); + if (res) + goto out; set_nlink(inode, 1); if (S_ISREG(inode->i_mode)) { if (file->permissions.dev) -- 2.51.0 From - Thu Jan 15 18:37:16 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id qI9DOdczaWlQviEAYBR5ng (envelope-from ) for ; Thu, 15 Jan 2026 18:37:11 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Thu, 15 Jan 2026 18:37:12 +0000 Received: from sin.lore.kernel.org ([104.64.211.4]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vgSDX-00000009czj-1Ijb for hi@josie.lol; Thu, 15 Jan 2026 18:37:11 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sin.lore.kernel.org (Postfix) with ESMTP id 1E7213103E1F for ; Thu, 15 Jan 2026 17:41:13 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D6F3734216C; Thu, 15 Jan 2026 17:41:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="r7icK8O3" X-Original-To: stable@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B2CE43271F2; Thu, 15 Jan 2026 17:41:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768498867; cv=none; b=cbSe63BMONi1pt/XP/7auUFcxG3qQFxj4ukddZl0QU7d6KTmUS9sgNZIJHl5TzqglBpTmjyEp222U5M4mlnLaSyK3pN5i8uKf30pUSonZ+iwZqLmMVP6HPHwavqJ/f0cECjITucxUA+sVpmjujSXNbUY5t2A4yFjkJP9s66euS8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768498867; c=relaxed/simple; bh=QWuVjbbJWXbZ4AfqrC9/yu5E6CeaDGLbPeYVQUHjfl0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ms5iD7UewTg//e1h7woTG9WpO5nmlzID0Z3mvl7Lsk469qlu/JbYwovNg+2GH6kMzJBs/cnKFFS84aj3d/2z/M1SwdxYeyUsONZbGohMqSbdYeumbOmxDIrDaQUMV62Uy2aJv+xyUa1bvYhE6fR0VY6BbaFNp2lPj7zQkSYJJ8I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=r7icK8O3; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33D03C19422; Thu, 15 Jan 2026 17:41:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1768498867; bh=QWuVjbbJWXbZ4AfqrC9/yu5E6CeaDGLbPeYVQUHjfl0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r7icK8O3by6lbohCSN61JiomTMBDuZmk90QNbscwXLM415Amx5IbEaZ2NavLAk8kc 4ZOvPJaIbeqR6OOo2fXUwfIO3/l0Em9CF961ZIypFWCjM4lPihptulDV3AQhIBG1NY etxlUSu53TY+HHQU7zAqyIpfVrQIBCh+c25+ekwk= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Navaneeth K , stable Subject: [PATCH 5.10 027/451] staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing Date: Thu, 15 Jan 2026 17:43:48 +0100 Message-ID: <20260115164231.874871687@linuxfoundation.org> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260115164230.864985076@linuxfoundation.org> References: <20260115164230.864985076@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linuxfoundation.org] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [104.64.211.4 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Navaneeth K commit 6ef0e1c10455927867cac8f0ed6b49f328f8cf95 upstream. The Supported Rates IE length from an incoming Association Request frame was used directly as the memcpy() length when copying into a fixed-size 16-byte stack buffer (supportRate). A malicious station can advertise an IE length larger than 16 bytes, causing a stack buffer overflow. Clamp ie_len to the buffer size before copying the Supported Rates IE, and correct the bounds check when merging Extended Supported Rates to prevent a second potential overflow. This prevents kernel stack corruption triggered by malformed association requests. Signed-off-by: Navaneeth K Cc: stable Signed-off-by: Greg Kroah-Hartman --- drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c +++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c @@ -1281,6 +1281,9 @@ unsigned int OnAssocReq(struct adapter * status = _STATS_FAILURE_; goto OnAssocReqFail; } else { + if (ie_len > sizeof(supportRate)) + ie_len = sizeof(supportRate); + memcpy(supportRate, p+2, ie_len); supportRateNum = ie_len; @@ -1288,7 +1291,7 @@ unsigned int OnAssocReq(struct adapter * pkt_len - WLAN_HDR_A3_LEN - ie_offset); if (p != NULL) { - if (supportRateNum <= sizeof(supportRate)) { + if (supportRateNum + ie_len <= sizeof(supportRate)) { memcpy(supportRate+supportRateNum, p+2, ie_len); supportRateNum += ie_len; } From - Thu Jan 15 18:37:28 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id cJsND+MzaWlQviEAYBR5ng (envelope-from ) for ; Thu, 15 Jan 2026 18:37:23 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Thu, 15 Jan 2026 18:37:23 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vgSDj-00000009dNg-0Are for hi@josie.lol; Thu, 15 Jan 2026 18:37:23 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 11C6230DD2AF for ; Thu, 15 Jan 2026 18:19:31 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2D7FE2D663D; Thu, 15 Jan 2026 18:19:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="dh+9WMVl"; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="QdYvF4zM" X-Original-To: stable@vger.kernel.org Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87E761EF09B; Thu, 15 Jan 2026 18:19:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.177.32 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768501169; cv=fail; b=bJEQDzAQY4H/z6dgLfny69WU5F73IM0AYh5WRtuZwqYhKeIHHYgtbLooFa7rFKPIvRInevz+++LpMLsGO73LpgC9Lt6mwf/OgXDJTUeZHzgMbURwBoSQG7s0HRrxURE6jYkc6AfY5mFpxzX8YvJ/ZTtD46i3rHlV3GodD5shTek= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768501169; c=relaxed/simple; bh=sAc6nrp2Krft0Yz9BGx8pNUewIDd8KRK+wni/gvA4I4=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=neOgwkpxfmoTADNXvHfjGVR2s3kzYUSlrssvz2re+mpywlAz8wXJxVE4xMZ6pPsycVZHzBmUFQowPZifCuSE5Vvbdnz6E2Cj+89EZ5wIVDj6D/EgttPkqg6nYej0dds+1U427wTeusWtFyto3UowzpFP4EupWLTit1ENT0tsXZ8= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=dh+9WMVl; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=QdYvF4zM; arc=fail smtp.client-ip=205.220.177.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 60FDbUNA1940280; Thu, 15 Jan 2026 18:17:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2025-04-25; bh=4I658GVqVGijdfXqpBuwyJV3eb5kWGgJndL45PvSAnU=; b= dh+9WMVlhTmLdLzs+3EUkuwSVPjRF/JIsbjBsfghoeH2QD7BamqzyujtwFLl3nP9 xRqwISLHHIVeeMSoIkiHZG5nQY3wZVmryoULmur2XGRUC3dXMg/xsOR72Hh5LVo0 uX/f0XVhtqhtSspyxqkNAmHRSPXAtjFfaMiR21Rt3hgLxctN0KJOkL/hCgXXN66J J76eG63T0a3Bu0/3EjtZPD5aqTOWFguL65W+m1ivn7VRmFye87Wq8vZhLI0XRYwY EFC3aDx2I0XV8z9AB0h+Ov3FBKdR1LCmG4yzOJOW57GDGb0ceWwA9vDBCYh3sb7Y tfJxHVWHbsIZlzzxdGa5Jw== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4bp5p3brts-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 Jan 2026 18:17:48 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 60FHTDB2040477; Thu, 15 Jan 2026 18:17:47 GMT Received: from cy7pr03cu001.outbound.protection.outlook.com (mail-westcentralusazon11010004.outbound.protection.outlook.com [40.93.198.4]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 4bkd7fdw23-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 Jan 2026 18:17:47 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LgJpTKKMLR4OXIWWnkpFuq+HTFVjIv3oCGSde/xkz8PBSBIQAzVcZPrn2TBU/WH/BJ3sWC8ZfM+nJuxxMvCy1+VW96Fu7lX5/56/V7LcpGMFHxe/kULTPbBsX6Jb6VluTvWTsRV/jauy/Tc6QbKtt9QHEkw6+fBzn89+Aisedc4f3OBFU8ZlGhv9G+bh/hrKuozd7eQTY+YQ9lCv9WCgRQlwih7GqYdG96/jg2g08I1TtqhCTaOjYvNegLZTWY89Lem8SjcddNviGaA7LApjYvUrfwf7Hue88gjjpG29+KjV/l8o+PkUhmrcXABiiHGKTZ5hpDxoqYKr3s0FCsvrNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4I658GVqVGijdfXqpBuwyJV3eb5kWGgJndL45PvSAnU=; b=pKijXnnY+zLeKWIRS/q1YSjDd1IWc6XDElgUcr4kvsi911xX+BHdkuteXsr3/i91gb1M0sNY+cyo40nPuJ1RS0X0TDAw0rI+w3ITXaOG04nd6cPR53BlbQyZZLq7LClhxT/6seoEcQIHPFiU13epkmpDKlxPe0JaRPcYVkpFIGIjZ8wQhWwdXYC88l5tMU2j7ewr4V7QoTHy2aAR+7qUAQ/mY8LknrRRa6ImwB2aRTIYxz2sx/9+MDXkddkHStULmN2H6hPtvj7cWWG/pUgQVmPZoyHDPABSvKKIWJaCrIA4jy+XeqG87JUALWCmnoaSXzuFubU314xg7sLBbQu8YA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4I658GVqVGijdfXqpBuwyJV3eb5kWGgJndL45PvSAnU=; b=QdYvF4zM2Fo3yorvNCEqwnQVOeHWyLs2BMhLi/b4bZGjdR+KF1WErnvNQNreElXbxHrSg4PkvOA554PzhI1hB/gotz6LTYvwNZhG8c05L8NYTUAOTNih25JP3LZmExP2nUT6LWi+t5RpSyvEQPUifYRezQfIdzQH7r8/oC2QEgg= Received: from DS0PR10MB7364.namprd10.prod.outlook.com (2603:10b6:8:fe::6) by DS0PR10MB6149.namprd10.prod.outlook.com (2603:10b6:8:c7::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Thu, 15 Jan 2026 18:17:43 +0000 Received: from DS0PR10MB7364.namprd10.prod.outlook.com ([fe80::a4df:c903:e1aa:322f]) by DS0PR10MB7364.namprd10.prod.outlook.com ([fe80::a4df:c903:e1aa:322f%5]) with mapi id 15.20.9520.005; Thu, 15 Jan 2026 18:17:43 +0000 Message-ID: Date: Thu, 15 Jan 2026 10:17:38 -0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/2] mm/memory-failure: teach kill_accessing_process to accept hugetlb tail page pfn To: Miaohe Lin Cc: linux-mm@kvack.org, stable@vger.kernel.org, muchun.song@linux.dev, osalvador@suse.de, david@kernel.org, jiaqiyan@google.com, william.roche@oracle.com, rientjes@google.com, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com, Liam.Howlett@Oracle.com, rppt@kernel.org, surenb@google.com, mhocko@suse.com, willy@infradead.org, clm@meta.com, linux-kernel References: <20260114213721.2295844-1-jane.chu@oracle.com> <20260114213721.2295844-2-jane.chu@oracle.com> Content-Language: en-US From: jane.chu@oracle.com In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PH7P223CA0017.NAMP223.PROD.OUTLOOK.COM (2603:10b6:510:338::10) To DS0PR10MB7364.namprd10.prod.outlook.com (2603:10b6:8:fe::6) Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR10MB7364:EE_|DS0PR10MB6149:EE_ X-MS-Office365-Filtering-Correlation-Id: 35ab965a-6a28-4ac8-3f73-08de54626044 X-LD-Processed: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|7416014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?SFRVZS91OVBCS2dON1FTV2c3VTVQVHZjR1RFK21NRlFXdzhLYzRPZ3h6NHc4?= =?utf-8?B?VmhITW41blJmcXlYRXZzVTk2cTFhWW8zd2I3UTJIWGNBZWNzRUVId0k1Rm1n?= =?utf-8?B?aktQazR3OE1PZVloMHpzM29mS1VFaER1YThOVFVRSGtESndRb2lXbXhPckRD?= =?utf-8?B?RThscFRtTFFaRkMzd2s4dm9kRkhhNEtIUlZ6TzQ5b01DUWpvVG1SUTlZLytZ?= =?utf-8?B?SWJ3eEJLcy9PUDRzWXgxS04rU3FNTjlRY0ZVV1BsbWhGNDZjTWw1VXpzdDVw?= =?utf-8?B?eWRmN3UySlhIaGM3b0k2cTlkNnFZNFdaZmdQVS90QnE3b29OYnNDbno0dDdz?= =?utf-8?B?Z0xuT0w5U2Y0VmZQcDRUL2NPRUo3N2d0K2ZPTFJPWEtTcmFmaWNHbTRyZWxJ?= =?utf-8?B?Sm1rQi9YK1lxbFpVUS9OQW1yYUYwSkd6L211d00zdENRR2lHY2Q1cGJTVnVF?= =?utf-8?B?NDZON3prQktMZFo1VE5DSzRPNmgxbE5iUWM0RFFBcW9YajVtdVo5VG1ZR211?= =?utf-8?B?R3R3NllSK3gxM3BHQTYyNFdkV0puRVdMWnZXeFpkL0FrRTNidEc5Lzg5bDFE?= =?utf-8?B?dFE4MjEzTVJzaklKTWVxV01zNkM5Q3BGTVlkR2wvbDJJaWFtWFpHV3pJcjgr?= =?utf-8?B?NmttM0pqZW85YzBCclo3QWRGT0cvcitLL09Mb2IrbHQ4aEoyaHR0ZnF4YWtU?= =?utf-8?B?akNZMG5iTmk5OXUwNy9Gd3VIUzRLdlRWTGRpVDZpd0RPNDM3M082VTFCcTlo?= =?utf-8?B?N1RkSHRsT21uTlRvMTdwMUtUaExnM3RtMzE0bUFFM1R1d3BMK1dKQlEwdzRK?= =?utf-8?B?Q1h3a3dpZ1Jpek5JTitKY0s2T0dneVB1WUtMN05UZGxGSEpybldBeVYzcGRv?= =?utf-8?B?VnNhcXpGNThjN01UdWN3NDB0ZHRPMXlWbUx5M0t2aHdKYVFYVHozV2h5TTFy?= =?utf-8?B?VCtyQ3Y2c3htMUdnQmhnVjRPUmtWbEVqRGJzVmZsMWNnc3BORnVNV2J0VkdW?= =?utf-8?B?VWFZenFFakZRNjJhNG8yekY4d09nOHI4RG5RelViaWtoUHN3NjFMOFR2dVBW?= =?utf-8?B?TG4vWGlVWkp2eHd3YzlPQkp6MXRPamxhZVN5SGEzQkxDUjYrWXdHL243UEd0?= =?utf-8?B?MWZiY1FVdHBYOExjUS9qM3VFS0VwNkcxMXJndEtUVmJlMkNDa3lVaVZCbmdu?= =?utf-8?B?NnZzUFlTbzdZa2ZCZGVrWVFGZWdoa0dXa05DM2crN3RUT0xoTjB0MUpNYTVH?= =?utf-8?B?MXREbEhZcW0xdVNwNEdNbFFFSlVGY0traVF3Z21vTHRrNTdIQ05VcmlkTSt5?= =?utf-8?B?RUtlRVJUTEIvNkJ6aUduaW5GaGFYUXp3NUJtc3d0WVEzUng5K1dGVVVTRlVX?= =?utf-8?B?dGdEbjZ1dzNQVXBmaFQxbnFnQ3E1SUYrOExMQ0hhb3QyQUQwcVVybStja0hR?= =?utf-8?B?WEFNd1NzNFdGYi94ZUxRQzFubmZlYTVDenRuTGlha2ppZlI4SnU0eXJuMVNM?= =?utf-8?B?Smwxb2hVb3ZZcDJWWkg5b1pRNGg1Ui9sSEpKQnBteGZRNEtVblFXK0FDTVlw?= =?utf-8?B?dWJwbzlLWXlVYktFNmRDQzllWGVwQmxiMlV1MlkrUkg5MVYvWDJsbG00a293?= =?utf-8?B?NWV4RzFHU3RUK1ZadlJIR3JNQnFEYlU1bnRjbTE3dzFJSTdtcjJ6MWQxbkcv?= =?utf-8?B?WkpSVVdDd3kxOTNYRXJpT3lPOFpNSko5ZmdSYWRJWWZ4WWtTU2JoZEVydUlD?= =?utf-8?B?LzRFbjFlZitoRGp1Zk9jWENBSTJkaVRoVDcvdFh4eFR1N0Z0b1FtbEV0b2h2?= =?utf-8?B?eW1qeitMdzVkOXowSGNJbEIvKzJMS3N2cWFqMDE3WkdsRndLK2tidWxKbkhk?= =?utf-8?B?cmVXK3ZEMXJiQ2Rzd2ZXTzlhZEpGaUNxRUxqenduOUQ4NzlPSVc3N2NWQUlz?= =?utf-8?B?bkF1elZtRTJUZG1ENytjc2g0Q2QwbFRnWlpPUkZLZ2RaNkw5eDBEeFd3T1JI?= =?utf-8?B?enJid1BZTHpVSW05ZUcwUHpPYXhqcjNDNHNRZkJXMXZRbTl3T2I5ZTEzdjQy?= =?utf-8?B?cmZBYkVJbFZSVW4zOTBUY1U0RXdSSTV0NEpjVHo3UElIblovZGxXeTdzODF4?= =?utf-8?Q?yPzxq3jgUN3pinmy7z3uiIIYx?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR10MB7364.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(7416014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q0VyVG1oWWZOL2o5dXBiM3YwUlVWak50UElKcXJmYU1DT3MvNW03cmtPTUd1?= =?utf-8?B?dEhHTWJ5UmswMzA1bmhSa0ZzaFR6S045V0pLUkx6WEU1L3g3cDNBMFZmdlVj?= =?utf-8?B?QTJUdzlUZzBZaG1XeGozeDJ6UDFvZm5vSTJnQ1dJRG9zQ0pKSHR4dXBmQS9t?= =?utf-8?B?VWNydkNoelJqZ25mRjZEZ2wwaUI2czNrRGxLYTZJeXorMUJBV0hRK1d0VDZO?= =?utf-8?B?Qmp3NzdnYVhYSm1yaGIxMWhrTEhJRWxNTzR5ZWE1TmlwOW12b3R4UGJKc2JS?= =?utf-8?B?QUs0MlhNK3VOWXcvNjhENkpaUGNRYWRzTVZSQmpvU2RXQ1JKZStyYmJmWlBJ?= =?utf-8?B?N3VvazdEU1U4V3c3bERDOERZYjJxTzZyd0hKRCtYTDc0Q0RjdkthRkRzVGVz?= =?utf-8?B?NTUyRFk5RGJQbXdTZDRvY0trNmdWclRETDZzU3p3V1NoL2ZHQVV6NWR1NHdL?= =?utf-8?B?RlpyM2pYa3FYdkp5SUtaTFJFN1g0MEQvWG8wQ0l1ZHlJOUliTS9OTmxIazR2?= =?utf-8?B?MmFKVEpJRzZEekJTUzAzQVpoSHcwVC93bTdwUVVzS3dEY3hSTDBlWlBJcVow?= =?utf-8?B?RW9aM3FOWFhadjkrMW5WVHBnTDkzWHBqMmJHNWl6Qk45T3JOeTdoNUlVK2tu?= =?utf-8?B?TDVJOVF5SzRDRnM4UUZXcURzbFRVS3hTRXZVYzFFK3JLREZwdnEzdXpFVXZr?= =?utf-8?B?Q29YVW1NSjFnQ0pNR2JJNmJMR1ErM3NwQW9DNmMxeUFBSXE2dmtYUnpjL281?= =?utf-8?B?QjBqZzdCb1U3RW5hMlFORWEzaGRhbFlJRm9wOElDV1V6V1NVU1l3SnAyWWRS?= =?utf-8?B?TWQrMGdjbFhKV2VvTndMOFpocUd6QVF6YTF3UkdyQ3pLQmNreThsTEhPVkFq?= =?utf-8?B?VkJSRDQ2WEJQbFpLTDBDaEM3TEFTY0hZbjVwL3NqbnVJV2QzSTNNaGhmWlMz?= =?utf-8?B?eDBuT1hGZERXMlF1dmxzT3Y4b3l5K3hVL2p2TU43bEpIb3dkQlY5aHBoNmpY?= =?utf-8?B?L0p0Z3B1bzdDY2lOV2JNa0xzblJXNUpRbHZEaGM5RWdjaTNiRk9CbDNRK3Z0?= =?utf-8?B?UzlmV3J2bkV5SDhmSWFvUEt4RHJSNlJwcXFPSlN1bjJ6ZmhSQ1plRGxlVmpF?= =?utf-8?B?NUtDMk1UUDQ1QkxuaGt1dktWSklDUmpDTkRTSHpGekxZa3BBRzVWQVRranli?= =?utf-8?B?TE5hRm9QbjNnbVNmeDNLSEhhbkFTamdUL1QrNHRub1pmT3EzUmwyRVYvcU8v?= =?utf-8?B?QlhkUGFUanNmTEd0eGJaeWNFVzZKSS85c1N5dmJpQVJHTzVjZVdZdTJKVG5U?= =?utf-8?B?UTNkanpiUEZkTE5Ea2FSdFA4QTZ6MVliTS9HbTlWN0dJRGJ4VmJ5MG12UmND?= =?utf-8?B?V0xtVEo1bTlma1dZbG1TM1lROUtJN09BYzI4aWJqaVpwcHRJdTJFdUIreFhT?= =?utf-8?B?aVBBNS9odmhkSkNrY1NRL0xjREtrc3BOY1g5Mm83RDhaLzFGRnlYQVNwem9U?= =?utf-8?B?ajVGZXNmQUxiSkMrQ2lWR0hPUFdkbGVJazdCWUs5eDFDL2tPNmJ4cW1CYnNR?= =?utf-8?B?ZDBGcldRa05Kbm1ldEhpd3BWejU4czZYbjBmUk1kTVlIOG1MOGcrVUFSaHhU?= =?utf-8?B?NjcxRlFYWXVyaEZCOUR4dW5GMm1nSVBJYmpDQUZNVmxFT1RodGppa1VDVWo5?= =?utf-8?B?c2RnZ0lLOWkwUnFjN1JjNmFQbm9vZXJoYnpNQ09wR0pkc1NDMDdlZkJUK0Jo?= =?utf-8?B?MVJMZG1GSHdwSlQvZ0VaUk51bWQxK0pyM1A5VGtKYVVoRnhVL0xMeFlXNW9O?= =?utf-8?B?ZXZZODF4cGxOeU9GaGgyOUQwenozOTIrVkd1MEJid3Fra2pOUTQyWmVhZDFi?= =?utf-8?B?SGFyUjJSbHd2S0JoZzZBVnROTzhNNEdOUGw0MUFqMkdVNmJDbDcwYXZ6eDhx?= =?utf-8?B?T1ZzQjN2WW9BaVh5RnVVc0RXTUxtSG02N1ZBTlp1YXRuaGQxVDNmMmZsdGND?= =?utf-8?B?TWtNazh4dnc4U0RVS1lpSHl2SlFCWE1yMEk0VlQ1SGtnZ3J2UDdsZnNHK3Bk?= =?utf-8?B?VXVGVzV6bTR2ZDRQeVI5U3BPa2YxcDVMYUpNY1hidXdVM2Ywc1o0MDdjNnVv?= =?utf-8?B?dUJCTllIS29mUVNrcWhvcGhQOHBoZ0NFd3Fpb1Y2L1VQbjluTlAyZUI2SFd6?= =?utf-8?B?SDdZc3hpaDBVYkVoMjZkM1hJSGFTTVNNOUtHcEllSC9CVFRYWUk0OXZ5N2Vl?= =?utf-8?B?VDdSUXNCckVLVmxuakg3SkhETDBuV040RldLa0ZIT0hOWTdjeVVBWU9TUnBk?= =?utf-8?B?OVJmSHFobHJCNkNMcENIV1FDZitTamZjQVFLbTBWZ3kzSkNZOEZXQT09?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: rrhOSXGJpkK0SW936407/81quqBqR1TnOg/gRIqaVHRXq/qRwUB5cnhOrH+dOU27Q37qdRLlUtrISn4ZqtN7zVUzkKjRA0TY4rc3JCXJF9fEiMSdiIxwWT1PxArawVosDuQtTOXAExgg/nbehEEcbOiKpeljaGmDHSZLLmuinYroKvC9UXCrr3fWGSCVrOBdiMyxBfJRQtWKqEzhj3BKoDnEmypX2D7hJlycI/T6kmTXUkj582CzcyeL2S2j+CoeO89TYyXE2Gaqrpc+4N++uDTfMkiov6wW4azXLDa0IdtokkkUMUdh+N3ncJuH5o4Z1KpUMQ/Oh2hQiwe+dLZDVAjWVkHeQzqY/PnqWC8vti2TZ324iAMN8xURHg5RVWXKRTpDi5cVQ/5kOdses/w6VOEEPThLgS+xhw68MzOrT0s3IIcQfp9/lXiin2hiBjdpwVcuQxN75crZvHmkQ0Zj4bAzJj6Dr5O24KSH/2qIkZ4flslXL218VbzUAyaqxNG3qPDUNxMpNVg9LjsGLiVGQPk9iz3vxMvLluHCtXOgZ8+R9IS1xsCJykzFpQFA8/7HnrxZAydfjEmpOLvcR66UJuNc5CtjQkmmZvYhjbi9XD4= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35ab965a-6a28-4ac8-3f73-08de54626044 X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7364.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 18:17:43.3252 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: m0yP8tvelvR+GcTidi+2Gj/zklIuM65C99G29PcW2494ohLpBWuB03Z/JHE56fNJzzTOCAt2qkZIh3JBZr48aQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB6149 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2026-01-15_05,2026-01-15_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 bulkscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2512120000 definitions=main-2601150140 X-Authority-Analysis: v=2.4 cv=OJUqHCaB c=1 sm=1 tr=0 ts=69692f4c b=1 cx=c_pps a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=GoEa3M9JfhUA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=JfrnYn6hAAAA:8 a=yPCof4ZbAAAA:8 a=1XWaLZrsAAAA:8 a=i0EeH86SAAAA:8 a=5Zckf8guCu-V8f7WwOkA:9 a=QEXdDO2ut3YA:10 a=1CNFftbPRP8L7MoqJWF3:22 cc=ntf awl=host:13654 X-Proofpoint-ORIG-GUID: 26mo57bWZ3dBI726lAnEgy4HQ0nHnaoG X-Proofpoint-GUID: 26mo57bWZ3dBI726lAnEgy4HQ0nHnaoG X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTE1MDE0MSBTYWx0ZWRfX+RxkaSAHTQEr T2W6w5XCApZmgg45fCKoaDnouWxeKoLSIXkYOYS2JSJzneun+CQ6jj6cUn59L5r/UxkZQD8jDsT PlMOWEqnLv4pcM2scvALdz+0rNFT2lawYT1BAsDAJC/2U/qSoZEMNgXoD07rn+JMWnMUt3Wi6LF MDcbqSPMPazzLxfw8ad0zf4P15HU2y0m+e4OE6BjdZHn5G8ZzcixB5TEadgTEkgGqGPEN1l2rXF KqaIbGC08iVopuAVzTyUXbaQ6d7OE9AWwCTCMUbec6unCmd3UF1zf6pCH65WaWVH+2rsWvxrR9T evHeNSGeVdmpOZWqrfEKTWdvWcW5+68KmEjuc2NlcZQM0NvjdkVU/1FMBPUU5pJiOsm0xFgpB7t uZCVaP4Hv3Ru6tbZE/5kE5GArbTOc2j2FCQy7G722c/HHhRg5D51PmBa5eVaM/8JF4JqyWZq3wA HDUxL8sj17jvxZtMv022Dp+9jWpS9YrXlBRDi63c= X-DKIM: signer='oracle.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-DKIM: signer='oracle.onmicrosoft.com' status='pass' reason='' X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 On 1/14/2026 11:36 PM, Miaohe Lin wrote: > On 2026/1/15 5:37, Jane Chu wrote: >> When a hugetlb folio is being poisoned again, try_memory_failure_hugetlb() >> passed head pfn to kill_accessing_process(), that is not right. >> The precise pfn of the poisoned page should be used in order to >> determine the precise vaddr as the SIGBUS payload. >> >> This issue has already been taken care of in the normal path, that is, >> hwpoison_user_mappings(), see [1][2]. Further more, for [3] to work >> correctly in the hugetlb repoisoning case, it's essential to inform >> VM the precise poisoned page, not the head page. >> >> [1] https://lkml.kernel.org/r/20231218135837.3310403-1-willy@infradead.org >> [2] https://lkml.kernel.org/r/20250224211445.2663312-1-jane.chu@oracle.com >> [3] https://lore.kernel.org/lkml/20251116013223.1557158-1-jiaqiyan@google.com/ >> >> Cc: >> Signed-off-by: Jane Chu >> Reviewed-by: Liam R. Howlett >> --- >> v5, v4: No change. >> v2 -> v3: >> incorporated suggestions from Miaohe and Matthew. >> v1 -> v2: >> pickup R-B, add stable to cc list. >> --- >> mm/memory-failure.c | 14 ++++++++------ >> 1 file changed, 8 insertions(+), 6 deletions(-) >> >> diff --git a/mm/memory-failure.c b/mm/memory-failure.c >> index 2563718c34c6..f6b806499caa 100644 >> --- a/mm/memory-failure.c >> +++ b/mm/memory-failure.c >> @@ -692,6 +692,8 @@ static int check_hwpoisoned_entry(pte_t pte, unsigned long addr, short shift, >> unsigned long poisoned_pfn, struct to_kill *tk) >> { >> unsigned long pfn = 0; >> + unsigned long hwpoison_vaddr; >> + unsigned long mask; >> >> if (pte_present(pte)) { >> pfn = pte_pfn(pte); >> @@ -702,10 +704,12 @@ static int check_hwpoisoned_entry(pte_t pte, unsigned long addr, short shift, >> pfn = softleaf_to_pfn(entry); >> } >> >> - if (!pfn || pfn != poisoned_pfn) >> + mask = ~((1UL << (shift - PAGE_SHIFT)) - 1); >> + if (!pfn || ((pfn & mask) != (poisoned_pfn & mask))) >> return 0; > > Nit: Maybe "(!pfn || pfn != (poisoned_pfn & mask))" is enough? That's nicer. > > Acked-by: Miaohe Lin Thanks! -jane > > Thanks. > . > From - Thu Jan 15 18:37:54 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id kLIAK/szaWnDJB8AYBR5ng (envelope-from ) for ; Thu, 15 Jan 2026 18:37:47 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Thu, 15 Jan 2026 18:37:47 +0000 Received: from sin.lore.kernel.org ([104.64.211.4]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vgSE7-00000009e35-0H2v for hi@josie.lol; Thu, 15 Jan 2026 18:37:47 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sin.lore.kernel.org (Postfix) with ESMTP id 5EBA630397F5 for ; Thu, 15 Jan 2026 17:41:58 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 993693BBA0F; Thu, 15 Jan 2026 17:41:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="G9lWhkJD" X-Original-To: stable@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 748173A35D9; Thu, 15 Jan 2026 17:41:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768498910; cv=none; b=A3nq2lpJt5pYMBG78WP1dCOelKjN75fe4HMCj17ZaB1DgQHqkGa2s523BvadnHR6mkhBZQAY3rdcQLZP+re+uoO5b+ZVeylwRV8NKrrOJyjiArsy7ulAkh4WV44YVdnuVAGvre+dloYdmaIBFg4kTVjByWMcRQRoJcQb5FoO7KU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768498910; c=relaxed/simple; bh=mhF6ylQVaa3cnXRefkNYgtWIFF/IpLlIrbmwnopMbT8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l5LpnX74FkTvBRUOq8LzTi+JjtihqPWqiWKvcjL1yoNLKHSuAdXtOwV4V5zk3G61NhFdye+A+59OcvvtKv1w9/HlDifAXoB/5wGUbt9p1l3s6cTpy1nueD+azKmbsISi1QQnfYxKQFnKnz5USlS3QVxRrqrL++l+TzUW3n6RqEg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=G9lWhkJD; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00100C16AAE; Thu, 15 Jan 2026 17:41:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1768498910; bh=mhF6ylQVaa3cnXRefkNYgtWIFF/IpLlIrbmwnopMbT8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=G9lWhkJDgUM67zD5vL7QcrLMWpoZfoRwFSBmxvzOjlGL1IUgt+IBRmn/CDWrReTRO /SraRm2m25OTKiUdeziF6vUCZxayICnBn334yhikQ6OTkqLv5pn5+SCQHcDWQ43RWn pj/DprtVqaCZn81pxP9udM08OhfUnbug4vYKc5HM= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Frank Li , Peng Fan , Shawn Guo , Sasha Levin Subject: [PATCH 5.10 041/451] firmware: imx: scu-irq: fix OF node leak in Date: Thu, 15 Jan 2026 17:44:02 +0100 Message-ID: <20260115164232.378532575@linuxfoundation.org> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260115164230.864985076@linuxfoundation.org> Reer.kernel.org> Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id GFjwDTNTamnbpTYAYBR5ng (envelope-from ) for ; Fri, 16 Jan 2026 15:03:15 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Fri, 16 Jan 2026 15:03:15 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vglM2-0000000FPkq-2Mch for hi@josie.lol; Fri, 16 Jan 2026 15:03:15 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id D8421324576B for ; Fri, 16 Jan 2026 14:48:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EC31E346E4E; Fri, 16 Jan 2026 14:47:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="pOm744By" X-Original-To: stable@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BAEB723EA85; Fri, 16 Jan 2026 14:47:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768574865; cv=none; b=gASRSgqvB9E5YzPd+4cz8EbxOynw14yH3LRLV4/d1+GUUINQXPkxRRJu5OelcouMlcvCbAzo5oB10lRGOxxxKOWaQv+vsqaxGFuuvtr1RQnUYOdjrdLqj3AsMLfcSFR3b5oA26dMGeNwuP41DOy6pVMSRyBN9dAqjTj/fQfE58I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768574865; c=relaxed/simple; bh=NmY6f/3++srymFtkQFv5iqmHppCm9HzuPAroq8sLV+0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rOTsqSCVIv+avP+ngphiEW822CmW1qppUclWA9Ecezk6XVKk9r3/PGZgRWsy2xoT2Z7Vm9snQmUZpdCSJLQhz+uO9NJyOvqdrRnuHX/yN+2D2eAb6LJDwT7xgOr/cLMDan4zJg75m1X9yGWyudGAuKabqPKGvNGubkmJhwfT7LU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=pOm744By; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09282C116C6; Fri, 16 Jan 2026 14:47:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1768574865; bh=NmY6f/3++srymFtkQFv5iqmHppCm9HzuPAroq8sLV+0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pOm744ByqRtqzwg0ncDID5yzmiFLYAyfuZQnFxz1nUOfRZyNZpG74HHT07eF7XE4n 7txNc0cHhHmobnzxhK21mhoXFsVYN04TNz0MtNeftlGzBDJWxjRVdcN7NFCZhKg5QL krSGx/52Mki3qjBaCiRe6opdag4NRJ8RYTxEL/VE= Date: Fri, 16 Jan 2026 15:47:42 +0100 From: Greg KH To: Xingjing Deng Cc: srini@kernel.org, amahesh@qti.qualcomm.com, arnd@arndb.de, dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Xingjing Deng , stable@vger.kernel.org Subject: Re: [PATCH v4] misc: fastrpc: check qcom_scm_assign_mem() return in rpmsg_probe Message-ID: <2026011637-statute-showy-2c3f@gregkh> References: <20260113143445.889031-1-xjdeng@buaa.edu.cn> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260113143445.889031-1-xjdeng@buaa.edu.cn> X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linuxfoundation.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 On Tue, Jan 13, 2026 at 10:34:45PM +0800, Xingjing Deng wrote: > In the SDSP probe path, qcom_scm_assign_mem() is used to assign the > reserved memory to the configured VMIDs, but its return value was not > checked. > > Fail the probe if the SCM call fails to avoid continuing with an > unexpected/incorrect memory permission configuration > > Fixes: c3c0363bc72d4 ("misc: fastrpc: support complete DMA pool access to the DSP") > Cc: stable@vger.kernel.org # 6.11-rc1 > Signed-off-by: Xingjing Deng > > --- > > v4: > - Format the indentation > - Link to v3: https://lore.kernel.org/linux-arm-msm/20260113084352.72itrloj5w7qb5o3@hu-mojha-hyd.qualcomm.com/T/#t > > v3: > - Add missing linux-kernel@vger.kernel.org to cc list. > - Standarlize changelog placement/format. > - Link to v2: https://lore.kernel.org/linux-arm-msm/20260113063618.e2ke47gy3hnfi67e@hu-mojha-hyd.qualcomm.com/T/#t > > v2: > - Add Fixes: and Cc: stable tags. > - Link to v1: https://lore.kernel.org/linux-arm-msm/20260113022550.4029635-1-xjdeng@buaa.edu.cn/T/#u > > Signed-off-by: Xingjing Deng > --- > drivers/misc/fastrpc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c > index cbb12db110b3..9c41b51d80ee 100644 > --- a/drivers/misc/fastrpc.c > +++ b/drivers/misc/fastrpc.c > @@ -2339,10 +2339,10 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev) > src_perms = BIT(QCOM_SCM_VMID_HLOS); > > err = qcom_scm_assign_mem(res.start, resource_size(&res), &src_perms, > - data->vmperms, data->vmcount); > + data->vmperms, data->vmcount); I'm all for coding style cleanups, but don't mix that into a patch that does something else. Also, please indent this properly, checkpatch should complain about this. > if (err) { > dev_err(rdev, "Failed to assign memory phys 0x%llx size 0x%llx err %d", > - res.start, resource_size(&res), err); > + res.start, resource_size(&res), err); Same here, that's not right. And I don't see the real change here, are you sure you generated this properly? This just looks like coding style cleanups, which do not match the changelog text. thanks, greg k-h From - Fri Jan 16 15:03:50 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id mHGMN1FTamloKzYAYBR5ng (envelope-from ) for ; Fri, 16 Jan 2026 15:03:45 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Fri, 16 Jan 2026 15:03:46 +0000 Received: from sin.lore.kernel.org ([104.64.211.4]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vglMW-0000000FQfY-3nqf for hi@josie.lol; Fri, 16 Jan 2026 15:03:45 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sin.lore.kernel.org (Postfix) with ESMTP id 9C46530366A1 for ; Fri, 16 Jan 2026 14:57:28 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4A4FF396B79; Fri, 16 Jan 2026 14:57:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b="J7Av3Jbg" X-Original-To: linux-s390@vger.kernel.org Received: from fra-out-014.esa.eu-central-1.outbound.mail-perimeter.amazon.com (fra-out-014.esa.eu-central-1.outbound.mail-perimeter.amazon.com [18.199.210.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2FDAE2FFDF8; Fri, 16 Jan 2026 14:57:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.199.210.3 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768575436; cv=none; b=Lj5Qq0jYxTksCPjPhYK9pkR8iDQo48dYgKdz/LYQ4JVl7ztDWesyhzmOsiIrhdjbj/qeC7Eb7rkHpV7scyBrX6hCNHFJu9JhWsWv+A8bYtbMUkPnbhPbWj9Ozgn7xgMXeWNWmmlkzh1optpOZE320/UuXeiYezWVfDfVhtYFP9c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768575436; c=relaxed/simple; bh=HqLuYnV5tuZ3t6R3gm9zbHuzUCEolVTdsZodN2etShg=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=g23iqQKyYS7fFcpJ0d4Sv3EJm5mOBvIlslOFKuiijkpO8/XHaA49UYKWyIuikVpR8HMS8b7aECqIoX/Nz5AnIYx2j5Sb/BxAieFZHA4nrxZPHEOi/Bd/pcWJBLdmnEM5YzACsl9rN+kGGyxqfhdLTdaAr1RzvQ3VbeYHkUcKeTA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com; spf=pass smtp.mailfrom=amazon.co.uk; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b=J7Av3Jbg; arc=none smtp.client-ip=18.199.210.3 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=amazon.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazoncorp2; t=1768575434; x=1800111434; h=message-id:date:mime-version:reply-to:subject:to:cc: references:from:in-reply-to:content-transfer-encoding; bh=MR+rnXxwxn/7x1Gj4j0jxSdDeJDLel3jNY29213m130=; b=J7Av3JbgmOW5Zw36TtyJiyqO5DK3zoHRj4hX6c0TpAbU8JNXbS6GTNHS kGZfR9zLBNaIcEf2GeqYZ5d9Xwi92eJ3cJCfR0Dn8vAsSGcdoT6Oule+v bfsmIVC2kxprMJKfrBCbgn+5zKOV80f84iCVUS3BE8O1bOrEz4I72Y/q6 zIVN84HKjGqvxx0UOOUJfrwsSRJYf3hqh2HDScRMNUFKseCpKThrM1X9B WCDBs3nEJjlgJyqX4KrzKrgsSRAnIFgpaKvLsswdwj56NZDIJ1xgS3VtX sToCkkVPbFeWIay0+W1VkQjbbfPHUJa4UPxRkjw6TxoKWSPF/RU5krcZ7 w==; X-CSE-ConnectionGUID: vQMfjCS2RPe/+ynLfnaVwA== X-CSE-MsgGUID: CK/cr+tHSwmdmlTSKnHeWA== X-IronPort-AV: E=Sophos;i="6.21,231,1763424000"; d="scan'208";a="7920258" Received: from ip-10-6-6-97.eu-central-1.compute.internal (HELO smtpout.naws.eu-central-1.prod.farcaster.email.amazon.dev) ([10.6.6.97]) by internal-fra-out-014.esa.eu-central-1.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jan 2026 14:56:55 +0000 Received: from EX19MTAEUB002.ant.amazon.com [54.240.197.232:20480] by smtpin.naws.eu-central-1.prod.farcaster.email.amazon.dev [10.0.28.56:2525] with esmtp (Farcaster) id fa6b071b-8258-4488-b17f-3ae252f37550; Fri, 16 Jan 2026 14:56:55 +0000 (UTC) X-Farcaster-Flow-ID: fa6b071b-8258-4488-b17f-3ae252f37550 Received: from EX19D005EUB003.ant.amazon.com (10.252.51.31) by EX19MTAEUB002.ant.amazon.com (10.252.51.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.35; Fri, 16 Jan 2026 14:56:52 +0000 Received: from [192.168.12.13] (10.106.82.9) by EX19D005EUB003.ant.amazon.com (10.252.51.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.35; Fri, 16 Jan 2026 14:56:48 +0000 Message-ID: Date: Fri, 16 Jan 2026 14:56:46 +0000 Precedence: bulk X-Mailing-List: linux-s390@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: Subject: Re: [PATCH v9 07/13] KVM: guest_memfd: Add flag to remove from direct map To: Ackerley Tng , "Kalyazin, Nikita" , "kvm@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "bpf@vger.kernel.org" , "linux-kselftest@vger.kernel.org" , "kernel@xen0n.name" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , "loongarch@lists.linux.dev" CC: "pbonzini@redhat.com" , "corbet@lwn.net" , "maz@kernel.org" , "oupton@kernel.org" , "joey.gouly@arm.com" , "suzuki.poulose@arm.com" , "yuzenghui@huawei.com" , "catalin.marinas@arm.com" , "will@kernel.org" , "seanjc@google.com" , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "luto@kernel.org" , "peterz@infradead.org" , "willy@infradead.org" , "akpm@linux-foundation.org" , "david@kernel.org" , "lorenzo.stoakes@oracle.com" , "Liam.Howlett@oracle.com" , "vbabka@suse.cz" , "rppt@kernel.org" , "surenb@google.com" , "mhocko@suse.com" , "ast@kernel.org" , "daniel@iogearbox.net" , "andrii@kernel.org" , "martin.lau@linux.dev" , "eddyz87@gmail.com" , "song@kernel.org" , "yonghong.song@linux.dev" , "john.fastabend@gmail.com" , "kpsingh@kernel.org" , "sdf@fomichev.me" , "haoluo@google.com" , "jolsa@kernel.org" , "jgg@ziepe.ca" , "jhubbard@nvidia.com" , "peterx@redhat.com" , "jannh@google.com" , "pfalcato@suse.de" , "shuah@kernel.org" , "riel@surriel.com" , "ryan.roberts@arm.com" , "jgross@suse.com" , "yu-cheng.yu@intel.com" , "kas@kernel.org" , "coxu@redhat.com" , "kevin.brodsky@arm.com" , "maobibo@loongson.cn" , "prsampat@amd.com" , "mlevitsk@redhat.com" , "jmattson@google.com" , "jthoughton@google.com" , "agordeev@linux.ibm.com" , "alex@ghiti.fr" , "aou@eecs.berkeley.edu" , "borntraeger@linux.ibm.com" , "chenhuacai@kernel.org" , "dev.jain@arm.com" , "gor@linux.ibm.com" , "hca@linux.ibm.com" , "Jonathan.Cameron@huawei.com" , "palmer@dabbelt.com" , "pjw@kernel.org" , "shijie@os.amperecomputing.com" , "svens@linux.ibm.com" , "thuth@redhat.com" , "wyihan@google.com" , "yang@os.amperecomputing.com" , "vannapurve@google.com" , "jackmanb@google.com" , "aneesh.kumar@kernel.org" , "patrick.roy@linux.dev" , "Thomson, Jack" , "Itazuri, Takahiro" , "Manwaring, Derek" , "Cali, Marco" References: <20260114134510.1835-1-kalyazin@amazon.com> <20260114134510.1835-8-kalyazin@amazon.com> Content-Language: en-US From: Nikita Kalyazin Autocrypt: addr=kalyazin@amazon.com; keydata= xjMEY+ZIvRYJKwYBBAHaRw8BAQdA9FwYskD/5BFmiiTgktstviS9svHeszG2JfIkUqjxf+/N JU5pa2l0YSBLYWx5YXppbiA8a2FseWF6aW5AYW1hem9uLmNvbT7CjwQTFggANxYhBGhhGDEy BjLQwD9FsK+SyiCpmmTzBQJnrNfABQkFps9DAhsDBAsJCAcFFQgJCgsFFgIDAQAACgkQr5LK IKmaZPOpfgD/exazh4C2Z8fNEz54YLJ6tuFEgQrVQPX6nQ/PfQi2+dwBAMGTpZcj9Z9NvSe1 CmmKYnYjhzGxzjBs8itSUvWIcMsFzjgEY+ZIvRIKKwYBBAGXVQEFAQEHQCqd7/nb2tb36vZt ubg1iBLCSDctMlKHsQTp7wCnEc4RAwEIB8J+BBgWCAAmFiEEaGEYMTIGMtDAP0Wwr5LKIKma ZPMFAmes18AFCQWmz0MCGwwACgkQr5LKIKmaZPNTlQEA+q+rGFn7273rOAg+rxPty0M8lJbT i2kGo8RmPPLu650A/1kWgz1AnenQUYzTAFnZrKSsXAw5WoHaDLBz9kiO5pAK In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: EX19D008EUC003.ant.amazon.com (10.252.51.205) To EX19D005EUB003.ant.amazon.com (10.252.51.31) X-DKIM: signer='amazon.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-DKIM: signer='@amazon.com' status='pass' reason='' X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 On 15/01/2026 20:00, Ackerley Tng wrote: > "Kalyazin, Nikita" writes: > >> From: Patrick Roy >> >> Add GUEST_MEMFD_FLAG_NO_DIRECT_MAP flag for KVM_CREATE_GUEST_MEMFD() >> ioctl. When set, guest_memfd folios will be removed from the direct map >> after preparation, with direct map entries only restored when the folios >> are freed. >> >> To ensure these folios do not end up in places where the kernel cannot >> deal with them, set AS_NO_DIRECT_MAP on the guest_memfd's struct >> address_space if GUEST_MEMFD_FLAG_NO_DIRECT_MAP is requested. >> >> Note that this flag causes removal of direct map entries for all >> guest_memfd folios independent of whether they are "shared" or "private" >> (although current guest_memfd only supports either all folios in the >> "shared" state, or all folios in the "private" state if >> GUEST_MEMFD_FLAG_MMAP is not set). The usecase for removing direct map >> entries of also the shared parts of guest_memfd are a special type of >> non-CoCo VM where, host userspace is trusted to have access to all of >> guest memory, but where Spectre-style transient execution attacks >> through the host kernel's direct map should still be mitigated. In this >> setup, KVM retains access to guest memory via userspace mappings of >> guest_memfd, which are reflected back into KVM's memslots via >> userspace_addr. This is needed for things like MMIO emulation on x86_64 >> to work. >> >> Direct map entries are zapped right before guest or userspace mappings >> of gmem folios are set up, e.g. in kvm_gmem_fault_user_mapping() or >> kvm_gmem_get_pfn() [called from the KVM MMU code]. The only place where >> a gmem folio can be allocated without being mapped anywhere is >> kvm_gmem_populate(), where handling potential failures of direct map >> removal is not possible (by the time direct map removal is attempted, >> the folio is already marked as prepared, meaning attempting to re-try >> kvm_gmem_populate() would just result in -EEXIST without fixing up the >> direct map state). These folios are then removed form the direct map >> upon kvm_gmem_get_pfn(), e.g. when they are mapped into the guest later. >> >> Signed-off-by: Patrick Roy >> Signed-off-by: Nikita Kalyazin >> --- >> Documentation/virt/kvm/api.rst | 22 ++++++++------ >> include/linux/kvm_host.h | 12 ++++++++ >> include/uapi/linux/kvm.h | 1 + >> virt/kvm/guest_memfd.c | 54 ++++++++++++++++++++++++++++++++++ >> 4 files changed, 80 insertions(+), 9 deletions(-) >> >> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst >> index 01a3abef8abb..c5f54f1370c8 100644 >> --- a/Documentation/virt/kvm/api.rst >> +++ b/Documentation/virt/kvm/api.rst >> @@ -6440,15 +6440,19 @@ a single guest_memfd file, but the bound ranges must not overlap). >> The capability KVM_CAP_GUEST_MEMFD_FLAGS enumerates the `flags` that can be >> specified via KVM_CREATE_GUEST_MEMFD. Currently defined flags: >> >> - ============================ ================================================ >> - GUEST_MEMFD_FLAG_MMAP Enable using mmap() on the guest_memfd file >> - descriptor. >> - GUEST_MEMFD_FLAG_INIT_SHARED Make all memory in the file shared during >> - KVM_CREATE_GUEST_MEMFD (memory files created >> - without INIT_SHARED will be marked private). >> - Shared memory can be faulted into host userspace >> - page tables. Private memory cannot. >> - ============================ ================================================ >> + ============================== ================================================ >> + GUEST_MEMFD_FLAG_MMAP Enable using mmap() on the guest_memfd file >> + descriptor. >> + GUEST_MEMFD_FLAG_INIT_SHARED Make all memory in the file shared during >> + KVM_CREATE_GUEST_MEMFD (memory files created >> + without INIT_SHARED will be marked private). >> + Shared memory can be faulted into host userspace >> + page tables. Private memory cannot. >> + GUEST_MEMFD_FLAG_NO_DIRECT_MAP The guest_memfd instance will behave similarly >> + to memfd_secret, and unmaps the memory backing > > Perhaps the reference to memfd_secret can be dropped to avoid anyone > assuming further similarities between guest_memfd and memfd_secret. This > could just say that "The guest_memfd instance will unmap the memory > backing it from the kernel's address space...". Agree, it may lead to a confusion down the line, thanks. > >> + it from the kernel's address space before >> + being passed off to userspace or the guest. >> + ============================== ================================================ >> >> When the KVM MMU performs a PFN lookup to service a guest fault and the backing >> guest_memfd has the GUEST_MEMFD_FLAG_MMAP set, then the fault will always be >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h >> index 27796a09d29b..d4d5306075bf 100644 >> --- a/include/linux/kvm_host.h >> +++ b/include/linux/kvm_host.h >> @@ -738,10 +738,22 @@ static inline u64 kvm_gmem_get_supported_flags(struct kvm *kvm) >> if (!kvm || kvm_arch_supports_gmem_init_shared(kvm)) >> flags |= GUEST_MEMFD_FLAG_INIT_SHARED; >> >> + if (kvm_arch_gmem_supports_no_direct_map()) >> + flags |= GUEST_MEMFD_FLAG_NO_DIRECT_MAP; >> + >> return flags; >> } >> #endif >> >> +#ifdef CONFIG_KVM_GUEST_MEMFD >> +#ifndef kvm_arch_gmem_supports_no_direct_map >> +static inline bool kvm_arch_gmem_supports_no_direct_map(void) >> +{ >> + return false; >> +} >> +#endif >> +#endif /* CONFIG_KVM_GUEST_MEMFD */ >> + >> #ifndef kvm_arch_has_readonly_mem >> static inline bool kvm_arch_has_readonly_mem(struct kvm *kvm) >> { >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index dddb781b0507..60341e1ba1be 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -1612,6 +1612,7 @@ struct kvm_memory_attributes { >> #define KVM_CREATE_GUEST_MEMFD _IOWR(KVMIO, 0xd4, struct kvm_create_guest_memfd) >> #define GUEST_MEMFD_FLAG_MMAP (1ULL << 0) >> #define GUEST_MEMFD_FLAG_INIT_SHARED (1ULL << 1) >> +#define GUEST_MEMFD_FLAG_NO_DIRECT_MAP (1ULL << 2) >> >> struct kvm_create_guest_memfd { >> __u64 size; >> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c >> index 92e7f8c1f303..43f64c11467a 100644 >> --- a/virt/kvm/guest_memfd.c >> +++ b/virt/kvm/guest_memfd.c >> @@ -7,6 +7,9 @@ >> #include >> #include >> #include >> +#include >> + >> +#include >> >> #include "kvm_mm.h" >> >> @@ -76,6 +79,43 @@ static int __kvm_gmem_prepare_folio(struct kvm *kvm, struct kvm_memory_slot *slo >> return 0; >> } >> >> +#define KVM_GMEM_FOLIO_NO_DIRECT_MAP BIT(0) >> + >> +static bool kvm_gmem_folio_no_direct_map(struct folio *folio) >> +{ >> + return ((u64) folio->private) & KVM_GMEM_FOLIO_NO_DIRECT_MAP; > > Nit: I think there shouldn't be a space between (u64) and what's being casted. True, will remove. > >> +} >> + >> +static int kvm_gmem_folio_zap_direct_map(struct folio *folio) >> +{ >> + u64 gmem_flags = GMEM_I(folio_inode(folio))->flags; >> + int r = 0; >> + >> + if (kvm_gmem_folio_no_direct_map(folio) || !(gmem_flags & GUEST_MEMFD_FLAG_NO_DIRECT_MAP)) >> + goto out; >> + >> + folio->private = (void *)((u64)folio->private | KVM_GMEM_FOLIO_NO_DIRECT_MAP); >> + r = folio_zap_direct_map(folio); >> + >> +out: >> + return r; >> +} >> + >> +static void kvm_gmem_folio_restore_direct_map(struct folio *folio) >> +{ >> + /* >> + * Direct map restoration cannot fail, as the only error condition >> + * for direct map manipulation is failure to allocate page tables >> + * when splitting huge pages, but this split would have already >> + * happened in folio_zap_direct_map() in kvm_gmem_folio_zap_direct_map(). >> + * Thus folio_restore_direct_map() here only updates prot bits. >> + */ > > Thanks for this comment :) Thanks to Patrick :) > >> + if (kvm_gmem_folio_no_direct_map(folio)) { >> + WARN_ON_ONCE(folio_restore_direct_map(folio)); >> + folio->private = (void *)((u64)folio->private & ~KVM_GMEM_FOLIO_NO_DIRECT_MAP); >> + } >> +} >> + >> static inline void kvm_gmem_mark_prepared(struct folio *folio) >> { >> folio_mark_uptodate(folio); >> @@ -398,6 +438,7 @@ static vm_fault_t kvm_gmem_fault_user_mapping(struct vm_fault *vmf) >> struct inode *inode = file_inode(vmf->vma->vm_file); >> struct folio *folio; >> vm_fault_t ret = VM_FAULT_LOCKED; >> + int err; >> >> if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode)) >> return VM_FAULT_SIGBUS; >> @@ -423,6 +464,12 @@ static vm_fault_t kvm_gmem_fault_user_mapping(struct vm_fault *vmf) >> kvm_gmem_mark_prepared(folio); >> } >> >> + err = kvm_gmem_folio_zap_direct_map(folio); > > Perhaps the check for gmem_flags & GUEST_MEMFD_FLAG_NO_DIRECT_MAP should > be done here before making the call to kvm_gmem_folio_zap_direct_map() > to make it more obvious that zapping is conditional. Makes sense to me. > > Perhaps also add a check for kvm_arch_gmem_supports_no_direct_map() so > this call can be completely removed by the compiler if it wasn't > compiled in. But if it is compiled in, we will be paying the cost of the call on every page fault? Eg on arm64, it will call the following: bool can_set_direct_map(void) { ... return rodata_full || debug_pagealloc_enabled() || arm64_kfence_can_set_direct_map() || is_realm_world(); } > > The kvm_gmem_folio_no_direct_map() check should probably remain in > kvm_gmem_folio_zap_direct_map() since that's a "if already zapped, don't > zap again" check. > >> + if (err) { >> + ret = vmf_error(err); >> + goto out_folio; >> + } >> + >> vmf->page = folio_file_page(folio, vmf->pgoff); >> >> out_folio: >> @@ -533,6 +580,8 @@ static void kvm_gmem_free_folio(struct folio *folio) >> kvm_pfn_t pfn = page_to_pfn(page); >> int order = folio_order(folio); >> >> + kvm_gmem_folio_restore_direct_map(folio); >> + > > I can't decide if the kvm_gmem_folio_no_direct_map(folio) should be in > the caller or within kvm_gmem_folio_restore_direct_map(), since this > time it's a folio-specific property being checked. I'm tempted to keep it similar to the kvm_gmem_folio_zap_direct_map() case. How does the fact it's a folio-speicific property change your reasoning? > > Perhaps also add a check for kvm_arch_gmem_supports_no_direct_map() so > this call can be completely removed by the compiler if it wasn't > compiled in. IIUC whether the check is added in the caller or within > kvm_gmem_folio_restore_direct_map() the call can still be elided. Same concern as the above about kvm_gmem_folio_zap_direct_map(), ie the performance of the case where kvm_arch_gmem_supports_no_direct_map() exists. > >> kvm_arch_gmem_invalidate(pfn, pfn + (1ul << order)); >> } >> >> @@ -596,6 +645,9 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags) >> /* Unmovable mappings are supposed to be marked unevictable as well. */ >> WARN_ON_ONCE(!mapping_unevictable(inode->i_mapping)); >> >> + if (flags & GUEST_MEMFD_FLAG_NO_DIRECT_MAP) >> + mapping_set_no_direct_map(inode->i_mapping); >> + >> GMEM_I(inode)->flags = flags; >> >> file = alloc_file_pseudo(inode, kvm_gmem_mnt, name, O_RDWR, &kvm_gmem_fops); >> @@ -807,6 +859,8 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot, >> if (!is_prepared) >> r = kvm_gmem_prepare_folio(kvm, slot, gfn, folio); >> >> + kvm_gmem_folio_zap_direct_map(folio); >> + > > Is there a reason why errors are not handled when faulting private memory? No, I can't see a reason. Will add a check, thanks. > >> folio_unlock(folio); >> >> if (!r) >> -- >> 2.50.1 From - Fri Jan 16 15:04:30 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 4KpnHHlTamncljYAYBR5ng (envelope-from ) for ; Fri, 16 Jan 2026 15:04:25 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Fri, 16 Jan 2026 15:04:25 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vglNB-0000000FRxx-0Bxa for hi@josie.lol; Fri, 16 Jan 2026 15:04:25 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id BD889300BBB6 for ; Fri, 16 Jan 2026 14:52:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AA7063358D4; Fri, 16 Jan 2026 14:52:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Adomgxsk" X-Original-To: linux-s390@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 86CB5221DAD; Fri, 16 Jan 2026 14:52:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768575162; cv=none; b=pAdYmHHOv4SzK6edFGNoygFcq2fO/neDNMC9F31FTUUoLyHDYUscQvx7lZgBtGRZXe7DlF7wSmZWVoUz8DCk27/xZb0nhMsv+d1wTO175NU9RPCBIF8Max+bj4LNiK3qNV+P2rW8Hh6xTRiqyf6VOT3YmWxQmoJ1+/ntk4j6ad0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768575162; c=relaxed/simple; bh=KdTiRwNqvvTUCK29uJFVf97xOZdvdCR4xQadD5dd7Pc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=O1C75L3p++jD9hUxULtRWXVVqadq/6d8BSE9IZuvGE8Qmo1D3M9+6vAp9GU/3uGMyt+83CPf8RdVQ819QayvqDOtuQ/hw9J27n/vkRENyQpXoYlsZkwepZCBdgD4PL49aMo3An5+S80D6KqKPxclD8CTOJSTkC2CCLPcRfDo+ds= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Adomgxsk; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43D42C116C6; Fri, 16 Jan 2026 14:52:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768575162; bh=KdTiRwNqvvTUCK29uJFVf97xOZdvdCR4xQadD5dd7Pc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AdomgxskzkU+sLSsmMYNhuPB6+HiDEHNe3Wx7a5u+FWDJg+MoxaTG491VnRfG9PM4 VwbMgd8WvqQBs+1XvJXxvoeBnrlgLJX4ddHNATB2nvc3bzW1P5fZH7TMd9PD7Zs0Ob iw9aQxCHGZMljcG1K9g1yIum4xwa4jXkLhrpGfUlviKobG9w5c/9QaA/VOuC7caFVD RiZ6VtCj1xk7+4MUVfNWd+NZJjGWbi5mjVOvnMERLr0gpI+C/ckt1g0ZJba6j9ssLh tpFq4s92Hngh5oZAKD5TmBIvJs71ct71mj7+/GNtJhxxEn6446EjsuepigZH1TKZnW 07Ocp25nPF4Mw== From: Frederic Weisbecker To: LKML Cc: Frederic Weisbecker , "Christophe Leroy (CS GROUP)" , "Rafael J. Wysocki" , Alexander Gordeev , Anna-Maria Behnsen , Ben Segall , Boqun Fe