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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.