Hi again!
I've remembered that patch and want to continue the discussion :)
My current question is about the memory allocation. In my original patch
I'm doing kzalloc(4 + fieinfo->fi_extents_max * sizeof(struct
fiemap_extent)) which is basically based on a userspace-supplied value.
Do I understand correctly this is bad i.e may lead to a DoS if a process
will request a very big buffer for extents? And what can be done about
it if so?
Miklos Szeredi wrote 2014-03-05 19:02:
On Wed, Mar 5, 2014 at 12:16 PM, <vitalif@xxxxxxxxxx> wrote:
The issue I have with the interface is: why reinvent a new API on
each
of the interfaces? Yes, we do that for most requests, but here's a
request that is already in a flat structure format, exactly what the
kernel API needs. So I suggest that we mirror the fiemap structures
there. On the library API you can also just pass a "struct fiemap *"
pointer to the fiemap method and be done with that.
Thanks for answering!
I copied API into fuse because I've seen 2 fiemap APIs in the kernel:
one in
include/uapi/linux/fiemap.h and one in include/fs.h... the 'request'
structure differs, first API uses platform-independent data types
(u32/u64),
and the second uses 'unsigned int'. I think that's what confused me.
But yes, the individual extent structure is the same... So OK, I'll
change
patches to use it instead of a copied structure.
But I have a small question - what about the headers? struct fiemap is
in
/usr/include/linux/fiemap.h. What's the correct way - should it be
copied
into fuse, or should the system header be required? (what about
non-linux
fuse?)
In <linux/fuse.h> the best is to copy the structures so that it works
on other archs.
On the userspace API we can just forward declare the structure without
having to include anything. Any portable implementations actually
using FIEMAP will have to check (e.g. with autoconf) whether struct
fiemap is defined and include the header if it is.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
