Re: [RFC resend PATCH] ceph: fix statx AT_STATX_DONT_SYNC vs AT_STATX_FORCE_SYNC check

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff Layton <jlayton@xxxxxxxxxx> wrote:

> On Tue, 2022-04-19 at 14:22 +0100, David Howells wrote:
> > Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> > 
> > >     if ((flags & AT_STATX_SYNC_TYPE) == (AT_STATX_DONT_SYNC|AT_STATX_FORCE_SYNC))
> > 
> > You can't do that.  DONT_SYNC and FORCE_SYNC aren't bit flags - they're an
> > enumeration in a bit field.  There's a reserved value at 0x6000 that doesn't
> > have a symbol assigned.
> > 
> 
> Right, but nothing prevents you from setting both flags at the same
> time. How should we interpret such a request?

A good question without a necessarily right answer.

Possibly we should do:

 #define AT_STATX_SYNC_TYPE	0x6000	/* Type of synchronisation required from statx() */
 #define AT_STATX_SYNC_AS_STAT	0x0000	/* - Do whatever stat() does */
 #define AT_STATX_FORCE_SYNC	0x2000	/* - Force the attributes to be sync'd with the server */
 #define AT_STATX_DONT_SYNC	0x4000	/* - Don't sync attributes with the server */
+#define AT_STATX_SYNC_RESERVED	0x6000

and give EINVAL if we see the reserved value.  But also these values can be
considered a hint, so possibly we should just ignore the reserved value.  Oh
for fsinfo()...

David





[Index of Archives]     [CEPH Users]     [Ceph Large]     [Ceph Dev]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux