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 shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 940C5C02181 for ; Fri, 24 Jan 2025 05:15:17 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.97.1) (envelope-from ) id 1tbC23-00000000206-263t; Fri, 24 Jan 2025 00:15:03 -0500 Received: from fout-a4-smtp.messagingengine.com ([103.168.172.147]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1tbC1S-000000001w1-0iZE for kernelnewbies@kernelnewbies.org; Fri, 24 Jan 2025 00:14:26 -0500 Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfout.phl.internal (Postfix) with ESMTP id 5066C1380181; Fri, 24 Jan 2025 00:14:06 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-09.internal (MEProxy); Fri, 24 Jan 2025 00:14:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h=cc :cc: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=fm3; t=1737695646; x=1737782046; bh=d7tVdytXqT YMikZaCP8NT80YxoYDW9BJvNOakYmMEVM=; b=xDutkOSyh4FbJTNmdMPgrEzCiQ vWPwRdWjHhjIDnRNoy5K28LeXWrK6ulzTylnmXV75Jej7zM02UKZiXOJ43IYxWWH G11qXOlQB5MWVKOSrWLww4Ho1OUDxPsQvQYElNVLz5v5yGzrKhj+VNl7vfYAMOZ9 isZJbi2xmzB4kvEpzfWi+k04t60ywtIyUKg0CNlrbc79OAHuR5MZPMz72HqP0+Ax /xsZMKA328ZdybNecK3zIcc16Bz9r9uZDOqvlb3e6CaRYPNRSVN/qpHUUi/zZ7YM 57RYKPtLqhQkFmhIPJLoMPgDAEM2nK57jF3yffDXQpo2hMgXPNbnD7m7GfFA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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=fm3; t= 1737695646; x=1737782046; bh=d7tVdytXqTYMikZaCP8NT80YxoYDW9BJvNO akYmMEVM=; b=YKpQ9CRt2ilOerlpExVjlvlslXeiX99RtkzHZIVkhcTb6hJ+CmR nQ4rlWjyeFCSixu2Dno3XPZKijUPhRyfhzJYiUclhd86yTu0yuRz1i6jq8V45yGA b+M9JoQKxAv9JascSFnCOHQf7AGU0RjRp/g2oD2Qij3+jdnnfF3Ty1FqDK24Tlc8 BhTt8TZ0KTatZainpowNKheUlMjGaOojEpcOfXlc0/n9bIYGj2MyakdWbKN7F8mA FtPDEu1MmJOKHYzKNayjgf2I2B49R1Opg8shwa/017Grmv16fxs8V775TSoZ+8So EICKxouMcKh+pmzBZoCq/K2copV1N11Wq0A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejgedgfeeijecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddv necuhfhrohhmpefirhgvghcumffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucggtf frrghtthgvrhhnpeegheeuhefgtdeluddtleekfeegjeetgeeikeehfeduieffvddufeef leevtddtvdenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhrvghgsehkrhhorghhrdgtohhm pdhnsggprhgtphhtthhopeekpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegtoh hsthgrrdhshhhulhesrhgvughhrghtrdgtohhmpdhrtghpthhtohepshhnuggrnhgrihhl ohhvsehgmhgrihhlrdgtohhmpdhrtghpthhtoheplhgvrghmhhgrlhhlsehgmhgrihhlrd gtohhmpdhrtghpthhtohepkhgvrhhnvghlnhgvfigsihgvsheskhgvrhhnvghlnhgvfigs ihgvshdrohhrgh X-ME-Proxy: Feedback-ID: i787e41f1:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Jan 2025 00:14:05 -0500 (EST) Date: Fri, 24 Jan 2025 06:13:58 +0100 From: Greg KH To: Costa Shulyupin Subject: Re: Typecasting a void pointer to unsigned long in zsmalloc.c Message-ID: <2025012408-amenity-quaintly-fce5@gregkh> References: <2025012321-fool-blatantly-069a@gregkh> <2025012347-shorthand-october-ada2@gregkh> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: Sotir Danailov , Leam Hall , kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Thu, Jan 23, 2025 at 11:09:47PM +0200, Costa Shulyupin wrote: > Hi. I've found this: > > Pointers are __u64, cast from/to a uintptr_t on the userspace side and > from/to a void __user * in the kernel. Try really hard not to delay this > conversion or worse, fiddle the raw __u64 through your code since that > diminishes the checking tools like sparse can provide. The macro > u64_to_user_ptr can be used in the kernel to avoid warnings about integers > and pointers of different sizes. > > https://origin.kernel.org/doc/html/latest/process/botching-up-ioctls.html#:~:text=Pointers%20are%20__u64 That is talking about the ioctl user/kernel boundry and passing pointers across it. Not the use of pointers directly in the kernel tree. The goal of that paragraph is to tell people to always use a 64bit value for a pointer they are putting into an ioctl, which ensures that the structure remains the same size no matter if you are running on a system that has 32bit or 64bit pointers. So while this is great advice, and should be followed, it doesn't really discuss the implicit rule that "unsigned long can always hold a pointer" that Linux relies on. hope this helps, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies