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 8E0DCC282D1 for ; Sun, 9 Mar 2025 08:08:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4CF49280002; Sun, 9 Mar 2025 04:08:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 47F99280001; Sun, 9 Mar 2025 04:08:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34752280002; Sun, 9 Mar 2025 04:08:17 -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 16D4A280001 for ; Sun, 9 Mar 2025 04:08:17 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 31126142382 for ; Sun, 9 Mar 2025 08:08:17 +0000 (UTC) X-FDA: 83201285034.16.27BF045 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf14.hostedemail.com (Postfix) with ESMTP id DA2D6100004 for ; Sun, 9 Mar 2025 08:08:14 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SbNsWys8; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of ryasuoka@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=ryasuoka@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741507695; a=rsa-sha256; cv=none; b=K9KO8s+puUTm3gEy9+aDcybI8AhXRCjM5Hb8Hl7aRw66gf4OpFF5uDe/i/RQFBPOsTGdne 5bEoT+hspXZg1yxMWit+iPDtUCz4FUf2/lh+QAjO3FCeGyLieRfQLYWP49Ch3HppMRpbqZ nm5JhOC+ATTpYXUzAVUm8IxfM/njd3U= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SbNsWys8; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of ryasuoka@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=ryasuoka@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741507695; 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=VMLbs4g+4S3w8PTcwZhqCiZ4jHgvhgmMpYzifm6s+EY=; b=bahe7LxkpfkULyxovfrx8wevWRxDDFTDDJ/u8qAxXHdeA0XCp8Y1lFgMbkBmep98fLkeCz 8Mxb7srGQqx7Qt0h5mYBQ7WpP5TJfDAESydigVs5uoWMMr8RHG01e3b+LC6WCZDqJh79/M b3Wib4KP9Wp0lXu70HWiKPWc2MiXOE0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1741507694; 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=VMLbs4g+4S3w8PTcwZhqCiZ4jHgvhgmMpYzifm6s+EY=; b=SbNsWys8uYmuQELkadRLZhHt2ajZxt53tjndRg5kh2twPvKMzb43TO8NCsZSiSZ7Qiux6d ZTpV/GWIqq94nOI2WRno+sdIl1GqzNeKv5FLd77JY5YdPDo2y47UkU3uy15vEvoTcsllBz 20UgQqlt4TCc3CZdCmNaSeN+e9aoqWM= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-460-_J4wViyaO2WJPyHd9Ushpg-1; Sun, 09 Mar 2025 04:08:12 -0400 X-MC-Unique: _J4wViyaO2WJPyHd9Ushpg-1 X-Mimecast-MFC-AGG-ID: _J4wViyaO2WJPyHd9Ushpg_1741507691 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-ac27ea62032so53224166b.1 for ; Sun, 09 Mar 2025 00:08:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741507691; x=1742112491; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VMLbs4g+4S3w8PTcwZhqCiZ4jHgvhgmMpYzifm6s+EY=; b=lhoT+nyWaWJbW32DTwYF9dDZlraqbOJREiZOB5j8vw0DswB+icUzHkRtYWa7skEMEi fHImcMwsQZZPjmN0t0Vpzf7Jbh1IsxdKIMYX8zqZ6yBsYoO+SY9f7cwq3VwkbbWaMtwX 1EGu68Nhdq8LEyBFYakwFEWi99aF+KRlMrsXOJxDvwMzj+bg1e8GftZo8RhvVX5L+qmM btyO+JNeS5NrpML/5UObvdnEf33MtXJAwptAnlBDgwodtTtc4cnImm3hZTFBu63uOmgK lKzZdvSM1M7TeIjQ+pOguOjg8/iZBHygjMRFjz5TfeLI5DCMbvFmq+hj7tvn7WNFiUuA F12A== X-Forwarded-Encrypted: i=1; AJvYcCUr9U6MsaTO/+ZpBqmF+NjI6V3bcMWJBG6d45Q+iRhkzMkU3GIczCOtT1uCUNUAamNTAZDR3JVeRg==@kvack.org X-Gm-Message-State: AOJu0Yw7ZtcHAkUqu8uUgIgIWK7278H4ec3zL2CVwUeB28Jswf8exh7+ VtV800w4+9zOYcXi8wwdymsNC0MN8r6uiSJRrLjKe6vEwe/C0QspeQHD/a1mALYdg4qJmgqEaZF jkTBYukcmZD4x6uPDtkAxDque/5GjU5wPyll+0ask/5zrjutUdfkdpeijMgf7btlW2PyXNtHB70 dm9SA11DK1nRvC9rwqZCEpZVc= X-Gm-Gg: ASbGnctozwPaB9zuvhcEHF78e5Z5ZthJOeZdbrsm+KcJ4gHf5BWuWvCUxbwqe0S3D+e u+lyw1kRR4GVqaMDcvBNw4cfI7xOqbcUhUFH9+I65tDTGUbu4YCMIjTiHuFZP1Jh5GoTfxxSq+/ D4t5Jr29R8zQqI4xPQOYFU5vVPS2S/ X-Received: by 2002:a17:907:c99b:b0:abf:5778:f949 with SMTP id a640c23a62f3a-ac252e9ebd1mr767362166b.42.1741507690640; Sun, 09 Mar 2025 00:08:10 -0800 (PST) X-Google-Smtp-Source: AGHT+IH7U1iyGgohuKugYCzgXBl6WixJZcBRcoUmHFNJf08mvE/aZ1aJlHcdE0jtRjcmbMxi9Sw/rCbNZ3E/zzGi4b0= X-Received: by 2002:a17:907:c99b:b0:abf:5778:f949 with SMTP id a640c23a62f3a-ac252e9ebd1mr767360566b.42.1741507690308; Sun, 09 Mar 2025 00:08:10 -0800 (PST) MIME-Version: 1.0 References: <20250305152555.318159-1-ryasuoka@redhat.com> <20250305152555.318159-2-ryasuoka@redhat.com> <3bfd4238-6954-41a3-a5a3-8515a3ac9dce@redhat.com> <51c11147-4927-4ebc-9737-fd1eebe4e0bd@redhat.com> In-Reply-To: <51c11147-4927-4ebc-9737-fd1eebe4e0bd@redhat.com> From: Ryosuke Yasuoka Date: Sun, 9 Mar 2025 17:07:59 +0900 X-Gm-Features: AQ5f1Jom-CKnJdgtaquTd67G5uzgxxqs44dKctiQ9yfQQxkLNniKi8t6ppg6oo4 Message-ID: Subject: Re: [PATCH drm-next 1/2] vmalloc: Add atomic_vmap To: Jocelyn Falempe Cc: Matthew Wilcox , 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, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, virtualization@lists.linux.dev, linux-mm@kvack.org X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: R1HLmfkqPVv7EyDTHzxGQQVx9HAD4jsndzbmEcxeLU8_1741507691 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: DA2D6100004 X-Rspamd-Server: rspam11 X-Stat-Signature: 4sasb1qb9zgdqznewffi5c9ofqhskuyr X-Rspam-User: X-HE-Tag: 1741507694-36858 X-HE-Meta: U2FsdGVkX18HiJN+0SeZ4liOaq6kYgEt0Ii9/qWPXjKMfgISyLzwDWVgdkp8eTLDLP2+Mg6jDtIUa8xtOJkO63+eKdRjV82r+KQeZhEebui7xVujQKeWU7YbUoCcmblsurVl8r1K42qO1XGEfiO17QVwzIOHSZEJkdgga+rk93HMrUtEhzWV+nF/NGoDa/KFjQ8t4mKOz6jAMglzN1JtIAPMHZgVETkrUjB76Nq1VcDG5Kvdjm+o4iCfrWDB/o6uKt+Ohadn4iGlZRSPbOVJlCGbJ4SxO5wWVlzUR7mcZXkAUYohob6gb/WipwY4QfA3QvUIs1Zpkljczx4roJDGNe2bMxfLqBwqiiaHmchK/ZktQo5EEfNrqPusDvOAoxNMv6LR//Mgs2aNBBve72LYhHMuxPN6jlkd+v2m8LvmYGdxR2xOru+eAYrFrQw4f4lZSzJmZJq4gde96JTnFRP+H4vK00o8vMQev28Ruq/ChKThdBnINe8q2zXugpDHjOSkPvrlYnD9CogaLAyLpfzLDKmHeYDU7Y4fSAzOvVcTZwjJoRlEhoeyg3tZeDfBNaIu1Rx2m7ADKv+4QjLS6jG2Wy836+DJGZVP01nt2IMS7o3CpyO8NhHPX6h46NmxOVTh3hXYh7PF0YQPb2xrhoCjOC5OzjE8xxwbt1KedYcPTJu09z1u78u5gA/oHFx+U/GBprxrV9BxjUmYlrim8QvVtz859llL1KlXcAX8T5aWTUmRwYWHPhzRe5J39p8ilh+VUG8Bxm0U18363nMmrQrjGrF8xbn+ji9jtJ85pFeaAk3gHxQ80Jg3nbkOorLaALD+iEuZ8VsloXYBFp8jJ4d5R1FkTjLywooT3xmG1N0R90CUpRpXezkvHPcmWJ3+yQjs887TGQzUH5UJtRGBZFIxQXitzPwWNIDtl9eUXzaOqWN2CzY65xycSm0q8aszH8r6JI99rwP9Wn4uw6zSMYw sFQQkwVh cJniI9iTbDJd/JPlx+t0OtXkwYvkgSgXh1j4MmEGqxt98L6WffK61q7meQUBvj4lZdHn1xfVElBEnSkD0N0luc42gNiV9EhspgTnc/GVWYG9GhRrZKHCYnMCslgMsJaN6jvcbPLIeTO3Bg0eYiYykugXGrOBgx6wIHRH+teZfsE1ece1GWgKaq1RFBcrs4jAZ8D9DVgUam0XAFkcuiIQlbJxGe0nDwqz8neNBXKYoBzEKB0ovWeV5Jx4dbapJ0cHUkhamGFsL34PV0TzUJw8FZSYDNU0kwpZZyhDu8o80GEAZY6zFztUzO5WosrvshiMBfJoKsBWL9wtJ7m+bFGyFHrholEbnLzIsHU9Nz9wZIYTwKFB0zzyx7EJ/XF7i6PguPRWMSiLq84sxD97MgnQQwiq3TfiYSSrL5oSZh695OLziSpL8XP44lhAvakcnlv8pl6DrUKLOQ80rYiohiEiPjKSkpx+VtHtfMNKMpp0m54QvGCX51x9J0ra0eNZXNLjvOYIQhzFB67ZU4SM98LwLNknLTP6l9TMDL6dzO8/Dpbzx+WQ/0CnSbV1+TQ== 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 Fri, Mar 7, 2025 at 4:55=E2=80=AFPM Jocelyn Falempe wrote: > > On 06/03/2025 16:52, Simona Vetter wrote: > > On Thu, Mar 06, 2025 at 02:24:51PM +0100, Jocelyn Falempe wrote: > >> On 06/03/2025 05:52, Matthew Wilcox wrote: > >>> 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 a= nd > >>>> 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, ho= w > >>> is this supposed to work? > >>> > >>>> + vn =3D 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 modifyin= g 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 some= thing > >>> 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 AP= Is > >>> to let you do that today, but it's something that could be added. > >>> > >> Regarding the lock, it should be possible to use the trylock() variant= , and > >> fail if the lock is already taken. (In the panic handler, only 1 CPU r= emain > >> active, so it's unlikely the lock would be released anyway). > >> > >> If we need to pre-allocate the page table and reserve the vmap area, m= aybe > >> it would be easier to just always vmap() the primary framebuffer, so i= t can > >> be used in the panic handler? > > > > Yeah I really don't like the idea of creating some really brittle one-o= ff > > core mm code just so we don't have to vmap a buffer unconditionally. I > > think even better would be if drm_panic can cope with non-linear buffer= s, > > it's entirely fine if the drawing function absolutely crawls and sets e= ach > > individual byte ... > > It already supports some non-linear buffer, like Nvidia block-linear: > https://elixir.bootlin.com/linux/v6.13.5/source/drivers/gpu/drm/nouveau/d= ispnv50/wndw.c#L606 > > And I've also sent some patches to support Intel's 4-tile and Y-tile form= at: > https://patchwork.freedesktop.org/patch/637200/?series=3D141936&rev=3D5 > https://patchwork.freedesktop.org/patch/637202/?series=3D141936&rev=3D5 > > Hopefully Color Compression can be disabled on intel's GPU, otherwise > that would be a bit harder to implement than tiling. > > > > > The only thing you're allowed to do in panic is try_lock on a raw spinl= ock > > (plus some really scare lockless tricks), imposing that on core mm soun= ds > > like a non-starter to me. > > > > Cheers, Sima > Thank you all for your comments. I understand adding atomic_vmap is not possible as vmalloc is not compatibl= e with GFP_ATOMIC. I'll re-implement this by pre-allocating the page table an= d reserve the vmap area while the kernel is alive. It'll might be allocated in driver codes so maybe I don't need to add any features in core mm code. Best regards, Ryosuke