12/17/2012 11:04 PM, Brian Foster пишет:
On 12/17/2012 09:13 AM, Maxim V. Patlasov wrote:
Hi,
12/15/2012 12:16 AM, Brian Foster пишет:
On 12/14/2012 10:21 AM, Maxim V. Patlasov wrote:
...
+
fuse_do_truncate() looks fairly close to fuse_do_setattr(). Is there any
reason we couldn't make fuse_do_setattr() non-static, change the dentry
parameter to an inode and use that?
fuse_do_setattr() performs extra checks that fuse_do_truncate() needn't.
Some of them are harmless, some not: fuse_allow_task() may return 0 if
task credentials changed. E.g. super-user successfully opened a file,
then setuid(other_user_uid), then write(2) to the file. write(2) doesn't
check uid, but fuse_do_truncate() - via fuse_allow_task() - does.
Conversely, what about the extra error handling bits in
fuse_do_setattr() that do not appear in fuse_do_truncate() (i.e., the
inode mode check, the change attributes call, updating the inode size,
etc.)? It seems like we would want some of that code here.
Yes, they won't harm.
fuse_setattr() is the only caller of fuse_do_setattr(), so why not embed
some of the initial checks (such as fuse_allow_task()) there? I suppose
we could pull out some of the error handling checks there as well if
they are considered harmful to this post-write error truncate situation.
Makes sense. I like it especially because it allows to avoid code
duplication (handling FUSE_SETATTR fuse-request).
FWIW, I just tested a quick change that pulls up the fuse_allow_task()
check (via instrumenting a write error) and it seems to work as
expected. I can forward a patch if interested...
I did exactly the same before sending previous email :) In my tests it
works as expected too (modulo fuse_allow_task() that we can move up).
I'll re-send corrected patch soon.
Thanks,
Maxim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/