Christoph Hellwig wrote:
> Honestly I think this really matters on the amount of 'emulation' we
> need - if it's just adding a new flag that can be trivially generated
> in the syscall stub in userland that's probably fine, but if we have
> actually differing semantics (like the stat weak attribu
On Fri, May 13, 2016 at 05:28:11PM +0200, Arnd Bergmann wrote:
> I'm trying to understand what that means for the 64-bit time_t syscalls.
>
> The patch series I did last year had a replacement 'sys_newfstatat()'
> syscall but IIRC no other stat variant, the idea being that we would
> only need to
Arnd Bergmann wrote:
> I'm trying to understand what that means for the 64-bit time_t syscalls.
>
> The patch series I did last year had a replacement 'sys_newfstatat()'
> syscall but IIRC no other stat variant, the idea being that we would
> only need to provide this one to the libc and have us
On Thursday 12 May 2016 02:11:41 Christoph Hellwig wrote:
> On Tue, May 10, 2016 at 09:25:55AM +0100, David Howells wrote:
> > Because it's not necessarily a perfectly working version of it. See the
> > Y2037
> > problem for example.
> >
> > I was assuming that C libraries might want to update t
On Tue, May 10, 2016 at 09:43:43AM +0100, David Howells wrote:
> Christoph Hellwig wrote:
>
> > All of these are easily available. But why special case them so that
> > userspace must not ask for them? This makes an otherwise totally
> > regular interface special now. Note that filesystems cou
On Tue, May 10, 2016 at 09:25:55AM +0100, David Howells wrote:
> Because it's not necessarily a perfectly working version of it. See the Y2037
> problem for example.
>
> I was assuming that C libraries might want to update the struct stat and the
> stat call() to provide fields that aren't curren
On Tue, 2016-05-10 at 00:00 -0700, Christoph Hellwig wrote:
> On Mon, May 09, 2016 at 08:02:58AM -0400, Jeff Layton wrote:
> > > > AT_FORCE_ATTR_SYNC can be set in flags.This will require a
> > > > network
> > > > filesystem to synchronise its attributes with the server.
> > > >
> > > > AT_NO_
Christoph Hellwig wrote:
> All of these are easily available. But why special case them so that
> userspace must not ask for them? This makes an otherwise totally
> regular interface special now. Note that filesystems could always fill
> it out anyway and set it in the return mask.
Because it
Christoph Hellwig wrote:
> > It does what stat() does now, whatever that is for each fs. The
> > assumption is that this might be used to emulate stat() from userspace.
> > However, we want to be able to make sure we get the two behaviours above.
>
> And why would you emulate stat if we already
On Mon, May 09, 2016 at 02:38:21PM +0100, David Howells wrote:
> Let's look at the list, and please bear in mind I'm trying to make it so that
> you can emulate stat() through this interface. If you want to waive that
> requirement - or push the emulation out to userspace - then I can forego
> pro
On Mon, May 09, 2016 at 01:57:32PM +0100, David Howells wrote:
> > > AT_FORCE_ATTR_SYNC can be set in flags. This will require a network
> > > filesystem to synchronise its attributes with the server.
> > >
> > > AT_NO_ATTR_SYNC can be set in flags. This will suppress synchronisation
> > > with
On Mon, May 09, 2016 at 08:02:58AM -0400, Jeff Layton wrote:
> > > AT_FORCE_ATTR_SYNC can be set in flags.This will require a network
> > > filesystem to synchronise its attributes with the server.
> > >
> > > AT_NO_ATTR_SYNC can be set in flags.This will suppress synchronisation
> > > wit
Christoph Hellwig wrote:
> And please prepare a man page to document this system call properly.
I intend to - but when it's stabilised sufficiently to warrant inclusion.
David
On 5/9/16, 08:57, "linux-nfs-ow...@vger.kernel.org on behalf of David Howells"
wrote:
>Christoph Hellwig wrote:
>
>> >int ret = statx(int dfd,
>> >const char *filename,
>> >unsigned int flags,
>> >unsigned int mask,
>> >
Christoph Hellwig wrote:
> How are the semantics defined when userspace asks for fields not
> available? I'd expect them to be ignored, but we should documentat that
> fact.
I went into this in some detail.
> > Fields in struct statx come in a number of classes:
>
> I really disagree with all
David Howells wrote:
> > > st_gen is
> > > the inode generation number, st_btime is the file creation time,
> > > st_version
> > > is the data version number (i_version),
> >
> > Please define semantics for st_gen and st_version.
>
> I've been asked to drop st_gen for security reasons.
>
> I
Christoph Hellwig wrote:
> > int ret = statx(int dfd,
> > const char *filename,
> > unsigned int flags,
> > unsigned int mask,
> > struct statx *buffer);
>
> Please move the flags and mask after the buffer, simil
On Sun, 2016-05-08 at 01:35 -0700, Christoph Hellwig wrote:
> >
> > int ret = statx(int dfd,
> > const char *filename,
> > unsigned int flags,
> > unsigned int mask,
> > struct statx *buffer);
>
> Please move the
On Mon, May 09, 2016 at 11:45:43AM +1000, Dave Chinner wrote:
> [ OT, but I'll reply anyway :P ]
>
> On Fri, May 06, 2016 at 02:29:23PM -0400, J. Bruce Fields wrote:
> > On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote:
> > > In the latest XFS filesystem format, we randomise the genera
[ OT, but I'll reply anyway :P ]
On Fri, May 06, 2016 at 02:29:23PM -0400, J. Bruce Fields wrote:
> On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote:
> > In the latest XFS filesystem format, we randomise the generation
> > value during every inode allocation to make it hard to guess th
> int ret = statx(int dfd,
> const char *filename,
> unsigned int flags,
> unsigned int mask,
> struct statx *buffer);
Please move the flags and mask after the buffer, similar to how all
the AT_ flags wer
On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote:
> IMO, exposing the inode generation number to anyone is a potential
> security problem because they are used in file handles.
>
> Most file handles provided by filesystems are simply an encoding of
> the inode number + generation numbe
On Thu, May 05, 2016 at 03:48:16PM -0400, Jeff Layton wrote:
> On Thu, 2016-05-05 at 10:09 +1000, NeilBrown wrote:
> > On Thu, May 05 2016, Dave Chinner wrote:
> >
> > >
> > > On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote:
> > > >
> > > > (4) File creation time (st_btime*), data
On Thu, May 05, 2016 at 09:04:09PM +0100, David Howells wrote:
> Jeff Layton wrote:
>
> > I don't see a real attack vector here either, but OTOH is there a
> > potential user of this at the moment?
>
> I'm not sure. BSD stat has an st_gen, so it's possible something out there
> will use it if i
Jeff Layton wrote:
> I don't see a real attack vector here either, but OTOH is there a
> potential user of this at the moment?
I'm not sure. BSD stat has an st_gen, so it's possible something out there
will use it if it exists.
> An earlier chunk of the patch description says:
>
> (7) Inode g
On Thu, 2016-05-05 at 10:09 +1000, NeilBrown wrote:
> On Thu, May 05 2016, Dave Chinner wrote:
>
> >
> > On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote:
> > >
> > > (4) File creation time (st_btime*), data version (st_version), inode
> > > generation number (st_gen).
> > >
On Thu, May 05 2016, Dave Chinner wrote:
> On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote:
>> (4) File creation time (st_btime*), data version (st_version), inode
>> generation number (st_gen).
>>
>> These will be returned if available whether the caller asked for them o
On Fri, Apr 29 2016, David Howells wrote:
> Add a system call to make extended file information available, including
> file creation time, inode version and data version where available through
> the underlying filesystem.
>
>
>
> OVERVIEW
>
I think all this documentation is inv
On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote:
> (4) File creation time (st_btime*), data version (st_version), inode
> generation number (st_gen).
>
> These will be returned if available whether the caller asked for them or
> not. The corresponding bits in st_mask
Andreas Dilger wrote:
> > STATX_INFO_ENCRYPTEDFile is encrypted
>
> This flag overlaps with FS_ENCRYPT_FL that is encoded in the FS_IOC_GETFLAGS
> attributes. Are the FS_* flags expected to be translated into STATX_INFO_*
> flags by each filesystem, or will they be partly duplic
On Apr 29, 2016, at 6:57 AM, David Howells wrote:
>
> Add a system call to make extended file information available, including
> file creation time, inode version and data version where available through
> the underlying filesystem.
Hi David,
thanks for resubmitting the patch series. No request
Add a system call to make extended file information available, including
file creation time, inode version and data version where available through
the underlying filesystem.
OVERVIEW
The idea was initially proposed as a set of xattrs that could be retrieved
with getxattr(), bu
32 matches
Mail list logo
