18 Mar, 2016
40 commits
-
This changes several users of manual "on"/"off" parsing to use
strtobool.Some side-effects:
- these uses will now parse y/n/1/0 meaningfully too
- the early_param uses will now bubble up parse errorsSigned-off-by: Kees Cook
Acked-by: Heiko Carstens
Acked-by: Michael Ellerman
Cc: Amitkumar Karwar
Cc: Andy Shevchenko
Cc: Daniel Borkmann
Cc: Joe Perches
Cc: Kalle Valo
Cc: Martin Schwidefsky
Cc: Nishant Sarmukadam
Cc: Rasmus Villemoes
Cc: Steve French
Cc: Stephen Rothwell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add support for "on" and "off" when converting to boolean.
Signed-off-by: Kees Cook
Cc: Amitkumar Karwar
Cc: Andy Shevchenko
Cc: Daniel Borkmann
Cc: Heiko Carstens
Cc: Joe Perches
Cc: Kalle Valo
Cc: Martin Schwidefsky
Cc: Michael Ellerman
Cc: Nishant Sarmukadam
Cc: Rasmus Villemoes
Cc: Steve French
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Some callers of strtobool() were passing a pointer to unterminated
strings. In preparation of adding multi-character processing to
kstrtobool(), update the callers to not pass single-character pointers,
and switch to using the new kstrtobool_from_user() helper where
possible.Signed-off-by: Kees Cook
Cc: Amitkumar Karwar
Cc: Nishant Sarmukadam
Cc: Kalle Valo
Cc: Steve French
Cc: Andy Shevchenko
Cc: Daniel Borkmann
Cc: Heiko Carstens
Cc: Joe Perches
Cc: Kees Cook
Cc: Martin Schwidefsky
Cc: Michael Ellerman
Cc: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Create the kstrtobool_from_user() helper and move strtobool() logic into
the new kstrtobool() (matching all the other kstrto* functions).
Provides an inline wrapper for existing strtobool() callers.Signed-off-by: Kees Cook
Cc: Joe Perches
Cc: Andy Shevchenko
Cc: Rasmus Villemoes
Cc: Daniel Borkmann
Cc: Amitkumar Karwar
Cc: Nishant Sarmukadam
Cc: Kalle Valo
Cc: Steve French
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Martin Schwidefsky
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Sometimes gcc mysteriously doesn't inline
very small functions we expect to be inlined. Seehttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
With this .config:
http://busybox.net/~vda/kernel_config_OPTIMIZE_INLINING_and_Os,
the following functions get deinlined many times.
Examples of disassembly:(24 copies, 108 calls):
66 8b 07 mov (%rdi),%ax
55 push %rbp
48 89 e5 mov %rsp,%rbp
86 e0 xchg %ah,%al
5d pop %rbp
c3 retq(25 copies, 181 calls):
8b 07 mov (%rdi),%eax
55 push %rbp
48 89 e5 mov %rsp,%rbp
0f c8 bswap %eax
5d pop %rbp
c3 retq(23 copies, 94 calls):
48 8b 07 mov (%rdi),%rax
55 push %rbp
48 89 e5 mov %rsp,%rbp
48 0f c8 bswap %rax
5d pop %rbp
c3 retq(2 copies, 11 calls):
89 f8 mov %edi,%eax
55 push %rbp
c1 ef 08 shr $0x8,%edi
c1 e0 08 shl $0x8,%eax
09 c7 or %eax,%edi
48 89 e5 mov %rsp,%rbp
66 89 3e mov %di,(%rsi)(8 copies, 43 calls):
55 push %rbp
0f cf bswap %edi
89 3e mov %edi,(%rsi)
48 89 e5 mov %rsp,%rbp
5d pop %rbp
c3 retq(26 copies, 157 calls):
55 push %rbp
48 0f cf bswap %rdi
48 89 3e mov %rdi,(%rsi)
48 89 e5 mov %rsp,%rbp
5d pop %rbp
c3 retqThis patch fixes this via s/inline/__always_inline/.
It only affects arches with efficient unaligned access insns, such as x86.
(arched which lack such ops do not include linux/unaligned/access_ok.h)Code size decrease after the patch is ~8.5k:
text data bss dec hex filename
92197848 20826112 36417536 149441496 8e84bd8 vmlinux
92189231 20826144 36417536 149432911 8e82a4f vmlinux6_unaligned_be_afterSigned-off-by: Denys Vlasenko
Acked-by: Ingo Molnar
Cc: Thomas Graf
Cc: Peter Zijlstra
Cc: David Rientjes
Cc: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Sometimes gcc mysteriously doesn't inline
very small functions we expect to be inlined. Seehttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
With this .config:
http://busybox.net/~vda/kernel_config_OPTIMIZE_INLINING_and_Os,
the following functions get deinlined many times.
Examples of disassembly:(12 copies, 51 calls):
66 8b 07 mov (%rdi),%ax
55 push %rbp
48 89 e5 mov %rsp,%rbp
86 e0 xchg %ah,%al
5d pop %rbp
c3 retq(12 copies, 135 calls):
8b 07 mov (%rdi),%eax
55 push %rbp
48 89 e5 mov %rsp,%rbp
0f c8 bswap %eax
5d pop %rbp
c3 retq(2 copies, 20 calls):
48 8b 07 mov (%rdi),%rax
55 push %rbp
48 89 e5 mov %rsp,%rbp
48 0f c8 bswap %rax
5d pop %rbp
c3 retq(16 copies, 146 calls):
55 push %rbp
89 f8 mov %edi,%eax
86 e0 xchg %ah,%al
48 89 e5 mov %rsp,%rbp
5d pop %rbp
c3 retq(43 copies, ~560 calls):
55 push %rbp
89 f8 mov %edi,%eax
0f c8 bswap %eax
48 89 e5 mov %rsp,%rbp
5d pop %rbp
c3 retq(21 copies, 119 calls):
55 push %rbp
48 89 f8 mov %rdi,%rax
48 0f c8 bswap %rax
48 89 e5 mov %rsp,%rbp
5d pop %rbp
c3 retq(6 copies, 47 calls):
8b 07 mov (%rdi),%eax
55 push %rbp
48 89 e5 mov %rsp,%rbp
0f c8 bswap %eax
89 07 mov %eax,(%rdi)
5d pop %rbp
c3 retqThis patch fixes this via s/inline/__always_inline/.
Code size decrease after the patch is ~4.5k:text data bss dec hex filename
92202377 20826112 36417536 149446025 8e85d89 vmlinux
92197848 20826112 36417536 149441496 8e84bd8 vmlinux5_swap_afterSigned-off-by: Denys Vlasenko
Acked-by: Ingo Molnar
Cc: Thomas Graf
Cc: Peter Zijlstra
Cc: David Rientjes
Cc: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Sometimes gcc mysteriously doesn't inline
very small functions we expect to be inlined. Seehttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
With this .config:
http://busybox.net/~vda/kernel_config_OPTIMIZE_INLINING_and_Os,
atomic_long_inc(), atomic_long_dec() and atomic_long_add()
functions get deinlined about 40 times. Examples of disassembly:(21 copies, 147 calls):
55 push %rbp
48 89 e5 mov %rsp,%rbp
f0 48 ff 07 lock incq (%rdi)
5d pop %rbp
c3 retq(4 copies, 14 calls) is similar to inc.
(11 copies, 41 calls):
55 push %rbp
48 89 e5 mov %rsp,%rbp
f0 48 01 3e lock add %rdi,(%rsi)
5d pop %rbp
c3 retqThis patch fixes this via s/inline/__always_inline/.
Code size decrease after the patch is ~1.3k:text data bss dec hex filename
92203657 20826112 36417536 149447305 8e86289 vmlinux
92202377 20826112 36417536 149446025 8e85d89 vmlinux4_atomiclong_afterSigned-off-by: Denys Vlasenko
Cc: Ingo Molnar
Cc: Thomas Graf
Cc: Peter Zijlstra
Cc: David Rientjes
Cc: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The new helper returns index of the mathing string in an array. We
would use it here.Signed-off-by: Heikki Krogerus
Signed-off-by: Andy Shevchenko
Cc: Greg Kroah-Hartman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The new helper returns index of the mathing string in an array. We
would use it here.Signed-off-by: Andy Shevchenko
Cc: "David S. Miller"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The new helper returns index of the mathing string in an array. We
would use it here.Signed-off-by: Andy Shevchenko
Acked-by: Tejun Heo
Cc: Bartlomiej Zolnierkiewicz
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The new helper returns index of the mathing string in an array. We
would use it here.Signed-off-by: Andy Shevchenko
Acked-by: Linus Walleij
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The new helper returns index of the mathing string in an array. We
would use it here.Signed-off-by: Andy Shevchenko
Cc: Sebastian Reichel
Cc: Dmitry Eremin-Solenikov
Cc: David Woodhouse
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The new helper returns index of the mathing string in an array. We
would use it here.Signed-off-by: Andy Shevchenko
Cc: David Airlie
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The new helper returns index of the mathing string in an array. We
would use it here.Signed-off-by: Andy Shevchenko
Acked-by: Linus Walleij
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The new helper returns index of the mathing string in an array. We
would use it here.Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Acked-by: Rafael J. Wysocki
Cc: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Occasionally we have to search for an occurrence of a string in an array
of strings. Make a simple helper for that purpose.Signed-off-by: Andy Shevchenko
Cc: "David S. Miller"
Cc: Bartlomiej Zolnierkiewicz
Cc: David Airlie
Cc: David Woodhouse
Cc: Dmitry Eremin-Solenikov
Cc: Greg Kroah-Hartman
Cc: Heikki Krogerus
Cc: Linus Walleij
Cc: Mika Westerberg
Cc: Rafael J. Wysocki
Cc: Sebastian Reichel
Cc: Tejun Heo
Cc: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Without fix test crashes inside tagged iteration.
Signed-off-by: Konstantin Khlebnikov
Cc: Matthew Wilcox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
After calling radix_tree_iter_retry(), 'slot' will be set to NULL. This
can cause radix_tree_next_slot() to dereference the NULL pointer. Add
Konstantin Khlebnikov's test to the regression framework.Signed-off-by: Matthew Wilcox
Reported-by: Konstantin Khlebnikov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
shmem likes to occasionally drop the lock, schedule, then reacqire the
lock and continue with the iteration from the last place it left off.
This is currently done with a pretty ugly goto. Introduce
radix_tree_iter_next() and use it throughout shmem.c.[koct9i@gmail.com: fix bug in radix_tree_iter_next() for tagged iteration]
Signed-off-by: Matthew Wilcox
Cc: Hugh Dickins
Signed-off-by: Konstantin Khlebnikov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Instead of a 'goto restart', we can now use radix_tree_iter_retry() to
restart from our current position. This will make a difference when
there are more ways to happen across an indirect pointer. And it
eliminates some confusing gotos.[vbabka@suse.cz: remove now-obsolete-and-misleading comment]
Signed-off-by: Matthew Wilcox
Cc: Hugh Dickins
Cc: Konstantin Khlebnikov
Signed-off-by: Vlastimil Babka
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Even though this is a 'can't happen' situation, use the new
radix_tree_iter_retry() pattern to eliminate a goto.[akpm@linux-foundation.org: fix btrfs build]
Signed-off-by: Matthew Wilcox
Cc: Hugh Dickins
Cc: Konstantin Khlebnikov
Cc: Chris Mason
Cc: Josef Bacik
Cc: David Sterba
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This is debug code which is #if 0 out.
Signed-off-by: Matthew Wilcox
Cc: Johannes Weiner
Cc: Matthew Wilcox
Cc: "Kirill A. Shutemov"
Cc: Ross Zwisler
Cc: Hugh Dickins
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
With huge pages, it is convenient to have the radix tree be able to
return an entry that covers multiple indices. Previous attempts to deal
with the problem have involved inserting N duplicate entries, which is a
waste of memory and leads to problems trying to handle aliased tags, or
probing the tree multiple times to find alternative entries which might
cover the requested index.This approach inserts one canonical entry into the tree for a given
range of indices, and may also insert other entries in order to ensure
that lookups find the canonical entry.This solution only tolerates inserting powers of two that are greater
than the fanout of the tree. If we wish to expand the radix tree's
abilities to support large-ish pages that is less than the fanout at the
penultimate level of the tree, then we would need to add one more step
in lookup to ensure that any sibling nodes in the final level of the
tree are dereferenced and we return the canonical entry that they
reference.Signed-off-by: Matthew Wilcox
Cc: Johannes Weiner
Cc: Matthew Wilcox
Cc: "Kirill A. Shutemov"
Cc: Ross Zwisler
Cc: Hugh Dickins
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
When we introduce entries that can cover multiple indices, we will need
to stop in __radix_tree_create based on the shift, not the height.
Split out for ease of bisect.Signed-off-by: Matthew Wilcox
Cc: Johannes Weiner
Cc: Matthew Wilcox
Cc: "Kirill A. Shutemov"
Cc: Ross Zwisler
Cc: Hugh Dickins
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Set the 'indirect_ptr' bit on all the pointers to internal nodes, not
just on the root node. This enables the following patches to support
multi-order entries in the radix tree. This patch is split out for ease
of bisection.Signed-off-by: Matthew Wilcox
Cc: Johannes Weiner
Cc: Matthew Wilcox
Cc: "Kirill A. Shutemov"
Cc: Ross Zwisler
Cc: Hugh Dickins
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This code is mostly from Andrew Morton and Nick Piggin; tarball downloaded
from http://ozlabs.org/~akpm/rtth.tar.gz with sha1sum
0ce679db9ec047296b5d1ff7a1dfaa03a7bef1bdSome small modifications were necessary to the test harness to fix the
build with the current Linux source code.I also made minor modifications to automatically test the radix-tree.c
and radix-tree.h files that are in the current source tree, as opposed
to a copied and slightly modified version. I am sure more could be done
to tidy up the harness, as well as adding more tests.[koct9i@gmail.com: fix compilation]
Signed-off-by: Matthew Wilcox
Cc: Shuah Khan
Cc: Johannes Weiner
Cc: Matthew Wilcox
Cc: "Kirill A. Shutemov"
Cc: Ross Zwisler
Cc: Hugh Dickins
Signed-off-by: Konstantin Khlebnikov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The radix-tree header uses the __ffs() function, which is defined in
bitops.h. The current kernel headers implicitly include bitops.h, but
the userspace test harness does not.Signed-off-by: Matthew Wilcox
Cc: Johannes Weiner
Cc: Matthew Wilcox
Cc: "Kirill A. Shutemov"
Cc: Ross Zwisler
Cc: Hugh Dickins
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Christian Borntraeger reported that panic_on_warn doesn't have any
effect on s390.The panic_on_warn feature was introduced with 9e3961a09798 ("kernel: add
panic_on_warn"). However it did care only for the case when
WANT_WARN_ON_SLOWPATH is defined. This is turn is only the case for
architectures which do not have an own __WARN_TAINT defined.Other architectures which do have __WARN_TAINT defined call report_bug()
for warnings within lib/bug.c which does not call panic() in case
panic_on_warn is set.Let's simply enable the panic_on_warn feature by adding the same code
like it was added to warn_slowpath_common() in panic.c.This enables panic_on_warn also for arm64, parisc, powerpc, s390 and sh.
Signed-off-by: Heiko Carstens
Reported-by: Christian Borntraeger
Tested-by: Christian Borntraeger
Acked-by: Prarit Bhargava
Cc: Catalin Marinas
Cc: Will Deacon
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Tested-by: Michael Ellerman (powerpc)
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
hlist_bl_unhashed() and hlist_bl_empty() are all boolean functions, so
return bool instead of int.Signed-off-by: Chen Gang
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Benjamin Romer is no longer a maintainer for the Unisys s-Par driver,
presently in drivers/staging/unisys/.Signed-off-by: David Kershner
Cc: Greg KH
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This allows us to extract from the vmcore only the messages emitted
since the last time the ring buffer was cleared. We just have to make
sure its value is always up-to-date, when old messages are discarded to
free space in log_make_free_space() for example.Signed-off-by: Zeyu Zhao
Signed-off-by: Ivan Delalande
Cc: Kay Sievers
Cc: Neil Horman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
have_callable_console() must also test CON_ENABLED bit, not just
CON_ANYTIME. We may have disabled CON_ANYTIME console so printk can
wrongly assume that it's safe to call_console_drivers().Signed-off-by: Sergey Senozhatsky
Reviewed-by: Petr Mladek
Cc: Jan Kara
Cc: Tejun Heo
Cc: Kyle McMartin
Cc: Dave Jones
Cc: Calvin Owens
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
console_unlock() allows to cond_resched() if its caller has set
`console_may_schedule' to 1, since 8d91f8b15361 ("printk: do
cond_resched() between lines while outputting to consoles").The rules are:
-- console_lock() always sets `console_may_schedule' to 1
-- console_trylock() always sets `console_may_schedule' to 0However, console_trylock() callers (among them is printk()) do not
always call printk() from atomic contexts, and some of them can
cond_resched() in console_unlock(), so console_trylock() can set
`console_may_schedule' to 1 for such processes.For !CONFIG_PREEMPT_COUNT kernels, however, console_trylock() always
sets `console_may_schedule' to 0.It's possible to drop explicit preempt_disable()/preempt_enable() in
vprintk_emit(), because console_unlock() and console_trylock() are now
smart enough:
a) console_unlock() does not cond_resched() when it's unsafe
(console_trylock() takes care of that)
b) console_unlock() does can_use_console() check.Signed-off-by: Sergey Senozhatsky
Reviewed-by: Petr Mladek
Cc: Jan Kara
Cc: Tejun Heo
Cc: Kyle McMartin
Cc: Dave Jones
Cc: Calvin Owens
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
console_unlock() allows to cond_resched() if its caller has set
`console_may_schedule' to 1 (this functionality is present since
8d91f8b15361 ("printk: do cond_resched() between lines while outputting
to consoles").The rules are:
-- console_lock() always sets `console_may_schedule' to 1
-- console_trylock() always sets `console_may_schedule' to 0printk() calls console_unlock() with preemption desabled, which
basically can lead to RCU stalls, watchdog soft lockups, etc. if
something is simultaneously calling printk() frequent enough (IOW,
console_sem owner always has new data to send to console divers and
can't leave console_unlock() for a long time).printk()->console_trylock() callers do not necessarily execute in atomic
contexts, and some of them can cond_resched() in console_unlock().
console_trylock() can set `console_may_schedule' to 1 (allow
cond_resched() later in consoe_unlock()) when it's safe.This patch (of 3):
vprintk_emit() disables preemption around console_trylock_for_printk()
and console_unlock() calls for a strong reason -- can_use_console()
check. The thing is that vprintl_emit() can be called on a CPU that is
not fully brought up yet (!cpu_online()), which potentially can cause
problems if console driver wants to access per-cpu data. A console
driver can explicitly state that it's safe to call it from !online cpu
by setting CON_ANYTIME bit in console ->flags. That's why for
!cpu_online() can_use_console() iterates all the console to find out if
there is a CON_ANYTIME console, otherwise console_unlock() must be
avoided.can_use_console() ensures that console_unlock() call is safe in
vprintk_emit() only; console_lock() and console_trylock() are not
covered by this check. Even though call_console_drivers(), invoked from
console_cont_flush() and console_unlock(), tests `!cpu_online() &&
CON_ANYTIME' for_each_console(), it may be too late, which can result in
messages loss.Assume that we have 2 cpus -- CPU0 is online, CPU1 is !online, and no
CON_ANYTIME consoles available.CPU0 online CPU1 !online
console_trylock()
...
console_unlock()
console_cont_flush
spin_lock logbuf_lock
if (!cont.len) {
spin_unlock logbuf_lock
return
}
for (;;) {
vprintk_emit
spin_lock logbuf_lock
log_store
spin_unlock logbuf_lock
spin_lock logbuf_lock
!console_trylock_for_printk msg_print_text
return console_idx = log_next()
console_seq++
console_prev = msg->flags
spin_unlock logbuf_lockcall_console_drivers()
for_each_console(con) {
if (!cpu_online() &&
!(con->flags & CON_ANYTIME))
continue;
}
/*
* no message printed, we lost it
*/
vprintk_emit
spin_lock logbuf_lock
log_store
spin_unlock logbuf_lock
!console_trylock_for_printk
return
/*
* go to the beginning of the loop,
* find out there are new messages,
* lose it
*/
}console_trylock()/console_lock() call on CPU1 may come from cpu
notifiers registered on that CPU. Since notifiers are not getting
unregistered when CPU is going DOWN, all of the notifiers receive
notifications during CPU UP. For example, on my x86_64, I see around 50
notification sent from offline CPU to itself[swapper/2] from cpu:2 to:2 action:CPU_STARTING hotplug_hrtick
[swapper/2] from cpu:2 to:2 action:CPU_STARTING blk_mq_main_cpu_notify
[swapper/2] from cpu:2 to:2 action:CPU_STARTING blk_mq_queue_reinit_notify
[swapper/2] from cpu:2 to:2 action:CPU_STARTING console_cpu_notifywhile doing
echo 0 > /sys/devices/system/cpu/cpu2/online
echo 1 > /sys/devices/system/cpu/cpu2/onlineSo grabbing the console_sem lock while CPU is !online is possible,
in theory.This patch moves can_use_console() check out of
console_trylock_for_printk(). Instead it calls it in console_unlock(),
so now console_lock()/console_unlock() are also 'protected' by
can_use_console(). This also means that console_trylock_for_printk() is
not really needed anymore and can be removed.Signed-off-by: Sergey Senozhatsky
Reviewed-by: Petr Mladek
Cc: Jan Kara
Cc: Tejun Heo
Cc: Kyle McMartin
Cc: Dave Jones
Cc: Calvin Owens
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The v850 port was removed by commits f606ddf42fd4 and 07a887d399b8 in
2008. These #defines are not used in the current kernel.Signed-off-by: Rob Landley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
There are various email addresses for me throughout the kernel. Use the
one that will always be valid.Signed-off-by: Christoph Lameter
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This has hit me a couple of times already. I would be debugging code
and the system would simply hang and then reboot. Finally, I found that
the problem was caused by WARN_ON_ONCE() and friends.The macro WARN_ON_ONCE(condition) is defined as:
static bool __section(.data.unlikely) __warned;
int __ret_warn_once = !!(condition);if (unlikely(__ret_warn_once))
if (WARN_ON(!__warned))
__warned = true;unlikely(__ret_warn_once);
Which looks great and all. But what I have hit, is an issue when
WARN_ON() itself hits the same WARN_ON_ONCE() code. Because, the
variable __warned is not yet set. Then it too calls WARN_ON() and that
triggers the warning again. It keeps doing this until the stack is
overflowed and the system crashes.By setting __warned first before calling WARN_ON() makes the original
WARN_ON_ONCE() really only warn once, and not an infinite amount of
times if the WARN_ON() also triggers the warning.Signed-off-by: Steven Rostedt
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
arch/mn10300/kernel/fpu-nofpu.c:27:36: error: unknown type name 'elf_fpregset_t'
int dump_fpu(struct pt_regs *regs, elf_fpregset_t *fpreg)Reported-by: kbuild test robot
Cc: Josh Triplett
Cc: David Howells
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
CONFIG_BUG=n && CONFIG_GENERIC_BUG=y make no sense and things break:
In file included from include/linux/page-flags.h:9:0,
from kernel/bounds.c:9:
include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside parameter list
static inline int is_warning_bug(const struct bug_entry *bug)
^
include/linux/bug.h:91:47: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/bug.h: In function 'is_warning_bug':
>> include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type
return bug->flags & BUGFLAG_WARNING;Reported-by: kbuild test robot
Cc: Josh Triplett
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
On i686 PAE enabled machine the contiguous physical area could be large
and it can cause trimming down variables in below calculation in
read_vmcore() and mmap_vmcore():tsz = min_t(size_t, m->offset + m->size - *fpos, buflen);
That is, the types being used is like below on i686:
m->offset: unsigned long long int
m->size: unsigned long long int
*fpos: loff_t (long long int)
buflen: size_t (unsigned int)So casting (m->offset + m->size - *fpos) by size_t means truncating a
given value by 4GB.Suppose (m->offset + m->size - *fpos) being truncated to 0, buflen >0
then we will get tsz = 0. It is of course not an expected result.
Similarly we could also get other truncated values less than buflen.
Then the real size passed down is not correct any more.If (m->offset + m->size - *fpos) is above 4GB, read_vmcore or
mmap_vmcore use the min_t result with truncated values being compared to
buflen. Then, fpos proceeds with the wrong value so that we reach below
bugs:1) read_vmcore will refuse to continue so makedumpfile fails.
2) mmap_vmcore will trigger BUG_ON() in remap_pfn_range().Use unsigned long long in min_t instead so that the variables in are not
truncated.Signed-off-by: Baoquan He
Signed-off-by: Dave Young
Cc: HATAYAMA Daisuke
Cc: Vivek Goyal
Cc: Jianyu Zhan
Cc: Minfei Huang
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds