On Fri, Sep 02, 2016 at 04:18:04PM +0100, Rainer Weikusat wrote: > As far as I can tell, this should work as I can't currently imagine why > a fs operation might end up binding a unix socket despite the idea to > make af_unix.c yet more complicated in order to work around irregular > behaviour of (as far as I can tell) a single filesystem (for which > kern_path_create doesn't really mean kern_path_create
Bullshit. kern_path_create() *does* mean the same thing in all cases. Namely, find the parent, lock it and leave the final name component for the create-type operation. It sure as hell is not guaranteed to take *all* locks that are going to be taken in process of mknod/mkdir/etc. Never had been. and it has to work > around that once it gets control) goes against all instincts I have in > this area. If filesystems need to do arbitrary stuff when > __sb_start_write is called for 'their' superblock, they should be able > to do so directly. > > At present, this is a theoretic concern as I can't (due to other work > committments) put any non-cursory work into this before Sunday. There > may also be other reasons why this idea is impractical or even > unworkable.
