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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2F667C0219B for ; Tue, 11 Feb 2025 13:08:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:To:Subject :MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qp8FXc7l2huQpDDqUvBf4BSAvHA6gyxKUiNVmQD6PLw=; b=IMS3WbRK4zi3TH fZiL8v3bhdjS6JKMZYqqp5g0+moBh0eFVYAwZFU13xfUWYM8kgn1NfixZkNFXTg6IBxTbzyQlg/Fi 8uR6FgdNaBPnNNW8XgXsf/ph1mTad4gDcgqx3+xjYxvaqWmyIzsHSh/cvN7fCBDf5fHUwGiqvfdps KZuZy0zfxq3a4QTGIqkh/UdfPq4vJT9VtHUnVIvz30AeykaOT/PalDTCCkIx3o5O/Xz+ikS6iP8pI gOnZ12DrBIHzEl66+EMhV67FRaVvsxIwcLC3OWWNd6dN1D1drJdkJkRVtNSaQ1PPv96JthbD66TJg 5ANGqD2YXfgudCvPGu1Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1thpzz-00000003t9q-0B2R; Tue, 11 Feb 2025 13:08:23 +0000 Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1thpZs-00000003oL1-1vsC for linux-arm-kernel@lists.infradead.org; Tue, 11 Feb 2025 12:41:26 +0000 Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-21f5a224544so45631145ad.0 for ; Tue, 11 Feb 2025 04:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1739277682; x=1739882482; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=qp8FXc7l2huQpDDqUvBf4BSAvHA6gyxKUiNVmQD6PLw=; b=Wxpz3ycWUEhxZwk7wvJoUWcXsDcEE9F9WWFDuU14vgq314CCbW9cDlHxElQB5DDYoE zE71pR0jERmkArA2lwAipF341Cym/bFzK43N7dZB8Zr81GqpC0bLbru78PQHnPWYH9pt cPGu3AMnPKZArh8DYorK1uzWIOo+EJfhhnEskw1zR5Ee2fT3KAaCPcKzZByFMposFcQn QOcPGdJHHvmLh0Hl4u6kuAivpAxd0cAII5Q1d+lHE11RRe1yqUGHOLAsCVlyhMs1YSBN LDMdl3kMZr2QT7gV7BAur49NNE7HoXVNyw4rUhPZJC8xD/ySAKZ4prMygOlPE/jeyTAu vIEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739277682; x=1739882482; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qp8FXc7l2huQpDDqUvBf4BSAvHA6gyxKUiNVmQD6PLw=; b=ndQROdo6NMSxyrcjmHom6IPrAIRmL08cdl1tfIzvFitunB8YpBSRRCXtsUMyV56XG1 ZMPZH+87kdC4UOP/3cpl+u49z8jG9ZK3+Z3cJEwF/XCnsD3Vk+XXl4/d1nmoQGDnyhrK n5eWt1V4e4mlIRllLekKWLOikHawnHTrJUVQE0qAQWPfXE614mG2IDn3JBwnhXDtAPNe AUks/P8COL4k/LOvIjCihTz+VFwKHxH5LVB1PABEzIKeOEIqYd167/GJBWYey81bnYOX A+lu0zNXJp5x+S0zJg1LUnwxHuGxAuQh6letXw4IH3dYjgN0JbwjSlgV+HaAjeNhTB89 EahQ== X-Forwarded-Encrypted: i=1; AJvYcCUyUC0N5gApJ6AxFEEyr2yyLyfaWjplYp+ea7fSiSPuIaowB2f4ynp9CKDVzeXBDtzT3/KfL11x61i5yjeiv5dT@lists.infradead.org X-Gm-Message-State: AOJu0Yxcsr6rCf09zFMsSeh077C0rzg9hiEV393RftP6uVRcjNXGUUrZ oS6lf8lU266QBDmmOMHj/hBM6ngwYbGJJhHegPxDWElFgQHSWzRad8kReBBmacU= X-Gm-Gg: ASbGncv40kDH6717ecn4o34//SxjU/r0/2pXp+3btOdeY4RlXK3h9vB1rbOyRviRPLr DhZcWeq3PCnA3BD85Bl5cHuKuqXTaxDFrt1qMFR+zAYDZdiyc7BU6V1o0UWzj9uuG0fVmB/X/g2 D8TPHo7Zi9vlUCfZV08jYlp3HCYT4PxeC3D6NnEkp+Vnn9fUhs7+ZtJQfOEYMITlzYq36mKiwAI 4YezX7vhayTJ9Kx6J6WMJ5ltN78UpDqv+Uz/qlYIHQX9Fv/mDU9cyQzjK0iZkxIGvFhkt9vhEG0 foFnJkSJEMeiXVB8sydf6mWOFBuZBFSL9jYkxIpBEg== X-Google-Smtp-Source: AGHT+IHOuwW2S8J1yw3NRTlkAu47N8Bv/dy8tpNXivF9AQn/HjfyDnQSydirHNWFT7gUC4WKzQR0nQ== X-Received: by 2002:a17:902:e946:b0:216:6f1a:1c81 with SMTP id d9443c01a7336-21f4e6a57f1mr313385905ad.2.1739277682572; Tue, 11 Feb 2025 04:41:22 -0800 (PST) Received: from [10.84.150.121] ([203.208.167.153]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21f368bb4bdsm94384425ad.235.2025.02.11.04.41.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Feb 2025 04:41:22 -0800 (PST) Message-ID: Date: Tue, 11 Feb 2025 20:41:14 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [REGRESSION] NULL pointer dereference on ARM (AT91SAM9G25) during compaction Content-Language: en-US To: David Hildenbrand References: <5d50d714-197f-44c0-94e0-ff70ee51e866@bytedance.com> <34bcf011-b4ac-479c-92ce-852623e73039@redhat.com> <3f7babee-b232-4e6b-a896-947150dcd1ef@bytedance.com> <2b0bb476-5bd6-489a-9b9e-7aa20964abfa@redhat.com> <4e298f68-36ff-496a-81d2-7124f792180d@bytedance.com> From: Qi Zheng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250211_044124_830373_BFFAA180 X-CRM114-Status: GOOD ( 25.95 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-kernel@lists.infradead.org, Alexandre Belloni , Ryan Roberts , open list , Hugh Dickins , Muchun Song , Ezra Buehler , "Russell King \(Oracle\)" , Matthew Wilcox , "Vishal Moola \(Oracle\)" , linux-mm@kvack.org, Peter Xu , Vlastimil Babka , Claudiu Beznea , Andrew Morton , "Mike Rapoport \(Microsoft\)" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2025/2/11 20:09, David Hildenbrand wrote: > On 11.02.25 10:43, Qi Zheng wrote: >> >> >> On 2025/2/11 17:37, David Hildenbrand wrote: >>> On 11.02.25 10:29, Qi Zheng wrote: >>>> >>>> >>>> On 2025/2/11 17:14, David Hildenbrand wrote: >>>>> On 11.02.25 04:45, Qi Zheng wrote: >>>>>> Hi Russell, >>>>>> >>>>>> On 2025/2/11 01:03, Russell King (Oracle) wrote: >>>>>>> On Mon, Feb 10, 2025 at 05:49:38PM +0100, Ezra Buehler wrote: >>>>>>>> When running vanilla Linux 6.13 or newer (6.14-rc2) on the >>>>>>>> AT91SAM9G25-based GARDENA smart Gateway, we are seeing a NULL >>>>>>>> pointer >>>>>>>> dereference resulting in a kernel panic. The culprit seems to be >>>>>>>> commit >>>>>>>> fc9c45b71f43 ("arm: adjust_pte() usepte_offset_map_rw_nolock()"). >>>>>>>> Reverting the commit apparently fixes the issue. >>>>>>> >>>>>>> The blamed commit is buggy: >>>>>>> >>>>>>> arch/arm/include/asm/tlbflush.h: >>>>>>> #define update_mmu_cache(vma, addr, ptep) \ >>>>>>>             update_mmu_cache_range(NULL, vma, addr, ptep, 1) >>>>>>> >>>>>>> So vmf can be NULL. This didn't used to matter before this commit, >>>>>>> because vmf was not used by ARM's update_mmu_cache_range(). However, >>>>>>> the commit introduced a dereference of it, which now causes a NULL >>>>>>> point dereference. >>>>>>> >>>>>>> Not sure what the correct solution is, but at a guess, both: >>>>>>> >>>>>>>       if (ptl != vmf->ptl) >>>>>>> >>>>>>> need to become: >>>>>>> >>>>>>>       if (!vmf || ptl != vmf->ptl) >>>>>> >>>>>> No, we can't do that, because without using split PTE locks, we would >>>>>> use shared mm->page_table_lock, which would create a deadlock. >>>>> >>>>> Maybe we can simply special-case on CONFIG_SPLIT_PTE_PTLOCKS ? >>>>> >>>>> if (IS_ENABLED(CONFIG_SPLIT_PTE_PTLOCKS)) { >>>> >>>> In this case, if two vmas map the same PTE page, then the same PTE lock >>>> will be held repeatedly. Right? >>> >>> Hmm, the comment says: >>> >>>           /* >>>            * This is called while another page table is mapped, so we >>>            * must use the nested version.  This also means we need to >>>            * open-code the spin-locking. >>>            */ >>> >>> "another page table" implies that it cannot be the same. But maybe that >>> comment was also wrong? >> >> I don't see make_coherent() ensuring this when traversing vma. > > Right, we could just have the same file range mapped MAP_SHARED into the > same page table using two VMAs ... I suspect writing a reproducer for > the deadlock should be easy. I guess so, but I don't have an arm32 test environment yet. :( [...] >>           vma_interval_tree_foreach(mpnt, &mapping->i_mmap, pgoff, >> pgoff) { >> +               unsigned long mpnt_addr; >> + >>                   /* >>                    * If this VMA is not in our MM, we can ignore it. >>                    * Note that we intentionally mask out the VMA >> @@ -151,7 +178,14 @@ make_coherent(struct address_space *mapping, struct >> vm_area_struct *vma, >>                   if (!(mpnt->vm_flags & VM_MAYSHARE)) >>                           continue; >>                   offset = (pgoff - mpnt->vm_pgoff) << PAGE_SHIFT; >> -               aliases += adjust_pte(mpnt, mpnt->vm_start + offset, >> pfn, vmf); >> +               mpnt_addr = mpnt->vm_start + offset; >> +               /* >> +                * If mpnt_addr and addr are mapped to the same PTE page, >> +                * also skip this vma. >> +                */ >> +               if (mpnt_addr >= start && mpnt_addr - start < PMD_SIZE) >> +                       continue; > > Hmm, but is skipping the right thing to do? Maybe you would want to Ah, your concern is that in this case we may also need to maintain cache coherency. I'm not sure about this. > indicate to adjust_pte() whether it must take the PTL or not. Indeed, this is a better approach. Will do it, and hope arm people can help test it. Thanks! > > I did not study that code in detail, though ... > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9868BC021A1 for ; Tue, 11 Feb 2025 12:41:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D95986B0089; Tue, 11 Feb 2025 07:41:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D455F6B008A; Tue, 11 Feb 2025 07:41:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE48B6B008C; Tue, 11 Feb 2025 07:41:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A205B6B0089 for ; Tue, 11 Feb 2025 07:41:27 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1A91B1A17FF for ; Tue, 11 Feb 2025 12:41:27 +0000 (UTC) X-FDA: 83107624614.27.2B8F94F Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf15.hostedemail.com (Postfix) with ESMTP id CA505A0008 for ; Tue, 11 Feb 2025 12:41:23 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=Ztw3hRbx; spf=pass (imf15.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739277685; 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=qp8FXc7l2huQpDDqUvBf4BSAvHA6gyxKUiNVmQD6PLw=; b=etMEoQeUs9IOkJ7WSiiB2FLgS/cP8lYU0FLKrFbnDqTqHvaJTyvqTy/BQTwFlB+OMdulmo y7nnqsUrcUzyRT3YGps95kJlul8T3Q7QrkR5uSiTqZ6K2t8i+SR3vlznt2CLczk/ka81AC 3Hc+SVq/tAx0LO6erjwFaYSAszfc2mc= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=Ztw3hRbx; spf=pass (imf15.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739277685; a=rsa-sha256; cv=none; b=NZieVzeyD1adkwzek7K99M6VY+GzZoafGn1+8YwMlm8cRrrZP61N3xJXGLzJj8a8FGPQ8+ H9m6cSMJiwLVMHgE7QDaT6eaAOJyvGlkbbWFl2lvFytHyEPZJqeOyNXSPuxrKHv7s0olqT UhNv/pqybtCMRJCpbRAFQJM+h+YKdOs= Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-21f44e7eae4so90185305ad.2 for ; Tue, 11 Feb 2025 04:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1739277682; x=1739882482; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=qp8FXc7l2huQpDDqUvBf4BSAvHA6gyxKUiNVmQD6PLw=; b=Ztw3hRbx4oFLyMxah7XuQwTw7pxh7/g0D0B9Np5Z+GUoEOlb/GO6oIEFiHlHRmlnNi pyu47ofY5mb+Be14bwKWtCVgFqndUHhjK1OlOtxf68UbaXvtREEzBxB69Ps6V5rQpYb2 WQM0cp0Ys1ievbiP5lB0kRoxxIYMZcn8fyPmUkq1osyzOcblCtJrduE0Mzbb68No3k46 ZEr56mr2Gtp9uhVttB7/VwwWcFop0TK/WEfHiCSiDFoYJz13hh9zGEsGV5XAWcGzImZE kktaOPCm8OCbCR3PIy1lPPzpwzNFCR+DERaWgGB2E+CTQ6mgtCy5aMj9z8Y7K0Up9b9h 0fhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739277682; x=1739882482; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qp8FXc7l2huQpDDqUvBf4BSAvHA6gyxKUiNVmQD6PLw=; b=DU5hP4JbB/oseD/PdbAULJuD9swKiiCSlGbqXL9a3vKNz54ZaaGGR+0I2A1BCeNriz x7WclMO3PfaDUnjtIop4NsZqU/wpeGu3gvauVOpygInThElGJgZFhh4bQ6ngVfJaZyT7 /w9QaPwSZ1Vrg5wwUCQsHYMwMQneZJWfl5i90bk2RdKFuZVzOQZJpHAugfsAT3uMRsM/ wcX2ph3a6FYsfNKggE44fBgt58oIg+zhT/HKOQX3bOq0NccUR/ODtMR7PSuXwyLKhr/M N5ah8pg5GqCCMSBjpW9SjGraG29lu7qAtjPmuSdhW8hwlAdu8lVULWl8bP1vYcK9zB3V ohgg== X-Forwarded-Encrypted: i=1; AJvYcCUq0laDJFek9hHpG/ArZgrXGIRo5G+Na/McSgAi0MobSPX3AMjfKOtFIk0dzHFD/Lp5dXDBQkFAGg==@kvack.org X-Gm-Message-State: AOJu0YwcPb0Y5dWsN0UmHEqnp4TJq2tbIyhWslKulO+23Ve5XLFKeAPv gKagPCW3zhk7LAI3i2B6HFpGNwwPfsE+sY5Xq9AoWGOjifSX5XeEsSARDJwd5yE= X-Gm-Gg: ASbGnct5A0JUKj3QqgK0FXaos5A83NTJ++pDCs89MR/fcw+3b0a0oCT4xPEUEleUPv9 Fvrhio2opwHmuJP3dvpV4vpHVSxRkc+1TZkr0xiNpbUqjC15Hy47+2Y32hKmxq+Oh9wyEbPA1Hr +SMmAyPdjCAe+/FcrRxP0ihSQgw02FX7yt83YafyT5XM84sVB/6LwE64dWn6LtjjPCBa3a4ed+U dd7c7BFQ0ezpfBP9yB4rEfrODYwEvJKQVohZ2ZXghBxKXfkMGE6kuz0/S5hqRFEhtQsxYtXM33A gPvQCcm2SpQ44BW+KjQqd/Sv+vESxi9pAq2ZqpOw0A== X-Google-Smtp-Source: AGHT+IHOuwW2S8J1yw3NRTlkAu47N8Bv/dy8tpNXivF9AQn/HjfyDnQSydirHNWFT7gUC4WKzQR0nQ== X-Received: by 2002:a17:902:e946:b0:216:6f1a:1c81 with SMTP id d9443c01a7336-21f4e6a57f1mr313385905ad.2.1739277682572; Tue, 11 Feb 2025 04:41:22 -0800 (PST) Received: from [10.84.150.121] ([203.208.167.153]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21f368bb4bdsm94384425ad.235.2025.02.11.04.41.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Feb 2025 04:41:22 -0800 (PST) Message-ID: Date: Tue, 11 Feb 2025 20:41:14 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [REGRESSION] NULL pointer dereference on ARM (AT91SAM9G25) during compaction Content-Language: en-US To: David Hildenbrand Cc: "Russell King (Oracle)" , Ezra Buehler , linux-mm@kvack.org, Andrew Morton , "Mike Rapoport (Microsoft)" , Muchun Song , Vlastimil Babka , Ryan Roberts , "Vishal Moola (Oracle)" , Hugh Dickins , Matthew Wilcox , Peter Xu , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , open list , linux-arm-kernel@lists.infradead.org References: <5d50d714-197f-44c0-94e0-ff70ee51e866@bytedance.com> <34bcf011-b4ac-479c-92ce-852623e73039@redhat.com> <3f7babee-b232-4e6b-a896-947150dcd1ef@bytedance.com> <2b0bb476-5bd6-489a-9b9e-7aa20964abfa@redhat.com> <4e298f68-36ff-496a-81d2-7124f792180d@bytedance.com> From: Qi Zheng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: CA505A0008 X-Stat-Signature: h1dozcefe8yocufm5zmsjk9uwokjyijp X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1739277683-137594 X-HE-Meta: U2FsdGVkX19m7ra6e0wYW8aNtvqfLb5p4worGoNYE54EbCVWHBGCDt3yOOG92NDilmNS/sxOxlY6k3nVCgmGfLm+APuG/USZefTafyZp9jhI3r0EnzgZxM4uOJAnKqe1uYLdHcY9AypmoGSayfelG3hWInhM9DKta8uJsPvAqxpKl+USnPXJWJNzV/OxNAMxdrs5btpfLStV2zcaTCk8EuOPqwPnoXjEORFWWs1EBVr91Djo/zl8/7SlM/CJWwuI9p4uXW7+6LCFgv60FqaSfW9t4Pikr2M4U5lB9rB4aTw5jJ9PgRQgPKxzZg1EUHFgESzu6R6CCl2u8mfAHdiy49GpQKjwHGQjlAGgQvmDhWQSDF/Py7l42eZ9LoBuKINiNU5GEHNDybAyVZN8FiyVBwAjpo4AGp5BDYgJPW139YJoidb3CKzKPYsc9dbXFnRB/MhV1sBiEtjtr7ml6dA4hlfNDaax0hjKmowZ73zScTUdRpdUiS8y54lqlQksHfDYu93xelxtMgG3+bJPj0Cf+ejZOV0nozHpYhokc0ivJm/U+Bn9QOaxtT6pHEmYZfFIMp+t/SzupW4motPr+lo6ziOrI9y19EbMCD83DEswHT30TK+wnw+Vmj0IC1jA2uCvy/Y18STp/41Mrvuyy1ojwv/n+sK3JqTk8PMmQm9wDVMVR/iakDtXEI1P0FPeCYysBV6FXqha8UIelx7Lt0y6AnaB70eG42yrSYrGT4iAuO62p3RsMuufGnx8oVnTuOVHknKRVErzB1TuKRYgtdUzPl3aTTNqS9s1zwRJvNnKasv8TjByf+UiLYcxe9AUDR9lvvWCpSt0XePn1KWPG2gk1IH7NVTZ9Me8eGmVww4oye62SUXYTE4W6pA/JSJQG4BrM6+urbi3lNSlcwtgwFY/YWB9NOxNYk9Lad0oh9eS/5yRY6omwdUD9xas0PTVa/gcFmMumg1XJUGP+bupw0X gj/fBtkB bAQO6Tw2QRiAdAQGU3j95yUlzD1uOMiChdjTb/XjA/ziPmSXN5Ug+KgWwVA29nyJAJS62PAeayJE+jtISxl15g0pTmMpD40jy/W06LCZjAs5xoHE9cKkf07/k4QBqAGzwoXTISSkY0jAEPJg09QpG1Zv41UUfm1n0vcR87ulnpSvJFXUceMbP+ASs1RaNpsNmDZ0ib/GxwQar2AFGoHrDLsqlixlllvNcoKm9/0KJ8Tx9l8tSQlU8g9bpNB3g6Qs0ZJOS082hVOxwTwskwy26YXgfUG9CNhTNjQpUPFc6JyLUV2Z7TVC7ujqnuw+2VRKt6TIgc6we/f8J7WvuD/fhxm6pnSXXDv0QJhd9SJA3X+KPnzvZg5PIPwoq7o5uDSrdn7gheLSDxw/9L33f84lKr/mgRCPXVfE2iLbDM3PIcCYTAa9d2ToGVCRe7Q== 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 2025/2/11 20:09, David Hildenbrand wrote: > On 11.02.25 10:43, Qi Zheng wrote: >> >> >> On 2025/2/11 17:37, David Hildenbrand wrote: >>> On 11.02.25 10:29, Qi Zheng wrote: >>>> >>>> >>>> On 2025/2/11 17:14, David Hildenbrand wrote: >>>>> On 11.02.25 04:45, Qi Zheng wrote: >>>>>> Hi Russell, >>>>>> >>>>>> On 2025/2/11 01:03, Russell King (Oracle) wrote: >>>>>>> On Mon, Feb 10, 2025 at 05:49:38PM +0100, Ezra Buehler wrote: >>>>>>>> When running vanilla Linux 6.13 or newer (6.14-rc2) on the >>>>>>>> AT91SAM9G25-based GARDENA smart Gateway, we are seeing a NULL >>>>>>>> pointer >>>>>>>> dereference resulting in a kernel panic. The culprit seems to be >>>>>>>> commit >>>>>>>> fc9c45b71f43 ("arm: adjust_pte() usepte_offset_map_rw_nolock()"). >>>>>>>> Reverting the commit apparently fixes the issue. >>>>>>> >>>>>>> The blamed commit is buggy: >>>>>>> >>>>>>> arch/arm/include/asm/tlbflush.h: >>>>>>> #define update_mmu_cache(vma, addr, ptep) \ >>>>>>>             update_mmu_cache_range(NULL, vma, addr, ptep, 1) >>>>>>> >>>>>>> So vmf can be NULL. This didn't used to matter before this commit, >>>>>>> because vmf was not used by ARM's update_mmu_cache_range(). However, >>>>>>> the commit introduced a dereference of it, which now causes a NULL >>>>>>> point dereference. >>>>>>> >>>>>>> Not sure what the correct solution is, but at a guess, both: >>>>>>> >>>>>>>       if (ptl != vmf->ptl) >>>>>>> >>>>>>> need to become: >>>>>>> >>>>>>>       if (!vmf || ptl != vmf->ptl) >>>>>> >>>>>> No, we can't do that, because without using split PTE locks, we would >>>>>> use shared mm->page_table_lock, which would create a deadlock. >>>>> >>>>> Maybe we can simply special-case on CONFIG_SPLIT_PTE_PTLOCKS ? >>>>> >>>>> if (IS_ENABLED(CONFIG_SPLIT_PTE_PTLOCKS)) { >>>> >>>> In this case, if two vmas map the same PTE page, then the same PTE lock >>>> will be held repeatedly. Right? >>> >>> Hmm, the comment says: >>> >>>           /* >>>            * This is called while another page table is mapped, so we >>>            * must use the nested version.  This also means we need to >>>            * open-code the spin-locking. >>>            */ >>> >>> "another page table" implies that it cannot be the same. But maybe that >>> comment was also wrong? >> >> I don't see make_coherent() ensuring this when traversing vma. > > Right, we could just have the same file range mapped MAP_SHARED into the > same page table using two VMAs ... I suspect writing a reproducer for > the deadlock should be easy. I guess so, but I don't have an arm32 test environment yet. :( [...] >>           vma_interval_tree_foreach(mpnt, &mapping->i_mmap, pgoff, >> pgoff) { >> +               unsigned long mpnt_addr; >> + >>                   /* >>                    * If this VMA is not in our MM, we can ignore it. >>                    * Note that we intentionally mask out the VMA >> @@ -151,7 +178,14 @@ make_coherent(struct address_space *mapping, struct >> vm_area_struct *vma, >>                   if (!(mpnt->vm_flags & VM_MAYSHARE)) >>                           continue; >>                   offset = (pgoff - mpnt->vm_pgoff) << PAGE_SHIFT; >> -               aliases += adjust_pte(mpnt, mpnt->vm_start + offset, >> pfn, vmf); >> +               mpnt_addr = mpnt->vm_start + offset; >> +               /* >> +                * If mpnt_addr and addr are mapped to the same PTE page, >> +                * also skip this vma. >> +                */ >> +               if (mpnt_addr >= start && mpnt_addr - start < PMD_SIZE) >> +                       continue; > > Hmm, but is skipping the right thing to do? Maybe you would want to Ah, your concern is that in this case we may also need to maintain cache coherency. I'm not sure about this. > indicate to adjust_pte() whether it must take the PTL or not. Indeed, this is a better approach. Will do it, and hope arm people can help test it. Thanks! > > I did not study that code in detail, though ... >