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 F1900C7EE23 for ; Wed, 7 Jun 2023 13:42:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 402FF6B0071; Wed, 7 Jun 2023 09:42:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B3BF8E0002; Wed, 7 Jun 2023 09:42:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 27AEA8E0001; Wed, 7 Jun 2023 09:42:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 19ABE6B0071 for ; Wed, 7 Jun 2023 09:42:09 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id DDB69402E4 for ; Wed, 7 Jun 2023 13:42:08 +0000 (UTC) X-FDA: 80876065536.22.F0246A4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf18.hostedemail.com (Postfix) with ESMTP id 9E7371C0028 for ; Wed, 7 Jun 2023 13:42:05 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="EI85S/O7"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf18.hostedemail.com: domain of aquini@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=aquini@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686145325; a=rsa-sha256; cv=none; b=BaDVl5oR5HKemGoXjlERoGLkwAYpgZ0bm4mIH5NdUfixf6Ob/L0BUp81I2Y7od++Fhtf2A uYtI2XbHyQ/U+pADF7Zev+8+VPhLYjqpc094XkJxNpmXvPSi+e2XPeUY2tvEpVomjeXtFY +vJ32VRKkUe19nGgtXHZMsplpnlkNzE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="EI85S/O7"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf18.hostedemail.com: domain of aquini@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=aquini@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686145325; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=spKLLuP6O+r1s/hdstXAgJMud94UgSfX2gIBHfXK4vw=; b=YJP8tHiBZUgeF71TiTMlvtrGCCUKYOkKRj3Xqpyt/u2MaigMu+bv4/RMth9NJ+hJ5zel3W tDuI42ZXeB0z4ElwRPdTuXdg376w5YrWZ3+XVar7c75jPIZSd3yTgaRqegnaKp59EJVZ76 6Bax/B9yNJwu55Xx5fp5Pjge+0b3WFY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1686145325; 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: in-reply-to:in-reply-to:references:references; bh=spKLLuP6O+r1s/hdstXAgJMud94UgSfX2gIBHfXK4vw=; b=EI85S/O7p6Dr2Nl3wS2nO4hWcugFWCOTYdiouxA59XWDgrEbxV2Mulq8pnhamxFB1q9M04 v1qjasMwq+j/PYJZ+RkF+ncXY8L8+8f7N/vTwkgBHMiuB8arrTlwIXjpk6GiJ83BXr6vUT oUSmudv9p0wu7umStEshZdJ2dtG6GZ8= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-52-LnUs0dDeP_mqRoN2JlKixQ-1; Wed, 07 Jun 2023 09:42:03 -0400 X-MC-Unique: LnUs0dDeP_mqRoN2JlKixQ-1 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-75d54f2b6c4so446278985a.2 for ; Wed, 07 Jun 2023 06:42:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686145323; x=1688737323; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=spKLLuP6O+r1s/hdstXAgJMud94UgSfX2gIBHfXK4vw=; b=MZ6fuTqEVntg0tyW3IXdis9ciEdtI/y0dbDUzpde/fXe8rAG2VYngcvINLG8bSXGcJ y+xcJur/FfPDNZMDgnh1iGFL7ncZ7dc+rP3M8+ZXRRy2aqO//P/04ZHkLzdDHe0aj5jY 5e3Y5PieDgqhRqhW4FS3C/dlR4f3IkBgra0D69l9gDiWBJcNb+MsHrIISMxLnFfBpWKE 6G16mMBqG+qgfY0jIepBgg8RkBeiT0Hn64YklHX1SVgEsXjGbXRLcxqqO6qUKCUVMvI1 axnPqPB4jsmzXL+8ks9gIbZcFGsfmk2telKefCUiuG8SyEXoeo9TrcwaZAdfUZu0X8I+ GD7A== X-Gm-Message-State: AC+VfDy1nWhVqc8KHfzXqixTrFgWdbijgq/l48uV8gHuriUSsErtrH8g FkCxhPrDOv/ICb6ptmAlheMpJ3TdULq3SuNWTI0PwrBW2w49Vj34cg61eRU4w7kFWz4RjoRhr5N TbZ1I8wkB2Qw= X-Received: by 2002:a05:620a:8d1:b0:75e:c57b:474c with SMTP id z17-20020a05620a08d100b0075ec57b474cmr2068447qkz.13.1686145323169; Wed, 07 Jun 2023 06:42:03 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5l7U5JgSV5T13cY5RpvTXXPfzQF/3Pku47suOZclV2+2Jk7neTSNpvNSmo/U6zAtW9LufRcg== X-Received: by 2002:a05:620a:8d1:b0:75e:c57b:474c with SMTP id z17-20020a05620a08d100b0075ec57b474cmr2068424qkz.13.1686145322889; Wed, 07 Jun 2023 06:42:02 -0700 (PDT) Received: from optiplex-fbsd (c-73-249-122-233.hsd1.nh.comcast.net. [73.249.122.233]) by smtp.gmail.com with ESMTPSA id c25-20020a05620a11b900b0075c9e048b19sm3139720qkk.29.2023.06.07.06.42.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jun 2023 06:42:02 -0700 (PDT) Date: Wed, 7 Jun 2023 09:41:59 -0400 From: Rafael Aquini To: Andrew Morton Cc: Yafang Shao , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, Aristeu Rozanski Subject: Re: [PATCH] writeback: fix dereferencing NULL mapping->host on writeback_page_template Message-ID: References: <20230606233613.1290819-1-aquini@redhat.com> <20230606174448.ba45510067bcb35b9ac7e739@linux-foundation.org> MIME-Version: 1.0 In-Reply-To: <20230606174448.ba45510067bcb35b9ac7e739@linux-foundation.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 9E7371C0028 X-Stat-Signature: ww4urbz7rtaezwahs6euefj94jycfiqf X-HE-Tag: 1686145325-935167 X-HE-Meta: U2FsdGVkX18zCQieI2gNAloEM/o9q3VwG9PJ+bQjYPfinFnaW9kCA88+I2LPjnRF3KcjEYcJIguxrbJaK3ig+imBhGmmVbZcC1WK22dmpNt7KQXQAFET/wJsqOYBpjnX2BGJWFGaQ+zb+YdSIOl48lMQD9ByPXNOXQsG6lpcatDsW+V82DKHZosYhq2EyfmbfjizVn1jXyIzhkyrgVCAo9QK6hH/HTRgCUqRYGU5WMAdznBgVqQnFDFGaPNjSeseza1eHLuhmV0u2nKWRodtWl3A4azSJReJRxYN8Xk4dOx7uVdTZlCCbxdBR7wIFxEEwjzU/97G2mH645jt+nz2zulEEN/62vGu1yYDsgMp7YUsqUgrcDU8MlOjByRjFNRSiEBPWnpu/ICg0L1KQBy3bKNZlhuUsEoSIo3wlmVGQc0E7Sh90HcypW+xvglsNt+lyWKIh//ZDzKnSY1r/STxv8ed8JuFBFvdiG13sRVmRKLTQVSa2yEz67Joi5x0Zz5sMC6v8X1NU8120yIkEdefMGe2i2EkK0hZj0cJ9FwuK7tRNur0K9UCL+dXf8NJj+Isz0ROD9xmmMg9hNYAd9tvtU5L4HXIdet6Tk0dAjjVb6F3mVdTT4oMFUxzmvL748zqCirpjzWB1A4j9u/C2H8Ts3jJdJhVvK/klGapSYvMoQPQePUQtagfcSz7fzMV+LaCxoPJbQ/rMpQAKN3vUY6bSpP7+bLrzsR0OmvHwqDC9jfYdpCysH+nSM6up1zmXugmPr+1Wbxgfocvlm/fnFwTSwT8ffmvrgavFWc1iQ/DbHvPybNyk33Pt8JhpObVUPW7yFRJ/pbwS9Nlk/CChnb/52Zl14DSI74uvqAPxSdp/SP5+GOFPOExyzzlyN3E9nDe1YlmzmA6J4xAaxUSXthBmtuTArFSCZI7rRqNUSh2TWeGMdLBd3On8kAnJIFRtEl254zFkBKIQXIjvytsP7m VRP8O7Er hMAmDpn1JbGWd9QWIXMQrHHxRz6u1zlrfTL3iWDanM4OyypQKLNIcMhirIdL+PxkDKmvDunsOea2kbLCJDmkA+8ybhXktnHD+f+eNqZWcoRYeWULhKTJNSWH+6gIh1Muz94gg3+rzTYs0j4Ugsaeq0YUzqoxfaOeLXbZDmfiOQek5GTbionxp7Lgetz/SWeo6S/NR6DVcCHu5fsPD37rWsTMPu+KW70bNspqS82NBckXSgFKhFSyZ1tySVnd9v55HCa97xoEMHEPbHox0jiA1MorkJ6l1ItPK6l2siVJtZrSMoE7ygQ1rnup8nBZ5GqwcXC1K3CK7sSk0Rz0TRWQA3+ljKOtX+lmksYyL4F+HbHCjo++7CFqZYvSRRhvn79d1VtW8yUXPWIFq2LTPw57PjDysYSdVLbHDoWqDUYyWP1Dl9vJQ06DKzE50NvLnsOkyRBJrNW59QgBZcWiwSYflD/htDRJlxFqL2pS6R5K4RQYECsbHdFsF0tSZ3Q== 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: On Tue, Jun 06, 2023 at 05:44:48PM -0700, Andrew Morton wrote: > On Tue, 6 Jun 2023 19:36:13 -0400 Rafael Aquini wrote: > > > When commit 19343b5bdd16 ("mm/page-writeback: introduce tracepoint for > > wait_on_page_writeback()") repurposed the writeback_dirty_page trace event > > as a template to create its new wait_on_page_writeback trace event, it > > ended up opening a window to NULL pointer dereference crashes due to > > the (infrequent) occurrence of a race where an access to a page in the > > swap-cache happens concurrently with the moment this page is being > > written to disk and the tracepoint is enabled: > > I don't see what the race is, or why a race is involved. > > > BUG: kernel NULL pointer dereference, address: 0000000000000040 > > #PF: supervisor read access in kernel mode > > #PF: error_code(0x0000) - not-present page > > PGD 800000010ec0a067 P4D 800000010ec0a067 PUD 102353067 PMD 0 > > Oops: 0000 [#1] PREEMPT SMP PTI > > CPU: 1 PID: 1320 Comm: shmem-worker Kdump: loaded Not tainted 6.4.0-rc5+ #13 > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230301gitf80f052277c8-1.fc37 03/01/2023 > > RIP: 0010:trace_event_raw_event_writeback_folio_template+0x76/0xf0 > > Code: 4d 85 e4 74 5c 49 8b 3c 24 e8 06 98 ee ff 48 89 c7 e8 9e 8b ee ff ba 20 00 00 00 48 89 ef 48 89 c6 e8 fe d4 1a 00 49 8b 04 24 <48> 8b 40 40 48 89 43 28 49 8b 45 20 48 89 e7 48 89 43 30 e8 a2 4d > > RSP: 0000:ffffaad580b6fb60 EFLAGS: 00010246 > > RAX: 0000000000000000 RBX: ffff90e38035c01c RCX: 0000000000000000 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff90e38035c044 > > RBP: ffff90e38035c024 R08: 0000000000000002 R09: 0000000000000006 > > R10: ffff90e38035c02e R11: 0000000000000020 R12: ffff90e380bac000 > > R13: ffffe3a7456d9200 R14: 0000000000001b81 R15: ffffe3a7456d9200 > > FS: 00007f2e4e8a15c0(0000) GS:ffff90e3fbc80000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 0000000000000040 CR3: 00000001150c6003 CR4: 0000000000170ee0 > > Call Trace: > > > > ? __die+0x20/0x70 > > ? page_fault_oops+0x76/0x170 > > ? kernelmode_fixup_or_oops+0x84/0x110 > > ? exc_page_fault+0x65/0x150 > > ? asm_exc_page_fault+0x22/0x30 > > ? trace_event_raw_event_writeback_folio_template+0x76/0xf0 > > folio_wait_writeback+0x6b/0x80 > > shmem_swapin_folio+0x24a/0x500 > > shmem_swapin_folio->folio_wait_writeback will always pass in a page > which has ->mapping==NULL, won't it? So why doesn't it crash every > time? > Hey Andrew, Here's why we end up looking at the swapper_spaces[] address space, for this particular case: void folio_wait_writeback(struct folio *folio) { while (folio_test_writeback(folio)) { trace_folio_wait_writeback(folio, folio_mapping(folio)); struct address_space *folio_mapping(struct folio *folio) ... if (unlikely(folio_test_swapcache(folio))) return swap_address_space(folio_swap_entry(folio)); when the shmem swap-in path stumbles on a page in the swapcache that is still under its way to disk (via swap_writepage->swap_writepage_bdev_async->submit_bio) the tracepoint, will get a swap_address_space pointer back from folio_mapping()