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 E5C34C43334 for ; Tue, 19 Jul 2022 15:51:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DA706B0074; Tue, 19 Jul 2022 11:51:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 48A786B0075; Tue, 19 Jul 2022 11:51:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 352AC6B0078; Tue, 19 Jul 2022 11:51:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2772B6B0074 for ; Tue, 19 Jul 2022 11:51:02 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D6C0B1C5B4C for ; Tue, 19 Jul 2022 15:51:01 +0000 (UTC) X-FDA: 79704287922.05.C72FF41 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 5A3BE18007B for ; Tue, 19 Jul 2022 15:51:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658245860; 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; bh=bytx0BWlQSL3lnY+bN1k2KN/IEh6mXjIzTlnoLU+R44=; b=apYHdp/NyGaxY8KjZ9zzSeByoW+NGf1vNQZkcaB3VDfKaWVh8JOddHGT5dgF6gwtVd1ZzQ jb2s3EhACqX7hN1SfgE6hwoPvPyycyEARR0pWq7SpCVR7iJs+VmUgPQMA4AfV5pg6Cvh0g xbt/ptXhrN8Lj/qp01JW0W6YNn9RkJ4= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-375-RGxKjnf7PoGc-AP84kG4ig-1; Tue, 19 Jul 2022 11:50:59 -0400 X-MC-Unique: RGxKjnf7PoGc-AP84kG4ig-1 Received: by mail-wm1-f71.google.com with SMTP id h189-20020a1c21c6000000b003a2fdf9bd2aso6948003wmh.8 for ; Tue, 19 Jul 2022 08:50:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=bytx0BWlQSL3lnY+bN1k2KN/IEh6mXjIzTlnoLU+R44=; b=F5iRBNDWbjwr9xA6RKt1EV/gUxtUO3JKoQV9giKbcqbV42xnHXGOIC6THNbZvAMezY Rz+E9TQs2ngiYskuLNptCllHDEoxE2pnbJ4X3G5VQbB93CuTvxlCnQILBt3BwCA25CRA zJV+kKbsZFYdiL7m95n2UUEC6h4JIPH4wwwMW0DvPpuf8lzFk3NvoZ5VFF4qKtGSBxWZ 937et8qtxX2Nbet7JMwcTLpIl5is9gbmzSmev4G9FOzFVf8iUPkCHewD965B4o8+bw3o CAIRR/gm6O8eHPptZJ/1HJsOwART3OB1I7lJwUBqExhiDOglAfQWssZ1ZBu+lvMLuJoD 2JGQ== X-Gm-Message-State: AJIora9tjLVqy32pKlrJdU3DAMywyQUy8Kjsrg1+niBDptr4M5ENgckM +Qelh6ZYfxE1JZ5DBdXIwAN6fGzciB+c3AIluRtO2GJQfKv22wHypXanhyOzbiLw1x4jN6O9Iy8 Ev6UqcV11pE0= X-Received: by 2002:a5d:6489:0:b0:21d:a9a1:3511 with SMTP id o9-20020a5d6489000000b0021da9a13511mr26418127wri.626.1658245858374; Tue, 19 Jul 2022 08:50:58 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sMzKHTkKdvFnFWDj04IvUBb2vwu3An8lHFZRWwftgjMUJ3NyEdhiR7vhJwlkJKNTox9kKrug== X-Received: by 2002:a5d:6489:0:b0:21d:a9a1:3511 with SMTP id o9-20020a5d6489000000b0021da9a13511mr26418114wri.626.1658245858130; Tue, 19 Jul 2022 08:50:58 -0700 (PDT) Received: from ?IPV6:2003:cb:c709:600:7807:c947:bc5a:1aea? (p200300cbc70906007807c947bc5a1aea.dip0.t-ipconnect.de. [2003:cb:c709:600:7807:c947:bc5a:1aea]) by smtp.gmail.com with ESMTPSA id m18-20020a7bca52000000b003a320e6f011sm4223270wml.1.2022.07.19.08.50.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Jul 2022 08:50:57 -0700 (PDT) Message-ID: Date: Tue, 19 Jul 2022 17:50:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 To: Michal Hocko Cc: Charan Teja Kalla , akpm@linux-foundation.org, pasha.tatashin@soleen.com, sjpark@amazon.de, sieberf@amazon.com, shakeelb@google.com, dhowells@redhat.com, willy@infradead.org, vbabka@suse.cz, minchan@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, "iamjoonsoo.kim@lge.com" References: <1657810063-28938-1-git-send-email-quic_charante@quicinc.com> <6fa6b7aa-731e-891c-3efb-a03d6a700efa@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm: fix use-after free of page_ext after race with memory-offline In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658245861; a=rsa-sha256; cv=none; b=yJoI0Lm4xqJhhJPfWvxNrc3v2CX2E+EdjASs6lGmFCX+397Eqz41JXA3wCJwPD2GO6yfq/ k3ReVpdYLCFZybvnAWDA83KWPntNPOLndTOAlEiFxaOZuAwUHBvMBBFhcK+UWBCKkea6Wt +Exgs6Hq0QyK62hLmyia8UK/IJXe8Eo= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="apYHdp/N"; spf=none (imf24.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658245861; 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=bytx0BWlQSL3lnY+bN1k2KN/IEh6mXjIzTlnoLU+R44=; b=Rzy0ZoRkh0vD4GmL1JfASVHG2vg/G8e2eYqMEYveaSUfm57aIF+rgt5bmd36qCPioh+QVz CpQS4WNlKiapsH0Kh/yzqKM5SfD0lBYutw/Btf8nwcfN1Z0fx6Iih3wkfEOVx8auLf+HGx I8GjxqvjqgkEGNUdxkCkUPR96VEr6WY= X-Rspamd-Queue-Id: 5A3BE18007B Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="apYHdp/N"; spf=none (imf24.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: jzbtyfdqd6rke41wop8dfogqwtybrent X-HE-Tag: 1658245861-358825 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: > >> 2) I really dislike having to scatter section online checks all over the >> place in page ext code. Once there is a difference between active vs. >> stale page ext data things get a bit messy and error prone. This is >> already ugly enough in our generic memmap handling code IMHO. > > They should represent a free page in any case so even they are stall > they shouldn't be really dangerous, right? Good question. The use-after-free tells me that there could at least be something accessing page_ext data after offlining right now. As long as it's only unsynchronized read access, we should be fine. > >> 3) Having on-demand allocations, such as KASAN or page ext from the >> memory online notifier is at least currently cleaner, because we don't >> have to handle each and every subsystem that hooks into that during the >> core memory hotadd/remove phase, which primarily only setups the >> vmemmap, direct map and memory block devices. > > Cannot this hook into __add_pages which is the real implementation of > the arch independent way to allocate vmemmap. Or at the sparsemem level > because we do not (and very likely won't) support memory hotplug on > any other memory model. As __add_pages() is also called from mm/memremap.c where we don't want that metadata, we'd have to special-case (would need a new parameter I guess). > >> Personally, I think what we have in this patch is quite nice and clean. >> But I won't object if it can be similarly done in a clean way from >> hot(un)plug code. > > Well, if the scheme can be done without synchronize_rcu for each section > which can backfire and if the scheme doesn't add too much complexity to > achieve that then sure I won't object. I just do not get why page_ext > should have a different allocation lifetime expectancy than a real page. > Quite confusing if you ask me. In contrast to memmap, people actually test for zero pointers here. If you ask me the memmap access is ugly enough and I don't really enjoy other metadata following that pattern of "stale and suddenly removed". Here seems to be an easy way to do it in a clean way. But yes, if the synchronize_rcu turns out problematic, we'd either have to optimize or move the allcoation/free phase. -- Thanks, David / dhildenb