Messages in this thread | | | Date | Wed, 2 Jan 2008 22:10:59 +0100 | From | "Torsten Kaiser" <> | Subject | Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4 |
| |
On Jan 2, 2008 9:51 PM, Christoph Lameter <clameter@sgi.com> wrote: > On Wed, 2 Jan 2008, Torsten Kaiser wrote: > > > I just tested something with vanilla 2.6.24-rc6 and had the same problem. > > Should this patch, or something similar be included for 2.6.24? > > Such a patch is in Andrew's tree. > > 2.6.24-rc6-mm1: > > tatic struct kmem_cache_node *early_kmem_cache_node_alloc(gfp_t gfpflags, > int node) > { > struct page *page; > struct kmem_cache_node *n; > unsigned long flags; > ... > > /* > > * lockdep requires consistent irq usage for each lock > * so even though there cannot be a race this early in > * the boot sequence, we still disable irqs. > */ > local_irq_save(flags); > add_partial(kmalloc_caches, page, 0); > local_irq_restore(flags); > return n; > } >
from 2.6.24-rc6-mm1 patch-series file: slub-noinline-some-functions-to-avoid-them-being-folded-into-alloc-free.patch slub-move-kmem_cache_node-determination-into-add_full-and-add_partial.patch slub-move-kmem_cache_node-determination-into-add_full-and-add_partial-slub-workaround-for-lockdep-confusion.patch slub-avoid-checking-for-a-valid-object-before-zeroing-on-the-fast-path.patch
It seems it got lumped into some other slub patches, but the bug does not seem to be introduced by them, as I can see it in mainline 2.6.24-rc6.
Should this patch made a candidate for the merge-before-2.6.24-final-queue?
Torsten
| |