linux-toradex.git/lib/kref.c, branch tegra-10.7.1 Linux kernel for Apalis and Colibri modules kref: add kref_set() 2008-01-25T04:40:05+00:00 Evgeniy Polyakov johnpol@2ka.mipt.ru 2007-12-10T20:03:43+00:00 41ca28ab2abd76dc203e2c3a7cd609607cb927c3 This adds kref_set() to the kref api for future use by people who really know what they are doing with krefs... From: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This adds kref_set() to the kref api for future use by people who really
know what they are doing with krefs...

From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kref: fix CPU ordering with respect to krefs 2007-04-27T17:57:29+00:00 Oliver Neukum oneukum@suse.de 2007-04-02T12:47:59+00:00 1b0b3b9980e482ab7c603430462538334f69f14a some atomic operations are only atomic, not ordered. Thus a CPU is allowed to reorder memory references to an object to before the reference is obtained. This fixes it. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
some atomic operations are only atomic, not ordered. Thus a CPU is allowed
to reorder memory references to an object to before the reference is
obtained. This fixes it.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kref refcnt and false positives 2006-12-20T18:56:43+00:00 Venkatesh Pallipadi venkatesh.pallipadi@intel.com 2006-12-19T21:01:29+00:00 f334b60b43a0927f4ab1187cbdb4582f5227c3b1 With WARN_ON addition to kobject_init() [ http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/dont-use/broken-out/gregkh-driver-kobject-warn.patch ] I started seeing following WARNING on CPU offline followed by online on my x86_64 system. WARNING at lib/kobject.c:172 kobject_init() Call Trace: [<ffffffff8020ab45>] dump_trace+0xaa/0x3ef [<ffffffff8020aec4>] show_trace+0x3a/0x50 [<ffffffff8020b0f6>] dump_stack+0x15/0x17 [<ffffffff80350abc>] kobject_init+0x3f/0x8a [<ffffffff80350be1>] kobject_register+0x1a/0x3e [<ffffffff803bbd89>] sysdev_register+0x5b/0xf9 [<ffffffff80211d0b>] mce_create_device+0x77/0xf4 [<ffffffff80211dc2>] mce_cpu_callback+0x3a/0xe5 [<ffffffff805632fd>] notifier_call_chain+0x26/0x3b [<ffffffff8023f6f3>] raw_notifier_call_chain+0x9/0xb [<ffffffff802519bf>] _cpu_up+0xb4/0xdc [<ffffffff80251a12>] cpu_up+0x2b/0x42 [<ffffffff803bef00>] store_online+0x4a/0x72 [<ffffffff803bb6ce>] sysdev_store+0x24/0x26 [<ffffffff802baaa2>] sysfs_write_file+0xcf/0xfc [<ffffffff8027fc6f>] vfs_write+0xae/0x154 [<ffffffff80280418>] sys_write+0x47/0x6f [<ffffffff8020963e>] system_call+0x7e/0x83 DWARF2 unwinder stuck at system_call+0x7e/0x83 Leftover inexact backtrace: This is a false positive as mce.c is unregistering/registering sysfs interfaces cleanly on hotplug. kref_put() and conditional decrement of refcnt seems to be the root cause for this and the patch below resolves the issue for me. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
With WARN_ON addition to kobject_init()
[ http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/dont-use/broken-out/gregkh-driver-kobject-warn.patch ]

I started seeing following WARNING on CPU offline followed by online on my
x86_64 system.

WARNING at lib/kobject.c:172 kobject_init()

Call Trace:
 [<ffffffff8020ab45>] dump_trace+0xaa/0x3ef
 [<ffffffff8020aec4>] show_trace+0x3a/0x50
 [<ffffffff8020b0f6>] dump_stack+0x15/0x17
 [<ffffffff80350abc>] kobject_init+0x3f/0x8a
 [<ffffffff80350be1>] kobject_register+0x1a/0x3e
 [<ffffffff803bbd89>] sysdev_register+0x5b/0xf9
 [<ffffffff80211d0b>] mce_create_device+0x77/0xf4
 [<ffffffff80211dc2>] mce_cpu_callback+0x3a/0xe5
 [<ffffffff805632fd>] notifier_call_chain+0x26/0x3b
 [<ffffffff8023f6f3>] raw_notifier_call_chain+0x9/0xb
 [<ffffffff802519bf>] _cpu_up+0xb4/0xdc
 [<ffffffff80251a12>] cpu_up+0x2b/0x42
 [<ffffffff803bef00>] store_online+0x4a/0x72
 [<ffffffff803bb6ce>] sysdev_store+0x24/0x26
 [<ffffffff802baaa2>] sysfs_write_file+0xcf/0xfc
 [<ffffffff8027fc6f>] vfs_write+0xae/0x154
 [<ffffffff80280418>] sys_write+0x47/0x6f
 [<ffffffff8020963e>] system_call+0x7e/0x83
DWARF2 unwinder stuck at system_call+0x7e/0x83
Leftover inexact backtrace:

This is a false positive as mce.c is unregistering/registering sysfs
interfaces cleanly on hotplug.

kref_put() and conditional decrement of refcnt seems to be the root cause
for this and the patch below resolves the issue for me.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] kref: avoid an atomic operation in kref_put() 2006-03-20T21:42:57+00:00 Eric Dumazet dada1@cosmosbay.com 2006-01-30T05:19:35+00:00 8b5536bbee53620f8d5f367987e5727ba36d886d Avoid an atomic operation in kref_put() when the last reference is dropped. On most platforms, atomic_read() is a plan read of the counter and involves no atomic at all. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Avoid an atomic operation in kref_put() when the last reference is
dropped. On most platforms, atomic_read() is a plan read of the counter
and involves no atomic at all.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!