From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v4 1/5] syscalls/quotactl01: Add Q_GETNEXTQUOTA test
Date: Thu, 21 Nov 2019 06:45:07 +0100 [thread overview]
Message-ID: <20191121054507.GB59487@x230> (raw)
In-Reply-To: <d1d72a63-fd3b-e670-4559-c0216176546c@cn.fujitsu.com>
Hi Xu,
> > @Jan, @Cyril: Do we want to generally avoid loading <linux/types.h> if not really needed?
> > __u64 can be uint64_t etc (as it's also visible in struct dqblk in <sys/quota.h>
> > in various libc headers).
> > We used this approach for /usr/include/linux/bpf.h and for fanotify fixes for
> > musl (testcases/kernel/syscalls/fanotify/fanotify.h).
> > So unless you're against this approach here I'll change it before merge
> > (and add this info to next version of library API writing guidelines patch
> > https://patchwork.ozlabs.org/patch/1166786/).
> I have no objection about using uint64_t becuase Q_GETNEXTQUOTA man-pages also uses it.
> I used struct if_nextdqblk as same as <linux/quota.h> defined. But I don't know why we can't use
> <linux/type.h> in lapi/quotactl.h and I also use it in lapi/seccomp.h. IMHO, they affected nothing.
> Or, they have some redefined errors or not having this headers files in special linux distribution.
Based on Jan's comment [1], maybe he meant it specifically for __kernel_fsid_t in
fanotify.h, not as a general approach. __kernel_fsid_t is more complicated than
uint64_t. That's why I'm asking whether there is a general approach we want to
take.
> > > + TEST(quotactl(QCMD(Q_GETNEXTQUOTA, USRQUOTA), tst_device->dev,
> > > + test_id, (void *) &res_ndq));
> > > + if (TST_ERR == EINVAL || TST_ERR == ENOSYS)
> > Does EINVAL really mans not supported? Shouldn't be just for ENOSYS.
> EINVAL can mean non-supported? by using correct argument.
> look do_quotactl function in fs/quota/quota.c.
> static int do_quotactl(struct super_block *sb, int type, int cmd, qid_t id,
> ?????????????????????? void __user *addr, const struct path *path)
> {
> ??? switch (cmd) {
> ??????? case Q_QUOTAON:
> ??????????????? return quota_quotaon(sb, type, id, path);
> ??????? case Q_QUOTAOFF:
> ??????????????? return quota_quotaoff(sb, type);
> ??????? case Q_GETFMT:
> ??????????????? return quota_getfmt(sb, type, addr);
> ??????? case Q_GETINFO:
> ??? ??? ......
> ??? ???? default:
> ??????????????? return -EINVAL;
> ??????? }
> }
> So if it doesn't have Q_GETNEXTQUOTA cmd, it should report EINVAL(we use correct argument and correct environment, so there is no failure).
OK, you're right, thanks for info :).
Kind regards,
Petr
[1] https://patchwork.ozlabs.org/patch/1178182/#2281586
next prev parent reply other threads:[~2019-11-21 5:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 9:13 [LTP] [PATCH v4 0/5] optimize quotactl test code Yang Xu
2019-11-20 9:13 ` [LTP] [PATCH v4 1/5] syscalls/quotactl01: Add Q_GETNEXTQUOTA test Yang Xu
2019-11-20 15:12 ` Petr Vorel
2019-11-20 15:16 ` Petr Vorel
2019-11-21 3:37 ` Yang Xu
2019-11-21 5:10 ` Petr Vorel
2019-11-21 7:07 ` Yang Xu
2019-11-21 8:21 ` Petr Vorel
2019-11-21 9:01 ` Yang Xu
2019-11-21 2:29 ` Yang Xu
2019-11-21 5:45 ` Petr Vorel [this message]
2019-11-21 7:45 ` Yang Xu
2019-11-21 8:32 ` Petr Vorel
2019-11-21 8:38 ` Yang Xu
2019-11-21 9:01 ` Jan Stancek
2019-11-21 10:30 ` Petr Vorel
2019-11-21 11:08 ` Jan Stancek
2019-11-21 15:19 ` Petr Vorel
2019-11-20 9:13 ` [LTP] [PATCH v4 2/5] syscalls/quotactl02: Add Q_XGETQSTATV test and group quota tests Yang Xu
2019-11-20 9:13 ` [LTP] [PATCH v4 3/5] syscalls/quotactl04: add project quota test for non-xfs filesystem Yang Xu
2019-11-20 9:13 ` [LTP] [PATCH v4 4/5] syscalls/quotactl05: add project quota test on xfs filesystem Yang Xu
2019-11-20 9:13 ` [LTP] [PATCH v4 5/5] syscalls/quotactl06: Add new error testcase Yang Xu
2019-11-21 17:01 ` [LTP] [PATCH v4 0/5] optimize quotactl test code Petr Vorel
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=20191121054507.GB59487@x230 \
--to=pvorel@suse.cz \
--cc=ltp@lists.linux.it \
/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.