linux-toradex.git/drivers/oprofile, branch v3.14.3

oprofile: get rid of pointless forward declarations of struct super_block

2013-09-04T02:52:48+00:00

Signed-off-by: Al Viro

oprofilefs_create_...() do not need superblock argument

2013-09-04T02:52:48+00:00

same story as with oprofilefs_mkdir()

Signed-off-by: Al Viro

oprofilefs_mkdir() doesn't need superblock argument

2013-09-04T02:52:47+00:00

it's always equal to ->d_sb of the second argument (parent dentry),
due to either being literally that, or ->d_sb of parent's parent.

Signed-off-by: Al Viro

don't bother with passing superblock to oprofile_create_stats_files()

2013-09-04T02:52:47+00:00

Signed-off-by: Al Viro

oprofile: don't bother with passing superblock to ->create_files()

2013-09-04T02:52:46+00:00

Signed-off-by: Al Viro

don't bother passing sb to oprofile_create_files()

2013-09-04T02:52:46+00:00

it's always root->d_sb

Signed-off-by: Al Viro

drivers: delete __cpuinit usage from all remaining drivers files

2013-07-14T23:36:59+00:00

The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

This removes all the remaining one-off uses of the __cpuinit macros
from all C files in the drivers/* directory.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Greg Kroah-Hartman 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Paul Gortmaker

fs: Limit sys_mount to only request filesystem modules.

2013-03-04T03:36:31+00:00

Modify the request_module to prefix the file system type with "fs-"
and add aliases to all of the filesystems that can be built as modules
to match.

A common practice is to build all of the kernel code and leave code
that is not commonly needed as modules, with the result that many
users are exposed to any bug anywhere in the kernel.

Looking for filesystems with a fs- prefix limits the pool of possible
modules that can be loaded by mount to just filesystems trivially
making things safer with no real cost.

Using aliases means user space can control the policy of which
filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
with blacklist and alias directives.  Allowing simple, safe,
well understood work-arounds to known problematic software.

This also addresses a rare but unfortunate problem where the filesystem
name is not the same as it's module name and module auto-loading
would not work.  While writing this patch I saw a handful of such
cases.  The most significant being autofs that lives in the module
autofs4.

This is relevant to user namespaces because we can reach the request
module in get_fs_type() without having any special permissions, and
people get uncomfortable when a user specified string (in this case
the filesystem type) goes all of the way to request_module.

After having looked at this issue I don't think there is any
particular reason to perform any filtering or permission checks beyond
making it clear in the module request that we want a filesystem
module.  The common pattern in the kernel is to call request_module()
without regards to the users permissions.  In general all a filesystem
module does once loaded is call register_filesystem() and go to sleep.
Which means there is not much attack surface exposed by loading a
filesytem module unless the filesystem is mounted.  In a user
namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
which most filesystems do not set today.

Acked-by: Serge Hallyn 
Acked-by: Kees Cook 
Reported-by: Kees Cook 
Signed-off-by: "Eric W. Biederman"

oprofilefs: add missing ->i_mutex locking in object creation

2013-02-23T04:31:38+00:00

Right now it's safe only during initial mount *and* functions are asking
to be abused for dynamic adding of objects.

Signed-off-by: Al Viro

mm: use mm->exe_file instead of first VM_EXECUTABLE vma->vm_file

2012-10-09T07:22:18+00:00

Some security modules and oprofile still uses VM_EXECUTABLE for retrieving
a task's executable file.  After this patch they will use mm->exe_file
directly.  mm->exe_file is protected with mm->mmap_sem, so locking stays
the same.

Signed-off-by: Konstantin Khlebnikov 
Acked-by: Chris Metcalf 			[arch/tile]
Acked-by: Tetsuo Handa 	[tomoyo]
Cc: Alexander Viro 
Cc: Carsten Otte 
Cc: Cyrill Gorcunov 
Cc: Eric Paris 
Cc: H. Peter Anvin 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Acked-by: James Morris 
Cc: Jason Baron 
Cc: Kentaro Takeda 
Cc: Matt Helsley 
Cc: Nick Piggin 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Robert Richter 
Cc: Suresh Siddha 
Cc: Venkatesh Pallipadi 
Acked-by: Linus Torvalds 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds