Date: Tue, 21 Jan 2003 15:39:32 -0800 From: Alfred Perlstein <bright@mu.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030121233932.GI42333@elvis.mu.org> In-Reply-To: <20030121.144243.52206100.imp@bsdimp.com> References: <20030121.144243.52206100.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* M. Warner Losh <imp@bsdimp.com> [030121 13:44] wrote: > In IRC there's much concern over alfred's changes from a cross os > portability standpoint, as well as a SMP standpoint. I'd like to > propose that we do something like the following: Let's address the portability issue. Just add this to the top of your module and you can get back the "non-flag" for waiting. #ifndef M_WAITOK #define M_WAITOK 0 #endif Not hard. > 1) Make M_WAITOK and M_NOWAIT mandatory and exclusive in malloc.c. > You must specify one or the other, but not both. I keep hearing people say that having M_WAITOK implicit when M_NOWAIT is absent as a problem, it is not a problem, it's how things should be. One should only, if ever use M_NOWAIT from interrupt context. You should not be using M_NOWAIT because your locking is incorrect and you're holding a mutex when you need to call malloc/mget in user context. > 2) We assign both M_WAITOK and M_NOWAIT values that aren't 0, let's > say 0x10 and 0x20. > 3) We assign both M_DONTWAIT and M_TRYWAIT from mbuf.h values 0x40 > and 0x80. What a load of wasted flags. :( We've lost 4 bits because people don't understand the API, have read the manpage or the 4.4 BSD book. > 4) We back out the bulk of the changes made, except where they were > real bugs. There were no bugs that I caught atm, however there will be if we revert the delta. > 5) Hack the mbuf routines to reject M_DONTWAIT and M_TRYWAIT that > aren't the right value in flags. This will allow more mistakes to creep into modules that are seldom used or codepaths that aren't excersized often. It's a good way to have a DoS in the code without realizing it, now typos become fatal boobytraps instead of just harmless typos. > 6) Hack all the places where we did a boolean test before to do the > right testing of the new bits. > > I think there'd be strong support for this. I'm sure there will be, but that doesn't make it the right thing to do. Perhaps because the code md5s fine and I neglected to break a whole slew of device drivers is giving people the mistaken impression that they know what they're talking about here. They don't. While not asthetically pleasing this is the most correct solution and I wish you'd all damn well leave it alone. There's a lot of other stuff to fix out there. > I've done 1, 2, 3, 5 in my tree and am looking for #6 as well. I'll > post a patch once #6 is done. > > Comments? > Yes. Leave it alone, people may be shocked, but it's the right thing. thank you, -Alfred 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?20030121233932.GI42333>