remaining FreeBSD 4.11-RC3 bugs

[Ken Smith]

On Mon, Jan 17, 2005 at 10:28:53AM +0100, Matthias Andree wrote:

> critical:
> kern/60313 (silent data corruption on block devices)
>            still open, may be FreeBSD 4 specific after the GEOM flurry
>            in FreeBSD 5 and 6.

I took a look at that one.  The patch provided doesn't map exactly into
RELENG_4 but I gave this a try:

Index: subr_diskslice.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/Attic/subr_diskslice.c,v
retrieving revision 1.82.2.6
diff -u -r1.82.2.6 subr_diskslice.c
--- subr_diskslice.c    24 Jul 2001 09:49:41 -0000      1.82.2.6
+++ subr_diskslice.c    17 Jan 2005 23:40:42 -0000
@@ -147,6 +147,7 @@
        daddr_t slicerel_secno;
        struct diskslice *sp;
        int s;
+       off_t offset;

        blkno = bp->b_blkno;
        if (blkno < 0) {
@@ -155,6 +156,14 @@
                bp->b_error = EINVAL;
                goto bad;
        }
+       offset = bp->b_offset;
+       if (offset % (off_t)DEV_BSIZE) {
+               printf(
+               "dscheck(%s): b_offset %ld is not on a DEV_BSIZE boundary\n",
+                   devtoname(bp->b_dev), (long)offset);
+               bp->b_error = EINVAL;
+               goto bad;
+       }
        sp = &ssp->dss_slices[dkslice(bp->b_dev)];
        lp = sp->ds_label;
        if (ssp->dss_secmult == 1) {

With that in place the kernel won't boot because the stuff dealing with
disk labels in at least two places on my machine didn't set the offset
properly in the buf structures it used.  Once I fixed that the machine
booted but *some* executables wouldn't start because spec_getpages()
was doing reads with an offset of 256 (DEV_BSIZE is 512).

I'll see if I can follow up on this and eventually get RELENG_4 fixed
(and perhaps even an Errata) but there is no way I'd be comfortable
with a fix for this going into 4.11 unless an expert worked on it
and we did an RC4.

> serious:
> bin/71453 (tcpdump ipv6 crash, trivial fix -- MFC sufficient) still open

It looks like the right way to fix this is with a fresh vendor import
if I'm understanding things correctly.  Again something that would
require more time than we have and might be best handled as an Errata
item after the release.

> bin/46866 (false data from getpwent, easy to fix) still open

There has been ongoing disagreements about how best to handle this one,
as far as I can tell the disagreements are still ongoing.

> non-critical:
> kern/44260 (missing device in LINT configuration) 
>            is long-standing although trivial to fix (patch included)

Scott fixed that earlier today (MFS pending).

-- 
						Ken Smith
- From there to here, from here to      |       kensmith at cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |