Andi,
The alloc_skb routine complains 5 times and then stops complaining,
but also the "bump to atomic" is stopped after 5 times. Ah. I found
the Email from Linus that explained this to me.....
Note1: this message is more than 3 years old, and the Email addresses
are probably no longer valid.
Note2: This was about "kmalloc", but the exact same code is in alloc_skb.
] Return-Path: <Linus.Torvalds@cs.Helsinki.FI>
] Date: Mon, 05 Dec 1994 18:51:55 +0200
] Subject: Re: linux kmalloc
] To: R.E.Wolff@ET.TUDelft.NL, mizzi@eu1.mpi-hd.mpg.de (Thomas Kihm)
]
] R.E.Wolff@et.tudelft.nl: "Re: linux kmalloc" (Dec 5, 12:55):
] > >
] > > hello roger,
] > >
] > > if (intr_count && priority != GFP_ATOMIC) {
] > > static int count = 0;
] > > if (++count < 5) {
] > > printk("kmalloc called nonatomically from interrupt %p
] \n",
] > > __builtin_return_address(0));
] > > priority = GFP_ATOMIC;
] > > }
] > >
] > > in this sequence only the first 5 times the priority is change to GFP_ATOMIC.
] > > i think the line
] > >
] > > priority = GFP_ATOMIC;
] > >
] >
] > Ah... You got it.
] >
] > I spotted this one a few months ago, together with a friend. I
] > forgot to report it to Linus. Later on I couldn't reproduce the
] > location where I found a "}" in the wrong place.
] >
] > Linus, I really think that the closing brace should be one line
] > further up.
]
] Nope, it's all intentional.
]
] The idea is: doing a allocation request from within a interrup handler
] (ie intr_count > 0) must be GFP_ATOMIC, so if it isn't, we print an
] error message and make it atomic. NOTE! This is really a *bad* bug, so
] I could just have panicced, but the above works most of the time (it
] didn't happen very often).
]
] HOWEVER: if things are going very badly, maybe the allocation per se is
] perfectly ok, and the "intr_count" got corrupted for some reason. In
] that case, we don't want to do lots of printk's and the priority may be
] good as well. So the logic is: "try to fix up the 5 first occurrences,
] and warn about it, but if we get more than that, something else is wrong
] and we can't fix it up here anyway".
]
] Note that I haven't gotten a single report of this message in a *very*
] long time, so we could just remove it altogether.. But I'd rather have
] the safety net there..
]
] Linus
]
-- If it's there and you can see it, it's REAL |___R.E.Wolff@BitWizard.nl | If it's there and you can't see it, it's TRANSPARENT | Tel: +31-15-2137555 | If it's not there and you can see it, it's VIRTUAL |__FAX:_+31-15-2138217 | If it's not there and you can't see it, it's GONE! -- Roy Wilks, 1983 |_____|- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu