On Nov 30 15:04, Corinna Vinschen wrote: > On Nov 30 13:49, Christian Franke wrote: > > Corinna Vinschen wrote: > > > On Nov 28 22:59, Christian Franke wrote: > > > > ... > > > > The attached experimental patch does not fix the lseek() (sorry), but > > > > handles such block devices with fhandler_dev_floppy instead. Tested with > > > > above use cases. > > > > > > > > I'm not sure whether this could break access to other /proc/sys block > > > > devices. This would happen if fh->exists() returns virt_blk for devices > > > > which do not support IOCTL_DISK_GET_DRIVE_GEOMETRY* or > > > > IOCTL_DISK_GET_PARTITION_INFO*. > > > Pushed, becasue it's a nice idea. The above problem shouldn't happen, > > > in theory, but I'm not sure. virt_blk is generated for devices types > > > > > > FILE_DEVICE_DISK > > > FILE_DEVICE_CD_ROM > > > FILE_DEVICE_VIRTUAL_DISK > > > FILE_DEVICE_DFS > > > FILE_DEVICE_NETWORK_FILE_SYSTEM > > > > > > FILE_DEVICE_DFS or FILE_DEVICE_NETWORK_FILE_SYSTEM might be a problem, > > > but there should be a way to workaround that, if necessary, isn't it? > > > Maybe it's a bad idea to treat those as blk devices at all? > > > > Could anything be read from such a node? If yes, treat as character device? > > > > If no and /proc/sys/foo/bar/some/path allows access to /some/path behind > > DFS/NFS node /proc/sys/foo/bar, then treat as directory? > > > > This is already the case for SMB shares: > > > > $ ls -ld /proc/sys/DosDevices/X: > > lr-------- 1 ... 0 Nov 30 13:10 /proc/sys/DosDevices/X: -> > > /proc/sys/Device/LanmanRedirector/;X:..../127.0.0.1/Share > > > > $ ls -lLd /proc/sys/DosDevices/X: > > drwxr-xr-x 1 ... 0 Nov 14 09:06 /proc/sys/DosDevices/X: > > > > $ ls -L /proc/sys/DosDevices/X: > > ... files on this share > > ...and it's already the case for NFS shares, too: > > $ ls -ld /proc/sys/DosDevices/Y: > lr-------- 1 corinna vinschen 0 Nov 30 14:59 /proc/sys/DosDevices/Y: -> > /proc/sys/Device/MRxNfs/;Y:00000000001cb27f/... > > $ ls -lLd /proc/sys/DosDevices/Y: > drwxr-xr-x 5 corinna vinschen 41 May 19 2016 /proc/sys/DosDevices/Y: > > That means we don't have to handle FILE_DEVICE_NETWORK_FILE_SYSTEM in > the code creating the virt_blk device type at all. I have high hopes > this is the same for DFS, albeit I can't test it...
Oh, right, I just realized that \Device\MRxNfs, as well as \Device\LanmanRedirector are symlinks pointing below \Device\Mup: $ ls -l /proc/sys/Device/LanmanRedirector lr--r--r-- 1 Administrators SYSTEM 0 Nov 30 15:20 /proc/sys/Device/LanmanRedirector -> /proc/sys/Device/Mup/;LanmanRedirector $ ls -l /proc/sys/Device/MRxNfs lr--r--r-- 1 Administrators SYSTEM 0 Nov 30 15:20 /proc/sys/Device/MRxNfs -> /proc/sys/Device/Mup/;MRxNfs \Device\Mup is a character device and thus the devices below are not accessible for directory enumeration. I assume it's the same for DFS. Corinna
