NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/bsd/5611

Text File | 1992-09-12 | 12.2 KB | 318 lines

Newsgroups: comp.unix.bsd
Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: [e-mail] (A Wizard of Earth C)
Subject: 386BSD PARTIAL PATCH KIT NOW AVAILABLE
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Weber State University  (Ogden, UT)
Date: Sun, 13 Sep 92 01:07:35 GMT
Lines: 307

I have uploaded the first 19 patches and the patchkit software to the
directory /pub/incoming/terry on agate.berkeley.edu.  This is not a
complete set, as there are still 10-20 patches not yet in patchkit format.

The following is a list of the patches in the current patch kit.
Remember that the patchkit expects to start with a "virgin" kernel... no
strange hacks allowed.

If you install a new machine, the patches will "just install".  If you are
the type that hacks around, it probably won't, but you'll you'll be able
figure out what files each patch modifies from the file named "PATCH" in
the subdirectory for each patch under "ready".

The "README" file is in the tar file, but it is also packed seperately so
you can tell how to install it without having to install it first 8-).

-----------------------------------------------------------------------------
PATCHES IN THE INITIAL PATCH KIT (TOTAL: 19 PATCHES)
-----------------------------------------------------------------------------

patch00001
PATCH:        KERNEL REBUILD
AUTHOR:        Terry Lambert ([e-mail])
DESCRIPTION:

    This patch fixes the missing vers.o problem which prevents the
kernel from being rebuilt.


patch00002
PATCH:        BIG MEMORY HANG
AUTHOR:        William Jolitz
DESCRIPTION:

    Because of the number of kernel map entries being to small
and an inappropriate calculation for the number of buffer pages, it was
possible for the kernel to hang if you had more than 8 Meg of memory
installed in your system.


patch00003
PATCH:          INCORRECT CMOS RAM SIZE CAUSES CRASH
AUTHOR:        Terry Lambert ([e-mail])
DESCRIPTION:

        This patch fixes the problem encountered on HP Vectra, AT&T
6386E/33 WGS, AT&T StarServer E, and AT&T 6386/25 WGS systems where
the CMOS RAM size is not what was expected.  It also has fixes to
allow running small kernels in 640K, and warns the user of conditions
which may cause the kernel to fail to boot correctly.


patch00004
PATCH:        FIRST SECTOR IN MULTISECTOR READ IN BAD144 TABLE
AUTHOR:        Frank Maclachlan ([e-mail])
DESCRIPTION:

    The bad144 table search code at finds the sector in the bad144
table and replaces the block number, cylinder, head, and sector addresses
with values corresponding to the replacement sector.  The sector count
register is loaded with the number of sectors in the entire transfer.
This is wrong; it *MUST* be set to *one* sector.  A read would return
the wrong data in sectors after the first; a write would *overwrite*
other replacement sectors or even the bad144 table on the last track.


patch00005
PATCH:        WHATIS COREDUMP
AUTHOR:        Andrew Moore ([e-mail])
DESCRIPTION:

    The whatis program had two unitinitialized pointers which would
cause it to core dump sporadically depending on the initial stack contents.


patch00006
PATCH:        CRASH FOR PARENT (.) REFERENCE AFTER CHROOT
AUTHOR:        Christoph Robitschko ([e-mail])
DESCRIPTION:

    When chroot() was used to change the apparent root directory
for a process, a reference to "./", the parent directory of the new
"root" directory, the system "panic"ed.


patch00007
PATCH:        GREENMAN BUGFIX KIT
AUTHOR:        David Greenman ([e-mail])
DESCRIPTION:

1.    Buffers were being immediately aged after read, greatly reducing
    file system performance.
2.    The file system buffer cache hash calculation resulted in hash
    collision occuring 100% of the time.
3.    File system buffers were allocated twice.  They were also deallocated
    twice, so there was not a memory leak, but freebufspace was incorrect
    and too much memory was being used.


patch00008
PATCH:        MAN PATHBUF OVER 1K
AUTHOR:        James W. Dolter
DESCRIPTION:

    In the function config.c:cadd() the pointer bp isn't recalculated
