search for: oeser

...sg->length; > + desc[i].next = i+1; > + sg++; > + } > + > + /* Last one doesn't continue. */ > + desc[i-1].flags &= ~VRING_DESC_F_NEXT; > + desc[i-1].next = 0; So this array index can fail (be -1). Please check and avoid within this function. Best Regards Ingo Oeser

...not set but CONFIG_HIGHMEM4G=y (I can provide further details, if required) - S.M.A.R.T meant everything is ok on both disks. - Machine has been rebooted and fscked (180 days without reboot). - Result of this fsck is not known. The condition didn't happen after this anymore. Regards Ingo Oeser -- Ingo Oeser axxeo GmbH Tiestestr. 16, 30171 Hannover Tel. +49-511-4753706 Fax. +49-511-4753716 mailto:support at axxeo.de

...sg->length; > + desc[i].next = i+1; > + sg++; > + } > + > + /* Last one doesn't continue. */ > + desc[i-1].flags &= ~VRING_DESC_F_NEXT; > + desc[i-1].next = 0; So this array index can fail (be -1). Please check and avoid within this function. Best Regards Ingo Oeser

Okay, as of this point, I think klibc is in quite good shape; my testing so far is showing that it can be used as a drop-in replacement for the kernel root-mounting code. That being said, there is guaranteed to be breakage, for two reasons: a. There are several architectures which don't have klibc ports yet. Since I don't have access to them, I can't really do them, either.

This patch changes HTB''s class storage from hash+lists to a two-level linear array, so it can do constant time (O(1)) class lookup by classid. It improves scalability for large number of classes. Without the patch, ~14k htb classes can starve a Xeon-3.2 at only 15kpps, using most of it''s cycles traversing lists in htb_find(). The patch eliminates this problem, and has a