From: Greg KH <greg@kroah.com>
To: Costa Shulyupin <costa.shul@redhat.com>
Cc: Sotir Danailov <sndanailov@gmail.com>,
Leam Hall <leamhall@gmail.com>,
kernelnewbies@kernelnewbies.org
Subject: Re: Typecasting a void pointer to unsigned long in zsmalloc.c
Date: Fri, 24 Jan 2025 06:13:58 +0100 [thread overview]
Message-ID: <2025012408-amenity-quaintly-fce5@gregkh> (raw)
In-Reply-To: <CADDUTFzN=BpNEOQB0r=rRRtiXNkgHzZpBsPfEgaLwJebBoPR1w@mail.gmail.com>
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
next prev parent reply other threads:[~2025-01-24 5:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-23 15:52 Typecasting a void pointer to unsigned long in zsmalloc.c Sotir Danailov
2025-01-23 15:59 ` Greg KH
2025-01-23 16:27 ` Sotir Danailov
2025-01-23 17:00 ` Greg KH
2025-01-23 17:05 ` Sotir Danailov
2025-01-23 17:40 ` Leam Hall
2025-01-23 18:30 ` Sotir Danailov
2025-01-23 19:54 ` Leam Hall
2025-01-23 20:48 ` Sotir Danailov
2025-01-23 21:09 ` Costa Shulyupin
2025-01-24 5:13 ` Greg KH [this message]
2025-01-24 21:45 ` Sotir Danailov
2025-01-26 23:29 ` Leam Hall
2025-01-27 10:39 ` Sotir Danailov
2025-01-27 13:48 ` Leam Hall
2025-01-28 8:45 ` Sotir Danailov
2025-01-28 8:58 ` Costa Shulyupin
2025-01-28 9:14 ` Sotir Danailov
2025-01-28 9:24 ` Sotir Danailov
2025-01-28 10:23 ` Leam Hall
2025-01-23 18:44 ` jim.cromie
[not found] <mailman.1.1737651601.26911.kernelnewbies@kernelnewbies.org>
2025-01-23 17:58 ` Alex Hogen
2025-01-23 18:23 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025012408-amenity-quaintly-fce5@gregkh \
--to=greg@kroah.com \
--cc=costa.shul@redhat.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=leamhall@gmail.com \
--cc=sndanailov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox