linux-kernel - Re: [PATCHSET] CUSE: implement CUSE, take #3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 Apr 2009 13:39:47 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	tj@...nel.org
CC:	linux-kernel@...r.kernel.org, fuse-devel@...ts.sourceforge.net,
	miklos@...redi.hu
Subject: Re: [PATCHSET] CUSE: implement CUSE, take #3

Hello Tejun,

Sorry for the delay, I was busy reimplementing some of the stuff in
your patchset.  The current state is here:

  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git cuse-test

  http://git.kernel.org/?p=linux/kernel/git/mszeredi/fuse.git;a=shortlog;h=cuse-test

What I changed (IIRC):

 - Don't store pointer to struct inode, struct fuse_inode, and struct
   file in struct fuse_file.  Instead store nodeid in struct
   fuse_file, no worries about object lifetimes this way.

 - Don't implement fsync and flush in CUSE, they don't really make
   sense on character devices.  At least I can't think of any use for
   them.

 - release() in CUSE can be synchronous.  Asynchronous release causes
   many headaches in fuse, but is necessary due to the possible DoS
   that an unprivileged filesystem could do with an unrelated process.
   Since CUSE servers are always privileged, this should not be an
   issue.

 - Other cleanups.

I still think that the INIT sequence in CUSE is way too complicated
and that the kernel thread is unnecessary.  How about doing the init
with a single CUSE_INIT message which embeds the fuse_init_in and
fuse_init_out structures.  I also don't see the purpose of the
CUSE_INIT_DONE message.  Isn't it enough not to send any other
messages while the initialization is not complete?  This is what fuse
does.

I'm currently testing with ossp and some things do work, but I'm also
having issues with some apps.  But that's a topic for another mail...

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/