search for: fdnum

...able>(J->second))) break; if (IOB) break; } } // Check to see if this is a reference to __iob... if (IOBBase) { unsigned FDNum = ((unsigned long)Ptr-IOBBase)/FILESize; if (FDNum == 0) return stdin; else if (FDNum == 1) return stdout; else if (FDNum == 2) return stderr; }...

...break; > if (IOB) break; > } > } > > // Check to see if this is a reference to __iob... > if (IOBBase) { > unsigned FDNum = ((unsigned long)Ptr-IOBBase)/FILESize; > if (FDNum == 0) > return stdin; > else if (FDNum == 1) > return stdout; > else if (FDNum == 2) > return stderr; > } >...

...reak; > > } > > } > > > > // Check to see if this is a reference to __iob... > > if (IOBBase) { > > unsigned FDNum = ((unsigned long)Ptr-IOBBase)/FILESize; > > if (FDNum == 0) > > return stdin; > > else if (FDNum == 1) > > return stdout; > > else if (FDNum == 2) > > return stderr; > > } > >...

...>https://bugzilla.samba.org/show_bug.cgi?id=15376? > >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271704? Samba uses a horrible hack, as far as I know Linux specific, to do this. Once it has a O_PATH fd, it then uses the path based xattr call on the string /proc/<pid>/fd/<fdnum> where fdnum is the O_PATH fd we already opened. This is proven safe.

I?ve been looking at an issue when compiling Samba on FreeBSD 13 with the vfs_zfsacl module. It seems the logic that detect O_PATH support in Samba doesn?t work right with FreeBSD 13 (since it has implemented O_PATH support) and especially with the acl_get_fd() function. This is a bug (or rather a missing feature) in FreeBSD that there is a patch for now (dunno when it?ll appear in a release

...rst index e33c81ed41f1..085f9b12a6a3 100644 --- a/docs/tools/virtiofsd.rst +++ b/docs/tools/virtiofsd.rst @@ -87,6 +87,10 @@ Options Listen on vhost-user UNIX domain socket at PATH. +.. option:: --socket-group=GROUP + + Set the vhost-user UNIX domain socket gid to GROUP. + .. option:: --fd=FDNUM Accept connections from vhost-user UNIX domain socket file descriptor FDNUM. diff --git a/tools/virtiofsd/fuse_i.h b/tools/virtiofsd/fuse_i.h index 1240828208ab..492e002181e2 100644 --- a/tools/virtiofsd/fuse_i.h +++ b/tools/virtiofsd/fuse_i.h @@ -68,6 +68,7 @@ struct fuse_session { size_...

....cgi?id=15376? >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271704? > > Samba uses a horrible hack, as far as I know Linux > specific, to do this. > > Once it has a O_PATH fd, it then uses the path > based xattr call on the string /proc/<pid>/fd/<fdnum> > where fdnum is the O_PATH fd we already opened. > This is proven safe.

[Just starting out with DTrace and was hoping to get some guidance.] I have a "benchmark" program that I monitored with both prstat (prstat -mL -P <PID>) and pfilestat (from the DTrace toolkit). Prstat reports LAT values in the 0.1-0.2% range, but pfilestat reports "waitcpu" values in the 6-10%. Since those two numbers supposedly represent time waiting for the CPU,

Hi, This is an initial implementation of a vhost-user backend for the VirtIO RPMB device. The device is currently in the draft of the next VirtIO specification and describes block device which uses combination of a key, nonce, hashing and a persistent write counter to prevent replay attacks (hence Replay Protected Memory Block). It is implemented as a vhost-user device because we want to