summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorEzequiel Garcia <ezequiel@collabora.com>2018-12-03 17:44:35 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-12-06 13:57:03 +0100
commit186bddb28ff9f61250d1b33554321d0bf5d085f6 (patch)
tree3bd5f8a73b4932fdddce73a9f628f055e7496182 /Documentation
parentdrivers/base/memory.c: Use DEVICE_ATTR_RO and friends (diff)
downloadlinux-186bddb28ff9f61250d1b33554321d0bf5d085f6.tar.xz
linux-186bddb28ff9f61250d1b33554321d0bf5d085f6.zip
kref/kobject: Improve documentation
The current kref and kobject documentation may be insufficient to understand these common pitfalls regarding object lifetime and object releasing. Add a bit more documentation and improve the warnings seen by the user, pointing to the right piece of documentation. Also, it's important to understand that making fun of people publicly is not at all helpful, doesn't provide any value, and it's not a healthy way of encouraging developers to do better. "Mocking mercilessly" will, if anything, make developers feel bad and go away. This kind of behavior should not be encouraged or justified. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/kobject.txt10
1 files changed, 7 insertions, 3 deletions
diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt
index fc9485d79061..ff4c25098119 100644
--- a/Documentation/kobject.txt
+++ b/Documentation/kobject.txt
@@ -279,10 +279,14 @@ such a method has a form like::
One important point cannot be overstated: every kobject must have a
release() method, and the kobject must persist (in a consistent state)
until that method is called. If these constraints are not met, the code is
-flawed. Note that the kernel will warn you if you forget to provide a
+flawed. Note that the kernel will warn you if you forget to provide a
release() method. Do not try to get rid of this warning by providing an
-"empty" release function; you will be mocked mercilessly by the kobject
-maintainer if you attempt this.
+"empty" release function.
+
+If all your cleanup function needs to do is call kfree(), then you must
+create a wrapper function which uses container_of() to upcast to the correct
+type (as shown in the example above) and then calls kfree() on the overall
+structure.
Note, the name of the kobject is available in the release function, but it
must NOT be changed within this callback. Otherwise there will be a memory