On Mon, 2009-06-01 at 22:49 +0200, Jarek Poplawski wrote: > > Actually, I'd insist with the old rock and handling that other rude > u32 case, at least until it's fixed in place. So I attach my version > of your patch (additionally I removed a pair of braces because of > checkpatch warning). Sure, it doesnt complicate anything - Minoru, this is the version to go for. > Alas, I still think we don't need to change so much in -stable to > fix the cls_cgroup oops, so I attach a patch which I think is > enough for -stable and probably -net too. It could be "reverted" > in -net-next just after applying cls_api patch. Of course, treat > it only as my humble proposal, and feel free to recommend to David > your version, no problem (really). My view is the same - that the second patch doesnt fix the root cause; and it is not that complicated to fix the root cause. So I humbly disagree with you. The issue is that a classifer (cls_group in this example) is being misconfigured. It rejects the config - but the tp has already been added. It then tries to use the tp in the fast and fails. If you look as closely as you did with the patch i posted, youd find ways to construct similar hostile misconfigs for other classifiers. You just need to create the scenario where the attributes will fail to validate. I actually suspect the most common scenario for such a failure is not that head is null (I doubt in Minoru case that allocation will fail); rather it is some reference to head->something. cheers, jamal _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers