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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AA95DCCD199 for ; Fri, 17 Oct 2025 22:41:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E11C98E0009; Fri, 17 Oct 2025 18:41:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE96B8E0008; Fri, 17 Oct 2025 18:41:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD8068E0009; Fri, 17 Oct 2025 18:41:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BE5988E0008 for ; Fri, 17 Oct 2025 18:41:34 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4D4AEC02DE for ; Fri, 17 Oct 2025 22:41:34 +0000 (UTC) X-FDA: 84009079308.20.6F88794 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf20.hostedemail.com (Postfix) with ESMTP id 80A841C0006 for ; Fri, 17 Oct 2025 22:41:31 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fsatUJsY; spf=pass (imf20.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1760740892; 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=uH8LJn4ypQODNYJ3orBEKrIWWsg1DgFIAiLDa76fO34=; b=cZ/v+QskvrYMxsPbBxMTSEL9ZUEGxcTZz5d1X+xxJdSHTKtrh91ViPdpjI6aCNepTF1jcc KzQRJecLi4b10T+uwmYXofxXDRsugCTNmbzi76IsJ9tg7V1ZBQeZI+z4mHH5T4DhNRv2K2 z/rwSJVKNBMsVC/cAkA62D2qZkTGS+k= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fsatUJsY; spf=pass (imf20.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1760740892; a=rsa-sha256; cv=none; b=v419Jrm4o1mY6eVcN+1uEPfAv3oqHqfaUlGZ2es5cUqrzNNsMmXhPOSwhv9u1SqFk208Px SqP08vRb45Vnft5ZfcO3IxsL2UxkUAEYC5lTSarjaZmHHpgymV1USRWToRjayGimlk5Zn5 L/xOxSv4rE61eQ/sX5yBjyDSrVzygd0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1760740890; h=from:from: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:autocrypt:autocrypt; bh=uH8LJn4ypQODNYJ3orBEKrIWWsg1DgFIAiLDa76fO34=; b=fsatUJsYa0aovfrulAxVVhzCRmqKXmES8VlODQRP/ocmuKvZARGHjOTf8BuGbrKY/Axjvf cGdbvsv/2bMVP+XU5K1eqsmHOL0VLSaVhGFZQCXYBX25lLp1fD++MpJ6j/+5xVBkVY+3Hx tamULMqw9PFrz+hJhNRfeiAqnF7WSvc= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-43-ZxsevGxINx2wut_GrT9AZA-1; Fri, 17 Oct 2025 18:41:28 -0400 X-MC-Unique: ZxsevGxINx2wut_GrT9AZA-1 X-Mimecast-MFC-AGG-ID: ZxsevGxINx2wut_GrT9AZA_1760740887 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-47114d373d5so20296385e9.1 for ; Fri, 17 Oct 2025 15:41:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760740887; x=1761345687; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uH8LJn4ypQODNYJ3orBEKrIWWsg1DgFIAiLDa76fO34=; b=aS0YYSZCzL2/Zh2nFdbGlEGd0sEmXjX0+MWWlkl2uxUSIgRe0XiqFQIatJaOE58exq iqzNSsFjkt9qnp+8tIyVLOG3mxz0ZXXyEPz6ezXCaFWGzvwmf1ZyBgkNokujCbWCD4x5 JGo4Ubf3PmY/nIrQMHMpI1zTbFiKO/yELkmllUEErQOVKQcuo+0t673AltKgq1Uy/W2W 3xEbXRE71RizK7IOQ4VRQZGE+WvCAa6Vi2kjPZXth6sAH9ZVUgvJSmCwd7Y7sAIVl4z+ hcWqdU0qNWhnNRfTppJK8Voj+YF95wmDgCgeyixLpAtW9lGyZWa2gyV68L9j1KdlaaQz 4lBQ== X-Forwarded-Encrypted: i=1; AJvYcCXHQ4gDrTd5vWg1h59M1ycPhr+ey9x7XktXZJqbAufrCAaVZy+KCJIfaI7HH5fXJM51QlaMn6avbg==@kvack.org X-Gm-Message-State: AOJu0YxtkTn6MGZeuoQoGvM/yEFstUcLWc7lB7yT7WBrrJ/O2oB1z3zE ZIrybpopsSEB+tE0/FWD+bNRdw7b4eqK/65mzFu9sG7b5WMKJr818srMxUyZ/V5qK45942SFI8j 6CJGg3OPx1SNBUm4nCwJkV7FbFrpPREje1zPw1BQrtHpF5kx3OK0p X-Gm-Gg: ASbGncsBCOBNIh65easszozQ5PZpIosfFb8fZvCbMdhFWykmPkVKOwkSQiPI3dGrgFf pPrqrqjzrdr6z11fhzkNVas5nH8k+B9/tdwOtgmUquQclJxJlmhAogArFBNMxCYtghHMxbFCLXW KExxP/WnNYeo5wE74U7D1jIZGccf5wqIfwTVyl/rnEyFinMBT8gfi2ovByv8yckFzc9THdu2qtg liCWXzS47t7sSukpXiVUsCSwPk5z4zLQP7GqwEh2xcC7aR12JRvSyrIvFbt7E+y9kmpyakx4oyB I/YhYEVnLNE++SCiF0CJyzhgM6pXdYKMy1Qolhn13acGfv+rxNF7elk8BD9fH4yDS45gsUWBGHn rOv7bAIF3N2TRUrKDmJG6XdHEX5KMhoTBHQyEmsUbPwGPv24F4YaSwhgY9/Oyk9km6uPALBTnsX bD7cqijpjFHBVBTsAgJfYhg8Pd3f8= X-Received: by 2002:a05:600c:681b:b0:45f:2ed1:d1c5 with SMTP id 5b1f17b1804b1-47117925e39mr44633825e9.36.1760740887429; Fri, 17 Oct 2025 15:41:27 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFOhQlU/0jutSd2tKVW+63SmQtJ+uWLZ1QBUrTpaFXK1fSJ1MmohMxqY5ZVQykyp7L0xHjr7w== X-Received: by 2002:a05:600c:681b:b0:45f:2ed1:d1c5 with SMTP id 5b1f17b1804b1-47117925e39mr44633605e9.36.1760740886944; Fri, 17 Oct 2025 15:41:26 -0700 (PDT) Received: from ?IPV6:2003:d8:2f0c:c200:fa4a:c4ff:1b32:21ce? (p200300d82f0cc200fa4ac4ff1b3221ce.dip0.t-ipconnect.de. [2003:d8:2f0c:c200:fa4a:c4ff:1b32:21ce]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-427ea5a0f19sm1596288f8f.9.2025.10.17.15.41.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Oct 2025 15:41:26 -0700 (PDT) Message-ID: Date: Sat, 18 Oct 2025 00:41:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: linux-next: KVM/s390x regression From: David Hildenbrand To: Balbir Singh , Christian Borntraeger Cc: Liam.Howlett@oracle.com, airlied@gmail.com, akpm@linux-foundation.org, apopple@nvidia.com, baohua@kernel.org, baolin.wang@linux.alibaba.com, byungchul@sk.com, dakr@kernel.org, dev.jain@arm.com, dri-devel@lists.freedesktop.org, francois.dugast@intel.com, gourry@gourry.net, joshua.hahnjy@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lorenzo.stoakes@oracle.com, lyude@redhat.com, matthew.brost@intel.com, mpenttil@redhat.com, npache@redhat.com, osalvador@suse.de, rakie.kim@sk.com, rcampbell@nvidia.com, ryan.roberts@arm.com, simona@ffwll.ch, ying.huang@linux.alibaba.com, ziy@nvidia.com, kvm@vger.kernel.org, linux-s390@vger.kernel.org, linux-next@vger.kernel.org References: <20251001065707.920170-4-balbirs@nvidia.com> <20251017144924.10034-1-borntraeger@linux.ibm.com> <9beff9d6-47c7-4a65-b320-43efd1e12687@redhat.com> <8c778cd0-5608-4852-9840-4d98828d7b33@redhat.com> <74272098-cfb7-424b-a55e-55e94f04524e@linux.ibm.com> <84349344-b127-41f6-99f1-10f907c2bd07@redhat.com> <3a2db8fc-d289-415b-ae67-5a35c9c32a76@redhat.com> Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: <3a2db8fc-d289-415b-ae67-5a35c9c32a76@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: w5nN7woRVZUKXSL_5-pwaLcPSo7jNZUwZZUuCWtgCjQ_1760740887 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 80A841C0006 X-Stat-Signature: zo8p56fsobxh1ze4i4a5anhoxhtshuy1 X-Rspam-User: X-HE-Tag: 1760740891-489110 X-HE-Meta: U2FsdGVkX199ZPLaP7PgDyZWChc5IUdpkionNk5volvpsq9syMi5Y3K63PhM+rO2wHX6HUri2PQYvcOOiDPjdXFh766BUnym05fEEINsr7uqkP9fIEHvxm3zRAIvckbOwmzZRp13/I2tlPB6pkZs0N1IysnYdMcx2lfAl5d2ZZ7TPDSQm5tU9z0zN0tSL9zlynf74oYubQCMU0fg0Pv4Z+gTiNGlCwwNk10/DdjJgW+SQr3czZRqMVqMw580FrL9FQWrrICbFI+6cA4kqKsi7v5Zpunk6jSltI6IK+sWzy8Mb1p1g+W8tyxV5DsiQdptwXlm9DHouifFqg9udonpbqRFeaO93lg3Fo9M5FCORbsYgO3IcMfJ0qcLm3jzl66dGvW4Qi+JCXgnxrMYuioFdaIbziN/bPEGl6oYGNzJInj38F1aTW6ogx52FOx3CVTbhTW+s9wHluGwdm/s2oUKZI8wP1jxTKRbGRnpRDRxDUO1966YG2ZQWNJYgInvcp8kcCHEHrFqbjudi5stYaX9W5QHFsgA21wxnAy19jDzsAmFGpaJ3iyFxZP3z0GJtYX02NEUBxijyfQmIeLSxQhkcQVNgrFABTwrA8ufy/qr7l0nQwAEFRC0MZXpk8ja5ARo+FsySPjI5TsQtgQzkU/Mr3HRrYVCtjm65ff4bsQ1aITDAXCeFGK6cdqkc7TFgqyvv3Qd3rsFaD6WW5Qvv4jP1hdea7WuO4+bsqjGNb43gRlT3FL8tRIgs7udv9cIhGLMyGLyBSnB9RpjpAOmk0NcTSvqWakHrYP8TRFZBK6vxaHvxaZTkU9zmXpZ4ETlG5KxRmzpvkyVKMryjI3qIO8gapDbKphkXSHiwqQksGVlAgQc+3ZKq5T0ByKIQv4+qcbKKy+SzP3P0ZaoC27gS0M6QmMTGocSxdYMsAFu2LSvyq58NVC37DCg+zB+80xNHVp2zW/8DHS1NWMyw5eD1Mt 4wIlzcGQ aZH6yjasHSbiv1hCvXUE9yGEmpHdsbpi1o9FArKhdJUskbE3j6I/mCSzklJENI/IxD2yJ0SPPhjf1I7Aj9T5CzDnId9BGNOTmmmwTz3MWolY0eO6HeDm2cWq7/3CI6Yyg01nXrGhBAmLVMaIvlowBMuZ1vZWsPVJRN9mc/kfWzFORvSa+1M6ko5B5Juo0l827+OJ7tkZM7lQTbkWREIemn12Nr8kwkbrvNkBTTHZXr05dUaGDpCYY2xmJVTOkdQxWOHXFEbqK3CuRLPD33ejrqR4QN/3xqvrLOHUIMAF+FJyslnU1t0n2uEsVf/FSz+mBlunuDgz3sXzG6EFt/uNUgBz4moU751w5aqMwxmGbgkQlZf1/ac/mzq3Y2kZI1ifjPOhzyIvy1ex35WnMjQ2Jdny3n2W8PkPA9DAoPr2UbY7jVAVZ9tKpSkQCAxQSH0K3BVRy0tIXEedHMZZt3NXwZFENW61vWXQcpnItQAzh/lMb23Lx29L9yPePaVljRemovvQjTS4VYJImXJT9fowu1gkq2QTOTI+AM4EYvdRU8k5ELs3F1HAKzAiRpFV2PdcGWul4Q9wARpCqviyWf8c5wb/OD1y7IRn9tC2gNh6jUYWNS5k= 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 18.10.25 00:15, David Hildenbrand wrote: > On 17.10.25 23:56, Balbir Singh wrote: >> On 10/18/25 04:07, David Hildenbrand wrote: >>> On 17.10.25 17:20, Christian Borntraeger wrote: >>>> >>>> >>>> Am 17.10.25 um 17:07 schrieb David Hildenbrand: >>>>> On 17.10.25 17:01, Christian Borntraeger wrote: >>>>>> Am 17.10.25 um 16:54 schrieb David Hildenbrand: >>>>>>> On 17.10.25 16:49, Christian Borntraeger wrote: >>>>>>>> This patch triggers a regression for s390x kvm as qemu guests can no longer start >>>>>>>> >>>>>>>> error: kvm run failed Cannot allocate memory >>>>>>>> PSW=mask 0000000180000000 addr 000000007fd00600 >>>>>>>> R00=0000000000000000 R01=0000000000000000 R02=0000000000000000 R03=0000000000000000 >>>>>>>> R04=0000000000000000 R05=0000000000000000 R06=0000000000000000 R07=0000000000000000 >>>>>>>> R08=0000000000000000 R09=0000000000000000 R10=0000000000000000 R11=0000000000000000 >>>>>>>> R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 >>>>>>>> C00=00000000000000e0 C01=0000000000000000 C02=0000000000000000 C03=0000000000000000 >>>>>>>> C04=0000000000000000 C05=0000000000000000 C06=0000000000000000 C07=0000000000000000 >>>>>>>> C08=0000000000000000 C09=0000000000000000 C10=0000000000000000 C11=0000000000000000 >>>>>>>> C12=0000000000000000 C13=0000000000000000 C14=00000000c2000000 C15=0000000000000000 >>>>>>>> >>>>>>>> KVM on s390x does not use THP so far, will investigate. Does anyone have a quick idea? >>>>>>> >>>>>>> Only when running KVM guests and apart from that everything else seems to be fine? >>>>>> >>>>>> We have other weirdness in linux-next but in different areas. Could that somehow be >>>>>> related to use disabling THP for the kvm address space? >>>>> >>>>> Not sure ... it's a bit weird. I mean, when KVM disables THPs we essentially just remap everything to be mapped by PTEs. So there shouldn't be any PMDs in that whole process. >>>>> >>>>> Remapping a file THP (shmem) implies zapping the THP completely. >>>>> >>>>> >>>>> I assume in your kernel config has CONFIG_ZONE_DEVICE and CONFIG_ARCH_ENABLE_THP_MIGRATION set, right? >>>> >>>> yes. >>>> >>>>> >>>>> I'd rule out copy_huge_pmd(), zap_huge_pmd() a well. >>>>> >>>>> >>>>> What happens if you revert the change in mm/pgtable-generic.c? >>>> >>>> That partial revert seems to fix the issue >>>> diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c >>>> index 0c847cdf4fd3..567e2d084071 100644 >>>> --- a/mm/pgtable-generic.c >>>> +++ b/mm/pgtable-generic.c >>>> @@ -290,7 +290,7 @@ pte_t *___pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp) >>>>              if (pmdvalp) >>>>                   *pmdvalp = pmdval; >>>> -       if (unlikely(pmd_none(pmdval) || !pmd_present(pmdval))) >>>> +       if (unlikely(pmd_none(pmdval) || is_pmd_migration_entry(pmdval))) >>> >>> Okay, but that means that effectively we stumble over a PMD entry that is not a migration entry but still non-present. >>> >>> And I would expect that it's a page table, because otherwise the change >>> wouldn't make a difference. >>> >>> And the weird thing is that this only triggers sometimes, because if >>> it would always trigger nothing would ever work. >>> >>> Is there some weird scenario where s390x might set a left page table mapped in a PMD to non-present? >>> >> >> Good point >> >>> Staring at the definition of pmd_present() on s390x it's really just >>> >>>     return (pmd_val(pmd) & _SEGMENT_ENTRY_PRESENT) != 0; >>> >>> >>> Maybe this is happening in the gmap code only and not actually in the core-mm code? >>> >> >> >> I am not an s390 expert, but just looking at the code >> >> So the check on s390 effectively >> >> segment_entry/present = false or segment_entry_empty/invalid = true > > pmd_present() == true iff _SEGMENT_ENTRY_PRESENT is set > > because > > return (pmd_val(pmd) & _SEGMENT_ENTRY_PRESENT) != 0; > > is the same as > > return pmd_val(pmd) & _SEGMENT_ENTRY_PRESENT; > > But that means we have something where _SEGMENT_ENTRY_PRESENT is not set. > > I suspect that can only be the gmap tables. > > Likely __gmap_link() does not set _SEGMENT_ENTRY_PRESENT, which is fine > because it's a software managed bit for "ordinary" page tables, not gmap > tables. > > Which raises the question why someone would wrongly use > pte_offset_map()/__pte_offset_map() on the gmap tables. > > I cannot immediately spot any such usage in kvm/gmap code, though. > Ah, it's all that pte_alloc_map_lock() stuff in gmap.c. Oh my. So we're mapping a user PTE table that is linked into the gmap tables through a PMD table that does not have the right sw bits set we would expect in a user PMD table. What's also scary is that pte_alloc_map_lock() would try to pte_alloc() a user page table in the gmap, which sounds completely wrong? Yeah, when walking the gmap and wanting to lock the linked user PTE table, we should probably never use the pte_*map variants but obtain the lock through pte_lockptr(). All magic we end up doing with RCU etc in __pte_offset_map_lock() does not apply to the gmap PMD table. -- Cheers David / dhildenb