Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 12 Apr 2023 15:21:38 -0700
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Liu Shixin <liushixin2@huawei.com>,
        Naoya Horiguchi <naoya.horiguchi@nec.com>,
        Tony Luck <tony.luck@intel.com>,
        Miaohe Lin <linmiaohe@huawei.com>,
        Muchun Song <muchun.song@linux.dev>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next] mm: hwpoison: support recovery from HugePage
 copy-on-write faults
Message-ID: <20230412222138.GB4759@monkey>
References: <20230411092741.780679-1-liushixin2@huawei.com>
 <20230412181350.GA22818@monkey>
 <20230412145718.0bcb7dd98112a3010711ad0b@linux-foundation.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230412145718.0bcb7dd98112a3010711ad0b@linux-foundation.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?3IGKg1f6vzZuGFBY/+5ADLoaY1tbRQOYCjN+IEXmnSnaLmjo66gEs3Gq0twI?=
 =?us-ascii?Q?7EhWQiJv5xcWx7sUe7qjCBxP/g+khJFK26tj3G+CzjbH2h4QN8hv6sJ1rDDG?=
 =?us-ascii?Q?g0hkrM6mMYh4+8cN4zSPlHOYdjzJhFBcUxLVyFLF4w38nP6E5z4SaYovGF6y?=
 =?us-ascii?Q?Y2zOsGGGEDJzP42FgWJCpuI7QfkCwnTt/JJUw72V9idnqHO6NgRX8G3Q4/us?=
 =?us-ascii?Q?UYcEiF6c1Yf3B30mzdP7OKdlcUjZKb1pguLdbBBv/EIpr2DX3xPWCWr7z7+R?=
 =?us-ascii?Q?8JVp75DQA6AV1BmFHeRoniU9ocskVoFpPVgMsSj2NnMLXzUXsMjk4YqDgNR+?=
 =?us-ascii?Q?h1Zo+V0eatE7K6aMufBqzCABA0PSZG7Y2LgqxcgmVr2Tj93lubslOCRj+sJK?=
 =?us-ascii?Q?crBNbQp1ECFPAH0rznYoW0vxwVRheDw1dCvIl+U77f4i7vS7gzMpfpTZJC3U?=
 =?us-ascii?Q?qA9nJj7APMaYhrAj1vzAC8EPKXQdj6MBnzR7DOrKcsHRkhkdFp0HFAoME0wP?=
 =?us-ascii?Q?7ykcSx6FMStd2lNCbtpc6H3jCwNehX2qYiVBrErxxXR9lcTXnOvgM/gO9s4E?=
 =?us-ascii?Q?/9VzEMmqv1NRd7FdmnQ3x9f2rP4Uj2xiuWaz+kbQtBB9YvYZWMaRNj1xUFuN?=
 =?us-ascii?Q?OrGyWVJWJEy5dcekTIpdM1uE4XQ8kFSkQ487FC13ZhT2L7BCPkIWkm44Tc8B?=
 =?us-ascii?Q?X6A71qHWLGUawE5nBpT3NNMiSFdDjRKRjQcD6w+x0PA+U5QIDz9vA40hbW3V?=
 =?us-ascii?Q?8zNQZn+JMMfIJ++5yZ/PJ5t848bm/pwOzkieAIT+2i3nPRkOZkK92I7qQn4H?=
 =?us-ascii?Q?20TrVZItTAl/SGENzaSZlfFHF2o/Hd2jVJbEm9Ssup41DqZLuElHV+m6a6fH?=
 =?us-ascii?Q?gaboCvGsnqTyD4e9PRgYK070Lm8V6HLHQ0GVA3mWMvzcNWCqDhYASIWqMs7r?=
 =?us-ascii?Q?icqY7s50hhxYiI0xm2VCJg0ku583HTx3/W8BOhcMhcRFtI+INZqHQgSATyY/?=
 =?us-ascii?Q?oLa9EpJUvPgO0avanWz7Jfwpf0k8HrP8QLLZFJVHQdmUoohEUcL06KUBUHtY?=
 =?us-ascii?Q?6yRork0+8KZP8hNRozJiXctnktK9jrK5fSBcxG+o1xhazQGTgmOXnynPcAIN?=
 =?us-ascii?Q?/XoQwHuBrpjrGY1+Rw42T+6fz9Jq7CWz6tgJ7Q08eMbgXpO02iedu6GMNPHI?=
 =?us-ascii?Q?hEDMy2bsFkhxZSvD+vqLpClu+OvgBhhWOtnUwv8R9Iqj9CMJmHecEJjYYU6w?=
 =?us-ascii?Q?IXTksg6Y8MlWgEabZ1fMzpz+P8xfLZZ2w7+NsGeaElp2AqeHeudVTzZ9ma7W?=
 =?us-ascii?Q?xYTP6hkA4olcGbfhtRDdZOZXEkLNDYaYOTPoXrlYgCYGPdXiN9jF+AJBydeu?=
 =?us-ascii?Q?AVD2cbnF51tFSUaQQ18pixmqTu0HaB83/0cFxc/s9b2nWq/24OwBn0p4efIu?=
 =?us-ascii?Q?VaAh8gqpAVbWx1tb5IVSg+SLk90T2JF3oDvwee0CmMs2ez0DEn1O031UReux?=
 =?us-ascii?Q?LJHzWPM1EmABNtuH7tL+AHp11i2HOInj97VyJLUr2Xj1vz9wybDyBhqUyMZm?=
 =?us-ascii?Q?92LaHWp9KDWmx3QM08m6x1ZJ9HJKtcOcsTYiMUU1?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?us-ascii?Q?NVugaNU+ButKmeBL+d4wagMZSipJft8SXuELku+P+14UqtZA7lp6lGBCCRHg?=
 =?us-ascii?Q?7yFLCRoOCuqsfXwUu00B6IVn3wzmWr3AhrZpTYRD0OnAz8ED3CDlQgdh105Y?=
 =?us-ascii?Q?hO8SqXDWS7Dr1t8ybb0WV0EPUe4+8dzhXXxhVls18iD2WCtCybw5ENXh8l4c?=
 =?us-ascii?Q?Iduo5+4JehFWf2rinZzifoUBh+83wYW05P4cMABAmGGCj6Y8VjpmY6OsCZaY?=
 =?us-ascii?Q?MTnjFIG1uam8qaEBDcGR7Kyd58CUaLz0EJ23kS48dR6L3dQqNjH5pCLRIyjO?=
 =?us-ascii?Q?zpOrJx8zLK9CyBXX5WPxkJO5mbjt48c4p4Xq2iPbo2FFmy3eobmxrF5WLTX/?=
 =?us-ascii?Q?bb67h0g0kxtTgPnFwnC0gUnWU/gU6yu2ISpL/CAP7v5eWAbFeuGfiiWYwxTs?=
 =?us-ascii?Q?CXnOdBKQreJnFkdz0yz6++mj4Q2SjbZodeoj1wBzb+voOtmVmUj1D2yu/Q+0?=
 =?us-ascii?Q?3J0FAtI/wwwDWfAlWWcHgCuBmGztOgpj4wYvPpbjpeUAiL1y6vsjnDvYEPW9?=
 =?us-ascii?Q?e0OxhBo316cfpDIsTlacZYZkzBvQ+qkjXlbyyF3I4335LDQ9Ry59kLyDUdyg?=
 =?us-ascii?Q?xe7gAjb1IujugkMoLxAo74cIQdZgrtj4KdZ23KSv0lgHh+pD/F7nCcwkNYQW?=
 =?us-ascii?Q?BNODcM3/l6x/Ue09RyHMhWvKt8pv8+KEubXAoim4xsSYLtZeUsqa8yQ14SY0?=
 =?us-ascii?Q?1jBQXeOp7itWc29v/OCoDYnexD0vTQ7S1h5oYsGzLroHBe20Heu/2NbVid2g?=
 =?us-ascii?Q?vto2tqSkNff3N7LLLS8DC77hvVwPlCReJ1H7QCivQXI5nmeMpKSL86PCRYpX?=
 =?us-ascii?Q?JZYRQJxOZ0ltOO1nbihkqHQKW97r0h8vZazNi/C8JZ/ajan+uv+5Jd9wcovn?=
 =?us-ascii?Q?vchSmENl6mOw8W0hLSxG+IqFj4TieXYcOBYg6TKkpE7pdm7bN0XxhDXShZbj?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3fff0d72-eee1-4c83-889b-08db3ba44a4c
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2023 22:21:41.2832
 (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: c8MCuxscxDpLVgSwHCd8A/pPj8LG2a0so1WR/SUeUjGoyzcguZT/n7Vvx7yl+XuwX+8uJqdRx58LT/3YTO/Pcw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR10MB4264
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22
 definitions=2023-04-12_12,2023-04-12_01,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 mlxscore=0
 malwarescore=0 suspectscore=0 bulkscore=0 spamscore=0 phishscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2303200000 definitions=main-2304120190
X-Proofpoint-GUID: K1riuzRMnx5_sQ_A1JSLUGFHZGb9lrGz
X-Proofpoint-ORIG-GUID: K1riuzRMnx5_sQ_A1JSLUGFHZGb9lrGz
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 04/12/23 14:57, Andrew Morton wrote:
> On Wed, 12 Apr 2023 11:13:50 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:
> 
> > On 04/11/23 17:27, Liu Shixin wrote:
> > > Patch a873dfe1032a ("mm, hwpoison: try to recover from copy-on write faults")
> > > introduced a new copy_user_highpage_mc() function, and fix the kernel crash
> > > when the kernel is copying a normal page as the result of a copy-on-write
> > > fault and runs into an uncorrectable error. But it doesn't work for HugeTLB.
> > 
> > Andrew asked about user-visible effects.  Perhaps, a better way of
> > stating this in the commit message might be:
> > 
> > Commit a873dfe1032a ("mm, hwpoison: try to recover from copy-on write
> > faults") introduced the routine copy_user_highpage_mc() to gracefully
> > handle copying of user pages with uncorrectable errors.  Previously,
> > such copies would result in a kernel crash.  hugetlb has separate code
> > paths for copy-on-write and does not benefit from the changes made in
> > commit a873dfe1032a.

I was just going to suggest adding the line,

Hence, copy-on-write of hugetlb user pages with uncorrectable errors            
will result in a kernel crash as was the case with 'normal' pages before        
commit a873dfe1032a.

However, I'm guessing it might be more clear if we start with the
runtime effects.  Something like:

copy-on-write of hugetlb user pages with uncorrectable errors will result
in a kernel crash.  This is because the copy is performed in kernel mode
and in general we can not handle accessing memory with such errors while
in kernel mode.  Commit a873dfe1032a ("mm, hwpoison: try to recover from
copy-on write faults") introduced the routine copy_user_highpage_mc() to
gracefully handle copying of user pages with uncorrectable errors.  However,
the separate hugetlb copy-on-write code paths were not modified as part
of commit a873dfe1032a.

> > 
> > Modify hugetlb copy-on-write code paths to use copy_mc_user_highpage()
> > so that they can also gracefully handle uncorrectable errors in user
> > pages.  This involves changing the hugetlb specific routine
> > ?copy_user_folio()? from type void to int so that it can return an error.
> > Modify the hugetlb userfaultfd code in the same way so that it can return
> > -EHWPOISON if it encounters an uncorrectable error.
> 
> Thanks, but...  what are the runtime effects?  What does hugetlb
> presently do when encountering these uncorrectable error?

-- 
Mike Kravetz