user/sven/linux.git/drivers/oprofile, branch v3.18.35

drivers/oprofile: Replace __get_cpu_var uses for address calculation

2014-08-26T17:45:46Z

Replace the uses of __get_cpu_var for address calculation with this_cpu_ptr. Cc: Robert Richter Cc: oprofile-list@lists.sf.net Signed-off-by: Christoph Lameter Signed-off-by: Tejun Heo

oprofile, nmi-timer: Fix CPU hotplug callback registration

2014-03-20T12:43:46Z

Subsystems that want to register CPU hotplug callbacks, as well as perform initialization for the CPUs that are already online, often do it as shown below: get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu); register_cpu_notifier(&foobar_cpu_notifier); put_online_cpus(); This is wrong, since it is prone to ABBA deadlocks involving the cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently with CPU hotplug operations). Instead, the correct and race-free way of performing the callback registration is: cpu_notifier_register_begin(); for_each_online_cpu(cpu) init_cpu(cpu); /* Note the use of the double underscored version of the API */ __register_cpu_notifier(&foobar_cpu_notifier); cpu_notifier_register_done(); Fix the nmi-timer code in oprofile by using this latter form of callback registration. Cc: Robert Richter Cc: Ingo Molnar Signed-off-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki

oprofile: get rid of pointless forward declarations of struct super_block

2013-09-04T02:52:48Z

Signed-off-by: Al Viro

oprofilefs_create_...() do not need superblock argument

2013-09-04T02:52:48Z

same story as with oprofilefs_mkdir() Signed-off-by: Al Viro

oprofilefs_mkdir() doesn't need superblock argument

2013-09-04T02:52:47Z

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:47Z

Signed-off-by: Al Viro

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

2013-09-04T02:52:46Z

Signed-off-by: Al Viro

don't bother passing sb to oprofile_create_files()

2013-09-04T02:52:46Z

it's always root->d_sb Signed-off-by: Al Viro

drivers: delete __cpuinit usage from all remaining drivers files

2013-07-14T23:36:59Z

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:31Z

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"