Date: Tue, 21 Jan 2003 19:23:09 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: bright@mu.org Cc: arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030121.192309.127431911.imp@bsdimp.com> In-Reply-To: <20030122004845.GM42333@elvis.mu.org> References: <20030122002758.GL42333@elvis.mu.org> <082501c2c1ae$83015c90$52557f42@errno.com> <20030122004845.GM42333@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20030122004845.GM42333@elvis.mu.org>
Alfred Perlstein <bright@mu.org> writes:
: I haven't said that. What I keep asking for is a solution other than
: "back it out". Do I really need to give a message that implies premature
: ejactulation as much respect as I already have?
I already gave an alternative to do that. Only part of my proposal
was a backout, but that was mostly to restore the M_ flags that were
there prior to the commit. I don't consider that whining. I
consider that proposing an alterative.
: The only other solution that makes some sense would be to do this:
:
: restore M_WAITOK, but make it a bit, 0x02
Can't make it bit 0x2 because that's already M_USE_RESERVE, which is
why I picked 0x10 and 0x20 for M_NOWAIT and M_WAITOK. I also
specifically didn't make M_WAITOK and M_DOWAIT the same because they
have subtly different semantics that the users of them should know.
: Now either just share them with the mbuf subsystem... or make the mbuf
: flags MB_WAIT/MB_NOWAIT.
The MB_ flag option is appealing, but has compatibility issues with
other systems. It wouldn't be a huge deal to add #ifdefs to those
files that are shared, but then you get the problem in a subset of
files. There was some agreement to change these, but not much when I
was talking it over. If enough people think this is a good idea, I'd
go with it, but I'm not sure that enough want it.
: Without looking at the manpages I'd like you to try to remeber which of
: the old flags went with which interface.
One could argue that using an interface w/o looking at the man page is
asking for problems.
: Of course we'll still have people making mistakes, and if assertions are
: sprinkled in to "catch" this, we'll have user or even remote DoS's when
: it creeps into uncommon code paths.
We already have that, except that people are silently doing the wrong
thing and we only die in rare cases.
: Before we even go down that path, can you show me some code that
: is not completely obviously wrong that can cause a problem with the
: current change? There's plenty of cvs history that shows that old
: flags/interface caused problems.
Sure. I'll post something later tonight.
Finally, this isn't an attack on you personally. I saw a lot of
people having concerns about the changes you made and went in and
proposed an alternative and am working on coding it up. I'll post
diffs and get a consensus (or as much of one as I can) before I change
anything.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030121.192309.127431911.imp>