[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.021 / U:7.240 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site