public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg K H <gregkh@linuxfoundation.org>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Linux Edac Mailing List <linux-edac@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 01/14] edac: rewrite the sysfs code to use struct device
Date: Fri, 30 Mar 2012 08:31:52 -0700	[thread overview]
Message-ID: <20120330153152.GD18488@kroah.com> (raw)
In-Reply-To: <4F7516B3.8070505@redhat.com>

On Thu, Mar 29, 2012 at 11:13:07PM -0300, Mauro Carvalho Chehab wrote:
> Em 29-03-2012 20:40, Greg K H escreveu:
> > On Thu, Mar 29, 2012 at 08:19:08PM -0300, Mauro Carvalho Chehab wrote:
> >>> Sweet, as per the documentation in the Documentation/kobjects.txt file,
> >>> I get to publically mock you for thinking you are smarter than the
> >>> kernel and this is an acceptable way to "outwhit" the driver core from
> >>> spitting errors at you when the kobject is released.
> >>
> >> There's nothing there to free: all EDAC structures are allocated once
> >> (see edac_mc_alloc() and edac_align_ptr() logic, at drivers/edac/edac_mc.c).
> >>
> >> Even the struct device for all csrows/channels/mcu is done on a single alloc
> >> there. Trying to free it earlier would cause a segfault.
> > 
> > That's wrong then, these are multiple struct devices, all with their own
> > reference counts, you can't just treat them all as the same thing, even
> > if it happens to line up with the module reference count.
> > 
> >> I didn't wrote that logic, nor I was tempted to change it: as this subsystem 
> >> is focused on memory error detection, having every data structure used there
> >> on a single page helps to minimize the probability of having an error at the 
> >> memory used to store the EDAC data.
> > 
> > Possibly, but again, you have multiple reference counts, you can't just
> > wave them off as being inconvenient.  Please read the documentation for
> > more details why.
> 
> This is there since the beginning. The current kobj's have this issue. Those
> patchsets are not making it better or worse, as the EDAC csrow kobj's are
> already there at the current approach: all of them are allocated together
> with the mci kobj.
> 
> On the other hand, I'm working on this patch series in order to correct a 
> serious bug at the EDAC API almost all days during the last 2 months, as
> nobody ever cared enough to address this serious issue.

That's because no one had touched the code.  Now that it has an active
developer (i.e. you), it needs to be fixed.

Especially as the code you just added is wrong, and it's documented as
wrong, and you know it is wrong as you are working around the kernel
warnings by providing release functions that do nothing.

So please fix it, it's your code now.

greg k-h

  parent reply	other threads:[~2012-03-30 15:32 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-29 17:06 [PATCH 00/14] Fix the EDAC API Mauro Carvalho Chehab
2012-03-29 17:06 ` [PATCH 01/14] edac: rewrite the sysfs code to use struct device Mauro Carvalho Chehab
2012-03-29 22:03   ` Greg K H
2012-03-29 23:19     ` Mauro Carvalho Chehab
2012-03-29 23:40       ` Greg K H
2012-03-30  2:13         ` Mauro Carvalho Chehab
2012-03-30  9:11           ` Borislav Petkov
2012-03-30 10:46             ` Mauro Carvalho Chehab
2012-03-30 15:32               ` Greg K H
2012-03-30 15:31           ` Greg K H [this message]
2012-03-30 17:34             ` Mauro Carvalho Chehab
2012-03-30 19:24               ` Greg K H
2012-03-29 17:06 ` [PATCH 02/14] mpc85xx_edac: convert sysfs logic " Mauro Carvalho Chehab
2012-03-29 17:06 ` [PATCH 03/14] amd64_edac: " Mauro Carvalho Chehab
2012-03-29 17:06 ` [PATCH 04/14] i7core_edac: convert it " Mauro Carvalho Chehab
2012-03-29 17:06 ` [PATCH 05/14] edac: Get rid of the old kobj's from the edac mc code Mauro Carvalho Chehab
2012-03-29 17:06 ` [PATCH 06/14] edac: add a new per-dimm API and make the old per-virtual-rank API obsolete Mauro Carvalho Chehab
2012-03-29 17:06 ` [PATCH 07/14] edac: add a sysfs node to report the maximum location for the system Mauro Carvalho Chehab
2012-03-29 17:06 ` [PATCH 08/14] edac: Add debufs nodes to allow doing fake error inject Mauro Carvalho Chehab
2012-03-29 17:06 ` [PATCH 09/14] edac: Create a per-Memory Controller bus Mauro Carvalho Chehab
2012-03-29 17:06 ` [PATCH 10/14] edac: Move grain/dtype/edac_type calculus to be out of channel loop Mauro Carvalho Chehab
2012-03-29 17:06 ` [PATCH 11/14] i82975x_edac: Test nr_pages earlier to save a few CPU cycles Mauro Carvalho Chehab
2012-03-29 17:06 ` [PATCH 12/14] i5100_edac: Fix a warning when compiled with 32 bits Mauro Carvalho Chehab
2012-03-29 17:07 ` [PATCH 13/14] i7300_edac: Get rid of some wrongly-solved rebase conflict Mauro Carvalho Chehab
2012-03-29 17:07 ` [PATCH 14/14] edac: Only expose csrows/channels on legacy API if they're populated Mauro Carvalho Chehab
2012-03-29 20:46 ` [PATCH 00/14] Fix the EDAC API Aristeu Rozanski Filho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120330153152.GD18488@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox