- 09 Jun, 2017 17 commits
-
-
Greg Kroah-Hartman authored
The dev_attrs field has long been "depreciated" and is finally being removed, and as this driver isn't even using it, just drop the NULL setting, it is pointless. Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The dev_attrs field has long been "depreciated" and is finally being removed, so move the driver to use the "correct" dev_groups field instead for struct bus_type. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Bart Van Assche <bart.vanassche@sandisk.com> Cc: Johan Hovold <johan@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Rob Herring <robh@kernel.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: <linuxppc-dev@lists.ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The dev_attrs field has long been "depreciated" and is finally being removed, so move the driver to use the "correct" dev_groups field instead for struct bus_type. Seems-ok: Geoff Levand <geoff@infradead.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: <linuxppc-dev@lists.ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The dev_attrs field has long been "depreciated" and is finally being removed, so move the driver to use the "correct" dev_groups field instead for struct bus_type. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: <linuxppc-dev@lists.ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The dev_attrs field has long been "depreciated" and is finally being removed, so move the driver to use the "correct" dev_groups field instead for struct bus_type. Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <linux-sh@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The dev_attrs field has long been "depreciated" and is finally being removed, so move the driver to use the "correct" dev_groups field instead for struct bus_type. Cc: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: <linux-remoteproc@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The dev_attrs field has long been "depreciated" and is finally being removed, so move the driver to use the "correct" dev_groups field instead for struct bus_type. Cc: Russell King <linux@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The dev_attrs field has long been "depreciated" and is finally being removed, so move the driver to use the "correct" dev_groups field instead for struct bus_type. Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Helge Deller <deller@gmx.de> Cc: Bart Van Assche <bart.vanassche@sandisk.com> Cc: Doug Ledford <dledford@redhat.com> Cc: <linux-parisc@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The dev_attrs field has long been "depreciated" and is finally being removed, so move the driver to use the "correct" dev_groups field instead for struct bus_type. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: <linux-mips@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The dev_attrs field has long been "depreciated" and is finally being removed, so move the driver to use the "correct" dev_groups field instead for struct bus_type. Cc: Russell King <linux@armlinux.org.uk> Cc: <linux-arm-kernel@lists.infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This field is no longer used or needed (use class_groups instead), so it can be removed along with the driver core functionality that created and removed these files. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The class_attrs pointer is long depreciated, and is about to be finally removed, so move to use the class_groups pointer instead. Cc: <linux-block@vger.kernel.org> Acked-by: Jens Axboe <axboe@fb.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Jan Kara <jack@suse.cz> Cc: Mike Christie <mchristi@redhat.com> Cc: Bart Van Assche <Bart.VanAssche@sandisk.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The class_attrs pointer is long depreciated, and is about to be finally removed, so move to use the class_groups pointer instead. Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: <linux-gpio@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The class_attrs pointer is long depreciated, and is about to be finally removed, so move to use the class_groups pointer instead. Cc: Minchan Kim <minchan@kernel.org> Cc: Nitin Gupta <ngupta@vflare.org> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The class_attrs pointer is long depreciated, and is about to be finally removed, so move to use the class_groups pointer instead. Cc: Artem Bityutskiy <dedekind1@gmail.com> Acked-by: Richard Weinberger <richard@nod.at> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Marek Vasut <marek.vasut@gmail.com> Cc: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr> Cc: <linux-mtd@lists.infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The class_attrs pointer is going away and it's not even being used in this driver, so just remove it entirely. Acked-by: "Bryant G. Ly" <bryantly@linux.vnet.ibm.com> Cc: Michael Cyr <mikecyr@linux.vnet.ibm.com> Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: <linux-scsi@vger.kernel.org> Cc: <target-devel@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The class_attrs pointer is long depreciated, and is about to be finally removed, so move to use the class_groups pointer instead. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 07 Jun, 2017 1 commit
-
-
Greg Kroah-Hartman authored
There was only 2 remaining users of CLASS_ATTR() so let's finally get rid of them and force everyone to use the correct RW/RO/WO versions instead. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 03 Jun, 2017 14 commits
-
-
Luis R. Rodriguez authored
This moves the usermode helper locks into only code paths that use the usermode helper API from the kernel. The usermode helper locks were originally added to prevent stalling suspend, later the firmware cache was added to help with this, and further later direct filesystem lookup was added by Linus to completely bypass udev due to the amount of issues the umh approach had. The usermode helper locks were kept even when the direct filesystem lookup mechanism is used though. A lot has changed since the original usermode helper locks were added but the recent commit which added the code for firmware_enabled() are intended to address any possible races cured only as collateral by using the locks as though side consequence of code evolution and this not being addressed any time sooner. With the firmware_enabled() code in place we are a bit more sure to move the usermode helper locks to UMH only code. There is a bit of history here so let's recap a bit of it to ensure nothing is lost and things are clear. The direct filesystem approach to loading firmware is rather new, it was added via commit abb139e7 ("firmware: teach the kernel to load firmware files directly from the filesystem") by Linus merged on the v3.7 release, to enable to bypass udev. usermodehelper_read_lock_wait() was added earlier via commit 9b78c1da ("firmware_class: Do not warn that system is not ready from async loads") merged on v3.4, after Rafael noted that the async firmware API call request_firmware_nowait() should not be penalized to fail if userspace is not available yet or frozen, it'd allow for a timeout grace period before giving up. The WARN_ON() was kept for the sync firmware API call though on request_firmware(). At this time there was no direct filesystem lookup for firmware though. The original usermode helper lock came from commit a144c6a6 ("PM: Print a warning if firmware is requested when tasks are frozen") merged on the v3.0 kernel by Rafael to print a warning back when firmware requests were used on resume(), thaw() or restore() callbacks and there was no direct fs lookups or the firmware cache. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Luis R. Rodriguez authored
This will make subsequent changes easier to read. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Luis R. Rodriguez authored
The firmware API should not be used after we go to suspend and after we reboot/halt. The suspend/resume case is a bit complex, so this documents that so things are clearer. We want to know about users of the API in incorrect places so that their callers are corrected, so this also adds a warn for those cases. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Luis R. Rodriguez authored
Now that we've have proper wrappers for the fallback mechanism we can easily share the reboot notifier for the firmware_class at all times. This change will make subsequent modifications to the reboot notifier easier to review. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Luis R. Rodriguez authored
We kill pending fallback requests on suspend and reboot, the only difference is that on suspend we only kill custom fallback requests. Provide a wrapper that lets us customize the request with a flag. This also lets us simplify the #ifdef'ery over the calls. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Luis R. Rodriguez authored
This routine will used in functions declared earlier next. This code shift has no functional changes, it will make subsequent changes easier to read. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juri Lelli authored
Now that some functions that deal with arch topology information live under drivers, there is a clash of naming that might create confusion. Tidy things up by creating a topology namespace for interfaces used by arch code; achieve this by prepending a 'topology_' prefix to driver interfaces. Signed-off-by: Juri Lelli <juri.lelli@arm.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juri Lelli authored
Create a new header file (include/linux/arch_topology.h) and put there declarations of interfaces used by arm, arm64 and drivers code. Signed-off-by: Juri Lelli <juri.lelli@arm.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juri Lelli authored
Reduce the scope of cap_parsing_failed (making it static in drivers/base/arch_topology.c) by slightly changing {arm,arm64} DT parsing code. For arm checking for !cap_parsing_failed before calling normalize_ cpu_capacity() is superfluous, as returning an error from parse_ cpu_capacity() (above) means cap_from _dt is set to false. For arm64 we can simply check if raw_capacity points to something, which is not if capacity parsing has failed. Suggested-by: Morten Rasmussen <morten.rasmussen@arm.com> Signed-off-by: Juri Lelli <juri.lelli@arm.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juri Lelli authored
arm and arm64 share lot of code relative to parsing CPU capacity information from DT, using that information for appropriate scaling and exposing a sysfs interface for chaging such values at runtime. Factorize such code in a common place (driver/base/arch_topology.c) in preparation for further additions. Suggested-by: Will Deacon <will.deacon@arm.com> Suggested-by: Mark Rutland <mark.rutland@arm.com> Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Juri Lelli <juri.lelli@arm.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juri Lelli authored
The sysfs cpu_capacity entry for each CPU has nothing to do with PROC_FS, nor it's in /proc/sys path. Remove such ifdef. Cc: Russell King <linux@arm.linux.org.uk> Reported-and-suggested-by: Sudeep Holla <sudeep.holla@arm.com> Fixes: 7e5930aa ('ARM: 8622/3: add sysfs cpu_capacity attribute') Signed-off-by: Juri Lelli <juri.lelli@arm.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juri Lelli authored
parse_cpu_capacity() has to return 0 on failure, but it currently returns 1 instead if raw_capacity kcalloc failed. Fix it (by directly returning 0). Reported-by: Morten Rasmussen <morten.rasmussen@arm.com> Fixes: 06073ee2 ('ARM: 8621/3: parse cpu capacity-dmips-mhz from DT') Signed-off-by: Juri Lelli <juri.lelli@arm.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Vincent Guittot <vincent.guittot@linaor.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juri Lelli authored
Reference to cpu capacity binding has a wrong number. Fix it. Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Juri Lelli <juri.lelli@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Catalin Marinas authored
The dma_common_pages_remap() function allocates a vm_struct object and initialises the pages pointer to value passed as argument. However, when this function is called dma_common_contiguous_remap(), the pages array is only temporarily allocated, being freed shortly after dma_common_contiguous_remap() returns. Architecture code checking the validity of an area->pages pointer would incorrectly dereference already freed pointers. This has been exposed by the arm64 commit 44176bb3 ("arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU"). Fixes: 513510dd ("common: dma-mapping: introduce common remapping functions") Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reported-by: Andrzej Hajda <a.hajda@samsung.com> Acked-by: Laura Abbott <labbott@redhat.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 27 May, 2017 1 commit
-
-
Peter Rajnoha authored
We expect the changes described in ABI/testing/sysfs-uevent doc to appear in 4.13. Signed-off-by: Peter Rajnoha <prajnoha@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 May, 2017 3 commits
-
-
Nick Desaulniers authored
sysfs_get_dirent is usually invoked with a string literal, which have the type char[]. While the toplevel Makefile disables -Wpointer-sign, other Makefiles like arch/x86/boot/compressed/Makefile redefine KBUILD_CFLAGS. Fixes the warning: In file included from arch/x86/boot/compressed/kaslr.c:17: In file included from ./include/linux/module.h:17: In file included from ./include/linux/kobject.h:21: ./include/linux/sysfs.h:517:37: warning: passing 'const unsigned char *' to parameter of type 'const char *' converts between pointers to integer types with different sign [-Wpointer-sign] return kernfs_find_and_get(parent, name); ^~~~ ./include/linux/kernfs.h:462:57: note: passing argument to parameter 'name' here kernfs_find_and_get(struct kernfs_node *kn, const char *name) ^ Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Rajnoha authored
This patch makes it possible to pass additional arguments in addition to uevent action name when writing /sys/.../uevent attribute. These additional arguments are then inserted into generated synthetic uevent as additional environment variables. Before, we were not able to pass any additional uevent environment variables for synthetic uevents. This made it hard to identify such uevents properly in userspace to make proper distinction between genuine uevents originating from kernel and synthetic uevents triggered from userspace. Also, it was not possible to pass any additional information which would make it possible to optimize and change the way the synthetic uevents are processed back in userspace based on the originating environment of the triggering action in userspace. With the extra additional variables, we are able to pass through this extra information needed and also it makes it possible to synchronize with such synthetic uevents as they can be clearly identified back in userspace. The format for writing the uevent attribute is following: ACTION [UUID [KEY=VALUE ...] There's no change in how "ACTION" is recognized - it stays the same ("add", "change", "remove"). The "ACTION" is the only argument required to generate synthetic uevent, the rest of arguments, that this patch adds support for, are optional. The "UUID" is considered as transaction identifier so it's possible to use the same UUID value for one or more synthetic uevents in which case we logically group these uevents together for any userspace listeners. The "UUID" is expected to be in "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" format where "x" is a hex digit. The value appears in uevent as "SYNTH_UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" environment variable. The "KEY=VALUE" pairs can contain alphanumeric characters only. It's possible to define zero or more more pairs - each pair is then delimited by a space character " ". Each pair appears in synthetic uevents as "SYNTH_ARG_KEY=VALUE" environment variable. That means the KEY name gains "SYNTH_ARG_" prefix to avoid possible collisions with existing variables. To pass the "KEY=VALUE" pairs, it's also required to pass in the "UUID" part for the synthetic uevent first. If "UUID" is not passed in, the generated synthetic uevent gains "SYNTH_UUID=0" environment variable automatically so it's possible to identify this situation in userspace when reading generated uevent and so we can still make a difference between genuine and synthetic uevents. Signed-off-by: Peter Rajnoha <prajnoha@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Adrian Salido authored
The driver_override implementation is susceptible to race condition when different threads are reading vs storing a different driver override. Add locking to avoid race condition. Fixes: 3d713e0e ("driver core: platform: add device binding path 'driver_override'") Cc: stable@vger.kernel.org Signed-off-by: Adrian Salido <salidoa@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 May, 2017 2 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
The code to fetch a 64-bit value from user space was entirely buggered, and has been since the code was merged in early 2016 in commit b2f68038 ("x86/mm/32: Add support for 64-bit __get_user() on 32-bit kernels"). Happily the buggered routine is almost certainly entirely unused, since the normal way to access user space memory is just with the non-inlined "get_user()", and the inlined version didn't even historically exist. The normal "get_user()" case is handled by external hand-written asm in arch/x86/lib/getuser.S that doesn't have either of these issues. There were two independent bugs in __get_user_asm_u64(): - it still did the STAC/CLAC user space access marking, even though that is now done by the wrapper macros, see commit 11f1a4b9 ("x86: reorganize SMAP handling in user space accesses"). This didn't result in a semantic error, it just means that the inlined optimized version was hugely less efficient than the allegedly slower standard version, since the CLAC/STAC overhead is quite high on modern Intel CPU's. - the double register %eax/%edx was marked as an output, but the %eax part of it was touched early in the asm, and could thus clobber other inputs to the asm that gcc didn't expect it to touch. In particular, that meant that the generated code could look like this: mov (%eax),%eax mov 0x4(%eax),%edx where the load of %edx obviously was _supposed_ to be from the 32-bit word that followed the source of %eax, but because %eax was overwritten by the first instruction, the source of %edx was basically random garbage. The fixes are trivial: remove the extraneous STAC/CLAC entries, and mark the 64-bit output as early-clobber to let gcc know that no inputs should alias with the output register. Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Benjamin LaHaise <bcrl@kvack.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: stable@kernel.org # v4.8+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- 21 May, 2017 2 commits
-
-
Linus Torvalds authored
Al noticed that unsafe_put_user() had type problems, and fixed them in commit a7cc722f ("fix unsafe_put_user()"), which made me look more at those functions. It turns out that unsafe_get_user() had a type issue too: it limited the largest size of the type it could handle to "unsigned long". Which is fine with the current users, but doesn't match our existing normal get_user() semantics, which can also handle "u64" even when that does not fit in a long. While at it, also clean up the type cast in unsafe_put_user(). We actually want to just make it an assignment to the expected type of the pointer, because we actually do want warnings from types that don't convert silently. And it makes the code more readable by not having that one very long and complex line. [ This patch might become stable material if we ever end up back-porting any new users of the unsafe uaccess code, but as things stand now this doesn't matter for any current existing uses. ] Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull misc uaccess fixes from Al Viro: "Fix for unsafe_put_user() (no callers currently in mainline, but anyone starting to use it will step into that) + alpha osf_wait4() infoleak fix" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: osf_wait4(): fix infoleak fix unsafe_put_user()
-