[lkml]   [2006]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] EDAC: core EDAC support code
On Monday 06 March 2006 11:53, Greg KH wrote:
> > Is the concern here that EDAC is not waiting for the reference count
> > on the kobject to reach 0, therefore creating the possibility of the
> > module unloading while the kobject (declared statically within the
> > module) is still in use?
> Eeek, don't statically create a kobject :(
> Anyway, yes, that is a problem, if it is static, then you need to know
> it is safe to unload. Even if it is dynamic that is also true...

Ok, now I understand. At first I thought it was something specific
to the way the debugf1() call was implemented that people were
commenting on.

Regarding the above problem with the kobject reference count, this
was recently fixed in the -mm tree (see edac-kobject-sysfs-fixes.patch
in 2.6.16-rc5-mm2). The fix I implemented was to add a call to
complete() in edac_memctrl_master_release() and then have the module
cleanup code wait for the completion. I think there were a few other
instances of this type of problem that I also fixed in the
above-mentioned patch.

Is it more desirable to dynamically allocate kobjects than to declare
them statically? If so, I'd be curious to know why dynamic
allocation is preferred over static allocation. If desired, I can
make a patch that fixes EDAC so that its kobjects are dynamically

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-03-06 22:41    [W:0.057 / U:2.748 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site