Hi Linus,
Em 22-09-2012 15:57, Linus Torvalds escreveu:
> On Fri, Sep 21, 2012 at 5:59 PM, Shaun Ruffell <sruff...@digium.com> wrote:
>>
>> I posted patches [1,2,3] that resolve the issue for me. Shaohui Xie
>> also hit the issue and posted a slightly different patch [4]. The
>> patches are currently waiting for Mauro, who I understand is
>> catching up since returning from San Diego, to check them out.
>>
>> [1] http://marc.info/?l=linux-kernel&m=134764595921752&w=2
>> [2] http://marc.info/?l=linux-kernel&m=134764594721747&w=2
>> [3] http://marc.info/?l=linux-kernel&m=134764597921761&w=2
>> [4] http://marc.info/?l=linux-kernel&m=134753579818528&w=2
>
> That first patch needs a sign-off from you, since you are passing on
> somebody elses patch.
>
> Looking at that patch, the patch seems to be a memory leak (?) leaking
> the "channels" allocation, along with fixing an odd and incorrect
> kfree (and access) of mci->csrows[i]. If that is correct, please write
> a proper changelog. The current changelog for that thing is totally
> pointless, and doesn't actually explain what the patch *does*.
>
> I'd also like some ack's from people, and I'd love to know which
> commit introduced the problem(s). If this problem is new to 3.6, I
> want to know what caused it, and if it is *not* new, then the thing
> needs to be marked for stable. Please?
This was caused by the edac core rewrite I made, merged for 3.6, that
replaced the usage of raw kobj in order to use, instead, struct device.
I tested the patches on several machines and they're OK. It took
me some time to test them, as I got flooded with ~400 patches for
review while I was out for KS/2012... It is taking some time for me to
dig into each of them, especially since I hit into some internal dead
lines.
The good news is that we are equipping several machines at Red Hat labs
with different memory configurations, with is allowing us to do a
comprehensive testset on the EDAC x86 drivers. We've got already
some longstanding bugs there, as well as a few recent regressions.
So, in addition to the bugs noticed by Shaun and Fengguang,
I also got bug fixes for 3 EDAC drivers (sb_edac, i3200 and i5000).
> Finally, if I'm supposed to apply patches, I really *really* want to
> see the patches sent to me explicitly, instead of having people post
> pointers to them on the web. I don't apply random stuff on the web, I
> want the "please take this patch" to be a case of people *explicitly*
> sending it to me with the proper sign-offs in place etc.
>
> IOW, the "hey, you should apply that random patch that wasn't even
> sent to you" approach is not something I accept.
I just updated the patches today on my git tree (so, they should be
popping up tomorrow at -next).
So, I will send you tomorrow a pull request with all fixes I'm aware
of for edac, after the -next merging.
If you prefer otherwise to merge them today, you can get those patches
with my SOB at:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac.git master
Thanks!
Mauro
-
The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2:
Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac.git master
for you to fetch changes up to ded6223cfb75c4b5f61a285eee10df98a0291460:
sb_edac: Avoid overflow errors at memory size calculation (2012-09-23
10:16:36 -0300)
----------------------------------------------------------------
Fengguang Wu (1):
edac_mc: fix kfree calls in the error path
Mauro Carvalho Chehab (3):
i3200_edac: Fix memory rank size
i5000: Fix the memory size calculation with 2R memories
sb_edac: Avoid overflow errors at memory size calculation
Shaun Ruffell (2):
edac: edac_mc_free() cannot assume mem_ctl_info is registered in sysfs
edac: edac_mc no longer deals with kobjects directly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
