From: Greg KH <gregkh@linuxfoundation.org>
To: JeffleXu <jefflexu@linux.alibaba.com>
Cc: linux-erofs@lists.ozlabs.org, willy@infradead.org,
linux-kernel@vger.kernel.org, dhowells@redhat.com,
joseph.qi@linux.alibaba.com, linux-cachefs@redhat.com,
linux-fsdevel@vger.kernel.org, gerry@linux.alibaba.com,
torvalds@linux-foundation.org
Subject: Re: [PATCH v4 05/23] cachefiles: introduce new devnode for on-demand read mode
Date: Wed, 16 Feb 2022 18:48:11 +0100 [thread overview]
Message-ID: <Yg0421B10PPwunI+@kroah.com> (raw)
In-Reply-To: <becd656c-701c-747e-f063-2b9867cbd3d2@linux.alibaba.com>
On Wed, Feb 16, 2022 at 08:49:35PM +0800, JeffleXu wrote:
> >> +struct cachefiles_req_in {
> >> + uint64_t id;
> >> + uint64_t off;
> >> + uint64_t len;
> >
> > For structures that cross the user/kernel boundry, you have to use the
> > correct types. For this it would be __u64.
>
> OK I will change to __xx style in the next version.
>
> By the way, I can't understand the disadvantage of uintxx_t style.
The "uint*" types are not valid kernel types. They are userspace types
and do not transfer properly in all arches and situations when crossing
the user/kernel boundry. They are also in a different C "namespace", so
should not even be used in kernel code, although a lot of people do
because they are used to writing userspace C code :(
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: JeffleXu <jefflexu@linux.alibaba.com>
Cc: dhowells@redhat.com, linux-cachefs@redhat.com, xiang@kernel.org,
chao@kernel.org, linux-erofs@lists.ozlabs.org,
torvalds@linux-foundation.org, willy@infradead.org,
linux-fsdevel@vger.kernel.org, joseph.qi@linux.alibaba.com,
bo.liu@linux.alibaba.com, tao.peng@linux.alibaba.com,
gerry@linux.alibaba.com, eguan@linux.alibaba.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 05/23] cachefiles: introduce new devnode for on-demand read mode
Date: Wed, 16 Feb 2022 18:48:11 +0100 [thread overview]
Message-ID: <Yg0421B10PPwunI+@kroah.com> (raw)
In-Reply-To: <becd656c-701c-747e-f063-2b9867cbd3d2@linux.alibaba.com>
On Wed, Feb 16, 2022 at 08:49:35PM +0800, JeffleXu wrote:
> >> +struct cachefiles_req_in {
> >> + uint64_t id;
> >> + uint64_t off;
> >> + uint64_t len;
> >
> > For structures that cross the user/kernel boundry, you have to use the
> > correct types. For this it would be __u64.
>
> OK I will change to __xx style in the next version.
>
> By the way, I can't understand the disadvantage of uintxx_t style.
The "uint*" types are not valid kernel types. They are userspace types
and do not transfer properly in all arches and situations when crossing
the user/kernel boundry. They are also in a different C "namespace", so
should not even be used in kernel code, although a lot of people do
because they are used to writing userspace C code :(
thanks,
greg k-h
next prev parent reply other threads:[~2022-02-16 17:48 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-09 6:00 [PATCH v3 00/22] fscache,erofs: fscache-based demand-read semantics Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 01/22] fscache: export fscache_end_operation() Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-17 7:44 ` Liu Bo
2022-02-17 7:44 ` Liu Bo
2022-02-09 6:00 ` [PATCH v3 02/22] fscache: add a method to support on-demand read semantics Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 03/22] cachefiles: extract generic function for daemon methods Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-17 8:17 ` Liu Bo
2022-02-17 8:17 ` Liu Bo
2022-02-09 6:00 ` [PATCH v3 04/22] cachefiles: detect backing file size in on-demand read mode Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 05/22] cachefiles: introduce new devnode for " Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-15 9:03 ` JeffleXu
2022-02-15 9:03 ` JeffleXu
2022-02-15 10:37 ` Greg KH
2022-02-15 10:37 ` Greg KH
2022-02-16 8:17 ` JeffleXu
2022-02-16 8:17 ` JeffleXu
2022-02-15 11:13 ` [PATCH v4 05/23] " Jeffle Xu
2022-02-15 11:13 ` Jeffle Xu
2022-02-16 10:48 ` Greg KH
2022-02-16 10:48 ` Greg KH
2022-02-16 12:49 ` JeffleXu
2022-02-16 12:49 ` JeffleXu
2022-02-16 17:48 ` Greg KH [this message]
2022-02-16 17:48 ` Greg KH
2022-02-17 1:49 ` JeffleXu
2022-02-17 1:49 ` JeffleXu
2022-02-09 6:00 ` [PATCH v3 06/22] erofs: use meta buffers for erofs_read_superblock() Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-09 7:52 ` Gao Xiang
2022-02-09 7:52 ` Gao Xiang
2022-02-09 6:00 ` [PATCH v3 07/22] erofs: export erofs_map_blocks() Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 08/22] erofs: add mode checking helper Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 09/22] erofs: register global fscache volume Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 10/22] erofs: add cookie context helper functions Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 11/22] erofs: add anonymous inode managing page cache of blob file Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 12/22] erofs: add erofs_fscache_read_page() helper Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 13/22] erofs: register cookie context for bootstrap blob Jeffle Xu
2022-02-09 6:00 ` Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 14/22] erofs: implement fscache-based metadata read Jeffle Xu
2022-02-09 6:01 ` Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 15/22] erofs: implement fscache-based data read for non-inline layout Jeffle Xu
2022-02-09 6:01 ` Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 16/22] erofs: implement fscache-based data read for inline layout Jeffle Xu
2022-02-09 6:01 ` Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 17/22] erofs: register cookie context for data blobs Jeffle Xu
2022-02-09 6:01 ` Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 18/22] erofs: implement fscache-based data read " Jeffle Xu
2022-02-09 6:01 ` Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 19/22] erofs: implement fscache-based data readahead for hole Jeffle Xu
2022-02-09 6:01 ` Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 20/22] erofs: implement fscache-based data readahead for non-inline layout Jeffle Xu
2022-02-09 6:01 ` Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 21/22] erofs: implement fscache-based data readahead for inline layout Jeffle Xu
2022-02-09 6:01 ` Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 22/22] erofs: add 'uuid' mount option Jeffle Xu
2022-02-09 6:01 ` Jeffle Xu
2022-02-10 5:58 ` [Linux-cachefs] [PATCH v3 00/22] fscache, erofs: fscache-based demand-read semantics Gao Xiang
2022-02-10 5:58 ` Gao Xiang
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=Yg0421B10PPwunI+@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=dhowells@redhat.com \
--cc=gerry@linux.alibaba.com \
--cc=jefflexu@linux.alibaba.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-cachefs@redhat.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.org \
/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.