Date: Thu, 31 Aug 2000 17:35:02 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Brian Fundakowski Feldman <green@FreeBSD.ORG>, Don Lewis <Don.Lewis@tsc.tdk.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 4.1 STABLE broken since today! Message-ID: <200009010035.RAA10986@salsa.gv.tsc.tdk.com> In-Reply-To: <Pine.BSF.4.21.0008311915530.17114-100000@green.dyndns.org> References: <Pine.BSF.4.21.0008311915530.17114-100000@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 31, 7:25pm, Brian Fundakowski Feldman wrote:
} Subject: Re: 4.1 STABLE broken since today!
} On Thu, 31 Aug 2000, Don Lewis wrote:
}
} > On Aug 31, 6:11am, Tor.Egge@fast.no wrote:
} > } Subject: Re: 4.1 STABLE broken since today!
} > } 1. The value of diff in chgsbsize was always positive
} > } (unsigned - unsigned results in an unsigned value).
} > } This causes bogus values in ui_sbsize.
} > This depends on rlim_t being a signed type (which is happens to be).
} > Also, if "to" is the same width as rlim_t, then this code could break
} > if the difference was greater than the maximum positive value of rlim_t
} > (not likely in this particular case). Changing the test from
} > diff > 0
} > to
} > to > *hiwat
} > is much safer.
}
} Well, rlim_t isn't going to change in the foreseeable future. Also,
} we don't support any architectures that support nearly 2^63 bytes of
} physical memory; it's fair to say that there's no way for it to cause
} a problem, but if you don't like it, cleanups can be done at leisure
} :)
Yes, but ...
} > I prefer the following patch to kern_proc.c, which also pulls uifree()
} > out of splnet(), and eliminates some duplicate code. I'm not yet running
} > 4-stable, so I can't test this patch other than to see if it compiles
} > without error.
}
} We'll see, then; since this isn't critical, it can wait, right?
Either my patch or Tor's patch should be applied, since his comment
about the bogus value of diff is correct. In a private message, he
also pointed out that problems could occur when chgsbsize() is called
from an interrupt context because of the calls to uifind() and and
uifree(). At a minimum, we need to wrap the whole function in splnet().
Even that still leaves the problem of uicreate(), which can call
MALLOC(..., M_WAITOK).
A better long term solution would be to store a pointer to the uidinfo
structure in the pcred structure and just pass the uidinfo pointer to
chgsbsize(). That will eliminate most of the calls to ui{find,free}()
and confine them all to the top half of the kernel.
I'm also don't think we do the proper accounting across setuid(). Say
we have a socket with a full buffer, call setuid() to a new uid, and then
drain the socket. We will think the new uid is using a negative amount of
buffer space ...
Then there is the race condition that I found in access(). I think that
requires discussion in arch ...
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009010035.RAA10986>