From: David Laight <david.laight.linux@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Thomas Gleixner <tglx@linutronix.de>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] fs: Replace user_access_{begin/end} by scoped user access
Date: Wed, 18 Mar 2026 22:35:32 +0000 [thread overview]
Message-ID: <20260318223532.1abcf12b@pumpkin> (raw)
In-Reply-To: <CAHk-=widw8GwXNuq5ALr+NgDDUN+=pc77U=EczqUiVZeD2Dz+Q@mail.gmail.com>
On Wed, 18 Mar 2026 08:53:52 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, 18 Mar 2026 at 08:49, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > #define dirent_size(dirent, len) offsetof(typeof(dirent), d_name[len])
>
> That 'typeof(dirent)' needs to be 'typeof(*(dirent))' to be convenient.
>
> It was correct in the patch I attached, but I'll just point it out anyway.
>
> And we actually have a helper macro for that: struct_offset(). Which
> wasn't what I used in that attached patch, but *should* have been.
>
> IOW, the macro should look something like
>
> #define dirent_size(dirent, len) struct_offset(dirent, d_name[len])
>
> instead. That looks fairly clean, no?
And unnecessary - the struct_offset() isn't that much longer.
Actually, from a readability point of view even struct_offset() almost
makes things worse.
If you are being paranoid it is another definition to find and check.
There isn't that much difference in the lengths:
dirent_size(dirent, len)
struct_offset(dirent, d_name[len])
offsetof(typeof(*dirent), d_name[len])
and the last one really does tell you what it being calculated.
I do remember one compiler (and I thought it was gcc, but it might only
have been msvc) that required that offsetof() always generate a constant.
ISTR the C language requires that - which makes all the above invalid.
>
> Linus
next prev parent reply other threads:[~2026-03-18 22:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 8:52 [PATCH v3] fs: Replace user_access_{begin/end} by scoped user access Christophe Leroy (CS GROUP)
2026-03-16 17:12 ` Linus Torvalds
2026-03-16 23:19 ` David Laight
2026-03-18 12:29 ` Christophe Leroy (CS GROUP)
2026-03-18 15:49 ` Linus Torvalds
2026-03-18 15:53 ` Linus Torvalds
2026-03-18 22:35 ` David Laight [this message]
2026-03-24 11:42 ` Christophe Leroy (CS GROUP)
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=20260318223532.1abcf12b@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=brauner@kernel.org \
--cc=chleroy@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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.