02 Apr, 2014
1 commit
-
the only thing it's doing these days is calculation of
upper limit for fs.nr_open sysctl and that can be done
staticallySigned-off-by: Al Viro
25 Jan, 2014
1 commit
-
rcu_dereference_check_fdtable() looks very wrong,
1. rcu_my_thread_group_empty() was added by 844b9a8707f1 "vfs: fix
RCU-lockdep false positive due to /proc" but it doesn't really
fix the problem. A CLONE_THREAD (without CLONE_FILES) task can
hit the same race with get_files_struct().And otoh rcu_my_thread_group_empty() can suppress the correct
warning if the caller is the CLONE_FILES (without CLONE_THREAD)
task.2. files->count == 1 check is not really right too. Even if this
files_struct is not shared it is not safe to access it lockless
unless the caller is the owner.Otoh, this check is sub-optimal. files->count == 0 always means
it is safe to use it lockless even if files != current->files,
but put_files_struct() has to take rcu_read_lock(). See the next
patch.This patch removes the buggy checks and turns fcheck_files() into
__fcheck_files() which uses rcu_dereference_raw(), the "unshared"
callers, fget_light() and fget_raw_light(), can use it to avoid
the warning from RCU-lockdep.fcheck_files() is trivially reimplemented as rcu_lockdep_assert()
plus __fcheck_files().Signed-off-by: Oleg Nesterov
Signed-off-by: Al Viro
02 May, 2013
1 commit
-
Signed-off-by: Al Viro
29 Nov, 2012
1 commit
-
Signed-off-by: Al Viro
27 Sep, 2012
9 commits
-
descriptor-related parts of daemonize, done right. As the
result we simplify the locking rules for ->files - we
hold task_lock in *all* cases when we modify ->files.Signed-off-by: Al Viro
-
iterates through the opened files in given descriptor table,
calling a supplied function; we stop once non-zero is returned.
Callback gets struct file *, descriptor number and const void *
argument passed to iterator. It is called with files->file_lock
held, so it is not allowed to block.tty_io, netprio_cgroup and selinux flush_unauthorized_files()
converted to its use.Signed-off-by: Al Viro
-
no callers outside of fs/file.c left
Signed-off-by: Al Viro
-
nobody uses those outside anymore.
Signed-off-by: Al Viro
-
... and add cond_resched() there, while we are at it. We can
get large latencies as is...Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Similar situation to that of __alloc_fd(); do not use unless you
really have to. You should not touch any descriptor table other
than your own; it's a sure sign of a really bad API design.As with __alloc_fd(), you *must* use a first-class reference to
struct files_struct; something obtained by get_files_struct(some task)
(let alone direct task->files) will not do. It must be either
current->files, or obtained by get_files_struct(current) by the
owner of that sucker and given to you.Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Essentially, alloc_fd() in a files_struct we own a reference to.
Most of the time wanting to use it is a sign of lousy API
design (such as android/binder). It's *not* a general-purpose
interface; better that than open-coding its guts, but again,
playing with other process' descriptor table is a sign of bad
design.Signed-off-by: Al Viro
20 Feb, 2012
2 commits
-
Replace the fd_sets in struct fdtable with an array of unsigned longs and then
use the standard non-atomic bit operations rather than the FD_* macros.This:
(1) Removes the abuses of struct fd_set:
(a) Since we don't want to allocate a full fd_set the vast majority of the
time, we actually, in effect, just allocate a just-big-enough array of
unsigned longs and cast it to an fd_set type - so why bother with the
fd_set at all?(b) Some places outside of the core fdtable handling code (such as
SELinux) want to look inside the array of unsigned longs hidden inside
the fd_set struct for more efficient iteration over the entire set.(2) Eliminates the use of FD_*() macros in the kernel completely.
(3) Permits the __FD_*() macros to be deleted entirely where not exposed to
userspace.Signed-off-by: David Howells
Link: http://lkml.kernel.org/r/20120216174954.23314.48147.stgit@warthog.procyon.org.uk
Signed-off-by: H. Peter Anvin
Cc: Al Viro -
Wrap accesses to the fd_sets in struct fdtable (for recording open files and
close-on-exec flags) so that we can move away from using fd_sets since we
abuse the fd_set structs by not allocating the full-sized structure under
normal circumstances and by non-core code looking at the internals of the
fd_sets.The first abuse means that use of FD_ZERO() on these fd_sets is not permitted,
since that cannot be told about their abnormal lengths.This introduces six wrapper functions for setting, clearing and testing
close-on-exec flags and fd-is-open flags:void __set_close_on_exec(int fd, struct fdtable *fdt);
void __clear_close_on_exec(int fd, struct fdtable *fdt);
bool close_on_exec(int fd, const struct fdtable *fdt);
void __set_open_fd(int fd, struct fdtable *fdt);
void __clear_open_fd(int fd, struct fdtable *fdt);
bool fd_is_open(int fd, const struct fdtable *fdt);Note that I've prepended '__' to the names of the set/clear functions because
they require the caller to hold a lock to use them.Note also that I haven't added wrappers for looking behind the scenes at the
the array. Possibly that should exist too.Signed-off-by: David Howells
Link: http://lkml.kernel.org/r/20120216174942.23314.1364.stgit@warthog.procyon.org.uk
Signed-off-by: H. Peter Anvin
Cc: Al Viro
27 Jul, 2011
1 commit
-
This allows us to move duplicated code in
(atomic_inc_not_zero() for now) toSigned-off-by: Arun Sharma
Reviewed-by: Eric Dumazet
Cc: Ingo Molnar
Cc: David Miller
Cc: Eric Dumazet
Acked-by: Mike Frysinger
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
09 Jul, 2011
1 commit
-
Since ca5ecddf (rcu: define __rcu address space modifier for sparse)
rcu_dereference_check use rcu_read_lock_held as a part of condition
automatically so callers do not have to do that as well.Signed-off-by: Michal Hocko
Acked-by: Paul E. McKenney
Signed-off-by: Jiri Kosina
20 Aug, 2010
1 commit
-
This adds annotations for RCU operations in core kernel components
Signed-off-by: Arnd Bergmann
Signed-off-by: Paul E. McKenney
Cc: Al Viro
Cc: Jens Axboe
Cc: Andrew Morton
Reviewed-by: Josh Triplett
07 Aug, 2010
1 commit
-
* 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
Revert "net: Make accesses to ->br_port safe for sparse RCU"
mce: convert to rcu_dereference_index_check()
net: Make accesses to ->br_port safe for sparse RCU
vfs: add fs.h to define struct file
lockdep: Add an in_workqueue_context() lockdep-based test function
rcu: add __rcu API for later sparse checking
rcu: add an rcu_dereference_index_check()
tree/tiny rcu: Add debug RCU head objects
mm: remove all rcu head initializations
fs: remove all rcu head initializations, except on_stack initializations
powerpc: remove all rcu head initializations
21 Jul, 2010
1 commit
-
If a single-threaded process does a file-descriptor operation, and some
other process accesses that same file descriptor via /proc, the current
rcu_dereference_check_fdtable() can give a false-positive RCU-lockdep
splat due to the reference count being increased by the /proc access after
the reference-count check in fget_light() but before the check in
rcu_dereference_check_fdtable().This commit prevents this false positive by checking for a single-threaded
process. To avoid #include hell, this commit uses the wrapper for
thread_group_empty(current) defined by rcu_my_thread_group_empty()
provided in a separate commit.Located-by: Miles Lane
Located-by: Eric Dumazet
Signed-off-by: Paul E. McKenney
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Jun, 2010
1 commit
-
The sparse RCU-pointer annotations require definition of the
underlying type of any pointer passed to rcu_dereference() and friends.
So fcheck_files() needs "struct file" to be defined, so include fs.h.Signed-off-by: Arnd Bergmann
Signed-off-by: Paul E. McKenney
Cc: Al Viro
25 Feb, 2010
2 commits
-
Create an rcu_dereference_check_fdtable() that encapsulates the
rcu_dereference_check() condition for fcheck_files() use. This
has the beneficial side-effect of getting rid of a very long
line.Suggested-by: Peter Zijlstra
Signed-off-by: Paul E. McKenney
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: mathieu.desnoyers@polymtl.ca
Cc: josh@joshtriplett.org
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
Cc: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com
LKML-Reference:
Signed-off-by: Ingo Molnar -
Add lockdep-ified RCU primitives to alloc_fd(), files_fdtable()
and fcheck_files().Cc: Alexander Viro
Signed-off-by: Paul E. McKenney
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: mathieu.desnoyers@polymtl.ca
Cc: josh@joshtriplett.org
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
Cc: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com
Cc: Alexander Viro
LKML-Reference:
Signed-off-by: Ingo Molnar
03 Apr, 2009
1 commit
-
Impact: cleanup
We want to remove percpu.h from rcupdate.h (for upcoming kmemtrace
changes), but this is not possible currently without breaking the
build because fdtable.h has an implicit include file dependency: it
uses __init does not include init.h.This can cause build failures on non-x86 architectures:
/home/mingo/tip/include/linux/fdtable.h:66: error: expected '=', ',',
';', 'asm' or '__attribute__' before 'files_defer_init'
make[2]: *** [fs/locks.o] Error 1We got this header included indirectly via rcupdate.h's percpu.h
inclusion - but if that is not there the build will break.Fix it.
Cc: Pekka Enberg
Cc: Eduard - Gabriel Munteanu
Cc: paulmck@linux.vnet.ibm.com
LKML-Reference:
Signed-off-by: Ingo Molnar
01 Jan, 2009
1 commit
-
Instead of creating the "filp" kmem_cache in vfs_caches_init(),
we can do it a litle be later in files_init(), so that filp_cachep
is static to fs/file_table.cAcked-by: Paul E. McKenney
Signed-off-by: Eric Dumazet
Signed-off-by: Al Viro
17 May, 2008
1 commit
-
Move the sucker to fs/file.c in preparation to the rest
Signed-off-by: Al Viro
02 May, 2008
1 commit
-
Initial splitoff of the low-level stuff; taken to fdtable.h
Signed-off-by: Al Viro