On Thu, 2011-10-06 at 14:28 -0500, Seth Jennings wrote: > In the case that a cpu is taken offline before zcache_do_preload() is > ever called on the cpu, the per-cpu zcache_preloads structure will > be uninitialized. In the CPU_DEAD case for zcache_cpu_notifier(), > kp->obj is not checked before calling kmem_cache_free() on it. > If it is NULL, a crash results. > > This patch ensures that both kp->obj and kp->page are not NULL before > calling the respective free functions. In practice, just checking > one or the other should be sufficient since they are assigned together > in zcache_do_preload(), but I check both for safety. zcache_objnode_alloc() and zcache_obj_alloc() seem to do the same thing: dereference 'kp' without checking it for NULL. That's fine, but it requires that preemption be off between zcache_do_preload() and calling those functions. That seems to be the case today, but it worries me. I can see another user getting added that does zcache_obj_alloc() but forgot to disable preemption. We at least need a BUG_ON(!in_atomic()) near the dereferences. The enable/disable paths out of zcache_do_preload() look OK to me, but they're not trivial. Was there another purpose behind the preempt_disabling()? We have a number of spots on the kernel that do preloads but *don't* protect the percpu buffers in the same way. The radix-tree code, for instance, uses preempt_disable() to provide the guarantee that an allocation does not occur, but its data structures are safe to access without preempt. IOW, with the radix code, a missed preempt_disable() costs you an -ENOMEM. With zcache it costs you an oops. -- Dave _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