when the pathbuf needs to be realloced.  If realloc moves the storage
'bp' is left hanging.  The bug manifests itself when you modify man.conf
such that the pathbuf expands beyond 1k.


patch00009
PATCH:        MBUF ALLOCATION FLAGS
AUTHOR:        Wolfgang Solfrank ([e-mail])
DESCRIPTION:

    While the flags in sys/mbuf.h define M_DONTWAIT and M_WAIT in terms
of M_NOWAIT and M_WAITOK, these flags are only used for the kernel malloc.
But the actual code in kern/uipc_mbuf.h uses kmem_malloc, which has
only a parameter canwait.  This parameter has just the opposite meaning
from the flag values above.  This may result in occasional hangs of the
system (if mbuf allocation with M_DONTWAIT is called which may result in
a wait) or panics or other nasty things (if called with M_WAIT which may
return a NULL pointer that is not expected and as such not tested by the
calling code).


patch00010
PATCH:        SCROLLING BACKWORDS ON CONSOLE CAUSES CRASH
AUTHOR:        Frank Maclachlan ([e-mail])
DESCRIPTION:
    I was horrified whilst scrolling backwards in a file with the less
pager at my console when my 386BSD system suddenly rebooted.  Subsequent
tests revealed that the system would crash whenever I scrolled rapidly
backwards through this file using less.

