Matt Fleming [Thu, 3 May 2012 05:43:15 +0000 (15:43 +1000)]
m68k: use set_current_blocked() and block_sigmask()
As described in e6fa16ab ("signal: sigprocmask() should do
retarget_shared_pending()") the modification of current->blocked is
incorrect as we need to check whether the signal we're about to block is
pending in the shared queue.
Also, use the new helper function introduced in commit 5e6292c0f28f
("signal: add block_sigmask() for adding sigmask to current->blocked")
which centralises the code for updating current->blocked after
successfully delivering a signal and reduces the amount of duplicate code
across architectures. In the past some architectures got this code wrong,
so using this helper function should stop that from happening again.
Acked-by: Oleg Nesterov <oleg@redhat.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Matt Fleming [Thu, 3 May 2012 05:43:15 +0000 (15:43 +1000)]
m32r: use set_current_blocked() and block_sigmask()
As described in e6fa16ab ("signal: sigprocmask() should do
retarget_shared_pending()") the modification of current->blocked is
incorrect as we need to check whether the signal we're about to block is
pending in the shared queue.
Also, use the new helper function introduced in commit 5e6292c0f28f
("signal: add block_sigmask() for adding sigmask to current->blocked")
which centralises the code for updating current->blocked after
successfully delivering a signal and reduces the amount of duplicate code
across architectures. In the past some architectures got this code wrong,
so using this helper function should stop that from happening again.
Acked-by: Oleg Nesterov <oleg@redhat.com> Cc: Hirokazu Takata <takata@linux-m32r.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Kyle McMartin <kyle@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Matt Fleming [Thu, 3 May 2012 05:43:14 +0000 (15:43 +1000)]
avr32: use block_sigmask()
Use the new helper function introduced in commit 5e6292c0f28f ("signal:
add block_sigmask() for adding sigmask to current->blocked") which
centralises the code for updating current->blocked after successfully
delivering a signal and reduces the amount of duplicate code across
architectures.
In the past some architectures got this code wrong, so using this helper
function should stop that from happening again.
Acked-by: Oleg Nesterov <oleg@redhat.com> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no> Cc: Havard Skinnemoen <hskinnemoen@gmail.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Matt Fleming [Thu, 3 May 2012 05:43:13 +0000 (15:43 +1000)]
avr32: don't mask signals in the error path
The current handle_signal() implementation is broken - it will mask
signals if we fail to setup the signal stack frame, which isn't the
desired behaviour, we should only be masking signals if we succeed in
setting up the stack frame. It looks like this code was copied from the
old (broken) arm implementation but wasn't updated when the arm code was
fixed in commit a6c61e9dfdd0 ("[ARM] 3168/1: Update ARM signal delivery
and masking").
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Havard Skinnemoen <hskinnemoen@gmail.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Shérab [Thu, 3 May 2012 05:43:12 +0000 (15:43 +1000)]
arch/x86/platform/iris/iris.c: register a platform device and a platform driver
This makes the iris driver use the platform API, so it is properly exposed
in /sys.
[akpm@linux-foundation.org: remove commented-out code, add missing space to printk, clean up code layout] Signed-off-by: Shérab <Sebastien.Hinderer@ens-lyon.org> Cc: Len Brown <lenb@kernel.org> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
arch/x86/platform/geode/net5501.c: change active_low to 0 for LED driver
It seems that there was an error with the active_low = 1 for the
LED, since it should be set to 0 (meaning that active is high,
since 0 is false, hence the confusion.
The wiki article about it confuses it, since it contradicts itself,
regarding what turns on the LED.
I have tested 3.4-rc2 on my net5501 with this patch, and it makes the LED
behave correctly, where "none" turns it off, and "default-on" turns it on,
when echoed onto the trigger "file" in /sys/class/leds.
Signed-off-by: Bjarke Istrup Pedersen <gurligebis@gentoo.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Philip Prindeville <philipp@redfish-solutions.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tao Guo [Thu, 3 May 2012 05:43:11 +0000 (15:43 +1000)]
umem: fix up unplugging
Fix a regression introduced by 7eaceaccab5f40 ("block: remove per-queue
plugging"). In that patch, Jens removed the whole mm_unplug_device()
function, which used to be the trigger to make umem start to work.
We need to implement unplugging to make umem start to work, or I/O
will never be triggered.
Signed-off-by: Tao Guo <Tao.Guo@emc.com> Cc: Neil Brown <neilb@suse.de> Cc: Jens Axboe <axboe@kernel.dk> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Arnd Bergmann [Thu, 3 May 2012 05:43:11 +0000 (15:43 +1000)]
drivers/leds: correct __devexit annotations
__devexit functions are discarded without CONFIG_HOTPLUG, so they need to
be referenced carefully. A __devexit function may also not be called from
a __devinit function.
Mike Galbraith [Thu, 3 May 2012 05:43:10 +0000 (15:43 +1000)]
namespaces, pid_ns: fix leakage on fork() failure
Fork() failure post namespace creation for a child cloned with
CLONE_NEWPID leaks pid_namespace/mnt_cache due to proc being mounted
during creation, but not unmounted during cleanup. Call
pid_ns_release_proc() during cleanup.
Signed-off-by: Mike Galbraith <efault@gmx.de> Acked-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Louis Rilling <louis.rilling@kerlabs.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Chris Metcalf [Thu, 3 May 2012 05:43:09 +0000 (15:43 +1000)]
hugetlb: prevent BUG_ON in hugetlb_fault() -> hugetlb_cow()
66aebce747eaf ("hugetlb: fix race condition in hugetlb_fault()") added
code to avoid a race condition by elevating the page refcount in
hugetlb_fault() while calling hugetlb_cow().
However, one code path in hugetlb_cow() includes an assertion that the
page count is 1, whereas it may now also have the value 2 in this path.
The consensus is that this BUG_ON has served its purpose, so rather than
extending it to cover both cases, we just remove it.
Sasha Levin [Thu, 3 May 2012 05:43:09 +0000 (15:43 +1000)]
mm: fix division by 0 in percpu_pagelist_fraction()
percpu_pagelist_fraction_sysctl_handler() has only considered -EINVAL as a
possible error from proc_dointvec_minmax(). If any other error is
returned, it would proceed to divide by zero since
percpu_pagelist_fraction wasn't getting initialized at any point. For
example, writing 0 bytes into the proc file would trigger the issue.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Reviewed-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
include/linux/pagemap.h:492: warning: 'ret' may be used uninitialized in this function
include/linux/pagemap.h:492: note: 'ret' was declared here
Unlike a lot of gcc nags, this one appears somewhat legit. i.e. passing
in an invalid negative value of "size" does make it look like all the
conditionals in there would be bypassed and the uninitialized value would
be returned.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
projects / karo-tx-linux.git / log