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]

Message-ID: <49F908A1.70207@kernel.org>
Date:	Thu, 30 Apr 2009 11:10:41 +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:
>>> VFS inode should never be needed by the CUSE codepaths.  Well, maybe
>>> for setting access/modification times, but in any case those need not
>>> be shared with fuse code.
>> One more usage: locking.
> 
> You mean inode->i_mutex locking?  It doesn't look to me as if cuse
> would need to do any of that.

Well, there are a few places in file.c and dir.c IIRC and I think
there's one path which CUSE uses (or used, it might have gone away
with your changes).  I was concerned with the different assumptions
FUSE code paths are under depending on whether the code is used by
CUSE or that, which is not at all obvious from looking at the FUSE
code only, so the large update to put FUSE file handling paths under
the same assumptions which are safe for CUSE.  I think it's too subtle
but it's also true that the paths used by CUSE are quite limited, so
as long as you can keep a close eye on it I guess it would be okay.

>>> I don't see any problems with doing the device initialization in the
>>> context of the replying process (which will usually be the same as
>>> the one opening the device anyway).
>> I don't know.  If it's simple, sure why not.  If it makes things even
>> marginally more complex (state saving and so on), why go that way?
> 
> OK, I folded FUSE_INIT into CUSE_INIT, and moved the CUSE_INIT reply
> processing into the ->end() callback.  This also allows us to remove
> the CUSE_INIT_DONE message, since now the write(2) on the cuse device
> will only return when the device initialization is complete.
> 
> Overall it results in some 100 lines less code (well, some of that is
> because I folded <linux/cuse.h> into <linux/fuse.h>).  But the simpler
> initialization sequence is, I think, definitely worth it.
> 
> The patches are pushed out to the 'cuse' and 'for-next' branches of
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
>
> I'll post the updated libfuse patch as well.  Please let me know if
> you find anything wrong with the current patches.

Looks good to me.  Much prettier with two inits merged.

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/