On Thu, 8 Jan 2009, Bob Copeland wrote: > On Thu, Jan 8, 2009 at 11:18 AM, Hugh Dickins <[email protected]> wrote: > >> > So, that BUG_ON(bf->skb == NULL) appears to be unsafe under > >> > memory pressure; but the fix wasn't obvious to me, so over > >> > to you! > > Thanks for the report... I guess the error paths haven't been tested > much when rx buf setup fails. > > > (Of course, just removing the BUG_ON, and making sure there's > > no oops on the NULL pointer, would fix my immediate issue: > > but I doubt the right fix will be as simple as that.) > > Are your memory load testing scripts available somewhere?
No. They're little more than repeatedly running a "make -j20" kernel build in a tmpfs, and another in an ext2 on /dev/loop0 backed by large tmpfs file. But most of that will be irrelevant to the ath5k issue, and it can be tricky when setting up to get memory and swap and tmpfs sizes right to do plenty of swapping, without the test just collapsing in out-of-memory kills. Let me see if I can reproduce the ath5k BUG with a straightforward memhog, repeatedly dirtying more anon memory than RAM can provide. Is there something suitable I could run to exercise that wireless path concurrently? It was just idling when I hit the BUGs before. Hugh _______________________________________________ ath5k-devel mailing list [email protected] https://lists.ath5k.org/mailman/listinfo/ath5k-devel
