[Pvfs2-users] Segmentation fault on insmod pvfs2.ko (pvfs2.6.3-patched, kernel 2.6.22-rc4)

[Mark Van De Vyver]

Hi,
Thanks for everyone's effort put into trying to resolve this.

On 6/28/07, Murali Vilayannur <murali.vilayannur at gmail.com> wrote:
> Hi pete,
> Agreed. What I meant to say was that the kmem_cache_create interface
> may be deprecated soon. Instead of phasing out an argument, a BUG() in
> the kernel ensures that 3rd party folks such as us fix this issue
> before the actual release of the 2.6.22 kernel.
> How about the following patch? I have only compile tested it and made
> sure that it loads on my machine. But I don't run the latest kernels
> and so that is not such a good test..:)

The consensus seems to be this is not a trivial issue and may or may
not be an issue in the final version of 2.6.22.  Apologies if this
turns out to have been a waste of time :(

At the moment it seems like the path of least pain is to get of the
2.6.22.rc* sequence.  2.6.21 may suffice for my immediate needs.
I'll test Murali's patch as soon as I've got my immediate tasks out the way.

Thanks again for the prompt assistance.
Regards
Mark

> thanks,
> Murali
>
> On 6/27/07, Pete Wyckoff <pw at osc.edu> wrote:
> > murali.vilayannur at gmail.com wrote on Wed, 27 Jun 2007 08:14 -0700:
> > > Ah pete! thanks for the clarification. I was looking at 2.6.21 hoping
> > > that that would be the latest.
> > > It does look like a new ish kernel feature. I am sorta out of the loop
> > > on the newest kernel issues :(
> > > Let me look at the code a little bit and  work on a patch and send it
> > > later today.
> > > Basically, SLAB is deprecated. We need to find out an alternate
> > > way/interface.
> >
> > The verdict is still quite out on SLAB vs the other allocators.  But
> > regardless, they'll all have the same interface.  And that interface
> > no longer accepts a destructor function.  We might as well get used
> > to it.
> >
> > Regarding us wasting our time with these pre-release kernels.
> > Agreed it's a major pain to deal with, and we don't want to waste
> > time adapting to the daily changes in linux, especially as
> > reversions are not completely uncommon.  But for modifications that
> > are likely to stick, including the previous slab one mvdv ran into
> > at compile time, it's a question of fix it now or fix it later.
> >
> > We could always just dump the code and go with the fuse version.  :)
> >
> >                 -- Pete
> >
>
>