On 14 Oct 2010, at 15:10, Attilio Rao wrote: >> My concern is less about occasional lost dumps that destabilising the >> dumping process: calls into the memory allocator can currently trigger a lot >> of interesting behaviours, such as further calls back into the VM system, >> which can then trigger calls into other subsystems. What I'm suggesting is >> that if we want the mbuf allocator to be useful in this context, we need to >> teach it about things not to do in the dumping / crash / ... context, which >> probably means helping uma out a bit in that regard. And a watchdog to make >> sure the dump is making progress. > > I think that this would be way too complicated just to cope with panic > within the VM/UMA (not sure what other subsystems you are referring > to, wrt supposed to call). Besides, if we have a panic in the VM I'm > sure that normal dumps could also be affected. > When dealing with netdump, I'm not trying to fix all the bugs related > to our dumping infrastructure because, as long as we already > discussed, we know there are quite a few of them, but trying at least > to follow the same fragile-ness than what we have today. > And again, while I think the "watchdog" idea is good, I think it still > applies to normal dumps too, it is not specific to netdump.
No, what I'm saying is: UMA needs to not call its drain handlers, and ideally not call into VM to fill slabs, from the dumping context. That's easy to implement and will cause the dump to fail rather than causing the system to hang. Robert_______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
