From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Jan Kara <jack@suse.cz>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
xfs <linux-xfs@vger.kernel.org>,
hch@lst.de
Subject: Re: [PATCH v3] quota: widen timestamps for the fs_disk_quota structure
Date: Tue, 8 Sep 2020 19:29:09 -0700 [thread overview]
Message-ID: <20200909022909.GI7955@magnolia> (raw)
In-Reply-To: <20200909014933.GC6583@casper.infradead.org>
On Wed, Sep 09, 2020 at 02:49:33AM +0100, Matthew Wilcox wrote:
> On Tue, Sep 08, 2020 at 06:32:51PM -0700, Darrick J. Wong wrote:
> > +static inline void copy_to_xfs_dqblk_ts(const struct fs_disk_quota *d,
> > + __s32 *timer_lo, __s8 *timer_hi, s64 timer)
> > +{
> > + *timer_lo = timer;
> > + if (d->d_fieldmask & FS_DQ_BIGTIME)
> > + *timer_hi = timer >> 32;
> > + else
> > + *timer_hi = 0;
> > +}
>
> I'm still confused by this. What breaks if you just do:
>
> *timer_lo = timer;
> *timer_hi = timer >> 32;
"I don't know."
The manpage for quotactl doesn't actually specify the behavior of the
padding fields. The /implementation/ is careful enough to zero
everything, but the interface specification doesn't explicitly require
software to do so.
Because the contents of the padding fields aren't defined by the
documentation, the kernel cannot simply start using the d_padding2 field
because there could be an old kernel that doesn't zero the padding,
which would lead to confusion if the new userspace were mated to such a
kernel.
Therefore, we have to add a flag that states explicitly that we are
using the timer_hi fields. This is also the only way that an old
program can detect that it's being fed a structure that it might not
recognise.
Keep in mind that if @timer is negative (i.e. before the unix epoch)
then technically timer_hi has to be all ones if FS_DQ_BIGTIME is set.
The only user doesn't support that, but that's no excuse for sloppiness.
> > memset(dst, 0, sizeof(*dst));
> > + if (want_bigtime(src->d_ino_timer) || want_bigtime(src->d_spc_timer) ||
> > + want_bigtime(src->d_rt_spc_timer))
> > + dst->d_fieldmask |= FS_DQ_BIGTIME;
>
> You still need this (I guess? In case somebody's written to the
> d_padding2 field?)
Yes.
--D
next prev parent reply other threads:[~2020-09-09 2:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 1:32 [PATCH v3] quota: widen timestamps for the fs_disk_quota structure Darrick J. Wong
2020-09-09 1:49 ` Matthew Wilcox
2020-09-09 2:29 ` Darrick J. Wong [this message]
2020-09-09 10:51 ` Jan Kara
2020-09-09 12:42 ` Matthew Wilcox
2020-09-09 13:56 ` Jan Kara
2020-09-09 17:27 ` Darrick J. Wong
2020-09-10 7:07 ` Jan Kara
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=20200909022909.GI7955@magnolia \
--to=darrick.wong@oracle.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).