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 C748AC282D1 for ; Thu, 6 Mar 2025 04:52:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A621F280003; Wed, 5 Mar 2025 23:52:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A1252280002; Wed, 5 Mar 2025 23:52:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FFDE280003; Wed, 5 Mar 2025 23:52:25 -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 738C7280002 for ; Wed, 5 Mar 2025 23:52:25 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8F731C0F67 for ; Thu, 6 Mar 2025 04:52:26 +0000 (UTC) X-FDA: 83189905092.10.A5BFCA2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id 4E38880006 for ; Thu, 6 Mar 2025 04:52:24 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=T4DxHqsR; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741236745; 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=PSV6KR/L2RCJUIUbykQwn+3XqvL7U90zxgqKneqEbw0=; b=YKixWodxDqBB7P58xhd62wr80Yyy6pBdN+IsgaxhLXxFhllqUvvffNa7atWxwzasdUQveQ ZFhgsfADAfsZyl7FpGP9uI4H5wS2IDb8dIMUCLSrO2fxRc7alilq3kG7y7egIOLkLLxWLn egiJInZv+2uLrpiQIHI+uriwsja22pw= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=T4DxHqsR; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741236745; a=rsa-sha256; cv=none; b=ZWIdw9Iy9/KTTLbcxHLuDUnXoj9jyiRPF2JcJmSIo8OYs11GyLP/eE1PkmZmFSCiXepfps ijNU++y/gd3x4nYbgW//Id9Hr605JZTl3Gz9pdpSlndwd/5jIHCMgK0OpIMN6dUgQHawiu VEcE56GSkQrYdGvDEh+MrYHLzLHEEBE= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=PSV6KR/L2RCJUIUbykQwn+3XqvL7U90zxgqKneqEbw0=; b=T4DxHqsREMzOnsxlv3u/oTlt+/ 73IurSXLrDcL0/sykIwVZy8bMG38iXhrTyeXxr0tJxqK6NsRHlVcz1I1JFyveu9DmttTGiQUdWY4G eIooopUyLYl62tVcrpTdhURvmbOG9gVuCd6v3tC300MxtQvHlr0zl7UCz4LZdHzeH8QzYX/PluICc 3FJLvIAawW2nQrnKgxsilYLe3E4WD1sehIBLWCy3sAUc2Inn1gQz0byszk6BgdnyHBGFkFudqN3/U XGugWdBVKT/HbLBipL3kbyR9HwW2I36Pzmyd13eikwCwYYwrSlug9ac2HwSJMBDaRd1qdd9+Jsc6Y 4av/S6dg==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tq3DJ-00000006oty-2yf4; Thu, 06 Mar 2025 04:52:05 +0000 Date: Thu, 6 Mar 2025 04:52:05 +0000 From: Matthew Wilcox To: Ryosuke Yasuoka Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, kraxel@redhat.com, gurchetansingh@chromium.org, olvaffe@gmail.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, dmitry.osipenko@collabora.com, jfalempe@redhat.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, virtualization@lists.linux.dev, linux-mm@kvack.org Subject: Re: [PATCH drm-next 1/2] vmalloc: Add atomic_vmap Message-ID: References: <20250305152555.318159-1-ryasuoka@redhat.com> <20250305152555.318159-2-ryasuoka@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250305152555.318159-2-ryasuoka@redhat.com> X-Rspam-User: X-Stat-Signature: mgb74mysxorwpbyzw6pe4ydwbuxqjxh5 X-Rspamd-Queue-Id: 4E38880006 X-Rspamd-Server: rspam07 X-HE-Tag: 1741236744-362029 X-HE-Meta: U2FsdGVkX189TlRHeRBIYod1cA5GT3kOvx8X6+iipZh/kXjvLbj1l/w6RZiXy4Yf4vDD+mZZ0lL6X+VycNdX4UpqrWT+4zZmqHqd4+BPc/8+F0gQ7Xi+lR+VN/IRYhTmshDH9rjxGvHWAA1FzDdgz1LzZ4z3Xl3aUOiYVDtxZOHjoUrOFVzzOpR+YbJCVQufp5XdXwGQ6lNSlSE6rgXeqfGsovoh2U577YkMrHfpxoh/kltb2jaARwEEdXwp5I/dZGS2vLfX0ph821Xn9x8hmyNVzWhYNa7cZ2iZvgbgaOESfpIaDK3Fu/Ead4utFM96boy3uIz/cWdigaaysmfsd2lfgRnVNDxQwOEQkJA/seR2Izrho3mECMNbXB8zD6TUI8vnaY4/oM8gtHmtLlKeOgBaap5dHE83Ibq2cU1XqTRbodHKMl1q3micPTgL9SmzevBz4iuiOGHi3b7LU+qlDcXjY4+KQfEVhHixpnywCe9KugYO+7wKODszLNoJ8QpE+VEompy1nFjzgNxQAHw6HllO5N6525AelX58KPLMOiy6VtzwQTqe+npMfS9CB6XgE9MZMypC/miRi+gXrDjtshuU/OPpkctXpmgzPNpoulBguwMLrwe0ssKGl3SNDAE1H9EQI2rmJb07RrxEiwROfrxOmfrYOIrcjvnD5W6tzzQZYCF22LEXb7uw4xjpRtydiPx5bF2yktDn3ZKcxrBSGBzZAOHFIJ/onX+VYWLQleSiR1BV4whT6pU5+BJtxpII59uKNSGoamPcwXlXyHHe0Q9NawtINtAHJ+B5QadUiifY3B3KdwVaONRiJyNlbJIBUPvKT1sQEqHyYnTxTS+U6I7TJgYc3sS9aRACKwXqfEJWDdqFv53PpdmI83Usj/nhJwmWhW1G9jjST1iDgLJ/7cdazJ+FhY3g75J1Swy+Lm1vfvOc1vvWYc+DiJig+V9pgqIPqD5vd+WLz/PY9EJ Zz5sK7Bj 1kGsqS+ehxkpidZGauygBvNDwqlWuI3GcHbp6n7FIS42R7Vwzi7NxN6VT61DK0vEqAzy/tct0DsQ6d9L2TxRX9WVV2HM9+7wfOMTGiY/7NlvMOGF34Jj/JmsYvvtGb/VqNs2YGQKDNymN7+x0jkHqTIBWCQ6Pc+IM++ynDi8NWIFoLXSpMmqWo2eZed6U9khMmxgJ/wP2nqPRlAVk/NJZWPhbBefYEl4QOdTHlF9jdRUg3ktRb+gow9INbimdoJcHvRPz6zhbViEQpczDFcNNJIItMQ== 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 Thu, Mar 06, 2025 at 12:25:53AM +0900, Ryosuke Yasuoka wrote: > Some drivers can use vmap in drm_panic, however, vmap is sleepable and > takes locks. Since drm_panic will vmap in panic handler, atomic_vmap > requests pages with GFP_ATOMIC and maps KVA without locks and sleep. In addition to the implicit GFP_KERNEL allocations Vlad mentioned, how is this supposed to work? > + vn = addr_to_node(va->va_start); > + > + insert_vmap_area(va, &vn->busy.root, &vn->busy.head); If someone else is holding the vn->busy.lock because they're modifying the busy tree, you'll corrupt the tree. You can't just say "I can't take a lock here, so I won't bother". You need to figure out how to do something safe without taking the lock. For example, you could preallocate the page tables and reserve a vmap area when the driver loads that would then be usable for the panic situation. I don't know that we have APIs to let you do that today, but it's something that could be added.