Messages in this thread | | | Date | Fri, 11 Feb 2011 14:09:03 -0800 (PST) | From | Dan Magenheimer <> | Subject | RE: mmotm 2011-02-10-16-26 uploaded |
| |
> From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Friday, February 11, 2011 2:53 PM > To: akpm@linux-foundation.org; Dan Magenheimer > Cc: mm-commits@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > mm@kvack.org; linux-fsdevel@vger.kernel.org > Subject: Re: mmotm 2011-02-10-16-26 uploaded > > On Thu, 10 Feb 2011 16:26:36 PST, akpm@linux-foundation.org said: > > The mm-of-the-moment snapshot 2011-02-10-16-26 has been uploaded to > > > > http://userweb.kernel.org/~akpm/mmotm/ > > CONFIG_ZCACHE=m dies a horrid death:
Thanks Valdis. A fix for this has already been posted by Nitin Gupta and Randy Dunlap here:
https://lkml.org/lkml/2011/2/10/383
Another patch for a zcache memory leak has been posted here:
https://lkml.org/lkml/2011/2/10/306
I'm sorry that multiple people have run into this in multiple trees. I have to admit I am a bit baffled as to what the proper tree flow is for bug fixes like this, but would be happy to "follow the process" if I am told what it is or if someone can point me to a document describing it.
(Clearly making sure there are no bugs at all in a submission is the best way to go, but I'm afraid I can't claim to be perfect :-)
Thanks, Dan
P.S. I suppose there isn't really a good reason for CONFIG_ZCACHE to be tri-state as it really makes no sense as a module because, if CONFIG_CLEANCACHE is enabled, it will always get loaded.
| |