Re:PLEASE REMOVE US FROM YOUR MAILING LIST
Ballon's (snowman@ici.net)
Sat, 21 Feb 1998 13:01:51 -0500
At 08:22 PM 2/20/98 -0500, you wrote:
>On Fri, 20 Feb 1998, Doug Ledford wrote:
>
>> Thomas Schenk Z wrote:
>> >
>> > Which version of xntpd are you running? We never saw this message until we
>> > upgraded to xntp3-5.91 and then only after switching to 2.0.32 (when the
>> > kernel code changed).
>>
>> rpm reports:
>> xntp3-5.91_export-1
>>
>> > I asked the author about this message and he said
>> > that it is harmless, but my experience tells me otherwise. The other thing
>> > I would ask you is whether the machines on which you are running xntpd are
>> > SMP or not. I think that the problem I am experiencing with xntpd may be
>> > SMP specific.
>>
>> Nope, these systems of mine are non-SMP systems.
>>
>> --
>>
>> Doug Ledford <dledford@dialnet.net>
>> Opinions expressed are my own, but
>> they should be everybody's.
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.rutgers.edu
>>
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: "Peter J. Braam" <braam@cs.cmu.edu>
>Date: Fri, 20 Feb 1998 15:00:22 -0500 (EST)
>Subject: Re: PROPOSAL: Process Authentication Groups (PAGs) (fwd)
>
>On 20 Feb 1998, Aaron M. Ucko wrote:
>
>> Robert Watson <robert@cyrus.watson.org> writes:
>>
>> > appear to be that there is a need for finer granularity management of keys
>> > than a mere mapping to UID (which is what Coda currently does).
>>
>> Absolutely. However, it's not clear PAGs a la AFS are the right
>> solution. IMO, token sets (TS's for short, pending a better name)
>> should have the following properties:
>
>The purpose of a PAG is NOT to do token management, but to provide
>identity to token managers.
>
>>
>> (1) It should be possible to create and destroy a TS, and populate
>> it with credential information.
>>
>> (2) A user should be able to have multiple TS's.
>>
>> (3) A process should generally inherit its parent's TS.
>>
>> (4) User A should not be able to access a TS belonging to user B at
>> all, except possibly if A is root or B has explicitly let A.
>>
>> (5) A user should be able to switch TS's on the fly.
>>
>> (6) TS's should take up as little kernel space as possible.
>
>PAGS certainly meet 6.
>
>
>>
>> PAGs satisfy (1), (2), (3), and (4) (barring wraparound), and can
>> satisfy (6), but don't really satisfy (5). I see two sane ways to
>> satisfy (5) with existing shells:
>>
>> (a) Have a variable mapping from sessions or process groups to
>> TS's; this requires either the kernel or the cache manager to
>> keep track of more state, and has the disadvantage (shared
>> with AFS PAGs) that there's no way to start processes which
>> should have different TS's from the same shell.
>>
>> (b) Have the kernel look at the value of some environment variable
>> to determine which of a user's TS's to use. This method has
>> the disadvantage that there's no way for a process to change
>> TS's, because the kernel only sees the initial value of the
>> variable; I suppose it would be possible to provide an
>> additional, independent, mechanism for that, though. It also
>> requires us to be more careful about (4).
>
>In due course there will be many different types of tokens. I think that
>the extra layer of abstraction formed by the PAG will allow easy token
>management for a while to come.
>
>If you centralize things in the kernel, you would have different problems:
>how would you use one token for AFS and another for Coda etc.
>
>>
>> --
>> Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)
>>
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: "Phillip Burr" <philb@powerquest.com>
>Date: Fri, 20 Feb 1998 13:00:11 -0700
>Subject: Re: mounting unpartitioned drives
>
>If what you are looking for is access to the whole physical drive and not
>to just a partition, then you don't need to mount anything. Mounting gives
>you access to a filesystem. If you want access to the whole drive then
>I assume that you do not want the filesystem handled for you. There is,
>in fact, a very easy way to access the 'whole disk'. If, for example, you
>want to access the primary master ide HD, all you need to do is access
>the file /dev/hda. There is nothing more to it. You can read it as you
>would any other file. But remember, access through /dev/hda is on a
>byte offset and not a sector offset. Therefore, if you wanted to read the
>MBR, you would llseek to the beginning of the file and read in 512 bytes.
>To read in Cylinder 0, Head 0, Sector 3, you would llseek (512*2) bytes into
>the file (remember Sector is a 1 based number) and read in 512 bytes. If
>you want to access everything in terms of CHS, you would have to
>convert it into its appropriate LBA value.
>
>I hope this really covers the point of what you were trying to do. It
looked to
>me that you were heading the wrong direction.
>
>Phil Burr
>
>> ...
>>Why?? If I have not requested an access to any partition, but to the
>>whole disk, there must not be any partition scan. And if the first
>>sector does not end with "0x55aa" signature, the partition scan is
>>always incorrect.
>>
>> Best regards, -- Vladimir.
>
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: "phil.burr@usa.net (Phillip Burr)" <philb@powerquest.com>
>Date: Fri, 20 Feb 1998 12:49:16 -0700
>Subject: Block device locking (was Re: mkswap & swapon)
>
>Perhaps what is needed is a device locking mechanism. I am not
>refering to file locking; POSIX implementations should handle that.
>I mean locking on device major and minor codes. Aside from the
>link issues, you could also cause the same problem (and currently
>have no way of correcting or working around it that I know of) if
>you were to use mknod to create another device with the same
>major and minor codes. For example, if the swap partition were
>/dev/hda3, that block device has a major/minor of 3 and 3. One
>could create another device for that major/minor with the command
>'mknod ~/swap b 3 3' and get around any locking mechanism using
>i_count and d_count. (And any other that I know of!)
>
>Obviously, using mknod is not going to be as a common situation as
>the ln issues will be. However, if you truely want to lock a device for
>exclusive access, it must be absolute locking and that can only be
>done by locking the major/minor codes.
>
>Phil Burr
>
>>1. swapon
>>
>>People complain to me that under recent kernels it is
>>possible to do "swapon foo" on the same file twice,
>>and twice some amount is added to the available swap.
>>
>>No, this is not a bug in the swapon which I maintain;
>>it is a kernel bug present in 2.1.87 but not in 2.0.33.
>>
>>I wondered how to fix it but was not sure how to express
>>the property of not being in use under the 2.1.* regime.
>>In the good old days, testing i_count = 1 would suffice.
>>Today, testing d_count = 1 is not enough, because two
>>names can refer to the same file, and
>> ln foo bar; swapon foo; swapon bar
>>would succeed incorrectly.
>>On the other hand, testing i_count = 1 is no good either.
>>Indeed, i_count has become next to meaningless: there can
>>always be dentries that refer to the inode. Thus,
>> ln foo bar; swapon foo
>>would fail because two dentries refer to the inode of foo.
>>
>>How does one express that a file is not in use?
>>
>>(In case anyone answers, cc to aeb@cwi.nl; I do not read linux-kernel.)
>>
>
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
>Date: Fri, 20 Feb 1998 13:41:38 -0700 (MST)
>Subject: Oops on Linux/Alpha 2.0.33
>
>Linux Alpha, kernel 2.0.33 plus alpha-patches.
>
>When doing a backup to a SCSI tape I found myself starring, all of sudden,
>at the followin oops:
>
>Unable to handle kernel paging request at virtual address ffffffffffff8b48
>swapper(0): Oops 0
>pc = [<fffffc0000313098>] ps = 0000
>rp = [<fffffc00003130a0>] sp = fffffc0000303fb0
>r0=7 r1=1 r2=fffffc000041d7f8 r3=fffffc000041d7f8
>r8=1201219c8
>r16=0 r17=2 r18=1201222a0 r19=2800
>r20=2800 r21=11ffff330 r22=0 r23=18272f96f2
>r24=3000000000000000 r25=a r26=fffffc00003130a0 r27=fffffc000031a560
>r28=1 r29=0 r30=fffffc0000303fb0
>Code: c3e00008 203fff9c b4220008 <a77d8b48> 6b5b5d30 27ba0013 23bdcc10
> c3fffffb 47ff041f
>kfree of non-kmalloced memory:
> fffffc000041cb28, next= 0000000000000000, order=0
>kfree of non-kmalloced memory:
> fffffc000041cb10, next= 0000000000000000, order=0
>kfree of non-kmalloced memory:
> fffffc000041d430, next= 0000000000000000, order=0
>idle task may not sleep
>idle task may not sleep
>idle task may not sleep
>idle task may not sleep
>idle task may not sleep
>
>Program counter indeed sits between these two symbols:
>
>fffffc0000313068 T sys_idle
>fffffc00003130c0 t swap_context
>
>After that the machine was continuing merrily (good for Linux :-) and the
>backup did not stop - so I am not even exactly sure what was the other
>state of the machine when this happened as I catched that a while later.
>
>Does that say anything to anybody?
>
>The problem could have been possibly triggered by a fact that 8-bit
>SCSI tape was sitting on 16-bit SCSI controller (Diamond Fireport) with
>default settings. After adjusting on a controller settings for that
>particular ID I wrote over 3 Gig to a tape without any further incidents.
>
> Michal
>
>p.s. unfortunately I do not have this machine right now, so I cannot
>provide more info; maybe in a few days
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: "Michael L. Galbraith" <mikeg@weiden.de>
>Date: Fri, 20 Feb 1998 21:55:23 +0100 (MET)
>Subject: Re: Problems with the new "smp-calibration" routines
>
>On Fri, 20 Feb 1998, Mike Frisch wrote:
>
>> On Fri, 20 Feb 1998, Christian Rost wrote:
>>
>> > Running the CPU's at "normal" speed (166Mhz), everything works fine, but I
>> > don't want to do without the additional 34Mhz ;)
>>
>> If everything works properly when you're running the CPUs at their rated
>> speed, then it's a hardware problem. The solution is simple: don't
>> overclock.
>>
>
>The correct reply IMO sounds more like 'you exceeded design spec and
>didn't get away with it this time .. dang the bad luck'.
>
>You can't violate design spec on a whim and then attribute failures
>to hardware defficiencies.
>
> -Mike
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: Mark Stacey <heathclf@skynet.csn.ul.ie>
>Date: Fri, 20 Feb 1998 20:52:12 +0000 (GMT)
>Subject: hashing functions
>
>Can anyone tell me what this does and under what conditions the goto
>statement will be called (and what has to be done for the goto to be
>avoided):
>
> sk = __tcp_v4_lookup(th, saddr, th->source, daddr, th->dest, dev);
> if (!sk) {
> goto no_tcp_socket;
> }
>
>It's located in the ./net/ipv4/tcp_input.c file in the tcp_rcv function.
>
>Thanks
>
>Mark Stacey
>
>... and that's my two cents.
>
>knowledge, n.:
> Things you believe.
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: Jason Duerstock <jasond@cdc.net>
>Date: Fri, 20 Feb 1998 15:53:56 -0500 (EST)
>Subject: Linux/Alpha, VGA, + 80x50 console mode
>
>How do I get my Linux/Alpha machine to switch to 80x50 mode?
>
>Jason
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: Mark Spencer <markster@marko.net>
>Date: Fri, 20 Feb 1998 15:35:52 -0600 (CST)
>Subject: virtual disk system
>
>I was driving to school today and thought of a problem and a potential
>solution I might try working on for my senior design project, and I wanted
>to run it by some kernel people :)
>
>1. I work at a place. We've got lots of machines with lots of disk
>drives of lots of different sizes. Some are almost empty, others are at
>capacity.
>
>2. It would be great if when my physical disk filled up I could just
>start writing on emptier disks located either in my machine or across the
>network.
>
>3. It might be difficult to get every filesystem to support the idea of
>growing to accomodate more space.
>
>4. Why not implement a virtual disk, somewhat like a virtual memory
>system. Think of your local disk as a kind of cache, and the rest of the
>network as a kind swap. Ever machine thinks that it has 20 gigs of space
>or whatever, but it really doesn't. You just map virtual blocks to real
>blocks, either locally or on remote systems. You would have /dev/vd0 or
>/dev/vd1, etc etc which could be configured to be just about any size
>(larger sizes of course would have heavier fs overhead associated with
>them).
>
>5. This is *not* a filesharing system. It would be implemented at the
>*block* level. There would be an equivalent of a "page table" for looking
>up information. Only the original writer is guaranteed to know where
>their files were. Sharing would have to be done with NFS or something
>else.
>
>6. The system would be multiple logical volumes, multiple physical
>volumes, but with no obvious map between them. I would try to keep it as
>close to the virtual memory analogy as possible (see below # 8).
>
>7. The only obvious *filesystem* modification that would be necessary is
>that when an inode or equivalent is freed, an ioctl() would have to be
>added to tell the disk that it is now free so it could be overwritten.
>Perhaps this could be added to the VFS code and no individual filesystems
>would need modification at all!
>
>8. Rather than having a dedicated, fixed size cache, the system would be
>an all-cache system. When I requested a file to my workstation, if it was
>not already local, it would be copied to my local hard drive over
>something else, and then whoever I copied it from could mark that block as
>"able to be written over" since I have a valid copy.
>
>9. Some kind of redundancy (Can I use anything from RAID in this?) would
>be a great feature. Simple mirroring at the least, but that seems rather
>inefficient. At the simplest level, imagine that for every block in the
>virtual system, there are two physical blocks which contain the data (on
>different physical media). Then, if there is a media failure, you simply
>replace the bad media and ask all the other devices (which have exactly
>one copy of your data) to tell you what you had on it. Instant network
>level redundancy without backups.
>
>10. A quota system would probably be desirable to keep it from going
>completely out of hand, but then again, if you pick reasonable partition
>sizes, it should be okay since you won't expand past what you decide the
>partition be.
>
>
>Anyway, it's an idea that I would like to persue if any of you think it's
>viable. It would be alot of work to design, but hey, that's what senior
>design is all about, right? Any comments would be greatly appreciated.
>
>If you have any interest, please e-mail me, and maybe I can setup a list.
>I've actually thought through the problem more than I can relate here.
>
> -Mark Spencer
>
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
>Date: Fri, 20 Feb 1998 17:08:18 -0500 (EST)
>Subject: Re: PROPOSAL: Process Authentication Groups (PAGs)
>
>> there is a need for finer granularity management of keys
>> than a mere mapping to UID (which is what Coda currently does).
>...
>> One approach is that processes are in "groups" for the purposes
>> of distributed file system identities. Usually people aquire an
>> identity for a session, expect different identities for different
>> sessions, etc. However, the existing UNIX process groupings have
>> other purposes -- process groups are used for Job control, and
>> sessions are too fine grained (if I run xterm, which will be
>> associated with a new pty, I want to be in the same authentication
>> group). And UNIX UID does not seem to be sufficient. Hence a new
>> grouping, and that grouping is named the PAG, currently.
>
>This looks totally bogus. The UID is how Unix does security.
>Users don't share UIDs on any sane system. Try explaining to
>a user why they can't edit a file with one login even though
>it works fine with another login. Users have enough trouble
>as it is.
>
>Assume I want to "break" this system. I start the debugger...
>You'd need to consider processes in different PAGs as having
>different UIDs. I could edit a file (on ext2 in /tmp even)
>that a different PAG uses to store file names... Oh, I've just
>broken into my own account. :-)
>
>More useful: POSIX privs and ACLs. There is some existing code
>for both. One or both can be done on ext2, UFS, NTFS... and Coda.
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: "Pawel S. Veselov" <vps@unicorn.math.spbu.ru>
>Date: Sat, 21 Feb 1998 02:48:52 +0300 (MSK)
>Subject: [none]
>
> Hello, All !
>
> Strange problem here ...
>
> I typed reboot for 2.0.33 and after reinitialization I got "crc error,
> system halted" message after "uncompressing the kernel". The kernel
> was just recompiled and lile rerun. The most weird, that pressing reset
> did not fix the problem, but repowering did.
>
> This is a Pentium AMD-100 machine, with one IDE HD and IDE CD on different
> interfaces.
>
> I understand, that it is probably not kernel problem, but can anybody
> help me to explain what happening ? Pentiums have to have no difference
> between repowering and resetting and even rebooting...
>
> Thank you.
>
>Bye.
>- --
>Smear the road with a runner!!
>
>- --
> With best of best regards, Pawel S. Veselov (aka Black Angel)
> Internet e-mail : vps@mindless.com
> Web page : http://www.niimm.spb.su/~vps/ | ICQ UIN : 5252265
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: "David S. Miller" <davem@dm.cobaltmicro.com>
>Date: Fri, 20 Feb 1998 15:57:40 -0800
>Subject: Re: hashing functions
>
> Date: Fri, 20 Feb 1998 20:52:12 +0000 (GMT)
> From: Mark Stacey <heathclf@skynet.csn.ul.ie>
>
> Can anyone tell me what this does and under what conditions the goto
> statement will be called (and what has to be done for the goto to be
> avoided):
>
> sk = __tcp_v4_lookup(th, saddr, th->source, daddr, th->dest, dev);
> if (!sk) {
> goto no_tcp_socket;
> }
>
> It's located in the ./net/ipv4/tcp_input.c file in the tcp_rcv function.
>
>It happens when a TCP packet arrives for no socket we know about in
>the system, it is therefore an erroneous packet and we must jump to
>no_tcp_socket where we send a reset back to the sender and discard the
>packet. We must do this to stay within the specifications of the TCP
>protocol.
>
>Later,
>David S. Miller
>davem@dm.cobaltmicro.com
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: Bill Hawes <whawes@star.net>
>Date: Fri, 20 Feb 1998 18:07:29 -0500
>Subject: Re: Problem with inode-nr on 2.0.33
>
>Daniel.Veillard@w3.org wrote:
>
>> Lately I got suddenly a problem with a lack of inode in the kernel
>> it appeared first as in my console as:
>> ------------------------
>> 28!PCROND: can't open log file
>> /var/log/cron: Too many open files in system
>> CROND: can't write to log file
>> ------------------------
>> I killed a few apps to regain some new descriptors, and increased
>> the number by echoing a large number to /proc/sys/kernel/inode-max.
>> It now reflect this value correctly (32768, the previous one was
>> approximately 2000). And this corrected the problem, great !
>>
>> However 3 days have passed now and /proc/sys/kernel/inode-nr now
>> reflect something rather alarming:
>> ~ -> cat /proc/sys/kernel/inode-nr
>> 26272 25540
>> ~ ->
>>
>> This number has increased a lot in 3 days, I am unable to understand
>> why, and I'm afraid of being hit again by this problem. However it seem
>> to not have increased during the last 12 hours. There is definitely not
>> 25000 inode currently open in my system. There is around 160 processus
>> running, sockstat reports sockets: "used 382 TCP: inuse 241 highest 467"
>> and listing /proc/[0-9]*/fd/ doesn't show that amount of open files.
>>
>> Maybe it's just normal but it doesn't really seem so.
>
>>From your description it looks like there's an inode leak, as that's a huge
>number of inodes to be allocated. From your setup the only unusual entry seems
>to be the AFS filesystem, so possibly there's a problem there.
>
>Has anyone else on the list here had an inode problem with AFS? (Or
>alternatively, used AFS extensively _without_ a problem?)
>
>Regards,
>Bill
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: Bill Hawes <whawes@star.net>
>Date: Fri, 20 Feb 1998 18:01:02 -0500
>Subject: minor patch for ext2/namei.c
>
>This is a multi-part message in MIME format.
>- --------------B999F14B4325057B85F9C1BB
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>The attached patch does some minor cleanup in ext2/namei.c, and adds a call to
>shrink_dcache_parent() before checking for a busy directory dentry when
>renaming.
>
>Regards,
>Bill
>- --------------B999F14B4325057B85F9C1BB
>Content-Type: text/plain; charset=us-ascii; name="ext2_86-patch"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline; filename="ext2_86-patch"
>
>- --- fs/ext2/namei.c.old Wed Feb 11 00:06:11 1998
>+++ fs/ext2/namei.c Wed Feb 11 09:45:30 1998
>@@ -853,9 +853,7 @@
> struct ext2_dir_entry * old_de, * new_de;
> int retval;
>
>- - old_inode = new_inode = NULL;
> old_bh = new_bh = dir_bh = NULL;
>- - new_de = NULL;
> retval = -ENAMETOOLONG;
> if (old_dentry->d_name.len > EXT2_NAME_LEN)
> goto end_rename;
>@@ -875,7 +873,8 @@
> goto end_rename;
>
> new_inode = new_dentry->d_inode;
>- - new_bh = ext2_find_entry (new_dir, new_dentry->d_name.name,
new_dentry->d_name.len, &new_de);
>+ new_bh = ext2_find_entry (new_dir, new_dentry->d_name.name,
>+ new_dentry->d_name.len, &new_de);
> if (new_bh) {
> if (!new_inode) {
> brelse (new_bh);
>@@ -895,6 +894,9 @@
> retval = -EINVAL;
> if (is_subdir(new_dentry, old_dentry))
> goto end_rename;
>+ /* Prune any children before testing for busy */
>+ if (new_dentry->d_count > 1)
>+ shrink_dcache_parent(new_dentry);
> retval = -ENOTEMPTY;
> if (!empty_dir (new_inode))
> goto end_rename;
>@@ -927,11 +929,13 @@
> if (!new_inode && new_dir->i_nlink >= EXT2_LINK_MAX)
> goto end_rename;
> }
>- - if (!new_bh)
>- - new_bh = ext2_add_entry (new_dir, new_dentry->d_name.name,
new_dentry->d_name.len, &new_de,
>- - &retval);
>- - if (!new_bh)
>- - goto end_rename;
>+ if (!new_bh) {
>+ new_bh = ext2_add_entry (new_dir, new_dentry->d_name.name,
>+ new_dentry->d_name.len, &new_de,
>+ &retval);
>+ if (!new_bh)
>+ goto end_rename;
>+ }
> new_dir->i_version = ++event;
>
> /*
>@@ -975,6 +979,7 @@
> /* Update the dcache */
> d_move(old_dentry, new_dentry);
> retval = 0;
>+
> end_rename:
> brelse (dir_bh);
> brelse (old_bh);
>
>- --------------B999F14B4325057B85F9C1BB--
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: Bill Hawes <whawes@star.net>
>Date: Fri, 20 Feb 1998 17:58:00 -0500
>Subject: patch for 2.1.87 fs/locks.c
>
>This is a multi-part message in MIME format.
>- --------------3AEEC8B69402CF10B8B7C905
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Hi Linus,
>
>I've attached a minor patch for fs/locks.c splitting the locks_remove_locks()
>function into separate routines for POSIX and flocks, as we discussed last
week.
>
>I've had Andy Walker look it over, and if it looks OK to you as well, I'll get
>to back to work on my patch to protect the fd array for clone tasks.
>
>Regards,
>Bill
>- --------------3AEEC8B69402CF10B8B7C905
>Content-Type: text/plain; charset=us-ascii; name="locks_87-patch"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline; filename="locks_87-patch"
>
>- --- linux-2.1.87/include/linux/fs.h.old Tue Feb 17 11:10:48 1998
>+++ linux-2.1.87/include/linux/fs.h Wed Feb 18 12:17:26 1998
>@@ -446,7 +446,10 @@
>
> extern int fcntl_getlk(unsigned int fd, struct flock *l);
> extern int fcntl_setlk(unsigned int fd, unsigned int cmd, struct flock *l);
>- -extern void locks_remove_locks(struct task_struct *task, struct file *filp);
>+
>+/* fs/locks.c */
>+extern void locks_remove_posix(struct task_struct *, struct file *);
>+extern void locks_remove_flock(struct file *);
> extern struct file_lock *posix_test_lock(struct file *, struct file_lock *);
> extern int posix_lock_file(struct file *, struct file_lock *, unsigned int);
> extern void posix_block_lock(struct file_lock *, struct file_lock *);
>- --- linux-2.1.87/include/linux/file.h.old Mon Jul 14 00:20:10 1997
>+++ linux-2.1.87/include/linux/file.h Wed Feb 18 12:29:43 1998
>@@ -29,6 +29,7 @@
> int error = 0;
>
> if (!count) {
>+ locks_remove_flock(file);
> error = __fput(file);
> file->f_count = 0;
> remove_filp(file);
>- --- linux-2.1.87/fs/locks.c.old Fri Dec 5 18:32:36 1997
>+++ linux-2.1.87/fs/locks.c Wed Feb 18 12:25:22 1998
>@@ -441,30 +441,32 @@
> return (posix_lock_file(filp, &file_lock, cmd == F_SETLKW));
> }
>
>- -/* This function is called when the file is closed.
>+/*
>+ * This function is called when the file is being removed
>+ * from the task's fd array.
> */
>- -void locks_remove_locks(struct task_struct *task, struct file *filp)
>+void locks_remove_posix(struct task_struct *task, struct file *filp)
> {
>+ struct inode * inode = filp->f_dentry->d_inode;
> struct file_lock file_lock, *fl;
> struct file_lock **before;
>- - struct inode * inode;
>
>- - /* For POSIX locks we free all locks on this file for the given task.
>- - * For FLOCK we only free locks on this *open* file if it is the last
>- - * close on that file.
>+ /*
>+ * For POSIX locks we free all locks on this file for the given task.
> */
>- - inode = filp->f_dentry->d_inode;
> repeat:
> before = &inode->i_flock;
> while ((fl = *before) != NULL) {
>- - if (((fl->fl_flags & FL_POSIX) && (fl->fl_owner == task)) ||
>- - ((fl->fl_flags & FL_FLOCK) && (fl->fl_file == filp) &&
>- - (filp->f_count == 1))) {
>- - file_lock = *fl;
>- - locks_delete_lock(before, 0);
>- - if (filp->f_op->lock) {
>+ if ((fl->fl_flags & FL_POSIX) && fl->fl_owner == task) {
>+ int (*lock)(struct file *, int, struct file_lock *);
>+ lock = filp->f_op->lock;
>+ if (lock) {
>+ file_lock = *fl;
> file_lock.fl_type = F_UNLCK;
>- - filp->f_op->lock(filp, F_SETLK, &file_lock);
>+ }
>+ locks_delete_lock(before, 0);
>+ if (lock) {
>+ lock(filp, F_SETLK, &file_lock);
> /* List may have changed: */
> goto repeat;
> }
>@@ -472,8 +474,37 @@
> }
> before = &fl->fl_next;
> }
>+}
>
>- - return;
>+/*
>+ * This function is called on the last close of an open file.
>+ */
>+void locks_remove_flock(struct file *filp)
>+{
>+ struct inode * inode = filp->f_dentry->d_inode;
>+ struct file_lock file_lock, *fl;
>+ struct file_lock **before;
>+
>+repeat:
>+ before = &inode->i_flock;
>+ while ((fl = *before) != NULL) {
>+ if ((fl->fl_flags & FL_FLOCK) && fl->fl_file == filp) {
>+ int (*lock)(struct file *, int, struct file_lock *);
>+ lock = filp->f_op->lock;
>+ if (lock) {
>+ file_lock = *fl;
>+ file_lock.fl_type = F_UNLCK;
>+ }
>+ locks_delete_lock(before, 0);
>+ if (lock) {
>+ lock(filp, F_SETLK, &file_lock);
>+ /* List may have changed: */
>+ goto repeat;
>+ }
>+ continue;
>+ }
>+ before = &fl->fl_next;
>+ }
> }
>
> struct file_lock *
>- --- linux-2.1.87/fs/open.c.old Sat Jan 24 10:13:16 1998
>+++ linux-2.1.87/fs/open.c Wed Feb 18 12:21:03 1998
>@@ -745,17 +745,14 @@
>
> int close_fp(struct file *filp)
> {
>- - struct dentry *dentry;
>- - struct inode *inode;
>+ struct dentry *dentry = filp->f_dentry;
>
> if (filp->f_count == 0) {
> printk("VFS: Close: file count is 0\n");
> return 0;
> }
>- - dentry = filp->f_dentry;
>- - inode = dentry->d_inode;
>- - if (inode)
>- - locks_remove_locks(current, filp);
>+ if (dentry->d_inode)
>+ locks_remove_posix(current, filp);
> return fput(filp);
> }
>
>
>- --------------3AEEC8B69402CF10B8B7C905--
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>From: Bill Hawes <whawes@star.net>
>Date: Fri, 20 Feb 1998 17:50:27 -0500
>Subject: Re: nfs client probs 2.1.* (Patch attached)
>
>This is a multi-part message in MIME format.
>- --------------B4B39ABEB46B90A3E1C58EFA
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Hans-Christoph Rohland wrote:
>
>> I get the following syslog entries (2.1.87)
>>
>> Feb 19 18:46:41 kernel: NFS: short readdir reply! nr=170, slots=3, len=7
>> Feb 19 18:46:52 kernel: NFS: short readdir reply! nr=170, slots=3, len=7
>> Feb 20 03:37:00 kernel: NFS: short readdir reply! nr=170, slots=3, len=7
>> Feb 20 09:30:04 kernel: RPC: garbage, retrying 33342
>> Feb 20 09:30:04 kernel: RPC: garbage, retrying 33342
>> Feb 20 09:30:04 kernel: RPC: garbage, exit EIO
>>
>> The first three did not show up in an interactive program, but the
>> last three are xemacs trying to save a file, which failes with EIO.
>>
>> The server is a HP-UX box. I do not know the release.
>
>Hi Hans,
>
>I've attached a patch for 2.1.87 NFS client that will probably fix the "short
>reply" problem, and possibly the other problem as well. A similar problem was
>reported by another user with an HP-UX server and the patch works in that case.
>
>I'm hoping to get in touch with the appropriate engineer at HP to discuss this
>problem, as it appears to be a bug in their server. So if you have a tech
>contact at HP who would like to improve the quality of their software, please
>pass me an email address.
>
>In the case of your "RPC garbage" problem, it this repeatable? Does it only
>happen with xemacs, and can you copy files OK? The patch includes a fix to pad
>writes to a longword length, which fixes garbage args problems with some
>servers. You'll have to enable it by hand though by uncommenting the #define at
>the top.
>
>Please let me know if this helps out with the problems.
>
>Regards,
>Bill
>- --------------B4B39ABEB46B90A3E1C58EFA
>Content-Type: text/plain; charset=us-ascii; name="nfs_87-patch"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline; filename="nfs_87-patch"
>
>- --- linux-2.1.87/include/linux/nfs_fs.h.old Tue Jan 27 09:36:36 1998
>+++ linux-2.1.87/include/linux/nfs_fs.h Wed Feb 18 12:26:11 1998
>@@ -85,6 +85,9 @@
> */
> #define NFS_RPC_SWAPFLAGS (RPC_TASK_SWAPPER|RPC_TASK_ROOTCREDS)
>
>+/* Flags in the RPC client structure */
>+#define NFS_CLNTF_BUFSIZE 0x0001 /* readdir buffer in longwords */
>+
> #ifdef __KERNEL__
>
> /*
>- --- linux-2.1.87/fs/nfs/nfs2xdr.c.old Tue Jan 27 09:36:34 1998
>+++ linux-2.1.87/fs/nfs/nfs2xdr.c Wed Feb 18 12:49:59 1998
>@@ -22,6 +22,9 @@
> #include <linux/sunrpc/clnt.h>
> #include <linux/nfs_fs.h>
>
>+/* Uncomment this to support servers requiring longword lengths */
>+/* #define NFS_PAD_WRITES 1 */
>+
> #define NFSDBG_FACILITY NFSDBG_XDR
> /* #define NFS_PARANOIA 1 */
>
>@@ -181,7 +184,7 @@
> /*
> * Arguments to a READ call. Since we read data directly into the page
> * cache, we also set up the reply iovec here so that iov[1] points
>- - * exactly to the page wewant to fetch.
>+ * exactly to the page we want to fetch.
> */
> static int
> nfs_xdr_readargs(struct rpc_rqst *req, u32 *p, struct nfs_readargs *args)
>@@ -258,18 +261,34 @@
> static int
> nfs_xdr_writeargs(struct rpc_rqst *req, u32 *p, struct nfs_writeargs *args)
> {
>+ u32 count = args->count;
>+
> p = xdr_encode_fhandle(p, args->fh);
> *p++ = htonl(args->offset);
> *p++ = htonl(args->offset);
>- - *p++ = htonl(args->count);
>- - *p++ = htonl(args->count);
>+ *p++ = htonl(count);
>+ *p++ = htonl(count);
> req->rq_slen = xdr_adjust_iovec(req->rq_svec, p);
>
> req->rq_svec[1].iov_base = (void *) args->buffer;
>- - req->rq_svec[1].iov_len = args->count;
>- - req->rq_slen += args->count;
>+ req->rq_svec[1].iov_len = count;
>+ req->rq_slen += count;
> req->rq_snr = 2;
>
>+#ifdef NFS_PAD_WRITES
>+ /*
>+ * Some old servers require that the message length
>+ * be a multiple of 4, so we pad it here if needed.
>+ */
>+ count = ((count + 3) & ~3) - count;
>+ if (count) {
>+ req->rq_svec[2].iov_base = (void *) "\0\0\0";
>+ req->rq_svec[2].iov_len = count;
>+ req->rq_slen += count;
>+ req->rq_snr = 3;
>+ }
>+#endif
>+
> return 0;
> }
>
>@@ -334,12 +353,21 @@
> static int
> nfs_xdr_readdirargs(struct rpc_rqst *req, u32 *p, struct nfs_readdirargs
*args)
> {
>- - struct rpc_auth *auth = req->rq_task->tk_auth;
>+ struct rpc_task *task = req->rq_task;
>+ struct rpc_auth *auth = task->tk_auth;
>+ u32 bufsiz = args->bufsiz;
> int replen;
>
>+ /*
>+ * Some servers (e.g. HP OS 9.5) seem to expect the buffer size
>+ * to be in longwords ... check whether to convert the size.
>+ */
>+ if (task->tk_client->cl_flags & NFS_CLNTF_BUFSIZE)
>+ bufsiz = bufsiz >> 2;
>+
> p = xdr_encode_fhandle(p, args->fh);
> *p++ = htonl(args->cookie);
>- - *p++ = htonl(args->bufsiz);
>+ *p++ = htonl(bufsiz); /* see above */
> req->rq_slen = xdr_adjust_iovec(req->rq_svec, p);
>
> /* set up reply iovec */
>@@ -380,10 +408,9 @@
> nfs_xdr_readdirres(struct rpc_rqst *req, u32 *p, struct nfs_readdirres *res)
> {
> struct iovec *iov = req->rq_rvec;
>- - int status, nr, len;
>+ int status, nr;
> char *string, *start;
>- - u32 *end;
>- - __u32 fileid, cookie, *entry;
>+ u32 *end, *entry, len, fileid, cookie;
>
> if ((status = ntohl(*p++)))
> return -nfs_stat_to_errno(status);
>@@ -398,17 +425,25 @@
> end = (u32 *) ((u8 *) p + iov[1].iov_len);
>
> /* Get start and end of dirent buffer */
>- - entry = (__u32 *) res->buffer;
>+ entry = (u32 *) res->buffer;
> start = (char *) res->buffer;
> string = (char *) res->buffer + res->bufsiz;
> for (nr = 0; *p++; nr++) {
> fileid = ntohl(*p++);
>
> len = ntohl(*p++);
>+ /*
>+ * Check whether the server has exceeded our reply buffer,
>+ * and set a flag to convert the size to longwords.
>+ */
> if ((p + QUADLEN(len) + 3) > end) {
>- - printk(KERN_WARNING "NFS: short readdir reply! "
>- - "nr=%d, slots=%d, len=%d\n",
>+ struct rpc_clnt *clnt = req->rq_task->tk_client;
>+ printk(KERN_WARNING
>+ "NFS: server %s, readdir reply truncated\n",
>+ clnt->cl_server);
>+ printk(KERN_WARNING "NFS: nr=%d, slots=%d, len=%d\n",
> nr, (end - p), len);
>+ clnt->cl_flags |= NFS_CLNTF_BUFSIZE;
> break;
> }
> if (len > NFS_MAXNAMLEN) {
>- --- linux-2.1.87/include/linux/sunrpc/clnt.h.old Tue Feb 17 11:26:40 1998
>+++ linux-2.1.87/include/linux/sunrpc/clnt.h Wed Feb 18 12:39:39 1998
>@@ -30,6 +30,7 @@
> * The high-level client handle
> */
> struct rpc_clnt {
>+ unsigned int cl_users; /* number of references */
> struct rpc_xprt * cl_xprt; /* transport */
> struct rpc_procinfo * cl_procinfo; /* procedure info */
> u32 cl_maxproc; /* max procedure number */
>@@ -37,7 +38,6 @@
> char * cl_server; /* server machine name */
> char * cl_protname; /* protocol name */
> struct rpc_auth * cl_auth; /* authenticator */
>- - struct rpc_portmap cl_pmap; /* port mapping */
> struct rpc_stat * cl_stats; /* statistics */
>
> unsigned int cl_softrtry : 1,/* soft timeouts */
>@@ -47,10 +47,11 @@
> cl_binding : 1,/* doing a getport() */
> cl_oneshot : 1,/* dispose after use */
> cl_dead : 1;/* abandoned */
>+ unsigned int cl_flags; /* misc client flags */
> unsigned long cl_hardmax; /* max hard timeout */
>
>+ struct rpc_portmap cl_pmap; /* port mapping */
> struct rpc_wait_queue cl_bindwait; /* waiting on getport() */
>- - unsigned int cl_users; /* number of references */
> };
> #define cl_timeout cl_xprt->timeout
> #define cl_prog cl_pmap.pm_prog
>
>- --------------B4B39ABEB46B90A3E1C58EFA--
>
>
>- -
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
>------------------------------
>
>End of linux-kernel-digest V1 #1613
>***********************************
>
>To subscribe to linux-kernel-digest, send the command:
>
> subscribe linux-kernel-digest
>
>in the body of a message to "Majordomo@Majordomo.vger.rutgers.edu". If you
want
>to subscribe something other than the account the mail is coming from,
>such as a local redistribution list, then append that address to the
>"subscribe" command; for example, to subscribe "local-linux-kernel":
>
> subscribe linux-kernel-digest local-linux-kernel@your.domain.net
>
>A non-digest (direct mail) version of this list is also available; to
>subscribe to that instead, replace all instances of "linux-kernel-digest"
>in the commands above with "linux-kernel".
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu