summaryrefslogtreecommitdiff
path: root/include/linux/kref.h
AgeCommit message (Collapse)AuthorFilesLines
2013-05-16Merge branch 'queue' of ↵Linus Torvalds1-0/+33
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending Pull target fixes from Nicholas Bellinger: "A handful of fixes + minor changes this time around, along with one important >= v3.9 regression fix for IBLOCK backends. The highlights include: - Use FD_MAX_SECTORS in FILEIO for block_device as well as files (agrover) - Fix processing of out-of-order CmdSNs with iSBD driver (shlomo) - Close long-standing target_put_sess_cmd() vs. core_tmr_abort_task() race with the addition of kref_put_spinlock_irqsave() (joern + greg-kh) - Fix IBLOCK WCE=1 + DPOFUA=1 backend WRITE regression in >= v3.9 (nab + bootc) Note these four patches are CC'ed to stable. Also, there is still some work left to be done on the active I/O shutdown path in target_wait_for_sess_cmds() used by tcm_qla2xxx + ib_isert fabrics that is still being discussed on the list, and will hopefully be resolved soon." * 'queue' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: target: close target_put_sess_cmd() vs. core_tmr_abort_task() race target: removed unused transport_state flag target/iblock: Fix WCE=1 + DPOFUA=1 backend WRITE regression MAINTAINERS: Update target git tree URL iscsi-target: Fix typos in RDMAEXTENSIONS macro usage target/rd: Add ramdisk bit for NULLIO operation iscsi-target: Fix processing of OOO commands iscsi-target: Make buf param of iscsit_do_crypto_hash_buf() const void * iscsi-target: Fix NULL pointer dereference in iscsit_send_reject target: Have dev/enable show if TCM device is configured target: Use FD_MAX_SECTORS/FD_BLOCKSIZE for blockdevs using fileio target: Remove unused struct members in se_dev_entry
2013-05-15target: close target_put_sess_cmd() vs. core_tmr_abort_task() raceJoern Engel1-0/+33
It is possible for one thread to to take se_sess->sess_cmd_lock in core_tmr_abort_task() before taking a reference count on se_cmd->cmd_kref, while another thread in target_put_sess_cmd() drops se_cmd->cmd_kref before taking se_sess->sess_cmd_lock. This introduces kref_put_spinlock_irqsave() and uses it in target_put_sess_cmd() to close the race window. Signed-off-by: Joern Engel <joern@logfs.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <stable@vger.kernel.org> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2013-05-08kref: minor cleanupAnatol Pomozov1-3/+6
- make warning smp-safe - result of atomic _unless_zero functions should be checked by caller to avoid use-after-free error - trivial whitespace fix. Link: https://lkml.org/lkml/2013/4/12/391 Tested: compile x86, boot machine and run xfstests Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> [ Removed line-break, changed to use WARN_ON_ONCE() - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-11-20kref: Implement kref_get_unless_zero v3Thomas Hellstrom1-0/+21
This function is intended to simplify locking around refcounting for objects that can be looked up from a lookup structure, and which are removed from that lookup structure in the object destructor. Operations on such objects require at least a read lock around lookup + kref_get, and a write lock around kref_put + remove from lookup structure. Furthermore, RCU implementations become extremely tricky. With a lookup followed by a kref_get_unless_zero *with return value check* locking in the kref_put path can be deferred to the actual removal from the lookup structure and RCU lookups become trivial. v2: Formatting fixes. v3: Invert the return value. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-22introduce kref_put_mutex()Al Viro1-0/+18
equivalent of mutex_lock(mutex); if (!kref_put(kref, release)) mutex_unlock(mutex); Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-01-18Fix compile breakage with kref.hJames Bottomley1-0/+1
This set of build failures just started appearing on parisc: In file included from drivers/input/serio/serio_raw.c:12: include/linux/kref.h: In function 'kref_get': include/linux/kref.h:40: error: 'TAINT_WARN' undeclared (first use in this function) include/linux/kref.h:40: error: (Each undeclared identifier is reported only once include/linux/kref.h:40: error: for each function it appears in.) include/linux/kref.h: In function 'kref_sub': include/linux/kref.h:65: error: 'TAINT_WARN' undeclared (first use in this function) It happens because TAINT_WARN is defined in kernel.h and this particular compile doesn't seem to include it (no idea why it's just manifesting .. probably some #include file untangling exposed it). Fix by adding #include <linux/kernel.h> to linux/kref.h Signed-off-by: James Bottomley <JBottomley@Parallels.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-12-14kref: fix up the kfree build problemsGreg Kroah-Hartman1-5/+10
It turns out that some memory allocators use kobjects, which use krefs, and kref.h was wanting to figure out the address of kfree(), which ended up in a loop. kfree was only being needed for a warning to tell the caller that they were doing something stupid. Now we just move that warning into the comments for the functions, which results in a bit more fun as everyone enjoys digging for people to mock at times of boredom. So, remove the dependancy of slab.h on kref.h, and fix up the other include file as well (we really only need bug.h and atomic.h, not types.h). Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-12-13kref: Remove the memory barriersPeter Zijlstra1-2/+0
Commit 1b0b3b9980e ("kref: fix CPU ordering with respect to krefs") wrongly adds memory barriers to kref. It states: 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. While true, it fails to show why this is a problem. I say it is not a problem because if there is a race with kref_put() such that we could end up referencing a free'd object without this memory barrier, we would still have that race with the memory barrier. The kref_put() in question could complete (and free the object) before the atomic_inc() and we'd still be up shit creek. The kref_init() case is even worse, if your object is published at this time you're so wrong the memory barrier won't make a difference what so ever. If its not published, the act of publishing should include the needed barriers/locks to make sure all writes prior to the act of publishing are complete such that others will only observe a complete object. Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-12-13kref: Implement kref_put in terms of kref_subPeter Zijlstra1-18/+10
Less lines of code is better. Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-12-13kref: Inline all functionsPeter Zijlstra1-5/+75
These are tiny functions, there's no point in having them out-of-line. Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/n/tip-8eccvi2ur2fzgi00xdjlbf5z@git.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-22kref: Add a kref_sub functionThomas Hellstrom1-0/+2
Makes it possible to optimize batched multiple unrefs. Initial user will be drivers/gpu/ttm which accumulates unrefs to be processed outside of atomic code. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-05-21kref: remove kref_setNeilBrown1-1/+0
Of the three uses of kref_set in the kernel: One really should be kref_put as the code is letting go of a reference, Two really should be kref_init because the kref is being initialised. This suggests that making kref_set available encourages bad code. So fix the three uses and remove kref_set completely. Signed-off-by: NeilBrown <neilb@suse.de> Acked-by: Mimi Zohar <zohar@us.ibm.com> Acked-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-03-15kobj: kref.h incorrectly describes itself as kref.c.Robert P. J. Day1-1/+1
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-09-26headers: kref.h reduxAlexey Dobriyan1-1/+0
* remove asm/atomic.h inclusion from kref.h -- not needed, linux/types.h is enough for atomic_t * remove linux/kref.h inclusion from files which do not need it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30Remove "#ifdef __KERNEL__" checks from unexported headersRobert P. J. Day1-3/+0
Remove the "#ifdef __KERNEL__" tests from unexported header files in linux/include whose entire contents are wrapped in that preprocessor test. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-25kref: add kref_set()Evgeniy Polyakov1-0/+1
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>
2005-04-17Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+32
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!