Muli Ben-Yehuda's journal

This is the first in a series of snippets that present code that I personally consider an affront to humanity. All code must be from real, live projects. If the code is proprietary in origin, or otherwise confidential, symbol names might be changed to protect the guilty, but it’s ALL REAL. YMMV.

Today’s crime against humanity:

Returning from a within a macro

Witness this innocent chunk of code, from fs/intermezzo/journal.c in a kernel tree near you:

 
#define BUFF_ALLOC(newbuf, oldbuf)              \
        PRESTO_ALLOC(newbuf, PAGE_SIZE);        \
        if ( !newbuf ) {                        \
                if (oldbuf)                     \
                        BUFF_FREE(oldbuf);      \
                return -ENOMEM;                 \
        }

Do I really need to explain why returning from a macro is a bad, bad, bad, god awful idea? consider:

void foo(void)
{
	void* buf1, buf2, buf3; 

	BUFF_ALLOC(buf1, NULL); 
	BUFF_ALLOC(buf2, buf1); 

	BUFF_ALLOC(buf3, buf2); <----- BOOOM. Bye bye buf1 memory if
	                                      allocation fails. 
}

Resource allocation and deallocation should always be handled with care. Sequence points where resource book keeping is required must be explicit.

This diary is personal in nature. If that sort of thing unfazes you, skip.

Looking through some old emails, I came upon a diary excerpt I sent someone. That led me to look through my old files, until I found my personal diary, and that led to reading it.

Jesus.

So much angst, so much hurt, so much pain. Which should come as no surprise when I remind myself that I wrote only when I felt bad, but is still incredibly unnerving to read now. Time has a tendency to soften the memory, to sharpen one’s memory of the good times and obscure the bad ones. The diary bought those bad time, some of them spectacularly bad, under harsh 100 watt interrogation lights in all of their ugliness.

Oh, and … so many women, too. What the fuck (pun intended) was I thinking? thank god that’s all over now.

I would publish the entire diary here as a way of offsetting its bad mojo, but I’m ashamed of the god awful writing. Maybe anonymously?

Yes, it’s that time of the year again. I have nothing to say on the occasion, except, maybe, if you must.

Earlier this week, I got this nice email from Mel Gorman, author of the
excellent Linux Kernel VM documentation. Mel wrote:

“I’ve been offered a contract to write a book on the Linux VM with Prentice Hall based on the material I’ve made available to date at http://www.csn.ul.ie/~mel/projects/vm/ …

If you’re reading this, you are in the acknowledgments section for helping me out at some stage at the other getting the 2.4 docs together …”

The book is going to come out as part of Bruce Peren’s Open Series, but you should all go out and buy it, of course. I know I will. And after you buy it, make sure to highlight my name in the acknowledgments section 🙂

For those curious, here’s the email I sent Mel that will get me mentioned in the book:

First one:

 
Date: Sun, 12 Jan 2003 19:29:43 +0200
From: Muli Ben-Yehuda 
User-Agent: Mutt/1.4i
To: Mel Gorman 
Subject: typo in vmalloc document

Hi Mel,

In http://www.csn.ul.ie/~mel/projects/vm/docs/vmalloc.html, section
1.1, you wrote:
       if (vmalloc_area_pages(VMALLOC_VMADDR(addr), size, gfp_mask, prot)) {
                vfree(addr);
                return NULL;
        }

vmalloc_area_pages sets up the PGD, PMD and PTE entries to give out
the linear addresses needed. If it fails half way through, 0 is
returned so that vfree can be called to get rid of the PGD, PMD and
PTE entries that have been assigned.

END QUOTE

the '0 is returned' bit is wrong - it should be '-ERRNO is returned',
or at least, 'a non zero value is returned'.
--
Muli Ben-Yehuda

my opinions may seem crazy. But they all make sense. Insane sense, but
sense nontheless. -- Shlomi Fish on #offtopic.

And:

Date: Wed, 2 Apr 2003 14:30:55 +0300
From: Muli Ben-Yehuda 
User-Agent: Mutt/1.5.4i
To: Mel Gorman 
Subject: bug(?) in VM documentation

Apr 1st copy, page 39, section 4.4

"...
 mk_pte() takes a physical page...
 mk_pte_phys() treats the address as a physical page
 ..."

Looking at the code, I mk_pte appears to take a struct page, not a
physical page (which I parse as a physical page address).

Thanks,
Muli.
--
Muli Ben-Yehuda
http://www.mulix.org

Who woulda thunk? 🙂

Earlier this week, the official announcement of August Penguins 2003 finally went out. I’m really excited about Aug. Peng., looking forward to the MOSIX lecture and moshez‘s Python Internals lecture, and the geek trivia. Looking forward to seeing you all there!

Yesterday was the first class of the summer course I’m taking at the Open University, “Algorithmics – Foundations of Computer Science”. When I registered, I was pretty excited about this class. It’s based on the book by Prof. David Harel of the Weizmann institute, that I’ve been meaning to read anyway. Then I got the book (openu edition) and read the first four chapters. While it’s written quite clearly and is interesting, it’s a popular science book, not a text book! there is nary a proof in sight, and the treatment of the material is quite superficial. Therefore, it was with some trepidation that I went to class yesterday. My feelings of foreboding (“is this fluff what I’m going to waste the summer on?”) weren’t helped when I heard class mates talking about this course, which is supposed to be a breeze to pass.

Then the instructor started talking, and within an hour into the lesson, I realized that my summer wasn’t going to be wasted after all. We discussed the “subset sum problem”, NP complete problems, the graph coloring problem and its relation to the map coloring problem[0], and the variations of knapsack problem. Unlike my usual habit, I actually took part in the class, proposing solutions and optimizations and finding flaws in others proposed solutions. Fascinating stuff!

[0] The instructor discussed graph coloring, and showed that any graph which is a clique of size N cannot be colored with less than N colors. This statement, which is obviously correct, contradicted with what I remembered about any map being 4 colorable. After thinking about it for a few minutes, I asked what was the relation between coloring a graph and coloring a map. The answer is that any map can be represented by a planar graph, but not every graph can be represented by a map. All planar graphs are indeed 4 colorable, and a clique of N > 4 cannot be represented by a planar map. Contradiction solved.