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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 23 Apr 2009 09:09:13 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Miklos Szeredi <miklos@...redi.hu>
CC:	linux-kernel@...r.kernel.org, fuse-devel@...ts.sourceforge.net
Subject: Re: [PATCHSET] CUSE: implement CUSE, take #3

Hello,

Miklos Szeredi wrote:
> 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.

Hmm... there really isn't any object lifetime issue with or without
the pointers as both fuse_file and fuse_inode follow VFS lifetime
rules.  I tried several different approaches including adding nodeid
but what pushed me toward adding the pointers was that the parameter
passing and which uses/depends on what becomes a bit too complex with
other approaches.  e.g. How do you discern between needing vfs inode
and fuse inode?

>  - 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.

Cool.

>  - 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 don't see why the kernel thread is such a big problem.  It's just a
kernel thread.  We can surely fold FUSE_INIT inside FUSE_INIT tho but
one way or the other doesn't make whole lot of difference.

> 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.

The difference between FUSE and CUSE in this regard is that the
synchornous part of initialization is much less for CUSE.  ie. For
FUSE, after the mount is complete, all accesses go to FUSE, so it's
all good.  However, for CUSE, the device nodes are setup
asynchronously, so there's no such inherent synchronization point as
mount.  This becomes a problem when CUSE is started from modprobe to
emulate devices on demand because modprobe should not return before
the device nodes are setup.

Thanks.

-- 
tejun
--
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/