linux-toradex.git/fs/dcookies.c, branch v5.1-rc4

fs: add do_lookup_dcookie() helper; remove in-kernel call to syscall

2018-04-02T18:15:39+00:00

Using the fs-internal do_lookup_dcookie() helper allows us to get rid of
fs-internal calls to the sys_lookup_dcookie() syscall.

This patch is part of a series which removes in-kernel calls to syscalls.
On this basis, the syscall entry path can be streamlined. For details, see
http://lkml.kernel.org/r/20180325162527.GA17492@light.dominikbrodowski.net

Cc: Al Viro 
Cc: Andrew Morton 
Signed-off-by: Dominik Brodowski

Replace with globally

2016-12-24T19:46:01+00:00

This was entirely automated, using the script by Al:

  PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*'
  sed -i -e "s!$PATT!#include !" \
        $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h)

to do the replacement at the end of the merge window.

Requested-by: Al Viro 
Signed-off-by: Linus Torvalds

constify get_dcookie() and friends

2016-12-06T00:01:16+00:00

Signed-off-by: Al Viro

fs/compat: fix lookup_dcookie() parameter handling

2014-01-30T00:22:40+00:00

Commit d5dc77bfeeab ("consolidate compat lookup_dcookie()") coverted all
architectures to the new compat_sys_lookup_dcookie() syscall.

The "len" paramater of the new compat syscall must have the type
compat_size_t in order to enforce zero extension for architectures where
the ABI requires that the caller of a function performed zero and/or
sign extension to 64 bit of all parameters.

Signed-off-by: Heiko Carstens 
Cc: Al Viro 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Hendrik Brueckner 
Cc: Martin Schwidefsky 
Cc: 	[v3.10+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

consolidate compat lookup_dcookie()

2013-03-04T04:00:23+00:00

Signed-off-by: Al Viro

teach SYSCALL_DEFINE how to deal with long long/unsigned long long

2013-03-04T03:46:22+00:00

... and convert a bunch of SYSCALL_DEFINE ones to SYSCALL_DEFINE,
killing the boilerplate crap around them.

Signed-off-by: Al Viro

fs: reduce the use of module.h wherever possible

2012-02-29T00:31:58+00:00

For files only using THIS_MODULE and/or EXPORT_SYMBOL, map
them onto including export.h -- or if the file isn't even
using those, then just delete the include.  Fix up any implicit
include dependencies that were being masked by module.h along
the way.

Signed-off-by: Paul Gortmaker

oprofile, dcookies: Fix possible circular locking dependency

2011-05-31T14:33:35+00:00

The lockdep warning below detects a possible A->B/B->A locking
dependency of mm->mmap_sem and dcookie_mutex. The order in
sync_buffer() is mm->mmap_sem/dcookie_mutex, while in
sys_lookup_dcookie() it is vice versa.

Fixing it in sys_lookup_dcookie() by unlocking dcookie_mutex before
copy_to_user().

oprofiled/4432 is trying to acquire lock:
 (&mm->mmap_sem){++++++}, at: [] might_fault+0x53/0xa3

but task is already holding lock:
 (dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (dcookie_mutex){+.+.+.}:
       [] lock_acquire+0xf8/0x11e
       [] mutex_lock_nested+0x63/0x309
       [] get_dcookie+0x30/0x144
       [] sync_buffer+0x196/0x3ec [oprofile]
       [] task_exit_notify+0x16/0x1a [oprofile]
       [] notifier_call_chain+0x37/0x63
       [] __blocking_notifier_call_chain+0x50/0x67
       [] blocking_notifier_call_chain+0x14/0x16
       [] profile_task_exit+0x1a/0x1c
       [] do_exit+0x2a/0x6fc
       [] do_group_exit+0x83/0xae
       [] sys_exit_group+0x17/0x1b
       [] system_call_fastpath+0x16/0x1b

-> #0 (&mm->mmap_sem){++++++}:
       [] __lock_acquire+0x1085/0x1711
       [] lock_acquire+0xf8/0x11e
       [] might_fault+0x80/0xa3
       [] sys_lookup_dcookie+0x104/0x149
       [] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

1 lock held by oprofiled/4432:
 #0:  (dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149

stack backtrace:
Pid: 4432, comm: oprofiled Not tainted 2.6.39-00008-ge5a450d #9
Call Trace:
 [] print_circular_bug+0xae/0xbc
 [] __lock_acquire+0x1085/0x1711
 [] ? get_parent_ip+0x11/0x42
 [] ? might_fault+0x53/0xa3
 [] lock_acquire+0xf8/0x11e
 [] ? might_fault+0x53/0xa3
 [] ? path_put+0x22/0x27
 [] might_fault+0x80/0xa3
 [] ? might_fault+0x53/0xa3
 [] sys_lookup_dcookie+0x104/0x149
 [] system_call_fastpath+0x16/0x1b

References: https://bugzilla.kernel.org/show_bug.cgi?id=13809
Cc:  # .27+
Signed-off-by: Robert Richter

[CVE-2009-0029] System call wrapper special cases

2009-01-14T13:15:18+00:00

System calls with an unsigned long long argument can't be converted with
the standard wrappers since that would include a cast to long, which in
turn means that we would lose the upper 32 bit on 32 bit architectures.
Also semctl can't use the standard wrapper since it has a 'union'
parameter.

So we handle them as special case and add some extra wrappers instead.

Signed-off-by: Heiko Carstens

shrink struct dentry

2008-12-31T23:07:38+00:00

struct dentry is one of the most critical structures in the kernel. So it's
sad to see it going neglected.

With CONFIG_PROFILING turned on (which is probably the common case at least
for distros and kernel developers), sizeof(struct dcache) == 208 here
(64-bit). This gives 19 objects per slab.

I packed d_mounted into a hole, and took another 4 bytes off the inline
name length to take the padding out from the end of the structure. This
shinks it to 200 bytes. I could have gone the other way and increased the
length to 40, but I'm aiming for a magic number, read on...

I then got rid of the d_cookie pointer. This shrinks it to 192 bytes. Rant:
why was this ever a good idea? The cookie system should increase its hash
size or use a tree or something if lookups are a problem. Also the "fast
dcookie lookups" in oprofile should be moved into the dcookie code -- how
can oprofile possibly care about the dcookie_mutex? It gets dropped after
get_dcookie() returns so it can't be providing any sort of protection.

At 192 bytes, 21 objects fit into a 4K page, saving about 3MB on my system
with ~140 000 entries allocated. 192 is also a multiple of 64, so we get
nice cacheline alignment on 64 and 32 byte line systems -- any given dentry
will now require 3 cachelines to touch all fields wheras previously it
would require 4.

I know the inline name size was chosen quite carefully, however with the
reduction in cacheline footprint, it should actually be just about as fast
to do a name lookup for a 36 character name as it was before the patch (and
faster for other sizes). The memory footprint savings for names which are
<= 32 or > 36 bytes long should more than make up for the memory cost for
33-36 byte names.

Performance is a feature...

Signed-off-by: Al Viro