From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a3-smtp.messagingengine.com (fhigh-a3-smtp.messagingengine.com [103.168.172.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 77027413247 for ; Thu, 23 Jul 2026 09:00:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.154 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784797236; cv=none; b=QIrElUp+CqThM22gegX5oajcouUu1BtCx68v/U8Ry495t3fy1D4lyXH3GiH9YsvmQGcnZyyJiDE4aIsgPjZXuElse8H15cJw3fDy4XuXkEqwlDxGk6mGRNJCh8ry1uCsCUatJAtsCfm2QMTiXPukznYrn3C39JfkOqKxswQ5dVQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784797236; c=relaxed/simple; bh=gYFuZ7ifDHHgn767bur8CZlrXY/Dm0B2+dBRANi7xms=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=V+1Qqdrm8SRzbplnQJKlF2wxuUjv7WngT8mE1t4bYZZAepmeSCc3815Ge44LlFR/DetOoj5OdsR7BfPSxrnCazeEv532Z1PxctQlZWFJBWAI/ClVZXVolfRvCwYqOdtV/HFu/Gk2S9t2mIu3COTcWQI5aKw0B6rt5we4xsBdi78= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=MhC9IYmc; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=c0/woa7v; arc=none smtp.client-ip=103.168.172.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="MhC9IYmc"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="c0/woa7v" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 022B6140012F; Thu, 23 Jul 2026 05:00:32 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-04.internal (MEProxy); Thu, 23 Jul 2026 05:00:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1784797231; x=1784883631; bh=2QBxZKriJFHuZN6Z35es1VQXh4AQXzZ22zo0Cq/T5UE=; b= MhC9IYmchfODkVkzWv8TSLDTgMlTNmynreQBV8QNQGHtG81gc2UURP1gaiVbyWBG DsBfNtH93/dUjs7AT+32xRnfmG9EqK2VJ6g8OBpNHXJv4tovg2FF3ApvRpVcEA6x Olo/dJFMSecs7tGFGUE8C9TdMwwc7LqWv5HOIAIjcwgSQuq5gdL9baimKf6y13Dq DOxFPht5ZSdXXZKfLzovn47yiZT+BMoll4yQust2YIIx1Sykx+jdL6h6d09mKdl3 v9E9eljykaIl1Hy2Wgo1qTmrvV3Ywm4D65V4ROKKNPZUB9cmGZV6NFvmVqTr5JJa +bSQgRYUJkVBj6LsfRwAgQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1784797231; x= 1784883631; bh=2QBxZKriJFHuZN6Z35es1VQXh4AQXzZ22zo0Cq/T5UE=; b=c 0/woa7vZxWgu7P0bJVWGYDjSSpRhyBc/uAccseFg9NckclCDzDhn7lmjuHEwhYOg 7/lGn/8QNE8Uc0mn2wEVogcqMFf4C6XJJs6EhzvbM1XZ5IRbBl9slfiNQP9eOEZm cyeVQaoh3C1gLrvVewY3kdQGKbwC8pgjWSldL329YRlCb3HlWTSALtSnnoXbEikN pBqQYzw47UdZUSLlnpHKubOxBBTqHGb1GExGUe9jU/qOr6/qGgRBS389+TNxrPWL 0E59Lt53rmjn2xMEz6rWvyNY1HCgJuXHe1xHYQvPxgHo0Wv2Ev3rZ6LjJpaAONWS B4fygZiHh/bHafbkVUcaA== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTF28N2zVOgB4i+IDbUFo5lPnmWt5yN72Qeqda4VDxpbYcuatT80WlC7DQczBt9xnI 2xyeFNkCTHEcFqw0KQ9/zCYJ5y8+d4jKS9CHMWN7oOFafIiELdAqE5OGF8G9NEoV1A0EV7 wzvB0QsnDCkSzhQyoSvbS+LQq9sjAsaxCIPhdKC9nbTskJwGuiRO1HPeCbV98lVTWajI7D SixnyBVXkgQ/l/c2sBx6r6otcCfcENPmBvfcOizP+GeOC0B2DRmTxI0DR7X4k5+2TR4zst GwFAaeXC192JI7Lnh32mbEbdvSzAh0WrJgTXBZnLr7XNj7PDPT7Rrkm55fYu3FT0iGLhOI nTqD8t5p02jISOCbYJTQMeLMSBcYL318xz7hGJiP3jr8+3+5L8LM0BNII/9sf6ftWgAFCR EGLu5OB7KAUuDSpszH/wdJJVTZUEZHpVeuIVniqBhfDSWh1qXdwq6EY564QanpQkUqQCLq u9rJZyAd7WHIQL5k9a7PmblfiLdUe6XKLtyZQSko6iBlpYpIQDoOQgopIIkbwHSCELsvxS 3VQ0EDnT2b8A5sIFIKc0xrDaKQ/FKRNZKBitnfwh+JFlpIo+u3trgDu1+hhz6RSe116+e4 1EaWt/Wkq0Hn3/4sOlGbif+UeFkhgDUHd86qY/q9xqinnhM8qSzJtgOYfDKQ X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 7B07E182007E; Thu, 23 Jul 2026 05:00:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: Ay96WTovVnnN Date: Thu, 23 Jul 2026 11:00:01 +0200 From: "Arnd Bergmann" To: "David Laight" , "Mahad Ibrahim" Cc: "Kees Cook" , "Greg Kroah-Hartman" , "Mike Rapoport" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Message-Id: In-Reply-To: <20260723094522.535b284c@pumpkin> References: <20260722230246.2869-1-mahad.ibrahim.dev@gmail.com> <20260723094522.535b284c@pumpkin> Subject: Re: [PATCH] lkdtm: use kmalloc() instead of __get_free_page Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, Jul 23, 2026, at 10:45, David Laight wrote: > On Wed, 22 Jul 2026 23:02:46 +0000 > Mahad Ibrahim wrote: > >> lkdtm_debugfs_entry and direct_entry use __get_free_page to allocate a >> temporary buffer, perform copy_from_user to get the crashtype name, >> strim() to strip whitespace and find_crashtype to find the corresponding >> crashtype that is being requested. >> >> The lkdtm_debugfs_read uses __get_free_page to allocate a temporary >> buffer to store all the available crashtypes, and then copy it to >> userspace. >> >> The buffers that are allocated can be allocated with kmalloc as there is >> nothing special that requires a struct page, or the page allocator. >> >> kmalloc() additionally provides a better API that doesn't require ugly >> casts which obfuscate the code and kfree does not need to know the size >> of the freed object. >> >> Replace use of __get_free_page() with kmalloc(). > > None of those buffers need to be PAGE_SIZE. > Even the sanity limit for overlong requests could be 4k. > The longest 'crashtype->name' is probably about 32 characters, so could > probably go on stack. It is a straightforward change with a very low risk of regression, so I see nothing wrong with this version. If we wanted to improve readability here, I would suggest using strndup_user() to fold ten lines into one. Arnd