Most files won't cause the system to crash.  To demonstrate the failure,
do the the following (if you don't mind watching your system crash):

        hd /usr/mdec/bootwd >junk       # create a file
        less junk                       # invoke less
        G                               # go to the end of the file
        ^B^B^B...                       # rapid repeated control B's to
                                        #  scroll backwards


patch00011
PATCH:        COPY ON WRITE FOR TEXT PAGES
AUTHOR:        Paul Kranenburg ([e-mail])
DESCRIPTION:

    The 386 does not generate a page protection fault while it is
executing in supervisor mode :-(, so copy on write handling never takes
place when the kernel stuffs data into a process's text- or any other
non-anonymous segment.  So these cases must be explicitly checked for.

NOTE:        This is a security hole where it is possible for any
        normal user with access to the debugger and read access
        to any suid root program to become root!  You should
        apply this patch immediately!


patch00012
PATCH:        RING BUFFER LENGTH INCORRECTLY REPORTED
AUTHOR:        Stephen McKay ([e-mail] [forwarder])
DESCRIPTION:

    The RB_LEN() macro in /usr/include/sys/tty.h is sometimes out by 1.
In particular, in the case of a buffer containing a single character at the
very end, RB_LEN() would return 0.  This caused ttread() to block until a
2nd character was read before delivering them both.  The user would find
RAW mode programs such as vi would occasionally (1 in 1024 keypresses) get
"stuck" requiring a second keypress to bring it to life.

WARNING:    On the whole, this seems reasonable... HOWEVER, I feel the
        problem may be due to the ?: expression grouping.  In
        particular, perhaps all that's missing is some parenthesis
        around "RBSZ - 1 - ((rp)->rb_hd - (rp)->rb_tl)".


patch00013
PATCH:        CSH SEGMENTATION VIOLATION
AUTHOR:        Ed Hudson ([e-mail]
DESCRIPTION:

I have a prompt setting alias in my .cshrc for "cd", that looks like:
    alias cd 'cd \,* > /dev/null; set noglob; set xdirs = `dirs`; se
The bug manifests itself when I type:
    cd
    cd bin01
...csh says "Segmentation fault", and on a repeated attempt, dies.

It seems to occur whenever the target directory is 5 characters in name.
I think that it is blowing up when the statement "set xdirs = `dirs`" is
executed.  If I modify /usr/src/bin/csh/alloc.c so that the number of
bytes requested is automatically increased by 4 (on entry to malloc),
then the problem goes away.

WARNING:    This is a workaround.  The real problem is with the ALIGN
        macro getting a 0 for its offset, then the allocated buffer
        adds 4 regardless, causing overflow of the buffer on copy.


patch00014
PATCH:        CAN'T kill -1 OR kill -15 DAEMONS STARTED IN /etc/rc
AUTHOR:        Paul Kranenburg ([e-mail])
DESCRIPTION:

    The init program doesn't set up the proper signal disposition for
the process (sh) it creates to run /etc/rc.  While all signal handlers are
reset to SIG_DFL, the signal mask is left unchanged causing SIGHUP and
SIGTERM to be masked in all daemons started from /etc/rc.


patch00015
PATCH:        MAKE HUNG ON SINGLE "-" ARGUMENT
AUTHOR:        John Woods ([e-mail])
DESCRIPTION:

[ This is a patch rolled in from work done on 4.3Reno/NET2 ]

There is a bug in the new make from 4.3Reno and also present in the Net2
release (as found on uunet).  A command line argument consisting of a lone
dash (-) causes an infinite loop ("make - make" was an excellent test case).


patch00016
PATCH:        NFS SERVER CREATE TRUNCATES FILE
AUTHOR:        Arne Henrik Juul ([e-mail])
DESCRIPTION:

The file was always truncated if it existed. The reason why it only
happens when used from certain NFS clients, is that some clients does
not do a NFS create request at all if the file already exists.


patch00017
PATCH:        DMA SPECIAL HANDLING/DMA CHANNEL 4-7 TRANSFER COUNT
AUTHOR:        Frank Maclachlan ([e-mail])
DESCRIPTION:

At line 389 in isa_dmarangecheck(), the automatic variable priorpage
is used without being initially set to 0.  This causes the function
to flag special handling for virtually all DMA transfer requests.
Also, no check is made for DMA requests crossing DMA page boundaries
(64k for DMA chans 0..3, 128k for DMA chans 4..7).  This problem is
masked by priorpage not being initialized - almost all DMA is done
to/from safe 'bounce' buffers which don't cross DMA page boundaries
and the data are block moved from/to the user's buffer.

In line 359, nbytes is doubled by shifting it left 1 bit; it
should instead be divided by 2 by shifting right 1 bit position.
This occurs when any of the word mode DMA channels (4..7) is used.


patch00018
PATCH:        CORRECT MINOR NUMBER FOR COM PORT (SELECT FAILS)
AUTHOR:        Christoph Robitschko ([e-mail])
DESCRIPTION:

I had the problem with select() not working on com ports. I got no
response from a post regarding this one, so I started to look into it
myself. I found out that the com driver calculates unit = minor(dev) -1;
This has the following implications:
        /dev/com1 corresponds to COM0, /dev/com2 to COM1 (very confusing
                in kernel messages)
        It is incompatible with the config file entries com1 at..., com2 at...
        Unpredictible results will occur if someone puts a com0 at.. in
                his config file.
        It is incompatible with the DOS usage of COM1, COM2 (But who cares 8-)
        ttselect() calculates unit = minor(dev), and uses this as an index in
                com_tty. Because this index is different from that used
                in the com driver, select() on /dev/com1 looks at
                /dev/com2 and select() on /dev/com2 looks at an undefined
                entry in com_tty and returns always true.

WARNING: RE-mknod /dev/com1, /dev/com2, and modify your kernel config!


patch00019
PATCH:        CLEAN UP SLIP INTERFACE TO KEEP FROM HANGING
AUTHOR:        Poul-Henning Kamp ([e-mail])
DESCRIPTION:

Here is a patch to clean up the interface between the tty-drivers, in
particular the com driver, and the sl# interfaces, this is not a work-around
but a genuine bug-fix.

Symptoms: after a number of "com#: silo overflow" SLIP ceases to work.

Overview of the problem:  the slip interface will disregard any notice
from the tty-driver on problems (parity errors, framing errors or overruns),
which basicly means the one might as well throw the packet away right away.
Also overrun in the packetizing will go relatively unnotized.
-----------------------------------------------------------------------------


                    Terry Lambert
                    [e-mail]
                    [e-mail]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------