[PATCH] ncpfs in 2.3.30-pre5
Hi Linus,
when grab_cache_page was added to kernel, someone who did global
kernel search replace swapped grab_cache_page and find_lock_page
in ncpfs :-( Because of ncpfs requires page allocation to success,
it did not work as it did find instead of allocation... These
changes are limited to linux/fs/ncpfs/dir.c.
Except that, as support for upcoming new version of ncpfs, could
you apply rest of patch (linux/fs/ncpfs/Config.in and
linux/fs/ncpfs/ioctl.c). Change in Config.in is only enabling
(and renaming) configuration item prepared for long time.
Changes in linux/fs/ncpfs/ioctl.c make sure that no-one except
user (and root :-( ) can read your current session info from kernel.
Thanks for applying this.
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
diff -urdN linux/fs/ncpfs/dir.c linux/fs/ncpfs/dir.c
--- linux/fs/ncpfs/dir.cFri Dec 3 14:54:40 1999
+++ linux/fs/ncpfs/dir.cFri Dec 3 18:31:40 1999
@@ -487,7 +487,7 @@
filp-f_pos = 2;
}
- page = find_lock_page(inode-i_data, 0);
+ page = grab_cache_page(inode-i_data, 0);
if (!page)
goto read_really;
@@ -516,7 +516,7 @@
for (;;) {
if (ctl.ofs != 0) {
- ctl.page = grab_cache_page(inode-i_data, ctl.ofs);
+ ctl.page = find_lock_page(inode-i_data, ctl.ofs);
if (!ctl.page)
goto invalid_cache;
ctl.cache = (union ncp_dir_cache *)
@@ -661,7 +661,7 @@
ctl.cache = NULL;
ctl.idx -= NCP_DIRCACHE_SIZE;
ctl.ofs += 1;
- ctl.page = find_lock_page(inode-i_data, ctl.ofs);
+ ctl.page = grab_cache_page(inode-i_data, ctl.ofs);
if (ctl.page)
ctl.cache = (union ncp_dir_cache *)
kmap(ctl.page);
diff -urdN linux/fs/ncpfs/Config.in linux/fs/ncpfs/Config.in
--- linux/fs/ncpfs/Config.inThu Oct 7 17:17:09 1999
+++ linux/fs/ncpfs/Config.inFri Dec 3 14:56:40 1999
@@ -10,6 +10,6 @@
bool 'Lowercase DOS filenames' CONFIG_NCPFS_SMALLDOS
fi
bool ' Allow mounting of volume subdirectories' CONFIG_NCPFS_MOUNT_SUBDIR
-# bool ' NDS interserver authentication support' CONFIG_NCPFS_NDS_DOMAINS
+bool ' NDS authentication support' CONFIG_NCPFS_NDS_DOMAINS
bool ' Use Native Language Support' CONFIG_NCPFS_NLS
bool ' Enable symbolic links and execute flags' CONFIG_NCPFS_EXTRAS
diff -urdN linux/fs/ncpfs/ioctl.c linux/fs/ncpfs/ioctl.c
--- linux/fs/ncpfs/ioctl.c Fri Oct 29 17:53:32 1999
+++ linux/fs/ncpfs/ioctl.c Fri Dec 3 14:56:44 1999
@@ -364,8 +364,7 @@
#ifdef CONFIG_NCPFS_NDS_DOMAINS
case NCP_IOC_GETOBJECTNAME:
- if ( (permission(inode, MAY_READ) != 0)
-(current-uid != server-m.mounted_uid)) {
+ if (current-uid != server-m.mounted_uid) {
return -EACCES;
}
{
@@ -396,8 +395,7 @@
return 0;
}
case NCP_IOC_SETOBJECTNAME:
- if ( (permission(inode, MAY_WRITE) != 0)
-(current-uid != server-m.mounted_uid)) {
+ if (current-uid != server-m.mounted_uid) {
return -EACCES;
}
{
@@ -441,8 +439,7 @@
return 0;
}
case NCP_IOC_GETPRIVATEDATA:
- if ( (permission(inode, MAY_READ) != 0)
-(current-uid != server-m.mounted_uid)) {
+ if (current-uid != server-m.mounted_uid) {
return -EACCES;
}
{
@@ -471,8 +468,7 @@
return 0;
}
case NCP_IOC_SETPRIVATEDATA:
- if ( (permission(inode, MAY_WRITE) != 0)
-(current-uid != server-m.mounted_uid)) {
+ if (current-uid != server-m.mounted_uid) {
return -EACCES;
}
{
VFS: Busy inodes after unmount...
Hi Al, during last week I decided that I should retry my attempt to add NCP sessions support into kernel. My last attempts through adding NCP protocol family ended in some troubles because of connection to NDS requires connections to couple of Netware servers. So for now I decided to make these connections visible to userspace as filesystem. Except other pros it also allows me running old userspace code through each connection... Because of all inodes (== connections) are always in-core, I took ramfs as example (*) - and I found that double dget() way does not work now (2.3.99-pre9.1) - if I create file (== inode == connection), instead of getting -EBUSY from umount it unmounts with 'VFS: Busy inodes...'. Inspection of do_umount/may_umount revealed, that only usage count on vfsmnt counts - but vfsmnt is not available from -create and -unlink, so I cannot play with it. Should I, as temporary solution, remove dentry tree in put_super, or what's correct way doing this? My original idea was to return -EBUSY if ANY file (== connection) exist in ncpconnfs. If you tell me that it is impossible, I can create another solution, which will pin inodes in memory by holding them open by some daemon, but... Thanks, Petr Vandrovec [EMAIL PROTECTED] (*) I hoped that ramfs works. It probably does not :-(
Re: Proposal: int (permission*)(struct dentry *, int)
On 15 May 00 at 21:56, Alexander Viro wrote: On Sun, 14 May 2000, Petr Vandrovec wrote: On Sun, May 14, 2000 at 04:37:46AM -0400, Alexander Viro wrote: devfs_unlink() does - especially in free_dentries(). Or you can get your kicks looking at the crap (sorry, Petr, but it _is_ crap - populating dcache really shouldn't be done by readdir()) in ncp_readdir(). P.S.: Original idea was to cache only readdir data from server, but it could consume twice as much memory - once in pagecache and second time when real dentries/inodes get created. And ncp_lookup was forced to search pagecache before doing server lookup... So populating dentry tree from readdir looked perfect to me. It is not? It is not. For a lot of reasons, starting from pressure on dcache LRU (readdir() on ncpfs - lots of stuff fed into dcache - very long LRU - next dcache flush takes out former LRU population) and including the problems with making dcache SMP-safe. BTW, am I right assuming that volume number + dirExt... thing identify the Yes. object in unique way? If they do - I have a trick that can get rid of double memory use _and_ avoid dcache pollution/need of very messy locking. Unfortunately, during readdir NCP calls there is a thing called search sequence. Novell says that it is opaque 9 byte structure, so you have to store it somewhere (but in reality, it is volume number + parent (directory) entry number + last found entry number, so if you have idea how to do it, I can remove search sequence completely) during directory reads (and because of it is not number of next entry, but number of last found entry, it is really broken if you do 'rm -rf' - it will bomb with invalid search position under libc5, because of search sequence points to nonexistent entry (or under libc6 without caching data already fetched by ncpfs, but not returned to userspace by glibc2 getdents wrapper)). Petr Vandrovec [EMAIL PROTECTED]
Re: VFS: Busy inodes after unmount...
On 15 May 00 at 22:00, Alexander Viro wrote:
On Mon, 15 May 2000, Petr Vandrovec wrote:
Hi Al,
during last week I decided that I should retry my attempt to add
NCP sessions support into kernel. My last attempts through adding
NCP protocol family ended in some troubles because of connection to
NDS requires connections to couple of Netware servers.
So for now I decided to make these connections visible to userspace
as filesystem. Except other pros it also allows me running old userspace
Ummm... Details, please?
I'm trying to solve problem when one of user's tasks creates connection
to server and another of user's tasks (but without parent-child relation
to first task) wants to use this connection. Something like /dev/ptmx and
/dev/pts/*. But because of historically (under other OS-es) connections
to other servers are persistent across tasks, I wanted to stay connection
alive after close, unless you unlink slave file. So you could have
live connection connected to inode which is not open.
or what's correct way doing this? My original idea was to return -EBUSY
if ANY file (== connection) exist in ncpconnfs.
Exists or is busy? The latter will be caught, the former is trickier.
I wanted exists. But during yesterday/today I decided that it is better
to handle persistent connections through some systemwide daemon, which will
keep them open (== busy). So you can forget about these troubles (except
that ramfs needs fixing).
If you tell me that it is impossible, I can create another solution,
which will pin inodes in memory by holding them open by some daemon, but...
BTW, what's up with these root-chaning ioctls? What are they trying to do?
Because of there are no real NCP connections in-kernel, only through
mountpoint, just after mount() ncp filesystem is completely dead, because
of connection is not authenticated - you do not have any access to
files/dirs on server except SYS:LOGIN directory. Userspace opens
mountpoint and through NCP_IOC_REQUEST authenticates connection.
Then old ncpfs issues NCP_IOC_CONN_LOGGED_IN, which performs root inode
lookup. Newer ncpfs issues NCP_IOC_SETROOT instead, which sets root inode
from data supplied by userspace (and can set ncpfs root somewhere else
than what CONN_LOGGED_IN api allows).
After I add real NCP connections, I can then pass already authenticated
connection into mount(...,"ncpfs",...), getting rid of these two
ioctls.
[and after I realize how to fix file-lock() to actually work for
non-POSIX systems (partial unlocks impossible) and for failures, I can
get rid of NCP_IOC_LOCKUNLOCK]
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
Re: Proposal: int (permission*)(struct dentry *, int)
On Sun, May 14, 2000 at 04:37:46AM -0400, Alexander Viro wrote: devfs_unlink() does - especially in free_dentries(). Or you can get your kicks looking at the crap (sorry, Petr, but it _is_ crap - populating dcache really shouldn't be done by readdir()) in ncp_readdir(). Hi Alexander, is implementation wrong or whole idea (some race? Do not forget that it is network filesystem, so only troubles which cannot happen due to other machines count)? Netware does not have hardlinks (without BIG effort) and reading directory from server offer all data needed for constructing inode. By creating real dentries/inodes during readdir (and caching them for some time period) some operations are now twice as fast as before - for example unlinking directories. Al, BKernelJanitorFH Petr Vandrovec [EMAIL PROTECTED] P.S.: Original idea was to cache only readdir data from server, but it could consume twice as much memory - once in pagecache and second time when real dentries/inodes get created. And ncp_lookup was forced to search pagecache before doing server lookup... So populating dentry tree from readdir looked perfect to me. It is not?
Re: [PATCH][CFT] dcache-ac10-M1 - dcache threading
On 7 Jun 00 at 6:20, Alexander Viro wrote:
On Wed, 7 Jun 2000, Alexander Viro wrote:
Aiiee... Idiot me didn't notice that
a) atomic_read() is signed
b) 0 (131) on 32bit platforms
c) looking into logs is useful, even if flamage is actually
harmless.
Sorry, folks. Fix (compared to ac10-M) is to change the line 820 in
fs/inode.c to
if ((unsigned)atomic_read(inode-i_count)(1U31)) {
Hi Al,
I'm sorry, but what's wrong with
if (atomic_read(inode-i_count) 0) {
...
}
except that it produces different result for 0x8000 ? If someone
has 64bit atomic, why limit them to 31 bits only?
(also, smp sparc has only 24-bit atomic values, but it does not matter
here, as it is signed, so underflow is catched correctly anyway)
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
Re: [RFC] fhandle implementation.
On Fri, 16 Jun 2000, Neil Brown wrote:
knfsd can get answers to such questions as:
- can you support NFSD_FH_LOCATABLE
- is file name comparison case insensitive (will be needed for NFSv4)
Sorry, but does it mean that NFSv4 passes (by standard definition)
filenames only in UTF8 (or another Unicode encoding)?
Or means this that both client and server must use same codepage?
And how is resolved if there are two names in underlying exported
directory which match except for case?
Netware uses huge and complicated code to generate unique names and
stores these names in their own namespaces (NFS = 255 chars, case
sensitive; LONG = 255 chars, case insensitive; MAC = 31 chars, case ??;
DOS = 14 chars, uppercase; FTAM = 254 chars, lowercase only; of course
each namespace has different set of reserved characters, "*" from NFS
is translated as "STRANGE" to other namespaces... do we really want this) :-(
Thanks,
Petr Vandrovec
[EMAIL PROTECTED]
[PATCH] VFAT short names in 2.4.0-test5-pre[3,4]
Hi Gordon,
it looks like that recently added 16-bit charsets added few bugs
into VFAT code. I was really surprised when I found that for
VLAKC.TTR short name is VLAKCTTR...
I'm not VFAT guru, so please can you review this patch and
eventually fix it or send to Linus?
Thanks,
Petr Vandrovec
[EMAIL PROTECTED]
diff -urdN linux/fs/vfat/namei.c linux/fs/vfat/namei.c
--- linux/fs/vfat/namei.c Mon Jul 24 09:34:50 2000
+++ linux/fs/vfat/namei.c Mon Jul 24 09:38:51 2000
@@ -453,10 +453,11 @@
if (charbuf[chi] != vfat_tolower(nls, c)) return -EINVAL;
if (strchr(replace_chars,c)) return -EINVAL;
if (c ' '|| c==':') return -EINVAL;
- if (c == '.') break;
+ if (c == '.') goto dot;
space = c == ' ';
}
}
+dot:;
if (space) return -EINVAL;
if (len c != '.') {
len--;
@@ -464,6 +465,7 @@
if (charbuf[0] != '.') return -EINVAL;
} else
return -EINVAL;
+ c = '.';
}
if (c == '.') {
if (len = 4) return -EINVAL;
@@ -522,7 +524,7 @@
if (chl == 0)
return -EINVAL;
for (chi = 0; chi chl; chi++){
- if (charbuf[chi] == '.') break;
+ if (charbuf[chi] == '.') goto dot;
if (!charbuf[chi]) return -EINVAL;
if (walk-res == 8) return -EINVAL;
if (strchr(replace_chars,charbuf[chi])) return -EINVAL;
@@ -532,6 +534,7 @@
walk++;
}
}
+dot:;
if (space) return -EINVAL;
if (len = 0) {
while (walk-res 8) *walk++ = ' ';
Re: smbfs-mount flags
On 1 Aug 00 at 14:38, Urban Widmark wrote: To correct this with the current binary solution that requires a new protocol version and a new smbmount (possibly with all sorts of compile/version problems since it includes kernel headers directly). With You should not do it... For example you can compile userspace ncpfs on 2.0.0 kernel and although you did this, such binary will understand all kernels between 2.0.0 and 2.4.0-test6-pre1 - even 32bit uids will work... an ascii option string it would probably not have been done like that in the first place, but changing it requires only administrator changes (fix your fstab entry, autofs map, script). At least with ncpfs there is problem that some of mount options are parsed completely in userspace (passwd,ipserver), some are passed to mountpoint with ioctl (ttl,volume,codepage), some are mapped into VFS flags (ro,rw,noatime,...), some are ignored completely (auto,noauto) and some are pasted into binary mount structure (mode,uid,gid,owner)... So ncpmount has to parse options anyway... I know you were talking about VFS-level options. Is it more acceptable for fs-level options? If not, is there a plan/goal to make mount(8) start passing a binary struct as *data? And what about read_super returning error code except simple NULL/non-NULL error code? So ncpmount could distinguish different reasons of why mount() failed. If there is general consensus that passing binary structure to mount() is stupid, I can change ncpfs behavior for 2.5.x... Best regards, Petr Vandrovec [EMAIL PROTECTED]
i_blocksize, long long i_size and conversion size to blocks
Hi, I just downloaded 2.3.26-pre2 - and surprise, ncpfs does not compile. It happens because of there is inode-i_blocks = (inode-i_size - 1) / inode-i_blksize + 1; Should I introduce i_blksize_shift into private portion of inode and maintain i_blksize only for other kernel parts (stat syscall) or what is correct action? I can hardcode shift value into code because of block size on ncpfs is always 512 bytes, but I just want to know... Thanks, Petr Vandrovec [EMAIL PROTECTED] P.S.: I'm not subscribed to linux-fsdevel (yet), so please CC me if you are replying on fsdevel only.
